There is a pattern that repeats itself in nearly every SOC 2 preparation engagement: in the weeks before the audit window opens, someone produces a risk register. It is comprehensive, thoughtfully formatted, and completely disconnected from how security decisions are actually made day-to-day. The auditor reviews it, confirms it contains the required elements, and files it away. Three months later, the system has changed significantly and the register reflects none of it.
This is the SOC 2 evidence gap — the distance between documentation produced for compliance and the continuous security thinking that auditors are actually trying to confirm is happening. Experienced SOC 2 Type II auditors know the difference. They ask follow-up questions. They look at change management records. They ask how your risk assessment informed the controls you implemented after your last major deployment. A risk spreadsheet refreshed annually cannot answer those questions.
Living threat models can.
What SOC 2 actually asks for
SOC 2 is not prescriptive about how you manage security. The Trust Services Criteria (TSC) describe outcomes and evidence of process, not specific tools or techniques. The criteria most directly relevant to risk assessment and threat identification are:
| TSC Criterion | What it requires | What auditors look for as evidence |
|---|---|---|
| CC3.2 | The entity specifies relevant security objectives and identifies risks to achieving them | Documented risk identification process; evidence it was applied; risk owners named |
| CC3.3 | The entity assesses the significance of identified risks, including likelihood and impact | Scored risk register with rationale; evidence scores reflect current system state |
| CC4.1 | Ongoing monitoring activities evaluate the continuing relevance of controls | Records showing controls were re-evaluated after system changes; review cadence |
| CC7.2 | Security incidents are identified and addressed | Incident log with root cause; evidence threat model was updated post-incident |
| CC9.2 | The entity assesses and manages risk associated with vendors and business partners | Vendor risk assessments tied to specific data flows or integration points |
Read across those criteria and a consistent picture emerges: auditors want to see that risk identification is a process, not an event. They want evidence of identification, scoring, re-evaluation, and response — and they want that evidence to be connected to your actual system, not a generic threat taxonomy applied to an asset inventory.
Why static documents fail the continuous assurance test
A SOC 2 Type II audit covers a period — typically 12 months. The auditor is not just confirming that your controls exist at the end of that period; they are sampling across the period to confirm that controls were operative throughout. A risk register that was last substantively updated eight months ago tells the auditor that either your system has not changed in eight months (unlikely) or your risk management process did not keep pace with your system (concerning).
The same problem applies to DFDs and architecture diagrams produced as compliance artefacts. A diagram produced once and never updated is a snapshot of a system that no longer exists. When a penetration tester finds a vulnerability in a service that "wasn't there" according to the architecture diagram, the compliance narrative collapses.
The auditor's tell: When an experienced SOC 2 auditor asks "can you walk me through how your risk register was updated after your Q2 infrastructure migration?" and the answer involves silence followed by a version history showing zero edits, that is a gap finding — not necessarily a material one, but a signal that the process is not genuinely operational.
The core problem is that compliance-as-documentation is a dead-end model. Documentation produced to satisfy auditors has exactly as much accuracy and freshness as the organisation has motivation to maintain it. When the motivation is annual audit preparation, you get annual updates. When the motivation is operational security — and compliance is a by-product — you get continuous updates.
Threat models as evidence artefacts — what auditors actually want
A threat model maintained as a living document — updated whenever the system changes, reviewed after incidents, and connected to the actual controls implemented — produces exactly the evidence trail that SOC 2 requires. This is not a coincidence. The SOC 2 criteria were written to describe mature security programmes, and mature security programmes have always done this kind of systematic threat analysis.
What makes a threat model valuable as compliance evidence specifically is the chain of traceability it creates. As we explored in detail when discussing turning threat models into risk registers, each attack-tree leaf node can be traced from the initial threat identification through to the control that addresses it, the implementation that was deployed, and the test that confirmed it was effective. This chain — threat → risk register entry → control → implementation → verification — answers every CC3.x question in a single coherent document set.
For CC9.2 specifically — vendor and business partner risk — the Data Flow Diagram has a structural advantage that no flat vendor questionnaire can match. The DFD shows, explicitly and visually, exactly which external entities interact with which internal data stores and processes, across which trust boundaries, and with what authentication. A vendor risk assessment that can point to a DFD node and say "this is the specific integration point, this is the data it can access, and these are the controls on the boundary" is categorically stronger evidence than a questionnaire response that says "yes, we have security controls in place."
Three practices that close the evidence gap
Tie threat model updates to architectural change reviews
The most effective way to keep a threat model current is to make updating it a mandatory step in your change management process. This does not mean a full re-analysis for every configuration tweak — it means asking one question for every significant change: does this change affect a trust boundary, add a new data flow, or introduce a new external dependency?
If the answer is yes, the DFD gets updated, the affected attack trees are reviewed, and any new leaf nodes go into the risk register before the change is deployed to production. The audit evidence writes itself: the change management record shows the approval, the threat model shows it was reviewed, and the risk register shows any new risks were assessed and either mitigated or formally accepted with rationale.
Use risk register exports as audit evidence packages
A risk register that can be exported as a dated, versioned PDF — showing all active risks, their scores, their owners, their mitigations, and any accepted risks with documented rationale — is a self-contained evidence artefact. When an auditor asks "show me your risk register as of March 15th," you can produce it in seconds rather than trying to reconstruct the state of a spreadsheet from version history.
The timestamps matter. A risk register exported one day before the audit window opens is a red flag. A series of exports spread across the audit period — each one showing incremental updates corresponding to system changes and periodic reviews — is the evidence of continuous process that CC3.3 and CC4.1 require.
Version-control your threat models alongside your infrastructure code
If your infrastructure is defined as code — and in 2025, most cloud-native systems are — your threat models should live in the same version-controlled environment. A commit that adds a new Lambda function should be accompanied by a commit that updates the DFD to show it, the attack tree to analyse it, and the risk register to capture any new leaf nodes it introduces.
This creates the single most powerful evidence artefact in a SOC 2 Type II audit: a git history that shows security analysis keeping pace with system changes, with commit messages that link architectural changes to their corresponding risk assessments. No auditor can question the continuity of a process with this kind of paper trail.
Using threat models to contain audit scope — not just satisfy it
There is a strategic dimension to living threat models that compliance conversations rarely surface: they help you define what should be in scope for a SOC 2 audit in the first place.
SOC 2 audit scope is defined by the systems that handle customer data relevant to the Trust Services Criteria. Teams that lack a clear architectural model of data flows often over-scope their audit — including systems in scope because they might touch customer data, rather than because the DFD demonstrates they do. Over-scoping inflates audit cost, creates more controls to evidence, and introduces more potential gaps.
A well-maintained DFD makes scope decisions explicit and defensible. You can show exactly which systems handle customer data, across which boundaries, with what controls. Systems outside those boundaries are demonstrably out of scope. This is not a compliance trick — it is the consequence of knowing your own architecture precisely enough to defend your security claims about it.
Scope containment in practice: One common finding is that teams include their internal development tooling in SOC 2 scope because developers occasionally access production data for debugging. A DFD that explicitly models the boundary between development environments and production systems — and the controls on that boundary — either confirms the scope is correct or reveals it can be reduced. Either outcome improves the compliance posture.
The through-line across all three posts in this series is the same: security standards do not prescribe methodologies because they are trying to accommodate every organisation. But they all assume that someone has done the hard work of systematically identifying what could go wrong with their specific system and building defences against it. Threat modeling is that hard work — formalised, shareable, and continuously maintained.
Whether the standard is ISO 27001, SOC 2, PCI-DSS, or any other framework that requires a risk assessment, the evidence gap closes when the risk register is not a document produced for auditors but a living output of the security thinking your team is doing anyway.