Implement Secure by Design in Software Development
Follow Secure by Design practices throughout software development to ensure security.
Plain language
Implementing Secure by Design means thinking about security at every step of building software. It's like putting locks on doors and windows when building a house, rather than waiting for a break-in to happen. This matters because if we ignore security early on, we might end up with software that's easy for hackers to break into, causing data theft or service disruptions.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
May 2025
Control Stack last updated
19 May 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentOfficial control statement
Secure by Design principles and practices are followed throughout the software development life cycle.
Why it matters
Without Secure by Design across the SDLC, design and code flaws persist and are exploited, causing breaches and outages.
Operational notes
Integrate threat modelling, secure coding standards, code review and security testing into each sprint and CI/CD so controls evolve with changes.
Implementation tips
- The project manager should ensure security is included in the planning stage. This can be done by starting each project with a security checklist based on Australian Signals Directorate (ASD) guidelines. It helps to clearly outline who is responsible for each security aspect from the beginning.
- The software development team should integrate security features as they write code. This means using coding standards that prevent common vulnerabilities and regularly reviewing code for security issues. A simple way to start is to use tools that automatically check the code for known weaknesses during development.
- The IT team should conduct regular security training sessions for developers. These sessions can help the team stay updated on the latest security threats and practices. Providing real-world examples during training can make it relevant and engaging.
- The quality assurance team should test security features as part of their regular testing process. They should focus not just on functionality but also on how secure the software is. Running simulated attacks or using penetration testing tools can identify vulnerabilities before launch.
Audit / evidence tips
- AskThe project security plan: Request the document outlining the initial security considerations for the software project GoodIncludes clearly defined responsible personnel and security goals
- GoodResult shows regular training dates and topics that are up-to-date with current threats
- AskThe checklist of Secure by Design practices: Check the list to ensure it covers comprehensive security measures and that entries are ticked off as completed during development. A thorough checklist should cover coding practices, threat modelling, and regular reviews
- GoodLog includes entries of what was checked, potential issues found, and how they were resolved
- AskThem how they incorporate security testing into their testing procedures GoodIncludes details about using specific security testing tools and simulating attacks to probe for system weaknesses
Cross-framework mappings
How ISM-0401 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (1) expand_less | ||
| Annex A 8.29 | Annex A 8.29 requires organisations to define and implement security testing processes within the development and acceptance life cycle | |
| sync_alt Partially overlaps (1) expand_less | ||
| Annex A 8.30 | ISM-0401 requires embedding Secure by Design into both internal and outsourced SDLC processes | |
| link Related (3) expand_less | ||
| Annex A 8.25 | ISM-0401 requires Secure by Design principles to be followed throughout the SDLC | |
| Annex A 8.27 | ISM-0401 encompasses Secure by Design from design to operational transition | |
| Annex A 8.28 | ISM-0401 demands Secure by Design practices across the entire SDLC, covering stages like design, build, test, and release | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.