Skip to content

SOC 2® risk assessment and monitoring in plain English

Unofficial plain-English guide. Not affiliated with or endorsed by the AICPA. Read the AICPA’s own criteria

An unofficial plain-English look at SOC 2 criteria CC3, CC4, and CC5: finding risks, checking that controls work, and turning decisions into policies.

By Blank Slate Creative.

OrderFive custom security policies, $85 flat. Markdown, Word, and PDF.

Order the five policies

What could go wrong, what are you doing about it, and how do you know?

These three groups form a loop. You work out what could stop you keeping your promises (CC3), you check that your protections work (CC4), and you choose and write down the protections themselves (CC5).

For a startup the loop produces a few ordinary documents: a risk register, a record of recurring checks, and a policy set. The work is keeping them honest, so that each one describes what the team does and not what it hopes to do.

Where a small team starts

Start the risk register as a spreadsheet with a dozen rows: what could go wrong, how bad, who owns it, what you are doing about it, and when you will look again. Twelve true rows beat sixty copied from a template, because a reviewer asks about the ones on the page.

Then pick one recurring check you already do, such as a monthly look at who holds admin rights, and put it on a calendar with a place to record the result. One check with a record is worth more than ten described in a policy and never run.

The criteria, CC3.1 to CC5.3

Below are our short labels, what the criteria are about, and examples of what a small team might do or keep. The examples are our own views, not requirements of the standard.

CC3.1: Goals to measure risk against

Before listing risks, the company states what it is trying to protect and promise, such as uptime, customer data, and delivery dates. Risks only mean something against those goals.

In practice

  • A paragraph of security objectives at the top of the risk register.
  • A list of promises made to customers, such as uptime and data handling, that each risk maps back to.
  • A yearly check that the objectives still match the business.

CC3.2: Finding, rating, and deciding on risks

The company looks for what could stop it keeping its promises, rates each one, and decides what to do: fix it, reduce it, share it, or accept it. The decisions are recorded.

In practice

  • A risk register in a spreadsheet with an owner, a rating, a decision, and a review date for each row.
  • A yearly risk meeting with notes on what changed since the last one.
  • A risk accepted in writing by a named person, with a date to look again.
  • Rows for vendors and people, not only for servers.

CC3.3: Counting fraud and misuse as risks

The risk review asks how someone could abuse access, bend a process, or take money or data for themselves. It also considers the pressure and incentives that make that more likely.

In practice

  • Register rows for invoice fraud, insider data theft, and misuse of admin rights.
  • A call-back rule before anyone changes bank details or approves an unusual payment.
  • A second approver for refunds, payouts, and large transfers.

CC3.4: Noticing changes that shift your risks

New products, tools, leaders, rules, or sudden growth change the risk picture. The company has a habit of noticing and reassessing when they happen.

In practice

  • A risk review triggered by a new cloud provider, a new type of data, or an acquisition.
  • A line in project kickoffs asking whether the change affects security.
  • A change log on the risk register showing it was updated after big shifts.

CC4.1: Checking that controls really run

The company tests its own controls on a schedule, through ongoing checks and occasional deeper reviews, and doesn’t rely on the people who run a control to grade it. Results are kept.

In practice

  • A monthly ticket to review who has admin rights, closed with the evidence attached.
  • An automated alert when any account has multi-factor sign-in switched off.
  • A yearly penetration test or outside review.
  • A control list with the date each was last checked.

CC4.2: Escalating findings to the right people

A failed control check helps only if it reaches someone who can fix it, and leadership when the problem is serious. Reviewers look for findings that are tracked through to closure.

In practice

  • Finding tickets with an owner and a due date.
  • A standing item in the monthly leadership meeting for open security findings.
  • A written note to the founder or CTO when a serious finding appears.
  • Closure notes that show the evidence the fix worked.

CC5.1: Picking controls that fit your risks

The company chooses controls so that the risks it ranked fall to a level leadership will live with. It weighs cost and practicality and keeps the link between each risk and its control.

In practice

  • A column on the risk register that points each risk to the policy or tool that reduces it.
  • A note explaining why an expensive control was skipped and what covers the gap instead.
  • A mix of controls that prevent and controls that detect, such as multi-factor sign-in plus alerting.

CC5.2: Baseline rules for your technology

Controls on individual apps are only as strong as the shared technology under them, so that foundation needs house rules of its own. Expect a reviewer to ask for the standard setup that new machines and servers start from.

In practice

  • A standard laptop and server setup, kept as code or an image.
  • Automatic patching on a schedule the team can state.
  • Infrastructure kept in version control, so changes can be read and reviewed.

CC5.3: Policies and the procedures behind them

Controls rest on two layers of writing: policies that set expectations, and procedures that describe how the work is done. Owners review both on a cycle and fix them when practice changes.

In practice

  • Each policy has an owner, a version, and a review date.
  • A runbook for tasks like offboarding, linked from the policy that requires it.
  • A log of exceptions, with who approved each one.
  • A walk-through now and then to confirm the procedure matches what people do.

Questions worth being able to answer

These are ours, not a list of what an examiner will ask. If you can answer each in a sentence, and show where the proof lives, you are in good shape for the conversation.

  • Show me your last risk review. What changed since the one before?
  • Who decided to accept this risk, and when do they look at it again?
  • How would you find out that a control had stopped working?
  • What happened to the last problem a check turned up?
  • Where is the policy, and where is the procedure that carries it out?

More topics in this guide

This page is one part of our unofficial guide to the SOC 2 Trust Services Criteria. Here are the others.

Related guides

About this guide and the study tool

Who we are, and aren’t

Blank Slate Creative, LLC is not affiliated with, endorsed by, or sponsored by the AICPA, CIMA, or the Association of International Certified Professional Accountants. We are not a CPA firm. Only a licensed CPA firm can perform a SOC 2 examination and issue a report.

What this is, and isn’t

This is an unofficial, plain-English explanation written by Blank Slate Creative, LLC. It is not the Trust Services Criteria, and it does not reproduce or replace them.

It is not legal, audit, or attestation advice.

Using this guide or the study tool does not mean you will pass an audit or satisfy any customer or auditor.

The “in practice” notes and examples are our own views, not requirements of the standard.

Written about the 2017 criteria with the 2022 revised points of focus. The AICPA may revise them.

Read the AICPA’s own publication for the authoritative wording. The PDF download asks for a free AICPA account.

Trademarks

AICPA and American Institute of CPAs are trademarks of the American Institute of Certified Public Accountants and are registered in the US, the EU and other countries.

SOC 1®, SOC 2® and SOC 3® trademarks are registered trademarks of the AICPA.

← All guides