Approve Security Architecture Before System Development
Ensure system security plans are approved before starting system development.
Plain language
Before starting on system development, it's important to get approval for the system's security plans. This ensures that security is built into the system right from the start, reducing the risk of data breaches or cyber attacks that could cost you money and harm your reputation.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Feb 2022
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Official control statement
A system's security architecture is approved prior to the development of the system.
Why it matters
If security architecture isn’t approved before development, insecure design choices may be built in, causing rework, delays and exploitable vulnerabilities.
Operational notes
Require documented security architecture approval (e.g., design review sign-off) before build starts and before major changes or new development phases proceed.
Implementation tips
- System owners should draft the security architecture document. They should include all major security measures planned for the new system. Get input from IT experts and document how these measures will protect against potential cyber threats.
- Managers should organise a review meeting with key stakeholders. Key stakeholders include the system owner, IT team, and the person who will sign off on the project. During this meeting, confirm that the security plans cover all necessary areas and align with business needs.
- IT teams should conduct a risk assessment for the new system. Identify potential vulnerabilities and ensure that the architecture addresses these risks. Document the risk assessment and incorporate the outcomes into the security architecture.
- The person responsible for authorising the system should review the final security architecture document. They should ensure it aligns with organisational policies and standards. Authorisation should be formalised in writing, marking the document with an approval signature and date.
- Procurement should ensure that any software or tools being acquired for the system meet the approved security architecture requirements. Work closely with the IT team to verify compatibility and compliance with the approved security parameters.
Audit / evidence tips
- AskThe security architecture document that was approved before development GoodDocument includes explicit approval with a signature and date from the authorised person
- AskMeeting records or minutes from the approval process GoodRecord shows active participation and agreement on the security plans
- AskThe risk assessment report conducted during the development phase GoodReport is thorough and shows a clear link between risks and security measures
- AskEvidence of any communications between procurement and IT regarding security requirements for new tools GoodRecord includes emails, memos, or meeting notes confirming these discussions
- AskA copy of the organisational security policy that the architecture aligns with GoodIs a clear, dated policy document that supports what's outlined in the architecture
Cross-framework mappings
How ISM-1739 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| sync_alt Partially overlaps (2) expand_less | ||
| Annex A 8.26 | ISM-1739 requires the security architecture for a system to be approved before the system is developed | |
| Annex A 8.27 | ISM-1739 requires a system’s security architecture to be approved prior to development | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.