Document and Review Security Design in Development
Keep track of and check security choices throughout software development to ensure safety.
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.
Framework
ASD Information Security Manual (ISM)
Control effect
Proactive
Classifications
NC, OS, P, S, TS
ISM last updated
June 2025
Control Stack last updated
18 June 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentOfficial control statement
Security design decisions are documented and reviewed throughout the software development cycle.
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.
Audit / evidence tips
- AskThe documented security decision log: Request access to the central repository or document where all security decisions are recordedGoodShows consistent documentation with clear justification for each decision
- AskEvidence of external reviews: Request any reports or feedback from external security advisorsGoodWill include detailed responses and documented follow-up actions
- GoodChecklist will cover all areas of potential risk and ensure thorough evaluation
- AskThe periodic summary reports sent to business ownersGoodSummary 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, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(1)expand_less | ||
| Annex A 8.27 | ISM-2034 requires security design decisions to be documented and reviewed throughout the software development cycle | |
linkRelated(1)expand_less | ||
| Annex A 8.25 | Annex A 8.25 requires organisations to define and apply rules for secure development over the SDLC | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in Software development
See all Guidelines for software development controls, or browse the full ASD ISM library.