Skip to content

SOC 2® monitoring and incident response 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 CC7.1 to CC7.5: finding weak spots, noticing odd behavior, deciding what is an incident, responding, and recovering.

By Blank Slate Creative.

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

Order the five policies

How would you notice trouble, and what happens in the first hour?

CC7 is where the criteria stop being about intentions. Five criteria follow the life of a problem: finding weaknesses, noticing odd behavior, deciding whether it is an incident, responding, and then recovering and learning.

A reviewer looks for the trail: an alert, a ticket, a decision, a response, a write-up. A team can have the events without the trail, because the fix happened in a chat thread and nobody wrote down what was decided.

Where a small team starts

Pick one place where every security-relevant alert lands, a ticket queue or a channel with a bot, and decide that each alert gets a recorded decision, including “not an incident.”

Then run a short tabletop exercise and keep the notes. The notes, and the fixes that follow, are the evidence that the plan is more than a document.

The criteria, CC7.1 to CC7.5

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.

CC7.1: Finding weak spots and unplanned changes

Systems that were safe last month can be exposed today without anyone touching them. A reviewer looks for a routine that keeps checking, and for proof that what it finds gets fixed.

In practice

  • A weekly vulnerability scan whose findings become tickets with deadlines by severity.
  • Cloud configuration alerts that fire when a setting drifts from the baseline.
  • Dependency alerts that someone reviews and acts on.
  • Patch deadlines in the policy that you can show were met.

CC7.2: Watching for odd behavior

Systems and networks are monitored for activity that looks wrong, such as failed sign-ins, unusual data movement, or a new admin account. Someone also decides which alerts are real security events.

In practice

  • Central logs for the identity provider, the cloud audit trail, and application sign-ins.
  • Alerts for admin sign-ins, disabled logging, and new privileged accounts.
  • A named person, or an on-call rotation, who triages alerts.
  • A stated log retention period.

CC7.3: Is this event an incident?

When something suspicious turns up, someone judges whether it is a real incident and how serious, using a consistent method. The decision and the reasoning are recorded.

In practice

  • A short severity table in the incident plan.
  • A ticket for every security event, with the decision written down even when it is “not an incident.”
  • A weekly look through the alert tickets.

CC7.4: Running the response

When an incident hits, the difference between a scramble and a plan is who is in charge and what they do first. A reviewer looks for a response that was decided before it was needed, and for records showing it was followed.

In practice

  • A one-page incident plan with a named lead and a backup.
  • A drafted customer notice to adapt, not write from scratch.
  • A contact list for counsel, your insurer, and any forensics help.

CC7.5: Recovering, then learning from it

After an incident the company gets back to normal operation and changes something so it is less likely to happen again. It documents what happened and what it learned.

In practice

  • A blameless review written within a set time after each incident.
  • Follow-up tickets that are tracked until they are done.
  • The incident plan updated after each real incident or practice run.
  • Steps for restoring from known-clean backups.

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.

  • What alerts do you get, and who sees them?
  • Show me the last security event and what you decided.
  • Who leads an incident, and who covers for them?
  • When did you last test the plan, and what changed afterward?
  • How quickly do you patch a critical vulnerability, and how do you know?

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