Document and Review Security Design in Development
Keep track of and check security choices throughout software development to ensure safety.
🏛️ Framework
ASD Information Security Manual (ISM)
🧭 Control effect
Proactive
🔐 Classifications
NC, OS, P, S, TS
🗓️ ISM last updated
May 2025
✏️ Control Stack last updated
19 Mar 2026
🎯 E8 maturity levels
N/A
Guideline
Guidelines for software developmentSecurity design decisions are documented and reviewed throughout the software development cycle.
Source: ASD Information Security Manual (ISM)
Plain language
This control is about making sure that any security choices made during software development are carefully recorded and regularly checked. If you neglect to do this, important security issues might be missed, leaving your software vulnerable to attacks or data breaches, which can be costly and damage your reputation.
Why it matters
Poor documentation and review of security design can hide vulnerabilities, leading to unmitigated risks and potential breaches during software operation.
Operational notes
Maintain security design artefacts (architecture, threat model, controls) and review them at key SDLC stages, recording decisions, rationale, and approvals when designs change.
Implementation tips
- Software developers should document every security decision made during development. They can do this by adding notes to a shared document or a dedicated section in their project management tool, ensuring it's updated soon after decisions are made.
- Project managers need to schedule regular meetings to review these security decisions with the development team. Set a recurring fortnightly meeting where developers present recent changes or choices they've made and discuss their security impacts with a broader review team.
- The IT security team should establish a checklist for reviewing documented security decisions. This checklist should include cross-referencing the decisions with best practices from the ACSC (Australian Cyber Security Centre) and ensuring they align with organisational security policies.
- System owners should regularly consult with an external security advisor for an independent review of the documented security decisions. Engaging a fresh set of eyes can help identify potential oversights or improvements that internal teams might miss.
-
Ask: the project manager to compile this information and present it in simple language to ensure transparent communication of risks and protections in place
Audit / evidence tips
-
Ask: the documented security decision log: Request access to the central repository or document where all security decisions are recorded
Good: shows consistent documentation with clear justification for each decision
-
Ask: evidence of external reviews: Request any reports or feedback from external security advisors
Good: will include detailed responses and documented follow-up actions
-
Good: checklist will cover all areas of potential risk and ensure thorough evaluation
-
Ask: the periodic summary reports sent to business owners
Good: summary should clarify risks and defences without technical jargon, making the implications clear for decision-makers
Cross-framework mappings
How ISM-2034 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 overlaps (1) | ||
| Annex A 8.27 | ISM-2034 requires security design decisions to be documented and reviewed throughout the software development cycle | |
| Related (1) | ||
| Annex A 8.25 | Annex A 8.25 requires organisations to define and apply rules for secure development over the SDLC | |