Somewhere in every SOC 2 audit, the auditor asks to see your risk assessment — not because it's a checkbox, but because the Trust Services Criteria are built on it. CC3 expects you to identify risks to your objectives, analyze them, and show how your controls respond. A generic spreadsheet downloaded the week before fieldwork fails that test quickly.
What a defensible one contains
- Scope tied to your actual service commitments — uptime, confidentiality, data handling promises in your contracts.
- A real asset and data-flow inventory: what you run, where customer data lives, who and what touches it.
- Threats rated by likelihood and impact, including vendor, fraud and change-related risks — not just malware.
- A named owner and treatment decision for every risk: mitigate, accept, transfer, avoid.
- A mapping from each significant risk to the controls that address it.
The mistakes auditors flag most
Three patterns dominate: assessments that don't match the environment (cloud company, data-center threat list), assessments with no linkage to controls, and assessments that never change. The document should move when your business does — new market, new subprocessor, new architecture, new entry.
Make it earn its keep
Run the assessment annually and after material changes, take the top risks to leadership, and let the treatment plan drive your security roadmap. Done that way, the audit artifact is a by-product of a working program — which is precisely what a SOC 2 report is supposed to signal to your customers.
