SOC 2 controls

SOC 2 controls, written the way the teams that run them work.

The Trust Services Criteria state what must be true. The controls that make it true are yours to write, and the auditor tests what you wrote. The sample set below is arranged by the team that owns each control, because ownership is where a control either keeps running all year or quietly stops in month four.

Back to SOC 2 services

01 · Anatomy

Four parts every control needs

A control is testable only when all four are written down.

PartQuestion it answersWeak wordingTestable wording
OwnerWho does it?“IT”“The infrastructure lead”
FrequencyHow often, or on what trigger?“Regularly”“Each quarter, and whenever someone changes role”
ActionWhat exactly happens?“Access is managed”“Each production account is compared with the HR roster, and extras are removed”
EvidenceWhat is kept?Nothing stated“The signed review sheet and the removal tickets”

The criteria themselves are fixed: 33 common criteria in nine series, CC1 to CC9, plus optional series for availability, confidentiality, processing integrity and privacy. The AICPA publishes no matching set of controls. The first five series track the 17 principles of the COSO 2013 internal control framework, and CC6 to CC9 turn to access, operations, change and risk mitigation. Each line below ends with the criteria it most often supports; your own mapping may differ.

02 · Leadership & HR

Leadership and people

Mostly supports CC1 to CC5.

  1. GOV.1
    Security oversight meetingLeadership reviews security risks, incidents and open findings on a fixed cadence, and minutes are kept. (CC1.2, CC4.2)
  2. GOV.2
    Named security ownerA written role description makes one person accountable for the security programme. (CC1.3)
  3. GOV.3
    Yearly risk assessmentThreats to service commitments, fraud and major business changes included, are scored and each gets a treatment decision. (CC3.1 to CC3.4)
  4. GOV.4
    Policy sign-offEvery security policy carries an owner and an approval date, and is reviewed at least once a year. (CC5.3)
  5. GOV.5
    Commitments shared with customersSecurity commitments, and a route for reporting problems, are available to customers. (CC2.3)
  1. HR.1
    Screening before startBackground checks finish before a new joiner's first day, to the extent local law allows. (CC1.4)
  2. HR.2
    Conduct acknowledgementNew staff accept the code of conduct and acceptable-use policy during their first week. (CC1.1)
  3. HR.3
    Awareness trainingEveryone completes security training on joining and every year afterwards, and completions are tracked. (CC2.2)
  4. HR.4
    Leaver checklistHR's exit notice triggers account removal and device return, with both recorded. (CC6.2, CC6.3)

03 · Engineering & IT

Engineering and IT

Mostly supports CC6, CC7 and CC8.

  1. AC.1
    Single sign-on with MFAProduction and admin consoles accept only company identities protected by a second factor. (CC6.1)
  2. AC.2
    Access on requestNew access needs a ticket approved by the system owner before anyone grants it. (CC6.2)
  3. AC.3
    Quarterly access reviewSystem owners confirm every account still needs what it holds; removals are ticketed. (CC6.2, CC6.3)
  4. AC.4
    EncryptionCustomer data is encrypted when stored and when moving between systems. (CC6.1, CC6.7)
  5. AC.5
    Managed laptopsCompany laptops run disk encryption and anti-malware, confirmed through device management. (CC6.8)
  1. CH.1
    Second pair of eyesCode reaches the main branch only after a different engineer approves it. (CC8.1)
  2. CH.2
    Pipeline-only deploysEngineers cannot push straight to production; the pipeline deploys approved builds. (CC8.1, CC5.2)
  3. CH.3
    Emergency pathAn urgent fix may skip review beforehand but is reviewed afterwards within a set window. (CC8.1)
  1. OPS.1
    Central logs and alertsSecurity-relevant logs land in one place, and defined alerts page whoever is on call. (CC7.2)
  2. OPS.2
    Vulnerability scanningInfrastructure and dependencies are scanned on a schedule, with fix targets set by severity. (CC7.1)
  3. OPS.3
    Incident response planA written plan sets roles, severity levels and customer communication, and is exercised at least yearly. (CC7.3, CC7.4)
  4. OPS.4
    Restores, not just backupsBackups run daily and a restore is actually tested on a schedule. (CC7.5, A1.2, A1.3)

04 · Vendors & continuity

Suppliers, continuity and independent checks

Mostly supports CC4 and CC9, plus A1 when Availability is in scope.

  1. VR.1
    Supplier registerEvery supplier is listed with an owner, the data it touches and a risk grade. (CC9.2)
  2. VR.2
    Review before accessHigher-risk suppliers are assessed before they receive data or credentials. (CC9.2)
  3. VR.3
    Continuity planThe plan names critical services and recovery targets, and is tested or walked through each year. (CC9.1, A1.3)
  4. VR.4
    Outside testingAn external penetration test runs at the interval your policy sets, and findings are tracked to closure. (CC4.1)
  5. VR.5
    Insurance checkCyber cover is compared with the risk assessment at each renewal. (CC9.1)

05 · Optional series

If you add a category beyond Security

Each optional category brings a short series of its own.

CategorySeriesA control you would likely add
AvailabilityA1.1 to A1.3Capacity watched against thresholds, with recovery tested against stated targets
ConfidentialityC1.1 and C1.2Information marked confidential is tracked and destroyed on schedule, with each disposal recorded
Processing IntegrityPI1.1 to PI1.5Input checks and reconciliations confirm that records processed match records received
PrivacyP1 to P8Notice versions and consent records kept, and access requests handled within the time your notice states
  • Importing a template untouched. A bought list may include controls you never run. Each one becomes a test you fail.
  • Promising more than you do. Write “daily” and the auditor samples days. State the frequency you really keep.
  • One control per criterion, mechanically. Some controls serve several criteria and some criteria need several controls. Map honestly rather than padding.

Sources: AICPA TSP section 100, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy, with revised points of focus (2022); AICPA SOC 2 guide; COSO, Internal Control: Integrated Framework (2013).

Writing your own control set

Is there a right number of controls?

No. Scope, and how finely you write each one, decide it.

Two companies with identical scope can end up with very different counts, because one writes broad controls and the other splits them. The auditor cares that every applicable criterion is met and every control tests cleanly, not about the total.

Who maps our controls to the criteria?

You do; the CPA firm evaluates the result.

Management selects the controls and shows which criteria each addresses. The CPA firm then forms a view on whether each one is well designed for its criterion and, for a Type 2, whether it kept working across the whole period.

Can one control serve SOC 2 and ISO/IEC 27001 together?

Often, yes.

Access reviews, change approval and supplier assessment appear in both. Write the control once, map it to the criteria and to the matching Annex A control, and keep evidence that satisfies the stricter of the two.

What happens if a control stops running for a few weeks?

The missed instances show up as deviations.

In a Type 2, the auditor samples across the whole period, so a gap usually surfaces. Fix the cause, record what happened, and expect it to appear in the test results with your response beside it.

Get a control set that fits how you work.

A SOC 2 readiness assessment maps what you already do to CC1–CC9, then fills only the real gaps.