ASD ISM 2042 Ensuring security in software development lifecycle
What it says
Secure 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.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSecurity features must be included and enabled in software from the start, at no extra cost to users.
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.
Free. Save your status, tasks and notes.
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.
How to implement
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.
Keep it running
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.
Evidence and audit
- Check 1 of 4What an auditor asks for
Ask for
The project specification document: Examine it to see if security features are included from the start.
Good evidence
Document will list specific security measures as integral parts of the software design, not optional extras.
- Check 2 of 4What an auditor asks for
Ask for
Regular security testing reports.
Look at
The frequency and thoroughness of these tests. Good practice is shown by consistent testing intervals and detailed records of what was tested and the outcomes.
- Check 3 of 4What an auditor asks for
Ask for
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.
- Check 4 of 4What an auditor asks for
Ask for
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.
Mappings
Closest match in ISO/IEC 27001: A.8.29, Security testing in development and acceptance, which this control covers in full and more.
ISO/IEC 27001: 4 mappings
This control is broader than A.8.29.
Annex A 8.29 mandates defining and implementing security testing processes throughout development and acceptance. ISM-2042 enforces Secure by Default principles across the SDLC, often verified by testing. This widens its scope beyond testing to include default security settings, while Annex A 8.29 narrows down to the procedural aspects of security testing.
This control partially overlaps A.8.25.
Annex A 8.25 requires organisations to establish and apply secure development lifecycle rules. ISM-2042 mandates Secure by Default practices throughout the SDLC, including enabling built-in security measures in the base product. They overlap on embedding security rules into development, but ISM-2042 is specifically about default configurations/product posture, while Annex A 8.25 covers a wider set of SDLC controls beyond defaults.
This control partially overlaps A.8.27.
Annex A 8.27 requires organisations to define and apply secure architecture and engineering principles across system development. ISM-2042 overlaps by requiring Secure by Default practices throughout the software development lifecycle, which is a concrete expression of secure engineering principles. ISM-2042 is more SDLC- and product-configuration oriented, while Annex A 8.27 also encompasses system-level architecture principles beyond software defaults.
This control partially overlaps A.8.28.
Annex A 8.28 requires applying secure coding principles to reduce software vulnerabilities. ISM-2042 overlaps by mandating Secure by Default across the SDLC, including ensuring built-in security measures are included and enabled by default, which often depends on secure coding. ISM-2042 additionally emphasises default configuration and productised security features, which Annex A 8.28 does not explicitly address.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.