ASD ISM 1739 Approve security architecture before system development
What it says
A system's security architecture is approved prior to the development of the system.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure system security plans are approved before starting system development.
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.
Free. Save your status, tasks and notes.
Why it matters
If security architecture isn't approved before development, insecure design choices may be built in, causing rework, delays and exploitable vulnerabilities.
How to implement
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.
Keep it running
Require documented security architecture approval (e.g., design review sign-off) before build starts and before major changes or new development phases proceed.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The security architecture document that was approved before development.
Look at
Detailed descriptions of security measures and risk mitigation strategies.
Good evidence
Document includes explicit approval with a signature and date from the authorised person.
- Check 2 of 5What an auditor asks for
Ask for
Meeting records or minutes from the approval process.
Look at
The attendee list and ensure that the authorising officer and IT representatives were present.
Good evidence
Record shows active participation and agreement on the security plans.
- Check 3 of 5What an auditor asks for
Ask for
The risk assessment report conducted during the development phase.
Look at
Identified risks and how these are addressed in the security architecture.
Good evidence
Report is thorough and shows a clear link between risks and security measures.
- Check 4 of 5What an auditor asks for
Ask for
Evidence of any communications between procurement and IT regarding security requirements for new tools.
Look at
Clear discussions on compliance with the security architecture.
Good evidence
Record includes emails, memos, or meeting notes confirming these discussions.
- Check 5 of 5What an auditor asks for
Ask for
A copy of the organisational security policy that the architecture aligns with.
Look at
Sections that the security architecture refers to, ensuring they match.
Good evidence
Is a clear, dated policy document that supports what's outlined in the architecture.
Mappings
Closest match in ISO/IEC 27001: A.8.26, Defining security requirements for applications, which partially overlaps with this control.
ISO/IEC 27001: 2 mappings
This control partially overlaps A.8.26.
ISM-1739 requires the security architecture for a system to be approved before the system is developed. ISO/IEC 27001:2022 Annex A 8.26 requires security requirements to be identified, specified, and approved when developing or acquiring applications, which is typically a key input to the security architecture that ISM-1739 seeks to have approved. Annex A 8.26 is broader as it covers application requirements approval (including acquisition), whereas ISM-1739 is an architecture approval gate for the system prior to development.
This control partially overlaps A.8.27.
ISM-1739 requires a system's security architecture to be approved prior to development. ISO/IEC 27001:2022 Annex A 8.27 requires establishing, maintaining, and applying secure architecture and engineering principles to development activities, directly informing what an approvable security architecture should encompass. Annex A 8.27 is broader as it concerns principles across developments, whereas ISM-1739 is specifically an approval requirement for a particular system's architecture before build starts.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.