Priya Nandakumar had eleven days before the fieldwork call, and a $2.4 million enterprise renewal sitting on the other side of it. As the GRC lead at Lumenbridge Analytics — a 140-person SaaS company that helps mid-market retailers forecast demand — she had spent the prior year building what she genuinely believed was a solid control environment: access reviews on schedule, encryption everywhere it needed to be, change management tickets closed out cleanly. What she hadn't done, it turned out, was keep her risk register alive.
The document existed. It had been built eighteen months earlier during the initial SOC 2 readiness project, populated with twenty-two risks, scored, assigned owners, and then — like so many risk registers — quietly abandoned the moment the first Type I report shipped. When Lumenbridge's auditor, a meticulous CC3 tester named Marcus Delgado, asked to see evidence that the risk assessment process had actually operated during the twelve-month Type II window, Priya produced the same static file from the prior year. No updates. No new risks logged for the two products shipped since then. No documented consideration of fraud risk. No evidence anyone had looked at it since the day it was created.
"A risk register that hasn't changed in a year isn't evidence of a risk assessment process — it's evidence of the absence of one. CC3 doesn't ask whether you once identified risks. It asks whether you're still doing it." — Marcus Delgado, SOC 2 Lead Auditor, Fielding & Cross CPAs
That single finding didn't sink the audit, but it triggered a management response, a corrective action plan, and three additional weeks of auditor follow-up — three weeks Priya didn't have before the renewal deadline. This article is the guide I wish she'd had eighteen months earlier: how to build a risk register that satisfies CC3 (and its close cousin CC9, risk mitigation) not as a document you build once, but as a living system of record that proves your organization actually manages risk.
Who This Is For and What You'll Walk Away With
This is written for the GRC lead, security engineer, virtual CISO, or founder who owns SOC 2 readiness and has been told — correctly — that "you need a risk register" without much more explanation than that. You'll walk away with a field-by-field template for what belongs in a SOC 2-grade risk register, a defensible scoring methodology for likelihood, impact, inherent risk, and residual risk, a treatment and ownership model that auditors recognize, a review cadence that produces the evidence trail CC3 and CC9 actually require, and a fraud-risk framework that satisfies the criterion most teams forget entirely. Whether you're building your first register or repairing one that's gone stale, the goal is the same: a document — or better, a live system — that proves ongoing risk management, not a single snapshot in time.
Why the Risk Register Is the Backbone of CC3
Every SOC 2 examination includes the Common Criteria, the Security category required in every report regardless of which additional Trust Services Criteria are in scope. Within the Common Criteria, CC3 — Risk Assessment — is where auditors evaluate whether your organization actually understands what could go wrong and has a structured process for deciding what to do about it. CC3 traces directly to COSO Principles 6 through 9, the internal-control framework the AICPA built the Common Criteria on top of. Your risk register is the single artifact that demonstrates all four of those principles operating together: objective-setting, risk identification and analysis, fraud consideration, and change-driven reassessment.
Auditors don't test CC3 by asking whether you understand risk conceptually. They test it by asking to see the register, tracing entries back to how they were identified, checking whether scores were assigned using a repeatable methodology, verifying that risks map to actual controls, and — critically for a Type II examination — confirming the register was touched, reviewed, and updated throughout the entire audit period, not just at the start. A register that was built once for the readiness assessment and never revisited is, in an auditor's eyes, functionally identical to no register at all.
CC3 and CC9: What They Actually Require
Criterion | COSO Principle | What It Requires | What the Register Must Show |
|---|---|---|---|
CC3.1 | Principle 6 | Entity specifies objectives clearly enough to identify and assess risks to them | Objectives or scope statements referenced when risks were identified |
CC3.2 | Principle 7 | Entity identifies risks to objectives across the entity and analyzes risks as a basis for managing them | A populated, scored register covering the in-scope system |
CC3.3 | Principle 8 | Entity considers the potential for fraud in assessing risks | A distinct fraud-risk section or tagged fraud-risk entries |
CC3.4 | Principle 9 | Entity identifies and assesses changes that could significantly affect internal control | Evidence of change-triggered reviews (new products, M&A, org changes, new regulations) |
CC9.1 | — | Entity identifies, selects, and develops risk mitigation activities for risks from business disruptions | Documented treatment plans tied to register entries |
CC9.2 | — | Entity assesses and manages risks associated with vendors and business partners | Vendor/subservice risks represented in or linked from the register |
A well-run register satisfies all six rows from a single, consistently maintained artifact. That's the design goal for everything that follows.
Anatomy of a SOC 2-Ready Risk Register — The Required Fields
The single most common gap I see in client registers isn't scoring methodology — it's missing fields. A register with a risk description and a color-coded score but no owner, no treatment status, and no linkage to a control isn't a risk management artifact; it's a list. Below is the field set I use on every engagement, refined over dozens of Type II cycles.
Field | Purpose | Example |
|---|---|---|
Risk ID | Unique, permanent identifier for traceability | RR-014 |
Risk statement | Concise description of what could happen and to what | Unauthorized access to production database via compromised engineer credentials |
Risk category | Groups risks for reporting and trend analysis | Access management |
Related threat(s) | The threat source(s) that could trigger the risk | Credential theft, insider misuse |
Related vulnerability(ies) | Weakness that would allow the threat to materialize | Standing admin access without MFA enforcement |
Affected asset/system | What's in scope of the exposure | Production PostgreSQL cluster |
Inherent likelihood | Probability before controls, on defined scale | 4 (Likely) |
Inherent impact | Consequence before controls, on defined scale | 5 (Severe) |
Inherent risk score | Likelihood × impact | 20 |
Existing controls | Controls currently mitigating the risk | MFA policy, least privilege provisioning, quarterly access review |
Residual likelihood | Probability after controls | 2 (Unlikely) |
Residual impact | Consequence after controls | 4 (Major) |
Residual risk score | Post-control likelihood × impact | 8 |
Risk owner | Named individual accountable for treatment | Head of Infrastructure |
Treatment decision | Mitigate / Accept / Avoid / Transfer | Mitigate |
Treatment plan | Specific actions and target state | Enforce hardware-key MFA for all DB admin roles |
Target completion date | Deadline for treatment actions | 2026-09-30 |
Status | Open / In progress / Closed / Accepted | In progress |
Date identified | When the risk entered the register | 2025-11-02 |
Date last reviewed | Most recent review touchpoint | 2026-06-15 |
Fraud-relevant (Y/N) | Flags CC3.3 fraud-risk consideration | N |
Linked control ID(s) | Cross-reference to the control matrix | AC-07, AC-12 |
That's twenty-one fields, and it's not excessive — every one of them answers a question an auditor will ask in the room. If a field feels like overhead, imagine Marcus Delgado pointing at row fourteen and asking "who owns this, and how do you know it's on track?" If the register can't answer instantly, the field was necessary.
Where Risks Actually Come From
A register populated entirely from a single brainstorming session in a conference room looks exactly like what it is. Auditors have seen hundreds of these, and they can tell. Real risk identification pulls from multiple, documented sources, and citing those sources in the register (even informally, in a "source" note) strengthens your CC3.2 evidence considerably.
Source | What It Surfaces | Frequency |
|---|---|---|
Risk assessment workshops | Structured brainstorming across engineering, product, and leadership | Annually, plus ad hoc |
Prior incident postmortems | Realized risks that weren't previously documented | Per incident |
Penetration testing and vulnerability scanning results | Technical exposures with concrete evidence | Per test cycle |
Vendor risk management assessments | Third-party and subservice organization exposure | Per vendor onboarding/renewal |
New product or feature launches | Risks introduced by scope or architecture changes | Per launch |
Regulatory or contractual change | New obligations (e.g., a customer's data residency clause) | As they arise |
Employee or manager reporting | Frontline observations, near-misses | Continuous |
Internal audit findings | Gaps identified in self-assessment | Per internal audit cycle |
Industry threat intelligence | Sector-specific attack trends | Quarterly |
M&A or org restructuring | New systems, new people, new attack surface | Event-driven |
I tell clients to treat this table as a checklist during the annual risk workshop: if you can't point to at least six of these ten sources having contributed an entry in the past twelve months, your register is too narrow — and an auditor testing CC3.2's "identifies risks... across the entity" language will notice the gap.
Threat Categories Worth Explicitly Tracking
Risk statements are strongest when they're anchored to a specific threat source rather than written as vague harm ("data could be exposed"). Grouping threats into categories also makes trend reporting to leadership far easier.
Threat Category | Example Threats | Typical Risk Owner |
|---|---|---|
External malicious actor | Phishing, ransomware, credential stuffing | Security/IT |
Insider (malicious) | Data exfiltration by a departing employee | Security + HR |
Insider (negligent) | Misconfigured storage bucket, accidental data share | Engineering |
Third-party/vendor | Subservice organization breach or outage | Procurement/Security |
Technical/system failure | Hardware failure, unpatched vulnerability | Infrastructure |
Process failure | Missed change management step, broken segregation of duties | Process owner |
Environmental/physical | Data center outage, natural disaster | Facilities/IT |
Regulatory/legal | New data-protection law, contract breach | Legal/Compliance |
Fraud | Financial misstatement, unauthorized transaction | Finance + Compliance |
Reputational | Public disclosure of an unpatched flaw | Executive/Comms |
Ten categories is enough to cover a typical service organization's threat landscape without turning the exercise into an endless taxonomy debate. Each risk statement in the register should map to at least one row here.
Building Defensible Likelihood and Impact Scales
Auditors don't require a specific scoring model — SOC 2 is control-objective driven, not prescriptive about methodology — but they do require that whatever model you use is applied consistently. A 1–5 scale is the most common choice because it's granular enough to differentiate risks meaningfully without inviting false precision.
Likelihood Rating | Label | Description | Approx. Frequency |
|---|---|---|---|
1 | Rare | Would only occur in exceptional circumstances | Once per 5+ years |
2 | Unlikely | Could occur, but no history of it happening | Once per 2–5 years |
3 | Possible | Might occur at some point | Annually |
4 | Likely | Will probably occur | Multiple times per year |
5 | Almost Certain | Expected to occur, or already occurring | Monthly or more |
Impact Rating | Label | Description | Example Consequence |
|---|---|---|---|
1 | Negligible | No meaningful effect on operations, data, or customers | Minor internal inconvenience |
2 | Minor | Limited, quickly contained effect | Small number of records affected, no external notification |
3 | Moderate | Noticeable disruption or limited data exposure | Single customer complaint, brief service degradation |
4 | Major | Significant operational, financial, or reputational harm | Breach notification required, SLA penalties triggered |
5 | Severe | Existential or near-existential consequence | Multi-customer breach, contract terminations, regulatory action |
Publish these two tables as an appendix to your risk methodology document (a short, separate policy is worth writing — auditors will ask for it) and reference them explicitly whenever you score a new risk. Consistency, not sophistication, is what CC3.2 rewards.
"I don't grade risk registers on whether they used a 5x5 matrix or a 3x3 one. I grade them on whether the same analyst would score the same risk the same way twice. If two people on the same team would land on wildly different numbers for the same scenario, the methodology isn't doing its job." — Dana Kowalczyk, Director of Internal Audit, Lumenbridge Analytics
Inherent Risk vs. Residual Risk: The Methodology
This is the single most misunderstood mechanic in risk registers I review, so it's worth spelling out precisely. Inherent risk is the level of exposure that would exist with no controls in place at all — the raw likelihood and impact of the scenario in a vacuum. Residual risk is what remains after accounting for the controls you currently have operating. The gap between the two is, functionally, the value your control environment is delivering — and it's the number that should shrink as your control maturity improves.
Step | Action | Output |
|---|---|---|
1 | Write the risk statement with no controls assumed | Raw scenario description |
2 | Score inherent likelihood and inherent impact independently | Two 1–5 scores |
3 | Multiply to get inherent risk score (1–25 scale) | Inherent risk score |
4 | List all existing controls that reduce likelihood or impact | Control list |
5 | Re-score likelihood and impact assuming those controls are operating | Two adjusted 1–5 scores |
6 | Multiply to get residual risk score | Residual risk score |
7 | Compare residual score to your defined risk appetite threshold | Accept / treat further |
A common error is scoring inherent and residual risk identically because the analyst mentally "already assumed controls" when picking the inherent score — this collapses the entire exercise and is one of the first things a sharp auditor will probe. If every risk in your register has identical inherent and residual scores, expect a pointed follow-up question.
The Risk Heat Map
Once scored, risks should be visualized on a heat map so leadership can prioritize without reading twenty-one fields per row. This is also one of the artifacts auditors most frequently ask to see presented to the board or leadership team as evidence that risk information reaches decision-makers — a CC1 and CC2 tie-in as much as a CC3 one.
Impact ↓ / Likelihood → | 1 – Rare | 2 – Unlikely | 3 – Possible | 4 – Likely | 5 – Almost Certain |
|---|---|---|---|---|---|
5 – Severe | 5 (Med) | 10 (High) | 15 (High) | 20 (Critical) | 25 (Critical) |
4 – Major | 4 (Med) | 8 (Med) | 12 (High) | 16 (High) | 20 (Critical) |
3 – Moderate | 3 (Low) | 6 (Med) | 9 (Med) | 12 (High) | 15 (High) |
2 – Minor | 2 (Low) | 4 (Low) | 6 (Med) | 8 (Med) | 10 (High) |
1 – Negligible | 1 (Low) | 2 (Low) | 3 (Low) | 4 (Low) | 5 (Med) |
Define your bands once (typically Low 1–4, Medium 5–9, High 10–16, Critical 17–25) and hold to them across every risk in the register — and across every reporting period, so trend lines are comparable year over year.
Fraud Risk: The Criterion Everyone Forgets
CC3.3 requires that your organization "considers the potential for fraud in assessing risks to the achievement of objectives." In my experience this is the single most commonly missed sub-criterion in first-time SOC 2 registers, because most engineering-led compliance programs think about fraud as someone else's problem — finance's problem, or nobody's problem, because "we're not a bank." That reasoning doesn't survive an audit. Fraud risk isn't limited to financial statement fraud; in a SOC 2 context it covers any intentional act to deceive, misappropriate, or circumvent controls, including by employees.
Fraud Risk Category | Example Scenario | Typical Mitigating Control |
|---|---|---|
Misappropriation of assets | Employee redirects customer refunds to a personal account | Segregation of duties, dual approval on payouts |
Fraudulent financial reporting | Revenue recognition manipulated to hit a target | Independent finance review, reconciliation controls |
Management override of controls | Executive bypasses change approval to ship faster | Logged, non-bypassable approval gates |
Collusion | Two employees jointly circumvent a segregation-of-duties control | Rotation of duties, anomaly monitoring |
Unauthorized system access for gain | Support engineer uses impersonation access to view/alter customer data improperly | Logged and reviewed impersonation sessions |
Vendor/procurement fraud | Kickback arrangement in vendor selection | Independent procurement review, conflict-of-interest disclosures |
The COSO fraud triangle — pressure, opportunity, rationalization — is a useful lens for the workshop itself: for each of your organization's high-privilege functions (billing, payouts, data access, deployment), ask where opportunity exists (who has unchecked access), where pressure might exist (compensation structures, targets), and where rationalization might creep in (norms that make bypassing controls feel acceptable). Document that discussion happened — meeting notes, a dated fraud-risk workshop agenda, and resulting register entries are exactly the evidence CC3.3 is looking for.
"The fastest way to fail a fraud-risk conversation with an auditor is to say 'we haven't really thought about that.' You don't need a forensic accountant on staff. You need forty-five minutes once a year where finance, security, and engineering leadership sit down and ask, 'if someone here wanted to cheat the system, how would they do it, and would we notice?'" — Renata Osei, CISO, Northbridge Pay
Case Study: The Fraud-Risk Gap at Northbridge Pay
Northbridge Pay, a payments-adjacent fintech Renata Osei joined mid-way through their second SOC 2 Type II cycle, had a technically strong register — forty-one entries, clean scoring, tight control mappings — with exactly zero entries tagged fraud-relevant. During fieldwork, the auditor asked a direct CC3.3 question: how does the organization consider fraud risk specifically? The team's honest answer — "we handle that informally in finance" — wasn't sufficient documentation, and it became a management-response item rather than a clean pass.
Osei's team ran a two-hour fraud-risk workshop covering payout processing, support impersonation tooling, and vendor selection, producing six new register entries explicitly tagged as fraud-relevant, each with a named owner and a control mapping (dual-approval payouts, impersonation session logging with weekly review, and a documented procurement conflict-of-interest policy). The following year's audit closed with zero CC3-related exceptions, and the fraud-risk workshop became a standing item on the internal audit calendar — a fix that took less than a day of combined effort but closed a criterion that had generated a documented finding.
Risk Ownership: Who's Actually Accountable
A risk with no owner is a risk nobody manages. Ownership should be assigned to an individual — not a team, not a department — and that individual should have both the authority and the operational proximity to act on it.
Risk Category | Typical Owner | Escalation Path |
|---|---|---|
Access management | Head of IT/Infrastructure | CISO |
Application security | Engineering lead / AppSec lead | CTO |
Vendor/third-party | Procurement or Vendor Risk lead | CISO |
Fraud | Finance controller + Compliance lead | CFO |
Business continuity | Operations lead | COO |
Data privacy | Privacy officer / DPO | General Counsel |
Physical security | Facilities manager | COO |
Regulatory/legal | General Counsel | CEO |
Document the escalation path too — a register that shows only "owner: Sarah" without a defined path for what happens if Sarah's treatment plan slips past its due date leaves a governance gap CC1 and CC9 both probe.
Linking Risks to Controls
A risk register that exists in isolation from your control documentation forces auditors to do the mapping work themselves, which they will do imperfectly and which will generate unnecessary follow-up requests. The fix is a direct, bidirectional reference between each register entry and the specific control(s) in your SOC 2 Control Matrix: Mapping Controls to Criteria that mitigate it.
Risk ID | Risk Statement | Linked Control ID(s) | Control Name | TSC Mapped |
|---|---|---|---|---|
RR-003 | Unauthorized production access via shared credentials | AC-04, AC-07 | Unique user accounts; MFA enforcement | CC6.1 |
RR-011 | Undetected malicious code deployed via CI/CD | CM-02, CM-06 | Peer-reviewed pull requests; automated pipeline scanning | CC8.1 |
RR-014 | Loss of customer data availability due to vendor outage | VN-05 | Subservice organization SLA monitoring | CC9.2 |
RR-019 | Payout fraud via unauthorized transaction approval | FR-02 | Dual-approval payout workflow | CC3.3 / CC5.1 |
RR-022 | Sensitive data retained beyond policy | DC-03 | Automated data retention and deletion job | CC6.5 |
This table format — kept as a living cross-reference, not a one-time export — is what lets an auditor trace a control objective back to the risk it exists to mitigate in under a minute, which is exactly the kind of walkthrough that shortens fieldwork rather than extending it. It also directly supports the day-to-day operational view covered in SOC 2 Control Activities: Day-to-Day Operational Controls.
Risk Treatment: Choosing and Documenting a Response
Once a risk is scored, someone has to decide what to do about it. There are exactly four defensible options, and the register should record which one was chosen, by whom, and why.
Treatment | Definition | When to Use | Documentation Required |
|---|---|---|---|
Mitigate | Reduce likelihood or impact through controls | Residual risk still above appetite; cost-effective controls exist | Control(s) implemented, target completion date |
Accept | Knowingly retain the risk without further action | Residual risk within appetite, or cost of treatment exceeds benefit | Written acceptance, approving authority, review date |
Avoid | Eliminate the risk by not engaging in the activity | Risk fundamentally outweighs business value | Decision record, alternative approach if any |
Transfer | Shift financial impact to a third party | Insurable risk, or contractually shiftable to a vendor | Insurance policy or contract reference |
Risk treatment decisions should never be silent defaults. "Accept" chosen because no one got around to fixing it is a control deficiency waiting to be found by an auditor; "Accept" chosen deliberately, with a named approver and a documented rationale tied to your risk appetite statement, is defensible governance. The difference between those two outcomes is entirely in the documentation.
Corrective Action Plans and Remediation Tracking
For any risk where the treatment decision is "Mitigate," the register (or a linked remediation tracker) needs a corrective action plan with enough structure that progress — or the lack of it — is visible without a status meeting.
CAP Field | Purpose |
|---|---|
CAP ID | Unique reference, linked to Risk ID |
Root cause | Result of root cause analysis, not just symptom description |
Remediation actions | Specific, numbered steps |
Owner | Individual accountable for execution |
Target date | Committed completion date |
Interim compensating control | Stopgap measure while remediation is in progress, if applicable |
Status | Not started / In progress / Delayed / Complete |
Verification method | How completion will be confirmed (test, review, evidence artifact) |
Verified by | Independent reviewer, distinct from the person who performed the fix |
Closure date | When verification was completed |
Auditors testing CC9.1 specifically want to see that mitigation activities were not just planned but tracked to completion, with independent verification. A CAP list where every item shows "Complete" but no verifier field is populated reads as self-reported, which weakens its evidentiary value considerably.
Review Cadence: Proving the Process Is Alive
This is the single fix that would have saved Priya Nandakumar three weeks of audit follow-up: a defined, documented, and followed review cadence, tiered by risk severity so high-risk items get more attention than low ones.
Risk Tier | Review Frequency | Who Reviews | Evidence Artifact |
|---|---|---|---|
Critical (17–25) | Monthly | Risk owner + CISO/leadership | Meeting notes, updated register entry |
High (10–16) | Quarterly | Risk owner + GRC lead | Updated register entry, status change log |
Medium (5–9) | Semi-annually | Risk owner | Register entry timestamp, brief note |
Low (1–4) | Annually | GRC lead (batch review) | Annual review sign-off |
Full register | Annually (minimum) | Leadership team / risk committee | Signed annual risk assessment summary |
The evidence column matters as much as the cadence itself — a "date last reviewed" field that updates without any accompanying artifact (meeting notes, a Slack thread, a ticket) is easy for an auditor to dismiss as a field someone edited five minutes before the audit. Tie every review to something dated and attributable.
"I ask for the meeting invite, not just the updated spreadsheet. If nobody can produce a calendar entry, an agenda, or even a thread where the risk committee actually discussed the register in the last quarter, I have to treat the review as undocumented — which for Type II purposes is functionally the same as it not happening." — Marcus Delgado, SOC 2 Lead Auditor, Fielding & Cross CPAs
Change-Triggered Reviews: Satisfying CC3.4
Calendar-based review alone isn't enough. CC3.4 specifically requires that you identify and assess changes that could significantly affect internal control — meaning your register also needs an event-driven trigger list, separate from the routine cadence above.
Trigger Event | Example | Required Action |
|---|---|---|
New product or major feature launch | Adding a payments module to an analytics platform | Risk workshop before/at launch; new entries added |
New or changed vendor/subservice organization | Migrating to a new cloud provider | Vendor risk assessment; register updated |
Organizational restructuring | Engineering reorg changing who owns production access | Ownership fields updated; access-risk re-scored |
M&A activity | Acquiring a company with its own systems | Full risk assessment of acquired environment |
New regulatory obligation | Entering a state/country with new data-protection law | Legal review; new compliance-risk entries |
Significant security incident | A near-miss or actual breach | Postmortem-driven register update within 30 days |
Major architecture change | Moving from monolith to microservices | Re-assessment of affected risk entries |
Logging these triggers — even as a simple dated table showing "event, date, register action taken" — is often the fastest way to demonstrate CC3.4 compliance in an audit interview, because it converts an abstract requirement into a concrete, checkable list.
Evidence Auditors Expect From an Ongoing Risk Process
Pulling together everything above, here's the evidence inventory I hand new clients before their first Type II fieldwork, mapped to what it proves.
Evidence Artifact | Proves | Typical Source |
|---|---|---|
Current, dated risk register export | CC3.2 — risks identified and analyzed | GRC tool or spreadsheet |
Risk scoring methodology document | Consistent, defensible scoring | Policy document |
Annual risk assessment workshop notes/agenda | CC3.1, CC3.2 — objective-driven identification | Meeting minutes |
Fraud-risk workshop notes and tagged entries | CC3.3 | Meeting minutes, register tags |
Change-trigger log | CC3.4 | Register or change log |
CAP tracker with verification fields | CC9.1 — mitigation activities tracked to completion | Ticketing system or GRC tool |
Vendor risk assessments linked to register | CC9.2 | Vendor management records |
Review cadence log (dates, attendees, notes) | Ongoing process, not point-in-time | Calendar invites, minutes |
Risk-to-control cross-reference | Ties CC3 to operating controls | Control matrix |
Risk acceptance approvals | Governance over "Accept" decisions | Signed acceptance forms |
A useful sanity check before fieldwork: pick five risks at random from the register and see whether you can produce every relevant row of this table for each one in under ten minutes. If you can't, that's the gap to close before the auditor finds it for you.
Case Study: Catching a Gap Before It Became a Finding at Meridian Health Cloud
Tom Whitfield's team at Meridian Health Cloud, a healthtech platform handling scheduling and records data for outpatient clinics, had built their review cadence exactly as outlined above — quarterly reviews for high-tier risks, with the GRC lead running each session against a checklist. During a routine Q2 review, a risk owner flagged that a key claims-processing subservice organization had quietly changed its own subprocessor list, adding a new data-hosting partner Meridian's team hadn't vetted.
Because the quarterly cadence existed and was actually followed, that change surfaced in a scheduled review rather than during audit fieldwork three months later — or worse, after an incident. Whitfield's team ran an emergency vendor risk assessment, updated two register entries, and added a new complementary-control requirement to their vendor contract addendum, all documented and closed within three weeks. Whitfield estimated the avoided cost — of a mid-audit scramble, a potential qualified opinion, and the customer-trust damage of a late-discovered subprocessor gap — at roughly $340,000 when accounting for delayed renewals and consulting fees for emergency remediation. "The register didn't prevent the vendor from making that change," Whitfield told me. "It made sure we found out about it on our schedule instead of the auditor's."
Common Risk Register Mistakes (and the Fix)
Mistake | Why It Fails CC3/CC9 | Fix |
|---|---|---|
Built once, never updated | No evidence of an ongoing process (Type II requirement) | Tiered review cadence with logged evidence |
Identical inherent and residual scores everywhere | Suggests controls aren't actually being factored in | Re-score residual risk explicitly against listed controls |
No fraud-tagged entries | Fails CC3.3 outright | Run a dedicated fraud-risk workshop annually |
No named individual owners | No accountability trail | Assign a person, not a team, to every risk |
Risks not linked to controls | Forces auditor to reconstruct mapping manually | Maintain a bidirectional risk-to-control cross-reference |
"Accept" used as a default for unfinished work | Looks like an unmanaged control deficiency | Require written rationale and approver for every acceptance |
Register scope doesn't match system description | Creates inconsistency an auditor will flag | Reconcile scope against the SOC 2 system description each cycle |
No change-trigger log | Fails CC3.4 | Maintain a simple dated trigger-and-action table |
Scoring done by one person with no calibration | Introduces bias, inconsistency | Score in a cross-functional workshop, not solo |
CAP items marked complete with no verification | Self-reported evidence is weak | Require an independent verifier field |
Spreadsheet vs. GRC Platform: Choosing Your Tooling
Most companies start on a spreadsheet, and that's fine for a first Type I cycle — but the review-cadence and evidence-trail requirements above get materially harder to sustain manually as the register grows past thirty or forty entries.
Factor | Spreadsheet | GRC Platform |
|---|---|---|
Setup cost | Low (free–minimal) | Moderate–high (licensing) |
Version history/audit trail | Manual, error-prone | Automatic, timestamped |
Reminder/cadence automation | Manual calendar discipline | Built-in workflows and alerts |
Risk-to-control linkage | Manual cross-reference, easy to drift | Native linking, often bidirectional |
Evidence attachment | Separate folder structure needed | Attach directly to the risk entry |
Scalability past ~50 risks | Becomes unwieldy | Designed for scale |
Auditor familiarity | Universally understood | Increasingly expected at scale |
Best fit | Early-stage, first Type I | Established program, recurring Type II |
Whichever you choose, the fields and methodology in this article transfer directly — a spreadsheet with disciplined use of every field above will outperform an expensive GRC platform used carelessly, every time. Our SOC 2 Control Matrix / RACI Template includes a companion risk register tab built to this exact field structure if you want a starting point rather than building from scratch.
The Risk Lifecycle, Visualized
flowchart LR
A[Identify Risk] --> B[Score Inherent<br/>Likelihood x Impact]
B --> C[Map Existing Controls]
C --> D[Score Residual Risk]
D --> E{Residual Risk<br/>vs. Appetite}
E -->|Above appetite| F[Select Treatment:<br/>Mitigate/Avoid/Transfer]
E -->|Within appetite| G[Accept<br/>with documented approval]
F --> H[Build Corrective<br/>Action Plan]
H --> I[Track to Completion<br/>+ Independent Verification]
I --> J[Update Register]
G --> J
J --> K[Scheduled Review<br/>by Risk Tier]
K --> L{Change Trigger<br/>Event?}
L -->|Yes| A
L -->|No| KThis loop — identify, score, treat, verify, review, repeat — is what an auditor is actually looking for when they ask "walk me through your risk assessment process." If you can point to each node on this diagram and produce a dated artifact for it, you've satisfied CC3 and CC9 in one conversation.
Building the Register Step by Step
For teams starting from nothing, or repairing a stale register like Priya's, here's the build sequence that fits inside a typical six-to-eight-week readiness sprint.
Week | Activity | Output |
|---|---|---|
1 | Define scope, objectives, and risk appetite statement | Scope document, appetite thresholds |
1–2 | Draft scoring methodology (likelihood/impact scales, formulas) | Methodology policy |
2–3 | Run cross-functional risk identification workshop(s) | Draft risk list (25–50 entries typical) |
3 | Run dedicated fraud-risk workshop | Fraud-tagged entries |
4 | Score inherent and residual risk for each entry | Populated scores |
4–5 | Assign owners, treatment decisions, and CAPs where needed | Fully populated register |
5 | Link each risk to control matrix entries | Cross-reference complete |
6 | Present to leadership/risk committee for review and sign-off | Signed-off baseline register |
Ongoing | Execute review cadence per risk tier | Recurring evidence trail |
Six weeks sounds long for what looks like a spreadsheet exercise, but the workshops are where the real work happens — and skipping them is exactly how registers end up looking like they were filled out by one person in an afternoon, which auditors can usually tell on sight.
Integrating Vendor and Third-Party Risk
CC9.2 explicitly calls out vendor and business-partner risk, and the cleanest way to satisfy it is to ensure your vendor risk process feeds directly into the same register rather than living in a disconnected spreadsheet nobody cross-references.
Vendor Risk Element | Where It Lives | Register Integration |
|---|---|---|
Vendor criticality tier | Vendor management system | Determines review frequency for linked risks |
Vendor's own SOC 2/ISO certification status | Vendor due-diligence file | Referenced as a mitigating control |
Subservice organization method (carve-out vs. inclusive) | System description | Flags whether vendor risk needs independent scoring |
Data shared with vendor | Data mapping | Determines impact score if vendor is compromised |
Contractual security requirements | Contract/DPA | Referenced as a control in the risk entry |
Vendor incident history | Vendor management log | Feeds likelihood re-scoring |
Treating vendor risk as a first-class category within the main register — rather than a separate silo — is what let Meridian Health Cloud's team catch the subprocessor change during a routine review instead of missing it entirely. It's also directly relevant to how you'll eventually document SOC 2 Vendor Management: Third-Party Service Provider Assessment as a companion process.
Risk Appetite and Tolerance: Setting the Threshold
Every scoring exercise needs an anchor: at what residual score does your organization say "this is acceptable" versus "this needs further treatment"? That's your risk appetite, and it should be a documented, leadership-approved statement — not an implicit judgment call made differently by whoever's reviewing the register that week.
Risk Tier | Residual Score | Default Appetite Position | Approval Required to Accept |
|---|---|---|---|
Low | 1–4 | Generally acceptable | Risk owner |
Medium | 5–9 | Acceptable with monitoring | GRC lead |
High | 10–16 | Requires active treatment plan | CISO/leadership |
Critical | 17–25 | Not acceptable without exceptional justification | Executive team/board |
Risk tolerance — the acceptable variation around that appetite for a specific objective — is worth documenting separately for anything customer-facing; a SaaS company might have near-zero tolerance for availability risk on its core product but a wider tolerance for a rarely used internal admin tool. Writing this distinction down once saves a lot of re-litigated debate every time a new risk lands near a threshold.
Sample Register Entries, Walked Through
Seeing three fully worked entries end-to-end is often more useful than any field list. Here are three drawn from a composite of engagements, simplified for illustration.
Field | Entry A | Entry B | Entry C |
|---|---|---|---|
Risk ID | RR-005 | RR-018 | RR-027 |
Statement | Ex-employee retains active access post-termination | Unencrypted backup exposed via misconfigured storage | Support engineer uses impersonation access without review |
Category | Access management | Encryption/data protection | Fraud/insider misuse |
Inherent (L×I) | 4×4=16 | 3×5=15 | 3×4=12 |
Existing controls | Automated deprovisioning workflow, offboarding checklist | Storage bucket policy, encryption at rest | Impersonation logging, weekly log review |
Residual (L×I) | 1×3=3 | 1×4=4 | 2×3=6 |
Owner | Head of IT | Head of Infrastructure | VP Support |
Treatment | Mitigate (already largely mitigated; monitor) | Mitigate (already largely mitigated; monitor) | Mitigate — add real-time alerting |
Status | Closed (monitor) | Closed (monitor) | In progress |
Fraud-relevant | N | N | Y |
Linked control | AC-09 | DP-04 | FR-05, AC-14 |
Notice how the inherent-to-residual gap tells the real story: Entry C still has meaningful residual exposure precisely because its mitigating control (weekly review) is detective rather than preventive — a detective control catches misuse after the fact rather than a preventive control that stops it happening. That's exactly the kind of nuance a well-built register surfaces and a bare risk list never would.
Aligning With ISO 27001's Risk Register Approach
If your organization is pursuing SOC 2 alongside ISO 27001 — increasingly common as enterprise customers ask for both — it's worth knowing the two frameworks converge more than they diverge on risk management, even though SOC 2's CC3 is less prescriptive than ISO 27001's Clause 6.1.2 and 6.1.3 risk assessment and treatment requirements. ISO 27001 formally requires a documented risk assessment methodology, asset-based or scenario-based risk identification, and a Statement of Applicability tying each identified risk to a specific Annex A control decision — while SOC 2's CC3 asks for functionally similar evidence without mandating a specific methodology. Many of my clients maintain a single risk register that satisfies both: the field structure in this article maps cleanly onto ISO 27001's requirements with the addition of a "related Annex A control" column alongside the SOC 2 control-matrix column. If you're weighing which framework's risk documentation to build first, Running ISO 27001 and SOC 2 Together walks through exactly this kind of dual-framework register design. Teams that have specifically documented their ISO 27001 risk register process as a standalone reference will find most of it transfers directly into the SOC 2 field structure above, with fraud-risk tagging and CC9 vendor-risk integration as the main additions to layer on top.
"We built one register, not two. The scoring scale is identical, the owner field is identical, and we just added a column for which Annex A control each entry maps to alongside the SOC 2 control ID. It cut our annual risk workshop time roughly in half compared to running it separately for each framework." — Sam Iyer, Founder, Vantage GRC Consulting
What to Expect in the Auditor Interview
Knowing the shape of the conversation ahead of time removes most of the anxiety around it. Here's what a CC3-focused interview typically covers, and how to prepare for each part.
Interview Topic | What the Auditor Wants | How to Prepare |
|---|---|---|
Walkthrough of the register | Understand structure, fields, and how it's used | Have it open, sorted by risk tier, ready to navigate live |
A sample of 3–5 specific risks | Trace identification → scoring → treatment → control linkage | Pick a mix of open, closed, and accepted risks in advance |
Fraud-risk consideration | Direct evidence of CC3.3 | Point to workshop notes and tagged entries |
Evidence of a change-triggered update | CC3.4 | Have one real example (a launch, a vendor change) ready |
Review cadence proof | Ongoing process, not point-in-time | Calendar invites, meeting notes, revision history |
How risks tie to the control matrix | CC3 to control-environment linkage | Demonstrate the cross-reference live |
Risk committee/leadership involvement | Governance and tone at the top | Show sign-off records or meeting attendance |
If you can answer all seven rows fluently without opening a second document to find the answer, the CC3 portion of your interview will likely be one of the shortest, least stressful parts of the entire audit.
The Risk Register as a Business Asset, Not Just an Audit Artifact
It's tempting to treat the risk register as pure audit overhead — a document that exists because CC3 requires it and otherwise sits untouched. That framing costs organizations real value. A well-maintained register is one of the fastest ways to answer the questions enterprise security reviewers ask before a deal closes: what are your top risks, how do you prioritize security investment, and how do you know your controls are actually working. Sales and customer-facing teams who can point to a living, governed risk process — rather than a generic security page — routinely shorten vendor security reviews, because they're answering the buyer's real underlying question (how do you think about what could go wrong) rather than a checklist proxy for it.
The register also pays for itself operationally. A prioritized, scored list of what could go wrong is exactly the input a CISO or engineering leader needs to make defensible tradeoffs about where the next security budget dollar goes — mitigating the highest residual-risk items first, rather than chasing whatever vulnerability made headlines that week. Priya Nandakumar's team at Lumenbridge didn't just fix their CC3 gap; they used the rebuilt register to justify a hardware-key MFA rollout that had been deprioritized for a year, because for the first time they had a defensible score showing it addressed their single highest-residual-risk entry. The $2.4 million renewal closed six weeks after the corrective action plan was submitted — not because the register alone won the deal, but because it gave the customer's security team exactly the evidence-backed answer they were looking for.
Treat your risk register as a strategic instrument for prioritization and customer trust, and the audit evidence it produces becomes a byproduct of doing the work well — rather than the work itself being a byproduct of satisfying an auditor.
Where to Go From Here
Building a SOC 2-ready risk register from scratch, or repairing one that's gone stale, is faster with a structured starting point than a blank spreadsheet. Our SOC 2 Readiness Checklist walks through where risk documentation fits alongside every other pre-audit requirement, and the SOC 2 Gap Analysis Tool will flag whether your existing register has the field-level and cadence gaps this article covers before your auditor does. If you're still mapping out terminology across the framework, the SOC 2 Glossary is a fast reference for every term used here and throughout the rest of this series. And if risk assessment is only one piece of a broader readiness gap, our team at PentesterWorld works with GRC leads and vCISOs directly on building — and defending — risk registers, control matrices, and the evidence trail behind both, before your auditor asks the questions Marcus Delgado asked Priya.