Incorporate Threat Modelling in Software Development
Use threat modelling to identify potential risks when developing software.
Plain language
When developing software, it's important to think about how hackers might try to break in or cause harm. By doing this 'threat modelling', you can spot potential risks early and make your software safer. If you skip this step, you risk creating software that could easily be exploited by cybercriminals, leading to data breaches, financial loss, or damage to your 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
Threat modelling is used in support of the software development life cycle.
Why it matters
Without threat modelling in the SDLC, design flaws and missed attack paths can ship to production, increasing breach likelihood and cost.
Operational notes
Revisit the threat model at each major sprint/release and after architecture changes; update assets, trust boundaries, and mitigations.
Implementation tips
- Software developers should map out potential threats: During the planning stage, developers need to brainstorm possible threats to the software. Start by outlining all the ways people might use the software and consider how it could be attacked or misused.
- Project managers should organise threat modelling workshops: Gather your team for a workshop where everyone, from developers to managers, discusses the potential ways your software could be attacked. Use scenarios based on past incidents or industry examples to guide the conversation.
- IT security consultants should guide the process: Bring in a security expert to lead the threat modelling process. They can provide insights on common vulnerabilities and strategies to mitigate them, making it more robust.
- Teams should document their findings and actions: After identifying threats, record each one along with the strategies you'll use to address them. Ensure this document is kept updated and referenced throughout the software development life cycle.
- Businesses should integrate threat modelling tools: Use software tools that assist in threat modelling, such as those that help visualize potential attack paths. Familiarise your developers with these tools to enhance their understanding of possible threats.
Audit / evidence tips
- AskThe threat model document: Request the document that outlines identified threats and planned mitigations GoodIs a detailed document showing regular updates with responses to each identified threat
- AskWorkshop minutes or notes: Request the summaries from any threat modelling workshops held GoodIncludes detailed minutes, action items, and follow-up actions
- AskTo see developer training records: Request records of any security training for developers that emphasised threat modelling GoodIncludes regular, detailed training relevant to current security threats
- AskA demonstration of threat modelling tools in use: Request a walkthrough of the tools used during threat modelling sessions GoodIs a seamless demonstration showing active use of the tools
- AskIncident review reports: Request any reports from past incidents that reviewed threat modelling effectiveness GoodIncludes learning points and adjustments made following incidents
Cross-framework mappings
How ISM-1238 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| handshake Supports (3) expand_less | ||
| Annex A 8.26 | ISM-1238 requires organisations to apply threat modelling in the SDLC to identify potential risks early in development | |
| Annex A 8.28 | Annex A 8.28 requires secure coding principles to be applied to software development | |
| Annex A 8.29 | ISM-1238 requires threat modelling during the SDLC to identify potential risks and likely attack paths | |
| link Related (2) expand_less | ||
| Annex A 8.25 | Annex A 8.25 requires organisations to establish and apply rules for secure development of software and systems | |
| Annex A 8.27 | Annex A 8.27 requires documented secure architecture and engineering principles to be applied during information system development | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.