If you look at the major security frameworks, you might notice something frustrating. Most of them don’t actually use the words "threat modeling." Because of that, teams often skip it, thinking it’s an optional "nice-to-have" engineering exercise.
That's a dangerous assumption.
Even when a standard doesn't explicitly mandate threat modeling, it almost always requires the results that only threat modeling can provide. Let’s look at where it’s required, where it’s hidden, and how to use it to satisfy your auditors.
Why most frameworks don't mandate "Threat Modeling"
It might seem weird that major security frameworks don't just come out and say "Thou Shalt Threat Model." But there are a few practical reasons for that.
First, standards like ISO 27001 have to work for everyone, from a two-person startup to a Fortune 500 enterprise. If they forced a specific heavy-duty process, it wouldn't just be annoying—it could crush the smaller companies. Second, technology changes fast. If a standard mandated a specific tool or methodology today, it’d be obsolete by next year.
Strict mandates usually just lead to "checkbox compliance" where people do the bare minimum to pass an audit rather than actually fixing security.
So instead of telling you how to do it, regulators focus on the outcome. They ask: "Have you identified your risks?" and "Can you prove your controls work?"
Where threat modeling is explicitly required
That said, there are plenty of places where it is spelled out explicitly. If you are working in government or critical infrastructure, you don't really have a choice.
- NIST SP 800-53 (Control RA-3): If you're dealing with federal systems, this is the bible. It explicitly requires you to conduct a risk assessment that includes identifying threats and vulnerabilities. You can't just guess; you have to document it.
- CIS Controls (v8): The Center for Internet Security isn't vague about it either. Control 11 specifically tells you to establish and maintain a secure configuration process, which relies heavily on understanding your threat landscape.
Where threat modeling becomes strong guidance
Then you have the area of "strong guidance." This is where they don't legally force you to do it, but you’re going to have a hard time explaining why you didn't. These frameworks treat threat modeling as a standard duty of care.
- NIST SP 800-218 (SSDF): The Secure Software Development Framework is becoming the gold standard for anyone selling software to the government. It basically says if you aren't modeling threats, you aren't doing secure development.
- NIST SP 800-161: This covers supply chain risk. It recommends threat analysis to figure out where your weak points are before a vendor compromises you.
- OWASP ASVS: If you are building web apps, the Application Security Verification Standard pushes threat modeling as a core requirement for higher assurance levels.
Where threat modeling serves as compliance evidence
This is where most of us live. You might be looking at ISO/IEC 27001, SOC 2, or GDPR and thinking, "I don't see the words threat modeling anywhere."
You're right, you won't. But look closer at what they do ask for.
- ISO/IEC 27001 (Clause 6.1.2): Requires a risk assessment process. How do you identify risks without modeling threats?
- SOC 2 (CC 3.1): Asks how you identify risks to your objectives.
- GDPR (Article 35): Requires a Data Protection Impact Assessment (DPIA) for high-risk processing. That is effectively a privacy-focused threat model.
- PCI DSS (Req 6.3.2): Requires you to identify security vulnerabilities in your software.
In all these cases, threat modeling is your best friend during an audit. When an auditor asks, "How did you decide you didn't need a firewall here?", you don't want to shrug. You want to pull out your threat model. It shows exactly how you found the threats, weighed their impact, and chose your controls. It turns a subjective opinion into defensible evidence.
Why safety-critical industries are different
Safety-critical industries are a different beast entirely. In aviation or automotive, a hack doesn't just mean lost data; it means lost lives. So the rules here are strict and the mandates are clear.
- Avionics (DO-326A / ED-202A): If you want to fly, this isn't a suggestion. It mandates a rigorous security process.
- Automotive (ISO/SAE 21434): This standard requires you to perform TARA (Threat Analysis and Risk Assessment). It’s not optional for modern vehicles.
- Medical Devices (FDA Guidance): The FDA will bounce your 510(k) submission if you haven't modeled threats to patient safety.
- Nuclear (IEC 62645): Unsurprisingly, they have strict requirements for analyzing security controls.
Bringing it all together
So, what’s the bottom line? Threat modeling isn't an engineering exercise. Threat modeling is your paper trail. Threat modeling proves you looked for the problems, analyzed the risks, and implemented countermeasures. In the world of compliance, if you didn't document it, you didn't do it. Threat modeling ensures you have the documentation to back you up.
The PROTECT framework introduced earlier in this series was never about compliance for its own sake. It was about making threat modeling effective, repeatable, and decision-oriented.
- Article 1 showed how to do threat modeling comprehensively.
- Article 2 showed what questions actually matter when doing it.
- Article 3 explains why threat modeling remains one of the strongest tools for meeting real-world security, regulatory, and assurance expectations.
Threat modeling isn't just a technique. It's a way to make risk visible, decisions defensible, and security outcomes explainable when it matters most.
