Review Threat Model During Software Development
Regularly update the software threat model to match current and changing threats.
Plain language
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.
Framework
ASD Information Security Manual (ISM)
Control effect
Proactive
Classifications
NC, OS, P, S, TS
ISM last updated
May 2025
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentOfficial control statement
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.
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.
Operational notes
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.
Implementation tips
- 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.
Audit / evidence tips
- AskThe updated threat model documentation: Request copies of the threat model used throughout the software’s lifecycle GoodShows regular updates aligned with software changes and threat insights
- AskMeeting records that cover threat model reviews: Request minutes from meetings focused on threat model updates GoodIncludes regular discussions involving both technical and security representatives
- AskRecords of documented software changes: Request logs of software modifications during its development GoodFeatures thorough documentation and analysis of how changes impact security
- AskTo see third-party security assessments or consultations: Request reports from any external security reviews or consultations GoodIncludes detailed reports with actionable insights applied to your security posture
- AskCommunication logs between teams about security concerns: Request examples of communications related to identified threats or security issues GoodHighlights proactive engagement and effective problem solving
Cross-framework mappings
How ISM-2039 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (2) expand_less | ||
| Annex 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... | |
| Annex 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 ev... | |
| handshake Supports (4) expand_less | ||
| Annex A 5.7 | Annex A 5.7 requires collection and analysis of threat information to produce threat intelligence | |
| Annex 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 th... | |
| Annex A 8.29 | ISM-2039 requires reviewing the threat model throughout development so identified threats and assumptions remain accurate as the software... | |
| Annex A 8.30 | ISM-2039 requires continuous review of the software threat model across the SDLC so the model matches the as-built system and current thr... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.