ASD ISM 2033 Document and maintain software security requirements
What it says
All software security requirements are documented, stored securely and maintained throughout the software development life cycle.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure software security needs are documented and securely kept throughout all development stages.
This control is about making sure that the security needs of your software are carefully documented and kept safe throughout its development. If these requirements are not properly handled, there's a risk that security weaknesses could be overlooked, leading to data breaches or other security incidents.
Free. Save your status, tasks and notes.
Why it matters
Neglecting documented security requirements can lead to missed vulnerabilities, with potential exposure to data breaches or unauthorised access.
How to implement
System owners should ensure that a comprehensive list of security requirements is created at the start of a project.
This can be done by working closely with IT security specialists to understand potential risks and document the necessary protections for the software.
IT teams should establish a secure location for storing the documented security requirements.
This can involve setting up a password-protected folder on the internal network that only authorised team members can access.
Project managers should regularly update the security requirements document throughout the software's development life cycle.
They can do this by scheduling periodic review meetings with the development and IT teams to ensure the document reflects any changes or new threats.
Managers should ensure that staff involved in software development understand the importance of maintaining these security documents.
This could involve training sessions on how to recognise when updates are needed and the potential impact of outdated security requirements.
QA teams should integrate a checklist of security requirements into their testing processes.
This means that during every testing phase, the team verifies that all documented security needs are being met before the software moves to the next stage.
Keep it running
Regularly review and update documented security needs as the software evolves to address emerging threats and changes in context.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The initial software security requirements document: Request to see the list of security needs created for the project.
Look at
How specific the requirements are and whether they address identified risks.
Good evidence
Includes a comprehensive list that clearly outlines each security need with reasoning.
- Check 2 of 5What an auditor asks for
Ask for
Records of updates to the security requirements: Request evidence of how the requirements document was changed over the project's life.
Look at
The frequency and context of updates.
Good evidence
Shows a living document with regular and relevant updates recorded.
- Check 3 of 5What an auditor asks for
Ask for
To see the access logs for the secure storage location of the requirements: Request access history for where the document is stored.
Look at
Evidence of authorised access and any anomalies.
Good evidence
Reveals only relevant personnel access the document.
- Check 4 of 5What an auditor asks for
Ask for
The QA team for their security compliance checklist: Request the checklist used during software testing.
Look at
Items related to the specific documented requirements.
Good evidence
Is a detailed checklist that includes all the necessary security validations.
- Check 5 of 5What an auditor asks for
Ask for
The project manager for meeting notes or minutes from security review sessions: Request records from regular security review discussions.
Look at
The engagement level and topics covered, ensuring they relate to updating security requirements.
Good evidence
Evidences thoughtful discussion around maintaining security integrity.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which this control covers in full and more.
ISO/IEC 27001: 6 mappings
This control is broader than A.8.25.
ISM-2033 requires software security requirements to be documented, stored securely, and maintained throughout the SDLC. This is a specific element of Annex A 8.25, which requires the organisation to establish and apply rules for secure development more broadly (e.g. roles, processes, secure design, build, review and release practices). In other words, ISM-2033 is one concrete SDLC rule about requirements artefact management, whereas Annex A 8.25 covers the full secure SDLC governance set.
This control partially meets A.5.8.
Annex A 5.8 requires information security to be integrated into project management so security is considered and checked throughout project delivery. ISM-2033 relates by mandating that software security requirements are documented, stored securely and maintained across the SDLC, which is a concrete project/engineering activity that should be embedded in project governance. Annex A 5.8 is broader because it applies to all project types and security integration activities, not only software security requirements management.
This control partially overlaps A.8.26.
Annex A 8.26 requires information security requirements to be identified, specified and approved when developing or acquiring applications. ISM-2033 directly relates by requiring software security requirements to be documented, stored securely and maintained across the SDLC, which is a key mechanism for specifying and controlling those requirements. ISM-2033 emphasises documentation, secure storage and ongoing maintenance, while Annex A 8.26 additionally stresses up-front identification and formal approval, including for acquisition scenarios.
This control partially overlaps A.8.27.
ISM-2033 requires software security requirements to be documented, stored securely, and maintained throughout the SDLC. This overlaps with Annex A 8.27 because documented and maintained secure engineering principles are commonly used to derive, refine, and keep security requirements consistent across design and build activities. Annex A 8.27 is about establishing and applying engineering principles, while ISM-2033 is about the lifecycle control of the resulting software security requirements artefacts.
This control partially overlaps A.8.30.
ISM-2033 requires software security requirements to be documented, stored securely, and maintained throughout the SDLC. This overlaps with Annex A 8.30 because directing and reviewing outsourced development commonly includes ensuring security requirements are captured, controlled, versioned, and kept current between the organisation and supplier. Annex A 8.30 is specifically about governance of the supplier's development activities, while ISM-2033 applies regardless of whether development is in-house or outsourced and focuses on the requirements artefacts themselves.
This control supports A.8.29.
Annex A 8.29 stipulates defining and executing security testing processes within the SDLC. ISM-2033 focuses on maintaining detailed software security requirements that inform testing criteria. While Annex A 8.29 handles the practical testing execution, ISM-2033 reinforces it via robust requirements management.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.