Compliance

Threat modeling your auditor actually expects

SOC 2, ISO 27001, PCI DSS, NIST CSF, and Australian regulatory frameworks all require some form of risk identification and threat assessment. ThreatKrew generates the structured evidence that satisfies these requirements — automatically, repeatably, and in minutes.

The compliance gap most teams don't see

Vulnerability scans and pen tests satisfy some audit controls. But most frameworks also require proactive risk identification at the design level — identifying threats and architectural flaws before they become vulnerabilities. That's threat modeling.

What ThreatKrew generates for compliance: STRIDE-categorized threats with severity ratings, MITRE ATT&CK technique mappings, NIST SP 800-53 remediation controls with implementation guidance, a security assumptions register, and architecture diagrams. Every finding is independently verified and traceable to specific components in your architecture.

Framework-by-framework mapping

Here's how automated threat modeling maps to the specific controls your auditor checks.

SOC 2 Type II

CC3.2

SOC 2 Trust Services Criteria CC3.2 requires risk identification and assessment. Threat modeling provides the structured risk identification that auditors expect — documented threats, severity ratings, and mapped remediation controls.

What ThreatKrew maps to:

  • CC3.2 — Risk identification and assessment
  • CC3.4 — Consideration of fraud risk
  • CC6.1 — Logical and physical access controls
  • CC7.2 — Monitoring of infrastructure for anomalies

ISO 27001:2022

Clause 6.1.2 + Annex A.5.7

ISO 27001 requires a repeatable risk identification process and threat intelligence. ThreatKrew's STRIDE analysis satisfies Clause 6.1.2, while MITRE ATT&CK mapping addresses the Annex A.5.7 threat intelligence requirement.

What ThreatKrew maps to:

  • Clause 6.1.2 — Information security risk assessment
  • Annex A.5.7 — Threat intelligence
  • Annex A.8.25 — Secure development lifecycle
  • Annex A.8.27 — Secure system architecture

PCI DSS v4.0

Requirement 6.3.2

PCI DSS v4.0 mandates custom software inventory and vulnerability identification during development. Threat modeling identifies architectural design flaws in payment systems before they reach production.

What ThreatKrew maps to:

  • Requirement 6.3.2 — Software inventory and vulnerability identification
  • Requirement 6.2.2 — Secure software development training
  • Requirement 12.3.1 — Targeted risk analysis

NIST Cybersecurity Framework 2.0

ID.RA-03 through ID.RA-05

NIST CSF 2.0 explicitly calls for threat identification, risk assessment, and risk prioritization. ThreatKrew's pipeline directly maps to the Identify function's risk assessment subcategories.

What ThreatKrew maps to:

  • ID.RA-03 — Threats are identified and documented
  • ID.RA-04 — Potential impacts and likelihoods are identified
  • ID.RA-05 — Threats and vulnerabilities are used to determine risk
  • GV.RM — Risk management strategy

Australian regulatory frameworks

Australian organisations face a distinct set of regulatory requirements. ThreatKrew's STRIDE analysis, MITRE ATT&CK mapping, and NIST SP 800-53 controls provide the structured risk assessment evidence these frameworks demand.

AESCSF

Australian Energy Sector Cyber Security Framework

Based on the US C2M2 model, the AESCSF requires energy sector organisations to identify, assess, and manage cyber security risks. Threat modeling provides the structured risk assessment evidence that AESCSF Domains 1 (Risk Management) and 2 (Asset, Change, and Configuration Management) require.

Domain 1 — Risk Management Domain 3 — Threat and Vulnerability Management

Essential Eight

ACSC Essential Eight Maturity Model

The Essential Eight uses a threat-informed approach to prioritize mitigation strategies. Understanding your specific threat landscape — which is exactly what threat modeling provides — is fundamental to reaching Maturity Level 2 and above.

Application control scoping Network segmentation validation Privilege escalation path identification

APRA CPS 234

APRA Prudential Standard CPS 234

CPS 234 requires APRA-regulated entities to maintain information security capability commensurate with the threat to their information assets. Threat modeling directly satisfies the requirement to identify and classify information assets, assess threats, and implement proportionate controls.

Paragraph 15 — Threat exposure assessment Paragraph 18 — Information security controls Paragraph 33 — Testing program adequacy

Also relevant for

CIS Controls v8.1

Implementation Group 2, Control 16 (Application Software Security)

CMMC 2.0

Level 2 — Risk Assessment (RA.L2-3.11.1)

HIPAA

§164.308(a)(1) — Security Management Process

GDPR

Article 32 — Data Protection Impact Assessments

CCPA / CPRA

Risk assessment requirements for high-risk processing

Read the full compliance deep-dive on our blog

Generate audit-ready threat models in minutes

Stop scrambling for evidence before your next audit. ThreatKrew delivers the structured risk assessment your compliance framework requires.

Start free Talk to Sales