Ensuring Security in Software Development Lifecycle
Security features must be included and enabled in software from the start, at no extra cost to users.
🏛️ Framework
ASD Information Security Manual (ISM)
🧭 Control effect
Preventative
🔐 Classifications
NC, OS, P, S, TS
🗓️ ISM last updated
May 2025
✏️ Control Stack last updated
22 Feb 2026
🎯 E8 maturity levels
N/A
Guideline
Guidelines for software developmentSecure by Default principles and practices are followed throughout the software development life cycle, including by ensuring that all built-in security measures are included and enabled in the base product at no extra cost to consumers.
Source: ASD Information Security Manual (ISM)
Plain language
This control is about building security features into software from the very beginning. It’s like having a safety lock on a new car model, rather than asking buyers to pay extra for it later. If you don’t do this, users might end up exposed to hackers because the software lacks essential protections from the start.
Why it matters
If security features are not built-in and enabled by default, organisations face higher breach risk, compliance exposure, and costly post-release retrofits or paid add-ons.
Operational notes
For all releases, verify baseline security controls are built-in and enabled by default in the base product (not paid add-ons); enforce via SDLC checklists and release gates.
Implementation tips
- Software developers should design security features into the basic software framework. They can start by making a list of potential risks and ensuring security elements like passwords or encryption are part of the initial coding. This prevents vulnerabilities before the software is even finished.
- Project managers should ensure security requirements are clearly included in the project specifications. They can do this by working with security experts to define what 'secure by default' means for their product, ensuring these requirements are part of the project plan and budgeted accordingly.
- The IT team should regularly review software updates to ensure security features remain effective. They should schedule periodic assessments of the software to look for any vulnerabilities that need addressing, using updates to apply fixes as needed.
- Quality assurance (QA) teams should include security tests in their routine checks. They should develop tests that simulate attacks to see if the security features in the software are working properly and without extra cost to users.
- Procurement staff should include 'secure by default' requirements in purchasing criteria for software. When evaluating new products, they should look for documentation that shows how the software addresses security from the ground up.
Audit / evidence tips
-
Ask: the project specification document: Examine it to see if security features are included from the start
Good: document will list specific security measures as integral parts of the software design, not optional extras
-
Ask: regular security testing reports
-
Ask: procurement criteria documentation when buying software: Check if it includes requirements for built-in security features. A robust document will show 'secure by default' as a key purchasing criterion
-
Ask: training or guidance materials provided to staff: Check if they include instructions on using all security features. Effective materials will explain these built-in protections in simple terms
Cross-framework mappings
How ISM-2042 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| Partially meets (1) | ||
| Annex A 8.29 | Annex A 8.29 mandates defining and implementing security testing processes throughout development and acceptance | |
| Partially overlaps (3) | ||
| Annex A 8.25 | Annex A 8.25 requires organisations to establish and apply rules for secure development across the software and system lifecycle | |
| Annex A 8.27 | Annex A 8.27 requires organisations to define and apply secure architecture and engineering principles across system development | |
| Annex A 8.28 | Annex A 8.28 requires applying secure coding principles to reduce software vulnerabilities | |