The SOC 2 CC3 criteria require a documented risk assessment process — specifically that you identify risks to the achievement of your defined objectives, analyze those risks, and demonstrate that you're doing something about the ones that matter. Auditors expect to see evidence of this process operating throughout the audit period, not a single document that appeared the month before the audit window closed.
The tool almost every early-stage team uses for this is Excel or Google Sheets. We used it too, before we built something better. And the spreadsheet approach works — for about twelve months, with fewer than thirty identified risks, and with one person owning the whole thing. Add time, organizational change, or more than two contributors, and it starts to fail in predictable ways.
This post is about what specifically fails, how to structure a risk assessment process that holds up at audit time, and what "machine-readable risk register" means when you're not a CISO-led team with a dedicated GRC analyst.
Why Spreadsheet Risk Registers Break Under Audit Scrutiny
The audit evidence problem with a spreadsheet risk register isn't that spreadsheets are bad. It's that spreadsheets don't naturally produce the evidence chain that CC3 requires.
The first problem is versioning. An auditor sampling CC3 for Q2 of your audit period wants to see the risk assessment as it existed in Q2 — what risks were identified, what their rated severity was, what mitigating controls were mapped to them. A spreadsheet that's been updated since Q2 doesn't preserve that state unless someone was disciplined about saving timestamped exports. Most teams aren't. The "risk register" an auditor sees is today's version of the document, and there's no reliable way to prove it reflects what existed six months ago.
The second problem is ownership attribution. Risk registers need to show who assessed each risk — who rated the likelihood and impact, who approved the rating, who owns the mitigation action. Spreadsheets can have an "owner" column, but there's no system enforcement. Ratings get changed without an audit trail. Owner fields go stale when people leave. The document looks like a committee document when it's actually been maintained by one person who represents other people's initials.
The third problem is linkage to controls. A risk register that says "Risk: unauthorized data access — Mitigation: access controls in place" isn't demonstrating CC3 compliance. It's asserting it. What the auditor wants is a traceable link from the identified risk to the specific control that mitigates it, and from that control to the evidence that the control was operating. Without that chain, the risk assessment is circular — you identified risks and pointed to controls, but there's no demonstration that the controls actually ran.
The Anatomy of a Defensible Risk Register
A risk register that holds up under SOC 2 audit scrutiny needs to capture a specific set of fields for each identified risk. The field list isn't prescribed by the AICPA — the Trust Service Criteria are intentionally non-prescriptive about format — but the following structure satisfies the evidence requirements we've seen in practice:
- Risk ID. A stable identifier that doesn't change when the risk description is updated. This allows you to reference a specific risk in other documents and maintain history across update cycles.
- Category. Operational, compliance, technology, personnel, vendor. Categorization matters because auditors expect risk assessments to cover defined categories, not just whatever risks someone thought of on a given day.
- Objective at risk. Which of your stated operational or security objectives does this risk threaten? This connects CC3's "specify objectives" requirement to the "identify risks" requirement.
- Likelihood and Impact ratings. A simple 1-5 scale with defined anchors. The scale itself matters less than consistency and documentation of how the ratings are defined. An auditor who sees a risk rated 4 for likelihood needs to be able to find your rating definitions to understand what "4" means.
- Inherent vs. residual risk. Inherent risk is the rating before controls are applied. Residual risk is the rating after. This distinction is what makes a risk register a decision tool rather than a list — it shows that you thought about both the risk and whether your controls actually reduce it.
- Control mapping. One or more specific controls that mitigate the risk. Each control should be identifiable in your control matrix (see our post on control matrices for how to structure that document).
- Last reviewed date and reviewer. Timestamped, with attribution. This is the CC3 evidence of ongoing operation — it shows the risk assessment was actively maintained throughout the period, not created once and forgotten.
The Fraud Risk Requirement Most Teams Miss
CC3.3 specifically requires that the organization considers the potential for fraud in the risk assessment. This is a requirement that a lot of first-time SOC 2 programs either skip or add a one-line entry like "Fraud risk: low — mitigated by segregation of duties."
An auditor reviewing CC3.3 wants to see that you thought specifically about fraud scenarios relevant to your operating environment: insider theft of customer data, fictitious vendor payments if you have accounts payable, unauthorized access to production systems. The risk register needs at least a dedicated section for fraud risk with the same rigor as operational risks — rated likelihood and impact, mapped controls, evidence of periodic review.
We're not saying you need to document twenty fraud scenarios and run a fraud prevention program. A realistic fraud risk section for a small SaaS company might identify four to six scenarios, rate them, and map them to existing controls (access controls, financial authorization policies, audit logging). What you can't do is leave CC3.3 empty or add a single line that doesn't demonstrate real analysis.
Cadence: How Often Does a Risk Assessment Need to Run?
The TSC doesn't specify a frequency. The industry norm is annual, with a requirement to update when significant changes occur — a major new product feature, acquisition of a new customer segment with different data sensitivity, significant infrastructure changes, or a security incident.
Consider this pattern: an early-stage B2B payments SaaS at roughly $2M ARR, ten employees. They did their initial risk assessment during their first SOC 2 readiness engagement and rated it as a one-time effort. Eleven months later, they'd moved from a single-region AWS deployment to a multi-region active-active configuration and added a new customer segment in healthcare, bringing HIPAA into scope. Their risk register still reflected the original architecture and customer profile. When the auditor asked how that risk register had been updated to account for the infrastructure change and the new regulatory scope, the answer was — it hadn't. That's a CC3 finding, and an avoidable one.
The change-triggered update requirement is where a process rather than an artifact matters. You need a defined trigger: "when we make changes of type X, we review and update the risk register within 30 days." That trigger needs to be documented, and you need to show evidence it was followed — a ticket, a calendar reminder, some record that the update happened and why.
The Integration Between Risk Assessment and Control Monitoring
The risk register isn't an island. The reason continuous control monitoring matters to CC3 is that your residual risk ratings are only valid if the controls you mapped are actually operating. If your risk register says "Unauthorized access: residual risk Low — mitigated by MFA enforcement and quarterly access reviews," but your identity provider shows MFA disabled for six users and the last access review ran ten months ago, your residual risk rating is wrong. The actual residual risk is higher than what the register shows.
This is the integration we built into Tenurex: when a control check flags a gap, the risk register items that reference that control automatically surface as potentially under-mitigated. It's not that the risk rating changes automatically — risk ratings are human decisions. But the signal that the mitigating control is degraded reaches the person responsible for the risk register before the auditor does.
That feedback loop is what turns a risk register from a compliance artifact into an operational tool. Without it, the register accurately describes your risks at the moment it was written. With it, the register is a living document that reflects your actual control state — which is what CC3 intends.