SOC 2 CC7.4: Responding to Security Incidents

SOC 2 CC7.4 requires a company to respond to security incidents through a defined incident-response program that understands, contains, remediates, and communicates. It sits in the CC7 series (System Operations), taking over from the event-evaluation criterion once something has been judged to be an incident. A frequent finding under it is a team that handles real incidents competently but ad hoc, with no written plan, no classification, and no record an auditor can sample.

What does SOC 2 CC7.4 require?

In plain terms, CC7.4 is where the company turns a confirmed incident into a controlled response. Where CC7.3 decides that a security event is an incident, CC7.4 governs everything that follows: understanding what happened, containing the damage, removing the cause, restoring operations, and telling the people who need to know. The word that matters here is defined. The criterion is not satisfied by competent improvisation; it expects a documented program that assigns roles and lays out the steps in advance.

That program does not have to be elaborate. For most companies it is an incident-response plan, a small library of playbooks, a named set of roles, and a ticketing path that records each incident from detection through closure. The AICPA points of focus read like the phases of a standard lifecycle (the NIST SP 800-61 shape of preparation, detection, containment, eradication, recovery, and post-incident activity), so a team already working that way mainly needs to write it down.

CC7.4 also reaches past the technical fix. Communication is a named part of the criterion, covering internal updates, customer notifications, and regulatory notifications where privacy regimes apply. And the program is expected to learn: incidents are reviewed for patterns and root causes, and those reviews feed changes back into the security program. The recovery of operations that CC7.4 begins is carried further by CC7.5, which focuses on restoring the business to a known-good state.

What are the CC7.4 points of focus?

The AICPA defines 11 points of focus for CC7.4. Because the Trust Services Criteria are AICPA copyrighted material, the points of focus below are paraphrased and grouped by theme rather than reproduced verbatim; consult the official TSC document for exact wording.

• Roles and responsibilities. Roles for designing, maintaining, and executing the incident-response program are assigned, including external resources when needed. In practice these are the incident commander, technical lead, communications lead, evidence custodian, and any retained outside responders.
• Understand and contain. The nature and severity of an incident are understood well enough to choose a containment strategy and response time frame, and procedures contain incidents that actively threaten objectives and mitigate their ongoing effects. This is where a responder decides, for example, whether to preserve memory before pulling a host off the network.
• Resolve and restore. Incidents are resolved by closing the underlying vulnerability, removing unauthorized access, and completing other remediation, and operations are restored to at least an interim state that lets the company meet its objectives.
• Remediate vulnerabilities and communicate the fix. Vulnerabilities surfaced by the incident are remediated through documented activity, and those remediation activities are recorded and communicated in line with the program, flowing into the change and patch process as tracked work.
• Communicate the incident. Protocols exist to communicate timely information about incidents and the actions taken to affected parties, spanning internal updates, customer notifications, and regulatory notifications under regimes such as PIPEDA or Law 25 where they apply.
• Evaluate and learn. The design of incident-response activities is periodically evaluated for effectiveness, and management reviews incidents across the trust categories to spot patterns and root causes and identify the system changes those patterns call for.

How do you meet CC7.4 in cloud environments?

Cloud environments meet CC7.4 with a defined program layered over the provider's response tooling and the platform's ability to contain fast:

• A documented plan and playbooks. An incident-response plan names roles and severity levels, and playbooks cover the incident types the team actually faces, such as credential compromise, data exposure, and account takeover.
• Platform-native containment. Containment uses the platform: disabling an IAM principal, rotating keys and secrets, isolating a workload with security groups, or quarantining an endpoint through EDR, with each action recorded as a state change on the incident ticket.
• Ticketed lifecycle. Every incident runs through a ticket capturing detection, containment, eradication, recovery, and closure with timestamps, so the response leaves an audit trail rather than living in a chat thread.
• Communication paths. Escalation and notification routes are defined in advance, including customer and regulatory templates, so a serious incident does not stall on who to tell.
• Post-incident review. Confirmed incidents get a short review capturing timeline, root cause, and follow-up changes tracked to completion.

How do you meet CC7.4 on-prem?

On-prem environments run the same program against owned hardware and, often, a colocation provider whose boundary has to be part of the plan. The incident response on-prem guide covers the full playbook; for CC7.4 the shape is:

• A written plan with assigned roles. The plan names the incident commander, technical lead, communications lead, and evidence custodian, and states when outside responders are engaged, so nobody is inventing the structure at 2am.
• Containment on systems the team operates. Containment means network isolation, credential rotation, disabling accounts, killing malicious processes, EDR quarantine, or pulling a server off the network at its switch port, with the evidence-versus-speed tradeoff written into the playbook rather than left to the on-call engineer.
• Provider coordination. For colocated hardware, the plan includes the communication protocol and contact list for the provider, so physical and facility issues have a defined path.
• Ticketed incidents and tabletops. Incidents run through a ticket with timestamps and state transitions, and periodic tabletop exercises drill the scenarios the team owns, producing follow-up changes tracked to completion.
• Post-incident review feeding change. Each real incident closes with a review whose actions become tickets: a detection-rule update, a playbook revision, a configuration change, or a new tabletop scenario.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC7.4?

How does CC7.4 map to ISO 27001:2022?

The overlap is direct: A 5.26 is the ISO control for responding to incidents per documented procedures, the core of CC7.4, and A 5.28 covers the collection and preservation of evidence the criterion's understand-and-contain step relies on. Evidence produced for CC7.4 can be reused for both. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across all five Trust Services Categories.

Related criteria

CC7.4 is the response engine of the CC7 series. The previous criterion, CC7.3, evaluates security events and decides which are incidents; CC7.4 executes the defined program that understands, contains, remediates, and communicates them; and the next criterion, CC7.5, focuses on recovering operations to a known-good state after the response. The learning loop CC7.4 builds also feeds risk mitigation under CC9.1, since incident patterns and root causes are exactly the kind of business-disruption risk that criterion asks the company to address.

Frequently Asked Questions

What does SOC 2 CC7.4 mean?

SOC 2 CC7.4 means the company responds to confirmed security incidents by running a defined incident-response program that understands what happened, contains the damage, remediates the cause, restores operations, and communicates to affected parties. The emphasis is on a documented program with assigned roles, not ad hoc reaction.

What evidence satisfies CC7.4?

The core evidence is an incident-response plan and playbooks, an incident ticket history showing incidents handled from detection to closure, post-incident review records, tabletop exercise results, and communication or notification records for affected internal, customer, and regulatory parties.

What is the difference between CC7.3 and CC7.4?

CC7.3 is the evaluation step: reviewing security events and deciding which are incidents. CC7.4 is the response step: executing the defined program that contains, remediates, and communicates once something is confirmed to be an incident. CC7.3 identifies the incident; CC7.4 resolves it.

Do we need a formal incident-response plan to pass CC7.4?

Yes. CC7.4 calls for a defined program, so a written incident-response plan with assigned roles and severity levels is expected. Handling incidents competently but without a documented plan, classification, or ticket trail is a common gap, because there is nothing for the auditor to sample.

How often should we run incident-response tabletop exercises?

CC7.4 expects the design of incident-response activities to be evaluated for effectiveness periodically, and a tabletop at least annually is the common way to satisfy that. Many programs run them more often, using the follow-up changes each exercise produces as evidence that the program is being maintained.