CC7.4 Incident response: requirements and evidence

What CC7.4 incident response asks an organization to prove

CC7.4 asks the organization to show that it responds to identified security incidents through a defined incident response program, one that lets it understand what happened, contain it, remediate the cause, and communicate it as appropriate. The risk behind the criterion is familiar to any customer who has read a SOC 2 report: an incident handled ad hoc by whoever notices it first tends to produce slow containment, missed notifications and no record of what was decided. If a SOC 2 is underway, or a customer has asked for one, the incident response plan may already exist as a document, but the examiner will be looking for proof that the program was followed when something actually happened.

That gap between a written plan and operating evidence is where most teams struggle. The points of focus under CC7.4 point to specific things an assessor will check: roles and responsibilities assigned to named people, containment and mitigation steps, resolution and restoration of operations, communication protocols, remediation of the vulnerabilities involved, and an evaluation of whether the response worked. Each of these needs a record from a real event or a documented exercise. Confirm with your auditor how they will treat periods with no incidents, since the evidence an examiner accepts for a quiet observation period can differ from what they expect after an incident has occurred.

A practical first step is to list every incident in the examination period, including those that were closed as false positives, and check that each one has a case record showing its owner, timeline, decisions and closure. Confirm who owns the program, who can declare an incident, and how that decision is recorded. Where privacy is in scope, also confirm that breach response procedures are part of the same program and that the team knows which notifications depend on the incident's classification. Open-source case management tools such as DFIR-IRIS can hold this record in one place, although the tool only produces evidence; the organization still has to run the process and show it working.

Which incidents, systems and teams CC7.4 covers in a SOC 2

CC7.4 is only as wide as the system description and the scope choices behind it. The decisions below determine which incidents the response program must handle, which people own each step, and which outside parties must be part of the evidence trail.

System boundary and incident scope

Start with the components listed in the system description: production workloads, identity providers, admin consoles, CI pipelines and backup stores. An incident that touches a component outside that boundary may still matter if it reaches in-scope data or services. Write down which event types the program treats as incidents, such as malware, unauthorized access, data exfiltration, and misconfigurations that expose customer data. Ask your CPA firm to confirm the boundary before fieldwork starts, because the incident program must cover what the auditor tests.

Named incident roles and owners

CC7.4 expects roles and responsibilities to be assigned for responding to incidents. Name an incident commander, a technical lead, a communications owner and a legal or privacy contact, and record a backup for each. Map these roles to real people across engineering, security, operations and leadership, not only to a team alias. Auditors commonly ask for evidence that the named people were aware of their roles and that the roster was current during the examination period.

Cloud and hosting provider responsibilities

Cloud platforms and hosting providers often generate the logs, alerts and account events an incident depends on. Document which party detects, preserves and reports each event type, and how your team obtains those records during an investigation. If a provider's SOC report is used to cover parts of the environment, confirm which controls it covers and how your own response procedures connect to them. Keep the provider's contact and escalation paths in the runbook.

Managed security and outsourced responders

A managed detection provider or outside incident response firm may triage alerts, run investigations or contain threats on your behalf. Decide what they may do without approval, how they escalate to your staff, and how their actions appear in your case records. Their contract should state response times and access rights in writing, and their outputs must be retained as evidence. Confirm whether they are a subservice organization whose controls are carved out of your report or included with their own report.

Subservice organizations and their evidence

Subservice organizations are vendors whose services support in-scope systems, such as a hosting company, a database service or an identity provider. For CC7.4, check how each vendor notifies you of incidents, what timeframe applies, and what evidence they supply after an event. Where a vendor's controls are carved out, you still own the monitoring and communication steps that connect to them. Record these dependencies in the vendor register so the auditor can trace each one.

Privacy in scope and breach procedures

When the privacy category is in scope, CC7.4 adds points of focus on applying breach response procedures and communicating unauthorized use and disclosure. Decide which personal information is covered, which notices your contracts and laws require, and who approves external notification. Build a separate breach procedure that sets out assessment steps, documentation of impact and communication to affected parties. Ask your CPA firm whether the privacy criteria apply to your service and confirm the procedure matches the criteria in scope.

How to build an incident response program an auditor can test

This sequence turns CC7.4 into a working program with named owners, defined severity and escalation, documented playbooks and rehearsed response, so the auditor can trace each identified incident from detection to lessons learned.

Name incident roles and backups
Assign an incident commander, a technical lead, a communications owner and a scribe, each with a named backup. Include the people who can approve customer notices and contact legal or privacy counsel when personal data is involved. The output is a written responsibilities matrix with current names, approved by management and linked from the incident response policy. Confirm that the roster is reviewed on a schedule you define and that departures trigger an update, because an auditor will check the roster against the people who actually handled the sampled incidents.
Define severity levels and escalation paths
Write severity definitions in terms of impact on your service commitments, customer data and system availability, with examples of each level tied to your own environment. Map each level to who is paged, who must be informed and when leadership is engaged. The output is a severity table and an escalation diagram that the team can follow under pressure. Ask yourself whether two responders would classify the same event the same way; an auditor testing CC7.3 and CC7.4 together will look for consistent classification across tickets.
Set communication protocols for customers and vendors
Document who may speak to customers, subservice providers and other external parties, which channels they use, what information is shared at each severity, and what approvals a message needs. Include the contacts you rely on at cloud and software vendors, and any contractual notice terms in customer agreements. The output is a communication procedure with message templates and a log of notices sent. Where privacy is in scope, add the breach response steps for communicating unauthorized use or disclosure, and confirm the notice obligations with counsel rather than assuming them.
Document containment and recovery playbooks
Write one playbook for each incident type your risk assessment expects, such as credential compromise, malware on an endpoint, exposed storage, or a compromised deployment pipeline. Each playbook sets out triage questions, containment actions, mitigation steps, eradication of the cause, restoration of operations and the evidence to preserve. The output is a versioned set of playbooks with owners and review dates. An auditor will compare these against the incidents in the period, so keep the playbooks specific enough that a responder could follow them without the author present.
Connect detection sources to a case system
Route alerts from your SIEM, endpoint detection, cloud audit logs and other monitoring sources into one case management tool. DFIR-IRIS, an open-source platform licensed under LGPL-3.0-or-later, keeps each case as one record of assets, indicators, tasks and evidence with a full audit trail, and it can triage alerts from SIEM, EDR and REST sources into cases. Shuffle, licensed under AGPL-3.0-only, can automate the handoffs between tools through webhook, scheduled or manual workflows. Confirm each connector and integration against the current documentation for your versions. The output is a case for every triaged alert, with timestamps showing when the event was detected and when it was evaluated.
Rehearse response with tabletop exercises
Run tabletop exercises on the playbooks and the escalation path, using a scenario written for your own architecture and customer base. Record attendance, decisions, gaps in tooling or authority, and the actions assigned to close each gap. The output is a dated exercise report with the scenario, participants, findings and tracked remediation items. Auditors reviewing a Type 2 period look for evidence that the program was exercised and improved, so an exercise that produces no findings will draw questions about how it was run.
Set a post-incident review template
After each incident, hold a review that records the timeline, root cause, effectiveness of containment and communication, remediation of the vulnerability or configuration involved, and changes to playbooks or controls. Store the review in the case record so it stays linked to the evidence. The output is a standard review template and a completed review for every incident above the severity you define, including incidents with no customer impact. Ask whether the review feeds back into your risk assessment and monitoring, because that link is what an auditor tests when evaluating the effectiveness of the response.

How DFIR-IRIS and Shuffle support the incident response evidence trail

CC7.4 asks for a defined incident response program that can be shown to work. Two open-source tools can hold the case record and the automation behind it, but neither makes the program compliant on its own. The cards below cover what each tool contributes to the evidence trail and what your team must confirm before relying on it.

DFIR-IRIS case management

DFIR-IRIS (LGPL-3.0-or-later) keeps each incident as one case that holds assets, indicators of compromise, tasks and evidence, with an audit trail of who changed what. It can triage alerts from SIEM, EDR and REST sources into cases, and it builds a consolidated investigation timeline. Check that the deployed version provides the audit trail and reporting features you intend to cite, and confirm how your team will export case records for the auditor.

Evidence hashing and chain of custody

DFIR-IRIS logs evidence with SHA-256 verification and chain of custody, so a file collected during an incident can be shown to be unchanged since intake. Assessors look for this kind of record when they sample incidents and ask how evidence was handled. Confirm the hashing and custody features in your version, and write a procedure that says who may add, move or export evidence.

Shuffle event-driven workflows

Shuffle (AGPL-3.0-only) runs workflows started by a webhook, a schedule or a manual run, with app nodes that act on each step. Teams use these workflows to connect a SIEM, a ticketing system and a firewall without custom code, so that an alert opens a ticket and records each action. Map each workflow to the response step it supports, and test that every automated action is also logged in the case.

License and distribution obligations

The LGPL-3.0-or-later license of DFIR-IRIS and the AGPL-3.0-only license of Shuffle impose different duties depending on whether you modify the code and how you make it available to others, including users who reach it over a network. Your obligations also depend on how your organization deploys and distributes the tools. Ask counsel to confirm these duties before you customize either product or offer it to customers or partners.

How an assessor tests CC7.4 and which findings usually appear

This table compares what an assessor does for each CC7.4 element, what evidence they ask for, and where programs usually fall short. Read it as a checklist: the auditor samples incidents across the examination period, so each row must hold on every sampled case, not only on the day of fieldwork.

Test area	Evidence requested	Common findings
Written incident response program and approval	Current incident response plan, version history, and proof that management or the designated owner approved it before the period	Plan is undated or unapproved, or it describes a process the team does not follow
Roles and coverage	Role assignments, on-call or escalation schedules, and records showing who acted during each sampled incident	Named roles have left the company, or no backup covers nights, weekends and holidays
Sampled incidents traced from detection to closure	Alert or ticket, triage notes, containment and eradication actions, timestamps, and closure approval for each sampled case	Incidents lack timestamps, skip triage, or are closed without documented root cause or impact review
Communication records	Internal escalation messages, customer or regulator notices where required, and records of who approved them	Notices go out without approval, or the auditor cannot match a notice to a specific incident
Remediation of root vulnerabilities	Tickets linking each incident to the fix, patch or configuration change, plus evidence the fix was verified	Fix is recorded as complete but no verification exists, or the same weakness reappears in later incidents
Tabletop exercises and post-incident reviews	Exercise scenarios, attendee lists, action items, and review minutes showing lessons applied to the program	Exercises are planned but not run, or action items stay open with no owner or due date
Privacy breach procedures (when privacy is in scope)	Breach response procedure, notification decision records, and evidence of unauthorized disclosure assessments for sampled events	Procedure exists but decisions are undocumented, or notification timing is not tied to the stated criteria

Evidence that passes CC7.4 and how to keep it current

An auditor testing CC7.4 looks for a working incident response program and proof that it ran as written during the period. The artifacts below connect: the plan defines the roles and severity levels, the case records and custody logs show the plan in action, and the reviews and exercises show it improving. Each needs a named owner and a refresh cycle before fieldwork begins.

Incident response plan with version history

The written plan states the phases, roles, escalation paths and communication steps the organization follows when an incident is declared. Keep it under version control so the auditor can see the approved version in force on each date of the period. Check that the plan was reviewed at least once in the period, that each change has an approver and a reason, and that the plan matches what the team actually does. Management owns the plan and the security lead signs off on each revision.

Roles and contact register

This register names who leads, investigates, approves communications and handles legal or customer notices for each incident type, with primary and backup contacts. Auditors compare it against the people named in case records to confirm that assigned responders existed and were reachable. Refresh it after every joiner, leaver and role change, and test contact details during the tabletop exercise. The security lead owns the register and HR feeds it with leaver and transfer records.

Severity matrix

The severity matrix defines the criteria that place an event at each level, the response time expected at each level, and who must be notified. It is the reference that makes triage consistent, so two responders classify similar events the same way. Confirm that each classified incident in the period cites a level and that the matrix covers confidentiality and privacy impact where those categories are in scope. The security lead approves the matrix and reviews it after any significant incident.

Case records with timestamps and actions

Each incident case should record detection time, classification, assigned responders, actions taken and closure, with timestamps and an audit trail of who changed what. A case management platform such as DFIR-IRIS keeps assets, indicators, tasks and evidence in one record and builds a timeline from them. Auditors sample cases and check that timestamps are in order and that actions match the plan. Responders own their case entries, and the incident lead reviews each case before closure.

Chain of custody for collected evidence

When responders collect logs, disk images or files, the chain of custody records who collected each item, when, how its hash was verified and every transfer or access afterward. This proves the evidence was not altered and supports any legal or regulatory follow-up. Confirm that hashes are recorded at collection and re-verified before analysis, and that access is limited to named responders. The forensic lead owns custody records and reviews them when a case closes.

Post-incident review reports

A post-incident review documents root cause, impact, timeline, what worked, what failed and the corrective actions agreed. It is the main evidence that the organization evaluates how well its response performed, which CC7.4 expects. Confirm each material incident has a review completed within a timeframe the organization defined in its own plan, and that open actions are tracked to closure. The incident lead writes the review and the security leadership group approves it.

Remediation tickets linked to incidents

Remediation tickets show that identified vulnerabilities and control gaps were fixed, not just described. Link each ticket to its originating case so the auditor can follow a path from detection to fix and verification. Check that tickets carry owners, due dates, verification steps and closure evidence. Engineering managers own remediation work and the security team verifies closure.

Communication logs

Communication logs record internal notices, customer and regulator notifications, and any privacy breach notices, with dates, recipients, approvers and content references. They show the communication protocols in the plan were followed and that unauthorized use or disclosure was communicated when privacy is in scope. Confirm that legal or privacy review is recorded before external notices go out. Communications lead maintains the log and legal counsel approves external statements.

Tabletop exercise reports

Tabletop exercises walk the team through a simulated incident against the plan and record gaps. A dated report lists participants, scenario, decisions made, gaps found and the actions assigned. Auditors look for at least one exercise in the period and proof that the gaps raised were tracked to closure. Ask the auditor which exercise cadence they expect for your system before scheduling. The security lead designs the exercise and the executive sponsor signs the report.

What meeting CC7.4 costs in money and effort

This table compares the main cost components of running a CC7.4 incident response program, who is paid for each, whether the cost recurs, and what drives it up or down. Use it to build a written quote request, because no price or duration is given here and the figures depend on your environment, scope and provider.

Cost component	One-time or recurring	What drives it	How to keep it down
Incident case tooling and licenses	Recurring license or subscription, plus one-time setup	Number of users, case volume, and whether a commercial case platform or a self-hosted open-source option is chosen. Confirm the license model in writing.	Compare commercial terms with a self-hosted open-source case tool, where license spend is removed but hosting, patching and upkeep remain with you.
Detection and log sources feeding triage	Recurring (ingestion, storage, retention) plus one-time integration	Volume of logs from cloud, endpoints and applications, and how long evidence must be retained for the auditor's sampling period.	Log only the sources that map to documented incident criteria, set retention to your stated policy, and confirm ingestion pricing with each vendor.
Engineering time for playbooks and integrations	One-time build, with recurring updates when systems change	Number of incident types covered, count of systems to connect, and how many tools need custom connectors.	Start with a small set of high-impact playbooks, reuse templates, and define the ticketing and alerting connections in the statement of work.
Staff time for on-call and tabletop exercises	Recurring	Team size, rotation design, how often exercises run, and whether privacy breach procedures are included in scope.	Combine tabletop exercises with existing meetings, keep the on-call rota documented, and record each exercise so it doubles as evidence.
Evidence upkeep	Recurring, through the observation period	Number of incidents, the level of detail in each case record, and how consistently tickets, timelines and approvals are kept.	Use one case record per incident with timeline, decisions and approvals captured as the work happens, not reconstructed later.
External testing or incident response retainers	Recurring retainer or per-engagement fees	Retainer hours, response time expectations, and whether forensic support or breach counsel coordination is included.	Ask whether the retainer is needed for your risk profile, define what triggers a call, and request the response terms in writing.
Auditor sampling effort	Recurring with each examination period	Number of incidents in the period, how many the auditor samples, and the completeness of records for each sampled incident.	Keep a complete incident log from the start of the period, and agree the sampling approach with your CPA firm before fieldwork.

Who owns CC7.4, who can help, and where the auditor stops

Your organization owns CC7.4. CC7.4 asks the organization to respond to identified security incidents through a defined incident response program, so the program, its roles and its decisions must be yours. Someone accountable has to name the incident commander, decide severity, approve containment actions that affect customers, and sign off on what gets communicated and when. The incident record also belongs to you, because the auditor will sample real incidents from it and ask who made each call.

Program ownership: Approve the written incident response procedure and assign a named owner who reviews it on a schedule you set.
Roles and decisions: Document who declares an incident, who leads containment, who speaks to customers and who can take a system offline.
Incident record: Keep the authoritative log of detection, triage, actions, decisions and closure for every event that meets your threshold.
Communication: Define the internal and external notification paths, including any contractual or privacy-driven breach procedures when those categories are in scope.
Post-incident review: Run lessons-learned meetings and track the remediation items they produce to closure.

Check that every named role has a backup and that the people in those roles have actually been trained on the procedure.

When CC7.4 includes breach procedures for privacy commitments

When the privacy category is in scope, the CC7.4 incident response program has to go further than understanding, containing and remediating an incident. It must also apply breach response procedures and communicate unauthorized use and disclosure of personal information. The privacy points of focus added to CC7.4 in the 2017 Trust Services Criteria make this explicit, so an auditor will look for a written breach procedure that is connected to the incident process rather than a general plan that never mentions personal information. Before the examination period starts, the organization should decide which of its commitments to customers and data subjects are privacy commitments, because those commitments define what counts as an unauthorized disclosure.

The breach procedure should record four decisions. First, who determines that a security incident has become a breach of personal information, and on what evidence, such as the data classes involved, whether data was viewed or only exposed, and whether it left the environment. Second, which notification clocks apply, including timelines written into customer contracts, data processing agreements and any regulator rules that reach the organization. Third, who sends notices to affected parties and who approves the wording. Fourth, how the incident record in the case management tool links to the notification decision, so the auditor can trace a sampled incident from detection to communication. Each decision should name a role, not only a team, and the names should be checked against the on-call and escalation lists during the examination period.

Whether a particular law requires notice, how quickly, to whom and in what form is a legal question that belongs to counsel, not to the security or engineering team. The buyer should ask the service organization to confirm, in writing, which laws and contracts its breach procedure is built around and who gave that interpretation. An auditor tests whether the organization follows its own documented procedure, not whether the procedure is legally sufficient, so a clean report does not establish compliance with any notification statute. Organizations that serve customers in several jurisdictions should have counsel review the decision points above before the observation period begins, and should record that review as evidence.

Questions buyers ask about CC7.4 incident response

How much effort does CC7.4 incident response take, and what drives it?

The effort depends on how much of an incident response program already exists and how many systems, teams and customer obligations it has to cover. Writing the plan is the smaller part. The larger items are agreeing on roles, building runbooks for the incident types you actually expect, setting up a place to record cases, and running at least one exercise so the plan is tested rather than only written. Drivers that raise the effort include a large or multi-cloud estate, several products with separate on-call rotations, contractual notification duties to customers, and the presence of privacy or confidentiality commitments in scope. Ask any consultant or implementation partner for a written breakdown of these items before agreeing a fixed scope, and confirm which of them your own team will perform.

How long does it take to build operating evidence for a Type 2 period?

A Type 2 report tests whether controls operated over a period, so CC7.4 evidence has to exist for the whole observation window, not just on the day the plan is approved. The length of that window is set in your engagement with the CPA firm, and the practical question is whether the program is running before the window opens. Evidence accumulates through real incidents, tabletop exercises, post-incident reviews and tracked remediation. If no incidents occur, the auditor will look for exercises and documented reviews instead. Confirm with your auditor which events they expect to sample and how they will treat a period with few or no incidents, because that answer changes how you plan the exercise calendar.

Can our own security team run CC7.4 without outside help?

Many teams can, provided someone owns the program and there is time to maintain it. The tasks that most often need outside support are designing the response roles across engineering, legal and leadership, mapping the plan to the CC7.4 points of focus, and setting up tooling so evidence is captured without manual effort. An implementation partner can prepare systems, runbooks and evidence collection, but it does not decide the program's content on your behalf and does not issue any assurance. Whether you need outside help depends on in-house skills, staff availability and how often the process must be exercised. Decide who is accountable internally before buying any external service.

What does the incident response program need from engineering and leadership?

Engineering provides the technical capability: logs that can reconstruct events, the ability to isolate hosts or revoke credentials, backups for restoration, and people who can work an incident outside business hours. Leadership provides authority and decisions: who can declare an incident, who approves containment that stops revenue-generating services, who speaks to customers, and who signs off on closure. The program needs these roles written down and agreed, with named deputies. A useful test is whether an on-call engineer knows, at 2 a.m., when to escalate and to whom. Leadership should also review incident outcomes regularly, because the post-incident evaluation required by CC7.4 is only credible when management acts on its findings.

Can an auditor write our incident response plan?

No. An independent CPA firm examines your controls and issues the report, and auditors must remain independent of the systems and controls they test, so they cannot design the plan that they will assess. A consultant or implementation partner may draft the plan, runbooks and role definitions, and the organization must approve and own them. Your auditor can explain what evidence it expects, review the plan against the criteria, and tell you where the description of your controls is unclear. Ask the auditor in writing which parts of the work it can and cannot perform, since the rules on independence determine the answer for your engagement.

How does CC7.4 differ from the detection and recovery criteria?

CC7.4 covers the response itself: assigning roles, containing and mitigating an incident, restoring operations, communicating, remediating vulnerabilities and evaluating how well the response worked. The detection criteria sit before it. CC7.2 concerns monitoring for anomalies, and CC7.3 concerns deciding whether a security event is actually an incident. Recovery is covered by CC7.5, which deals with restoring the affected environment, finding root cause, preventing recurrence and testing the recovery plan. In practice the boundaries overlap, so a single post-incident review may serve CC7.4 and CC7.5 at once. Map each record to the criterion it supports so the auditor can follow the chain from detection through response to recovery.

How DeployOpen scopes and prepares CC7.4 evidence

DeployOpen plans, implements and documents the self-hosted open-source platforms that support a CC7.4 incident response program inside your own infrastructure. The organization owns its incident response program and controls, and an independent CPA firm performs the examination and issues the report.

How we scope

Agree in writing which systems, teams and incident types the CC7.4 response program covers before work starts.
Confirm whether privacy is in scope, since that adds breach response procedures and unauthorized disclosure communication to CC7.4.
Define which roles, escalation paths and communication protocols you own and which ones DeployOpen configures or documents.

How we build

Deploy and configure self-hosted case management, such as DFIR-IRIS, to record incidents with assets, indicators, tasks and evidence.
Build automated triage and notification workflows, such as Shuffle, that connect your SIEM, ticketing system and chat tools.
Set up evidence handling with hash verification, chain of custody and audit trails so each incident record can be reviewed later.

How we hand over

Deliver the written incident response runbooks, role assignments and communication templates for your review and approval.
Provide a control narrative mapping each CC7.4 point of focus to the configured tools, procedures and records.
Hand over sample incident records, tabletop exercise notes and post-incident review templates the auditor can request.

How we support

Fixed-scope engagements have deliverables and timelines agreed in writing before work begins.
Ongoing support, upgrades and continuous testing are available as a retainer to keep the response tooling current between audit periods.
Confirm with your CPA firm which evidence samples and time periods they will test before we finalize the handover package.