Templates · Last updated 31 July 2026 · 5 min read

The SOC 2 risk register, filled in

Most of these are an empty grid behind an email form. Here is the grid with rows in it, and the reasoning that decides what a row says.

A SOC 2 risk register template is one table: every risk you have identified, scored for likelihood and impact, assigned to a named owner, and pointed at the control that treats it. The one below is filled in rather than blank.

Copy the columns, delete our rows, write yours. Six seeded rows follow, written for a twelve person software company on AWS, because an empty grid teaches nobody what a real row sounds like.

Search this and you get a form: an email address for nine blank columns and a tab called Instructions. The grid was never the hard part.

The columns that carry it

Eleven. Two of them decide whether the register is operable at all: the owner, and the control reference.

Column	What goes in it	Why it earns its place
ID	R-01, never reused	Everything downstream points here
Risk	What happens, and to what	A category cannot be scored
Category	Access, change, availability, vendor, people, fraud	Exposes the area you skipped
Owner	One named person	Owned by a team means owned by nobody
Likelihood, impact	One number each	Kept apart so the score is arguable
Score	Likelihood times impact	Sets the order you work in
Treatment	Mitigate, transfer, avoid or accept	CC3.2 wants the analysis to drive a decision
Control	An ID from your control list	The link that makes a register testable
Evidence	The artifact, and where it lives	Turns a reference into something openable
Residual score	The score after treatment	Shows the register moved
Dates	Identified, last reviewed, next review	Coverage is shown with dates

The register, with six rows in it

These are rows a twelve person company actually has, not unauthorized access as a heading. L and I are likelihood and impact on the scale below.

ID	Risk	Owner	L	I	Score	Treatment	Control	Evidence
R-01	An engineer leaves and keeps AWS and GitHub access, because offboarding is a Slack message	CTO	3	5	15	Mitigate	AC-04	Offboarding checklist, access review export
R-02	Long lived AWS access keys sit on laptops and never rotate	Platform lead	3	4	12	Mitigate	AC-07	Monthly IAM credential report, keys over ninety days
R-03	All four engineers approve and merge their own pull requests	CTO	4	3	12	Mitigate	CM-02	Branch protection export, sample of merged requests
R-04	The production database snapshots nightly and nobody has restored one	Platform lead	2	5	10	Mitigate	BC-01	Quarterly restore test record, with duration
R-05	One admin role issues refunds and edits the billing record behind them	CEO	2	4	8	Mitigate	FR-01	Monthly refund report, signed and dated
R-06	The transactional email vendor holds customer addresses and has no SOC 2 report	Head of operations	3	3	9	Accept, CEO, review at renewal	VM-03	Acceptance memo, vendor register entry

One caveat across the whole table

Polara G.R.C. scopes Security only, and that examination does not test availability commitments.² R-04 still belongs in your register, because recovering from a security incident sits inside the common criteria, but how far it gets examined moves with scope. Which criteria to include covers the choice.

Why the criteria ask for this at all

The register is not administrative theater. The 2017 Trust Services Criteria fold COSO into the common criteria, and four of the results are about risk.¹ CC3.1 wants objectives specific enough to have risks attached. CC3.2 wants those risks analyzed as the basis for deciding how they get managed. CC3.3 wants fraud considered deliberately, which R-05 does above. CC3.4 wants changes reassessed, and CC9.1 asks for mitigation activities covering business disruption.

Read CC3.2 slowly. A register with no treatment column does not answer it.

Scoring, and why an elaborate scale costs you

Rate likelihood one to five. Rate impact one to five. Multiply. Twenty five possible scores, and a three by three grid works just as well. What has to hold is that the scale is written down, that a four means the same in row one and row twenty, and that higher scores get worked first.

Time disappears into something cleverer: weighted asset criticality, annualized loss expectancy, four decimals of precision on a number somebody guessed. That machinery earns its keep where an actuary maintains it. At twelve people it produces scores nobody can reconstruct later. Write down what a four for likelihood means.

Treatment, including the risk you accept on purpose

Four decisions exist. Looking into it further is not one of them, and a row parked there is a row with no treatment at all.

Mitigate: Add or strengthen a control, then point the row at it. Five of six rows above end here.
Transfer: Move the consequence, usually through insurance or a contract term. The event still happens.
Avoid: Stop doing the thing. Drop the feature, the vendor, or the data you never needed.
Accept: Decide that carrying it beats treating it. The only one that needs a signature.

An acceptance needs three things the others do not. A named person with authority to accept the risk for the company, the date they accepted it, and the date it gets revisited. The engineer who found it does not sign it. At this size that signature belongs to a founder or an officer.

R-06 is what that looks like written down: a vendor with no report, accepted knowingly, signed by the CEO, pinned to the renewal date so the decision expires on its own. The reasoning belongs in the row. Segregation problems like R-03 and R-05 come with the headcount, and what changes on a small team covers the substitutes.

Review cadence, and the two dates that matter

Annually is the floor. Quarterly survives a company that ships. Between reviews CC3.4 is the criterion that bites: a change big enough to move your risk profile triggers one.¹ A new subservice organization, a first enterprise customer, an incident, a new production region.

Two dates decide whether a review is evidence: the one on the review, and the one your reporting period opens on.³ A register last reviewed four months before your window opened is a fine document and no evidence. For a Type 2 the shortest period available is a 3-month observation window, so at least one review lands inside it. How long the observation period runs explains the floor.

Row, control, evidence

Build the register so one walk always works. Pick a row, name the control that treats it, open the evidence that control produced. A row missing any of the three is a claim rather than a control.

Row to control. An identifier from your own control list, not a criterion number. CC6.2 is a criterion. AC-04 is a thing you operate.
Control to evidence. Name the artifact and where it lives: the export carrying a date, a reviewer and the removals it produced.
Evidence back to the row. An access review that removed nobody three quarters running points at R-01, still scored fifteen.

Most of those artifacts already sit on the evidence request list an examination opens with. The PBC list, request by request is that evidence from the other side of the table, and the SOC 2 policy list covers the documents describing these controls.

Where the register meets the examination

The register indexes the rest of your evidence. Through Polara G.R.C. a SOC 2 Type 1 is $4,000 one time, with the first examination and the independent partner auditor engagement fee included. Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.

Questions

What is a SOC 2 risk register?

It is a single table listing the risks a company has identified, each one scored for likelihood and impact, assigned to a named owner, and pointed at the control that treats it. The SOC 2 common criteria ask for risks to be identified and analyzed as the basis for deciding how they get managed, and the register is where that analysis and that decision get written down.

What columns does a SOC 2 risk register need?

Eleven carry the work: an identifier that never gets reused, a one sentence risk statement, a category, a named owner, likelihood, impact, the score they produce, the treatment decision, the control that treats the row, where the evidence for that control lives, and the dates the row was identified and last reviewed. Anything beyond those is optional and you will maintain it forever.

How do you score risk in a SOC 2 risk register?

Rate likelihood one to five, rate impact one to five, multiply them for a score between one and twenty five. A three by three scale works just as well. What matters is that the scale is written down, that a four means the same thing in every row, and that higher scores get worked before lower ones. An elaborate model nobody can reconstruct six months later is worse than a crude one anybody can.

Can you accept a risk instead of fixing it?

Yes, and accepting a risk deliberately is a legitimate treatment decision. It needs three things the other treatments do not: a named person with the authority to accept it for the company, the date they accepted it, and the date it gets revisited. The person who found the risk is not the person who accepts it. Write the reasoning into the register row rather than leaving it in a message thread.

How often does a risk register have to be reviewed?

Annually is the floor and quarterly holds up better at a company that ships. Criterion CC3.4 asks for changes that could affect internal control to be identified and assessed, so a new subservice organization, a first enterprise customer, an incident or a new production region triggers a review whichever way the calendar reads. For a Type 2 report the review has to be dated inside the period the report covers, or it evidences nothing.

Sources

TSP Section 100, Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy AICPA. The criteria themselves, including the common criteria every SOC 2 report covers. Checked 1 August 2026.
Trust Services Criteria AICPA. The criteria overview and the current version in force. Checked 1 August 2026.
Statements on Standards for Attestation Engagements AICPA. The attestation standards a SOC 2 examination is performed under. Checked 1 August 2026.

Get audit-ready without a compliance team.

$4,000 one time for SOC 2 Type 1, with the first examination and the auditor engagement fee included. audit-ready starting at about a week.

Get started

Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.