ASD ISM 2039 Review threat model during software development
What it says
The software threat model is reviewed throughout the software development life cycle to ensure it reflects the as-built software and any changes to the threat environment.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishRegularly update the software threat model to match current and changing threats.
This control is about regularly reviewing your software's threat model during its development to ensure it stays current with any changes to the threats it faces. If this isn't done, your software might be vulnerable to new security risks that could lead to data breaches, financial losses, or harm to your organisation's reputation.
Free. Save your status, tasks and notes.
Why it matters
Failure to regularly update the threat model can miss new attack paths, leaving as-built software vulnerable to exploitation as requirements and threats change.
How to implement
The project manager should organise regular review sessions: During each phase of software development, arrange meetings with the development team and security experts to review and update the threat model.
Ensure these sessions are scheduled as part of the project's timeline.
Software developers should document changes: As updates or changes are made to the software, developers should note these modifications and evaluate how they affect the threat landscape.
This documentation will provide valuable insights during threat model reviews.
Security officers should assess new risks: Introduce any identified new threats or vulnerabilities into the threat model.
Use simulations or scenarios to determine how these threats could potentially impact the software.
The IT team should collaborate with external experts: Engage with cyber security specialists or use external threat intelligence to gain insights into emerging threats.
This will enhance the depth of your threat model and help prepare for unforeseen risks.
Team leaders should ensure communication: Foster open communication between developers, managers, and security experts.
Encourage team members to raise any security concerns immediately, and integrate their feedback into the threat model promptly.
Keep it running
Review and update the threat model at each SDLC phase gate and after significant design, dependency, or deployment changes so it matches the as-built system and current threats.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The updated threat model documentation: Request copies of the threat model used throughout the software's lifecycle.
Look at
How often it's been updated and if it includes recent threat assessments.
Good evidence
Shows regular updates aligned with software changes and threat insights.
- Check 2 of 5What an auditor asks for
Ask for
Meeting records that cover threat model reviews: Request minutes from meetings focused on threat model updates.
Look at
The meeting frequency, topics discussed, and attendees.
Good evidence
Includes regular discussions involving both technical and security representatives.
- Check 3 of 5What an auditor asks for
Ask for
Records of documented software changes: Request logs of software modifications during its development.
Look at
How these changes are reflected in the threat model updates.
Good evidence
Features thorough documentation and analysis of how changes impact security.
- Check 4 of 5What an auditor asks for
Ask for
To see third-party security assessments or consultations: Request reports from any external security reviews or consultations.
Look at
Their integration and influence on the threat model.
Good evidence
Includes detailed reports with actionable insights applied to your security posture.
- Check 5 of 5What an auditor asks for
Ask for
Communication logs between teams about security concerns: Request examples of communications related to identified threats or security issues.
Look at
Clear, timely, and responsive measures taken.
Good evidence
Highlights proactive engagement and effective problem solving.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which this control partially meets.
ISO/IEC 27001: 5 mappings
This control partially meets A.8.25.
ISM-2039 requires the software threat model to be reviewed throughout the SDLC to ensure it reflects the as-built software and changes to the threat environment. ISO/IEC 27001:2022 Annex A 8.25 requires organisations to establish and apply rules for a secure development lifecycle, within which ongoing threat modelling review is a common required practice. The ISO control is broader because it covers the whole set of secure-SDLC rules (e.g., governance, roles, practices), while ISM-2039 focuses specifically on continuous threat model review.
This control partially meets A.8.27.
ISM-2039 requires the software threat model to be reviewed throughout the SDLC to keep pace with design/implementation changes and the evolving threat environment. ISO/IEC 27001:2022 Annex A 8.27 requires secure system architecture and engineering principles to be established and maintained, and threat modelling review is a mechanism to validate those principles against current threats as the design evolves. Annex A 8.27 is broader because it addresses overall engineering principles and architecture governance beyond the specific activity of reviewing a threat model.
This control depends on A.5.7.
Annex A 5.7 requires collection and analysis of threat information to produce threat intelligence. ISM-2039 supports this by requiring the software threat model to be reviewed through the SDLC to reflect changes to the threat environment, which typically relies on current threat intelligence inputs. ISM-2039 is limited to application/system threat modelling, whereas Annex A 5.7 is organisation-wide and includes establishing processes for ongoing threat intelligence production.
This control depends on A.8.26.
ISM-2039 requires the software threat model to be reviewed throughout the SDLC to ensure it remains aligned to the as-built system and threat environment. ISO/IEC 27001:2022 Annex A 8.26 requires security requirements for applications to be identified, specified and approved, and ongoing threat model review helps validate that requirements remain sufficient and drives updates when new threats or design changes emerge. The ISO control is centred on requirements definition/approval, while ISM-2039 is centred on continuous threat-driven validation and update during build and change.
This control depends on A.8.29.
ISM-2039 requires reviewing the threat model throughout development so identified threats and assumptions remain accurate as the software is built and changed. ISO/IEC 27001:2022 Annex A 8.29 requires security testing processes to be defined and implemented in the development life cycle, and an up-to-date threat model directly informs what to test, when to retest, and which abuse cases to prioritise. Annex A 8.29 is about executing testing activities, whereas ISM-2039 is about maintaining the threat model that guides and justifies those tests.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.