Incorporate Threat Modelling in Software Development
Use threat modelling to identify potential risks when developing software.
🏛️ Framework
ASD Information Security Manual (ISM)
🧭 Control effect
Proactive
🔐 Classifications
NC, OS, P, S, TS
🗓️ ISM last updated
May 2025
✏️ Control Stack last updated
22 Feb 2026
🎯 E8 maturity levels
N/A
Guideline
Guidelines for software developmentThreat modelling is used in support of the software development life cycle.
Source: ASD Information Security Manual (ISM)
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.
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
-
Ask: the threat model document: Request the document that outlines identified threats and planned mitigations
Good: is a detailed document showing regular updates with responses to each identified threat
-
Ask: workshop minutes or notes: Request the summaries from any threat modelling workshops held
Good: includes detailed minutes, action items, and follow-up actions
-
Ask: to see developer training records: Request records of any security training for developers that emphasised threat modelling
Good: includes regular, detailed training relevant to current security threats
-
Ask: a demonstration of threat modelling tools in use: Request a walkthrough of the tools used during threat modelling sessions
Good: is a seamless demonstration showing active use of the tools
-
Ask: incident review reports: Request any reports from past incidents that reviewed threat modelling effectiveness
Good: includes learning points and adjustments made following incidents
Cross-framework mappings
How ISM-1238 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| Supports (3) | ||
| 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 | |
| Related (2) | ||
| 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 | |