ASD ISM 1238 Incorporate threat modelling in software development
What it says
Threat modelling is used in support of the software development life cycle.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishUse threat modelling to identify potential risks when developing software.
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.
Free. Save your status, tasks and notes.
Why it matters
Without threat modelling in the SDLC, design flaws and missed attack paths can ship to production, increasing breach likelihood and cost.
How to implement
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.
Keep it running
Revisit the threat model at each major sprint/release and after architecture changes; update assets, trust boundaries, and mitigations.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The threat model document: Request the document that outlines identified threats and planned mitigations.
Look at
Its comprehensiveness and how regularly it is updated.
Good evidence
Is a detailed document showing regular updates with responses to each identified threat.
- Check 2 of 5What an auditor asks for
Ask for
Workshop minutes or notes: Request the summaries from any threat modelling workshops held.
Look at
Evidence of who attended, what was discussed, and the key outcomes.
Good evidence
Includes detailed minutes, action items, and follow-up actions.
- Check 3 of 5What an auditor asks for
Ask for
To see developer training records: Request records of any security training for developers that emphasised threat modelling.
Look at
Dates, content descriptions, and participant lists.
Good evidence
Includes regular, detailed training relevant to current security threats.
- Check 4 of 5What an auditor asks for
Ask for
A demonstration of threat modelling tools in use: Request a walkthrough of the tools used during threat modelling sessions.
Look at
How teams interact with these tools and how effectively they use them to find vulnerabilities.
Good evidence
Is a seamless demonstration showing active use of the tools.
- Check 5 of 5What an auditor asks for
Ask for
Incident review reports: Request any reports from past incidents that reviewed threat modelling effectiveness.
Look at
Instances where a lack of threat modelling led to issues.
Good evidence
Includes learning points and adjustments made following incidents.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which this control partially meets.
ISO/IEC 27001: 4 mappings
This control partially meets A.8.25.
Annex A 8.25 requires organisations to establish and apply rules for secure development of software and systems. ISM-1238 is one specific rule/practice within that lifecycle, requiring threat modelling to support secure development activities. Annex A 8.25 is broader because it covers the full set of SDL rules (e.g., requirements, coding, testing, release) beyond threat modelling alone.
This control partially meets A.8.27.
Annex A 8.27 requires documented secure architecture and engineering principles to be applied during information system development. ISM-1238 relates by mandating threat modelling to support the software development lifecycle, which is a key secure engineering practice used to derive and validate architectural security requirements. ISM-1238 is narrower because it specifies one technique, whereas Annex A 8.27 requires a broader set of principles and their application.
This control supports A.8.26.
ISM-1238 requires organisations to apply threat modelling in the SDLC to identify potential risks early in development. Annex A 8.26 requires identifying, specifying and approving information security requirements when developing or acquiring applications, and threat modelling is a common mechanism to discover and justify those requirements (e.g., authentication strength, input validation, logging). The difference is that Annex A 8.26 is about requirements governance and approval, while ISM-1238 is the analysis technique that feeds requirements.
This control depends on A.8.29.
ISM-1238 requires threat modelling during the SDLC to identify potential risks and likely attack paths. Annex A 8.29 requires security testing processes to be defined and implemented in the development life cycle, and threat models are commonly used to derive and prioritise security test cases (e.g., abuse-case testing) and acceptance criteria. The key difference is that ISM-1238 is about analytical risk identification, while Annex A 8.29 is about executing and governing testing activities.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.