Skip to content

SOC 2® governance in plain English: who owns security

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 CC1 and CC2: who owns security, who oversees it, and how people inside and outside the company find out.

By Blank Slate Creative.

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

Order the five policies

Who owns security here, and how does everyone else find out?

Before a reviewer asks about firewalls, they ask who is in charge. CC1 and CC2 cover what exists before any tool is involved: who sets expectations, who oversees them, who owns which duty, and how information moves between people.

A five-person company can show this with very little paper. The trap to avoid is the opposite one: the whole arrangement lives in a founder’s head, so a reviewer has nothing to read and a customer has nothing to be shown.

Where a small team starts

Write one page that names an owner for security, a backup for that owner, and the person or group the owner answers to. Add a sentence on how a new hire learns the rules and where anyone sends a concern.

That page is a good first answer to most of what a reviewer asks here. It also tends to expose the gaps early: a backup who has never been told, or a concern channel that goes to the person concerned.

The criteria, CC1.1 to CC2.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.

CC1.1: Honest conduct, expected and enforced

Leaders say what honest conduct looks like and behave that way themselves, including when someone raises a problem. A reviewer looks for expectations on paper and for signs they are applied.

In practice

  • A short code of conduct in the handbook that each person acknowledges when they join.
  • A named way to raise a concern, such as a founder or an email alias, that doesn’t route through the person concerned.
  • A private note of a past conduct issue, what was decided, and what changed after.

CC1.2: Someone outside management keeps watch

A group that doesn’t run daily operations looks over how security is managed. In a small company that is usually a board, advisors, or investors who ask for regular updates.

In practice

  • A one-page security update sent each quarter to the board or advisors.
  • Meeting notes that show security, risk, or the SOC 2 plan as an agenda item.
  • A named director or advisor who follows up on open security questions.

CC1.3: Reporting lines and decision rights

Management sets reporting lines and decision rights so every security duty has an owner. At small scale that means writing down who owns what, even when one person holds several roles.

In practice

  • A roles page naming the owner of security, IT, HR, and vendor approvals.
  • A small table of who approves access, who leads incidents, and who signs off on vendors.
  • A named backup for each owner, for the weeks they are out.

CC1.4: Hiring, training, and keeping skilled people

The company looks for the right skills, trains people for the work they do, and plans for the day a key person leaves. A reviewer samples how security-relevant roles are filled and kept competent.

In practice

  • Background checks, where lawful and relevant, before someone gets production access.
  • Security training at hire and once a year, with a completion record.
  • Runbooks for the jobs only one person knows, so a departure doesn’t stop them.

CC1.5: People answer for their security duties

Security duties are assigned to people, and meeting them has consequences, good and bad. Deadline pressure shouldn’t be allowed to outrank them.

In practice

  • An acceptable use policy that states what happens when it is broken, acknowledged at hire.
  • A security goal in the review of each person who owns a control.
  • An escalation to a manager when someone ignores a required task, such as overdue training.

CC2.1: Good data feeds the controls

Controls run on information: asset lists, logs, and reports. The company decides which information matters and checks that it is accurate before relying on it.

In practice

  • A system inventory in one sheet or tool, compared with the cloud console every quarter.
  • A list of which systems send logs where, so nobody assumes coverage that isn’t there.
  • Access-review lists exported from the identity provider, not typed by hand.

CC2.2: Telling staff what is expected

Staff are told, in a way they can find again, what their security duties are and how to report a problem. That covers new hires, changes to the rules, and a way to speak up.

In practice

  • An onboarding checklist that links each policy and records that it was read.
  • A short message to the team whenever a policy changes, with what is different.
  • A pinned channel or alias for security questions and reports.

CC2.3: Telling outsiders what affects them

Customers, vendors, and others who depend on you hear about your commitments and about events that affect them, and they have a way to reach you. Think support address, status page, and a security contact.

In practice

  • A security overview or trust page that customers can request or read.
  • A security contact address that a person actually reads.
  • A template for telling customers about an outage or incident.
  • A list of what you have promised customers in contracts, kept where the team can see it.

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.

  • Who is responsible for security, and who do they answer to?
  • How does a new employee find out what is expected of them, and how do you know they read it?
  • What happens when someone breaks a rule?
  • How would a customer reach you about a security problem?
  • What do you do when the one person who knows a process leaves?

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