You can complete the SOC 2 risk assessment in one spreadsheet: list assets and processes, write risks against each, score likelihood and impact on a 1 to 5 scale, record controls and a treatment decision, then have leadership sign it. Date it and repeat at least yearly. This satisfies the intent of CC3.1 to CC3.4.
What does the criterion actually ask for?
CC3.1 asks that objectives are clear enough to identify risks. CC3.2 asks you to identify risks to those objectives across the entity and analyze them as a basis for deciding how to manage them. CC3.3 adds fraud. CC3.4 asks you to assess changes that could affect the control system, such as a new cloud region, an acquisition or a large customer.
Notice what is missing: no required scoring method, no required tool. The auditor in a Type 1 reads the design. They want to see a method, evidence that you used it, and that decisions followed from it.
Step 1: write down your objectives
Three or four sentences. For example: customer data stays confidential, the service stays available during business hours, code changes are reviewed, and staff access is removed on departure. Everything else hangs off these.
Step 2: build the inventory
Add one tab with rows for systems (production cloud account, source control, identity provider, ticketing), data types, vendors and key processes (deploy, onboard, respond to an incident). Keep it to what you really run. Thirty to sixty rows is normal for a small company.
Step 3: write risks in a fixed sentence
Use "Because of X, Y could happen, harming Z." For example: because production admin access is shared, an attacker could use a leaked credential, harming confidentiality of customer data. A fixed sentence stops vague risks like "cyber attack."
Step 4: score with a simple scale
Likelihood 1 to 5, impact 1 to 5, multiply for an inherent score. Define each number in a legend with plain words. A 5 for impact could mean customer data exposure or a multi day outage. A 1 could mean a small internal inconvenience. Then record the controls that already exist, and score again for residual risk.
Do not make the second score smaller by wishful thinking. If the control is a policy nobody follows, the residual score stays high.
Step 5: choose a treatment
For each risk above your threshold, pick mitigate, accept, transfer or avoid. Each choice needs an owner and a date. Accepting needs a named leader and a reason.
Step 6: cover the special cases
Add a row set for fraud (CC3.3): who can approve payments, who can change payroll, who can alter logs. Add vendor risk, which links to CC9.2. Add a change trigger list for CC3.4: new product, new data type, new region, merger, big hire or layoff, a major incident. When a trigger happens, you update the sheet and note it.
Sample rows
- Shared admin credential leaks. Likelihood 3, impact 5. Controls: single sign on, MFA, no shared accounts. Residual 2 times 5 = 10. Mitigate, owner CTO.
- Vendor with customer data has a breach. Likelihood 2, impact 4. Controls: vendor review, contract terms. Residual 2 times 3 = 6. Accept with a yearly review.
- Unreviewed code reaches production. Likelihood 3, impact 4. Controls: branch protection, required review. Residual 1 times 4 = 4. Mitigate, owner engineering.
What to do
- Write the objectives and the scoring legend, and have leadership approve both.
- Build the inventory tab from real systems, not from a template.
- Draft at least 20 risks in the fixed sentence format, spread across assets and vendors.
- Score inherent and residual risk, and link each risk to a control that exists.
- Choose treatments, owners and dates, and hold a 60 minute review with leadership.
- Save the dated, signed version as evidence, and schedule the next review.
Quick check
Do we need a certified risk framework to pass?
No. The criteria do not name one. A simple, consistent, documented method that you actually use is enough for the design test.
How often should we update it?
At least once a year, and whenever a change trigger from your list happens. Keep every dated version.
How Safeguard helps automate this
Spreadsheets work until the inventory goes stale. Safeguard's compliance suite covers frameworks, controls and evidence, and continuous monitoring runs between audits so the controls you list in a risk row are checked, not only described. Technical evidence comes from your real code and dependencies: scans, SBOMs and reachability analysis show which vulnerable packages are actually exercised, which makes likelihood scores less of a guess. Autonomous remediation can open tested fix pull requests, but it is off by default, every category starts on Manual, and you choose what runs automatically. Safeguard helps prepare evidence. The independent auditor decides whether your design is adequate. Book a call to see how it fits.
Sources
- AICPA, Trust Services Criteria (2017, with 2022 points of focus): CC3.1, CC3.2, CC3.3, CC3.4, CC9.2, paraphrased.
- Type 1 reports describe the design of controls at a point in time and give no opinion on operating effectiveness (AICPA text).
Last reviewed: 18 October 2026.
