Threat Modeling for Compliance: SOC 2, ISO 27001, PCI DSS

If you’ve been through a SOC 2 audit, an ISO 27001 certification, or a PCI DSS self-assessment, you’ve probably encountered the moment. The auditor asks: “Can you show me your risk assessment?” You point them at your vulnerability scanner output. They nod politely, then ask: “And your threat model?”

That’s usually where the conversation gets uncomfortable.

Here’s the thing: threat modelling isn’t an exotic security practice reserved for banks and defence contractors. It’s a foundational requirement in every major compliance framework your customers, investors, or regulators are going to ask about. SOC 2 and PCI DSS reference it directly. ISO 27001 and NIST CSF require it as part of their risk management processes. You’re probably already required to do it. You just don’t know it yet.

What auditors are actually asking for

When an auditor asks for a “threat model” or “risk assessment,” they’re looking for evidence that you’ve thought systematically about what could go wrong with your architecture before you built it, not just scanned for vulnerabilities after deployment. They want to see that you’ve identified threats, assessed their severity, and documented how you’re mitigating them.

This is fundamentally different from what your vulnerability scanner, SAST tool, or cloud security posture manager produces. Those tools check what you’ve already built. A threat model checks whether the design itself is sound.

Let’s walk through what each framework actually requires.

SOC 2 Type II — CC3.2

SOC 2’s Common Criteria 3.2 requires organisations to “identify and assess risks to the achievement of objectives.” In practice, this means your auditor expects a documented risk assessment that identifies threats to your system’s security, availability, and confidentiality.

A threat model that maps your architecture to specific threats (STRIDE categories), links those threats to real-world attack techniques (MITRE ATT&CK), and recommends controls (NIST SP800-53) is exactly the kind of artefact that satisfies CC3.2. It’s not the only way to meet the requirement, but it’s one of the strongest — because it shows you’ve assessed risk at the architectural level, not just the code or infrastructure level.

Most startups going through their first SOC 2 audit discover this requirement about three weeks before the audit window. Don’t be that team.

ISO 27001:2022 — Clause 6.1.2 and Annex A.5.7

ISO 27001 is more explicit. Clause 6.1.2 mandates an information security risk assessment process — you must identify risks, assess likelihood and impact, and determine risk treatment. Clause 8.2 requires you to actually execute that process at planned intervals.

The 2022 revision added Annex A.5.7: Threat Intelligence. This is new, and it’s significant. It requires organisations to collect, analyse, and produce threat intelligence at strategic, operational, and tactical levels. A structured threat model — one that identifies threats grounded in real attack techniques and maps them to your specific architecture — is a direct way to demonstrate compliance with both Clause 6.1.2 and A.5.7.

For teams pursuing ISO 27001 certification, having a repeatable, documented threat modelling process moves you from “we do ad-hoc risk assessments” to “we have a systematic, evidence-based security analysis capability.” That’s a maturity jump your certification body will notice.

PCI DSS v4.0 — Requirement 6.3.2

PCI DSS v4.0 introduced Requirement 6.3.2, which requires organisations to perform threat analysis for custom and bespoke software. If you’re handling cardholder data and you’ve written custom code to do it, your QSA or SAQ is going to ask how you identified threats to that software.

This is where threat modelling maps most directly to a compliance checkbox. The requirement doesn’t say “run a vulnerability scan.” It says perform a threat analysis — understand what an attacker could do to your custom software and how you’ve designed against it. A structured threat model with STRIDE categorisation and MITRE ATT&CK mappings gives your QSA exactly what they need.

NIST CSF 2.0 — ID.RA-03 through ID.RA-05

The NIST Cybersecurity Framework uses a tiered approach. At Tier 1 (Partial), your risk management is ad-hoc and reactive. At Tier 2 (Risk Informed), you’re making risk-aware decisions but not consistently. At Tier 3 (Repeatable), your security processes are documented, followed regularly, and updated as needed.

The ID.RA subcategories — identifying threats (ID.RA-03), assessing impact and likelihood (ID.RA-04), and using that analysis to prioritise risk response (ID.RA-05) — are essentially a description of what a threat model produces.

Having no formal threat modelling process keeps you at Tier 1. Having one pushes you to Tier 2. Having it automated and repeatable gets you to Tier 3. That’s a concrete maturity claim you can make to customers, partners, and regulators.

CIS Controls v8.1 — Implementation Group 2

The CIS Controls use Implementation Groups: IG1 is essential cyber hygiene, IG2 is for organisations with dedicated security staff handling sensitive data, and IG3 is for high-risk organisations facing advanced threats.

Threat modelling becomes formally relevant at IG2, where Control 16 (Application Software Security) and risk-based remediation strategies require you to understand threats to your applications — not just scan for known CVEs. If you’re claiming IG2 compliance without any form of architectural threat analysis, you’ve got a gap.

CMMC 2.0 — Level 2

For organisations selling to the US Department of Defense, CMMC 2.0 Level 2 requires periodic risk assessments that consider “threat sources, vulnerabilities, likelihood, and impact” (RA.L2-3.11.1). At Level 3, this becomes explicitly threat-informed, with proactive threat hunting required.

If you’re pursuing CMMC Level 2 certification, a documented threat model for your CUI-handling systems directly addresses the Risk Assessment domain. It’s not optional — it’s a practice you’ll be assessed against.

The Australian angle: AESCSF and Essential Eight

For Australian organisations — particularly in the energy sector — the Australian Energy Sector Cyber Security Framework (AESCSF) published by AEMO includes Risk Management and Threat & Vulnerability Assessment as core domains. Threat modelling supports the maturity progression from MIL 1 (basic practices) to MIL 2 (systematic, documented practices).

The Essential Eight, published by the ACSC, is more operational — it prescribes eight specific mitigation strategies (patching, MFA, application control, etc.) rather than risk assessment processes. Threat modelling doesn’t directly map to any of the eight strategies. But it does tell you which of those strategies matter most for your specific architecture, and at what maturity level you need to implement them. It’s the analytical layer that informs your Essential Eight prioritisation.

For organisations subject to APRA CPS 234 (financial services), the prudential standard explicitly requires boards to ensure “information security capability is commensurate with the size and extent of threats.” Threat modelling is how you determine what those threats are.

HIPAA — §164.308(a)(1)

If you’re handling protected health information (PHI), HIPAA’s Security Rule requires a “risk analysis” as its very first administrative safeguard — §164.308(a)(1)(ii)(A). The Office for Civil Rights has been clear that this isn’t a one-time exercise: you need to document threats to the confidentiality, integrity, and availability of ePHI, assess their likelihood and impact, and implement security measures accordingly.

A threat model that analyses your architecture’s data flows — where PHI is stored, how it moves between systems, and which trust boundaries it crosses — directly addresses this requirement. It’s more thorough than a vulnerability scan (which only checks what you’ve deployed) and more specific than a generic risk register (which often lists threats without grounding them in your actual architecture).

GDPR, CCPA, and privacy frameworks

Privacy regulations don’t use the words “threat model,” but they do require Data Protection Impact Assessments (DPIAs under GDPR) and evidence of “reasonable security measures” (CCPA). A threat model that identifies data flows, trust boundaries, and PII exposure risks provides the technical underpinning for a DPIA. It’s the difference between “we think our data is secure” and “here’s our documented analysis of how data moves through our system and where it’s at risk.”

The EU Cyber Resilience Act, due for enforcement in 2027, will make this even more explicit — Article 10 requires risk assessment for products with digital elements. If you’re building software sold in the EU, threat modelling is about to become mandatory.

The pattern you should notice

Every framework listed above requires some form of systematic threat identification and risk assessment. None of them say “threat model” on the tin. But all of them require exactly what a threat model produces: documented analysis of threats to your architecture, assessed by severity, with corresponding controls or mitigations.

The maturity progression is remarkably consistent across frameworks:

• Level 1 / Ad-hoc: You react to security issues as they arise. No formal threat analysis. If an auditor asks, you scramble.
• Level 2 / Risk Informed: You’ve done threat analysis at least once. It’s documented. You can point an auditor at it with confidence.
• Level 3 / Repeatable: Threat analysis is a regular, documented process. It happens on every significant architecture change — whether that’s done manually, with a tool, or with a combination of both.

Most organisations are at Level 1. Getting to Level 2 is what keeps you compliant. Getting to Level 3 is what keeps you secure. How you get there — manual workshops, structured methodologies like PASTA or LINDDUN, or automated tooling — matters less than the fact that you’re doing it consistently.

What auditors actually want to see

When your auditor asks for a threat model, they’re not expecting a 200-page academic paper. They want evidence of structured thinking. That means your architecture is described (components, data flows, trust boundaries), threats are identified using a recognised methodology (STRIDE is the most common), those threats are ranked by severity (not everything is critical — differentiation is what makes an assessment credible), and mitigations are mapped to a control framework (NIST SP800-53, CIS Controls, ISO 27002).

An assumptions register — documenting what you assumed about your environment’s security posture — is the detail that separates a good threat model from a great one. It shows intellectual honesty and gives future reviewers the context to understand why certain threats were rated the way they were.

Whether you produce this through a manual workshop, a structured methodology like PASTA, Microsoft’s Threat Modeling Tool, or an automated platform doesn’t matter to the auditor. What matters is that the analysis exists, it’s documented, and it covers your architecture specifically — not a generic template with your company name pasted in.

Stop treating threat modelling as a security activity

Here’s the mindset shift: threat modelling isn’t just a security best practice. It’s compliance infrastructure. Every framework requires it. Every audit will ask about it. Every customer security questionnaire touches on it.

If you treat it as something your security team does when they have spare cycles, you’ll always be scrambling before an audit. If you treat it as a regular, repeatable part of your development process — something that happens alongside architecture reviews, not instead of them — you’ll find that compliance becomes a side effect of building securely from the start.

The frameworks all agree on this. The only question is whether you figure it out before or after your auditor asks.

---

Learn more about why threat modelling matters for your architecture, or explore how maturity frameworks like NIST CSF help you improve incrementally. For a deeper comparison of STRIDE, PASTA, and other methodologies, see our methodology guide. See how automated threat modelling maps to your compliance framework, or visit how ThreatKrew works.

Ready to make threat modelling repeatable — and audit-ready? Explore the automated threat modeling tool or join the Founders Program and get professional STRIDE analysis in minutes, not months.