ASD ISM 2034 Document and review security design in development
What it says
Security design decisions are documented and reviewed throughout the software development cycle.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishKeep track of and check security choices throughout software development to ensure safety.
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.
Free. Save your status, tasks and notes.
Why it matters
Poor documentation and review of security design can hide vulnerabilities, leading to unmitigated risks and potential breaches during software operation.
How to implement
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.
Keep it running
Maintain security design artefacts (architecture, threat model, controls) and review them at key SDLC stages, recording decisions, rationale, and approvals when designs change.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The documented security decision log: Request access to the central repository or document where all security decisions are recorded.
Look at
The frequency of updates and whether decisions are aligned with business objectives.
Good evidence
Shows consistent documentation with clear justification for each decision.
- Check 2 of 5What an auditor asks for
Look at
Detailed discussions addressing potential risks and agreed actions. Good minutes include specific attendees, discussions, and outcomes.
- Check 3 of 5What an auditor asks for
Ask for
Evidence of external reviews: Request any reports or feedback from external security advisors.
Look at
The advisor's comments and recommended actions to see if they are being addressed.
Good evidence
Will include detailed responses and documented follow-up actions.
- Check 4 of 5What an auditor asks for
Good evidence
Checklist will cover all areas of potential risk and ensure thorough evaluation.
- Check 5 of 5What an auditor asks for
Ask for
The periodic summary reports sent to business owners.
Look at
How well these reports explain the security decisions in layman's terms.
Good evidence
Summary should clarify risks and defences without technical jargon, making the implications clear for decision-makers.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.25.
Annex A 8.25 requires organisations to define and apply rules for secure development over the SDLC. ISM-2034 requires documenting and reviewing security design decisions throughout development, which is a specific lifecycle rule supporting secure architecture and traceability. Annex A 8.25 is broader because it encompasses security requirements, implementation, verification, release and maintenance rules in addition to design decision management.
This control partially overlaps A.8.27.
ISM-2034 requires security design decisions to be documented and reviewed throughout the software development cycle. Annex A 8.27 requires secure system architecture and engineering principles to be established, documented, maintained and applied to development activities, which overlaps with ISM-2034 where those principles drive and shape design decisions that must be recorded and reviewed. Annex A 8.27 is focused on defining and applying architectural principles, while ISM-2034 is focused on the traceability and review of the resulting design decisions over time.
ISO/IEC 42001: 2 mappings
This control partially overlaps A.6.2.2.
Both Annex A 6.2.2 and ISM-2034 require maintained documentation, with the former focusing on AI system specifications and the latter on security design decisions. They overlap where design decisions trace back to documented AI requirements.
This control partially overlaps A.6.2.3.
Annex A 6.2.3 requires organisations to document AI system design and development with traceability to requirements, while ISM-2034 requires documenting and reviewing security design decisions during development. This overlap highlights common requirements for documenting design decisions, albeit with Annex A 6.2.3 having a broader scope.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.