SOC 2 risk assessment policy and register

CC3 asks whether you identify risks to your objectives and decide what to do about them. A dated register with owners and treatment decisions is the whole answer.

Last reviewed 2026-09-01Written by Jacob Masse, TrazTech Inc.

The risk assessment is the control most first-time companies do last and the one an auditor can dismiss fastest, because it is either a real document with owners and dates or it is a spreadsheet somebody produced the week before fieldwork. What satisfies CC3 is narrow: a stated objective, a method for identifying risks including fraud, a register that scores and ranks them, a treatment decision per risk with an owner, and evidence that management reviewed it. An afternoon and a half produces a defensible first version.

The policy behind it is short. It names who runs the assessment, how often, what scale is used, who approves the results, and what triggers an off-cycle reassessment. Two pages at most. The register is the artifact.

15 to 25 Risks in a first register for a company of 10 to 100 people

How do you actually run the assessment?

1. Write the objective in one sentence. For SOC 2 it is usually the security, availability and confidentiality of the customer data your product holds. Every risk below is a risk to that.
2. Get three or four people in a room for two hours: whoever owns infrastructure, whoever owns the product, whoever owns the company. Not a consultant working alone, because the value is in the argument.
3. List risks by walking your own system: how data gets in, where it rests, who can reach it, what you depend on, who leaves. Add the fraud category explicitly, since CC3 asks about fraud risk and most registers skip it.
4. Score each on likelihood and impact using a 1 to 5 scale you define in the policy. Multiply for an inherent score. Do not build anything more elaborate.
5. Name the existing controls, then score the residual risk. The gap between inherent and residual is what makes the register readable.
6. Decide treatment for each: mitigate with a named action and a date, accept with a named person accepting it, transfer to insurance or a contract, or avoid by not doing the thing.
7. Have management review and approve it in a meeting with minutes. The approval record is what CC3 evidence usually rests on.

A worked register extract

Scores below are likelihood times impact on a 1 to 5 scale, so 25 is the maximum. These are the rows that turn up in almost every Canadian SaaS company's first register, written the way they should read.

Two things make this extract read as real rather than generated. The residual scores are not all comfortable, and one row is accepted with a named accepter rather than mitigated. A register where every risk is mitigated to a low score is a register nobody believed while writing it. The vendor management policy is where the last two rows get their controls, and the continuity plan owns the second.

Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.

What cadence and what triggers a reassessment?

Annually is the right commitment for a company under a hundred people, with management review of the register at a shorter interval, usually quarterly, so that treatment actions get chased. Writing quarterly full assessments into the policy is a mistake: four thorough reassessments a year produces three shallow ones and an exception.

Name the off-cycle triggers explicitly. That is what turns the policy from a calendar entry into a live control. A material change in the product, a significant security incident, entering a new market or regulated data type, a new critical vendor, or an acquisition. Write those five and you have a policy that responds to events rather than only to dates.

What gets a risk assessment turned into a finding?

No date and no approver. A register with no assessment date, no attendee list and no evidence that management saw it is not an assessment. This is the single most common defect, and it is fixed by an agenda item and a set of minutes.

Generic risks nobody could act on. "Cyber attack", "data breach", "non-compliance" appear in every downloaded template. They are categories, not risks, and they produce no treatment decision. A risk statement should name a thing that could happen to a system you actually run.

No fraud consideration. CC3 asks about the potential for fraud in assessing risks to objectives. Most first registers are purely technical and skip it entirely, which is an easy question for an auditor to ask and an awkward one to answer. One or two rows covering payment fraud, expense abuse or insider misuse of customer data closes it.

Risks accepted with nobody accepting them. Acceptance is a legitimate treatment and it is often the right one. What fails is an accepted risk with a blank owner column, because acceptance is an act by a person with authority to accept it. Write the name.

A register disconnected from the gap analysis. If your gap analysis found six missing controls and none of them appear as risks, the two documents are describing different companies. An auditor who reads both will notice. Reconcile them once, and use the policy checklist to confirm whether risk content should sit in its own document or inside your information security policy. The policy templates page covers editing the inherited version down to something you will keep.

Common questions