Skip to content
AuditFront
CC7.4 SOC 2

SOC 2 CC7.4: System Operations - Incident Response

What This Control Requires

The entity responds to identified security incidents by executing a defined incident response program to understand, contain, remediate, and communicate security incidents, as appropriate.

In Plain Language

When a breach happens at 2am, you don't want your team figuring out the process on the fly. CC7.4 is about having a tested, documented plan ready to execute the moment an incident is confirmed.

Once an event is classified as an incident, you need established processes for containing the damage, investigating the cause and scope, remediating the threat, communicating with affected parties, and documenting everything. The response should be proportional to severity and focused on minimising damage while preserving evidence.

Auditors look at the quality of your incident response plan, whether it's been tested through exercises or real incidents, whether recent incidents were handled according to the plan, and whether you actually learn from incidents and improve your posture afterward. A plan that's never been tested is barely better than no plan at all.

How to Implement

Write a comprehensive incident response plan covering the full lifecycle: preparation, detection, analysis, containment, eradication, recovery, and post-incident review. Define the team composition, communication protocols (internal teams, management, customers, regulators, law enforcement), severity-based response procedures, evidence preservation requirements, and escalation criteria.

Build an incident response team with clear roles. At minimum: an incident commander to lead the response, technical investigators for analysis and containment, a communications coordinator for internal and external messaging, and a legal adviser for regulatory obligations and evidence handling.

Create playbooks for common incident types. Write step-by-step procedures for malware infections, unauthorised access, data breaches, denial-of-service attacks, insider threats, and ransomware. Each playbook should include specific containment actions, investigation steps, communication templates, and recovery procedures.

Test the plan regularly. Run at least one annual tabletop exercise with the full response team and executive stakeholders. Supplement with technical exercises that test detection and containment capabilities. Document results, gaps, and improvement actions.

Set up an incident documentation and tracking system. Every incident should be documented from detection through post-incident review: timeline, actions taken, decisions, evidence collected, communications sent, and lessons learned. Maintain an incident register tracking all incidents and outcomes.

Run a post-incident review after every significant incident. Analyse what happened, why, what worked, what didn't, and what changes prevent recurrence. Document findings and track implementation of improvements. This is where the real value of an IR programme lives.

Evidence Your Auditor Will Request

  • Documented incident response plan with roles, procedures, and communication protocols
  • Incident response team roster with defined roles, contact information, and escalation chains
  • Incident response playbooks for common incident scenarios
  • Incident response exercise records (tabletop or technical) with findings and improvement actions
  • Incident documentation for actual incidents including timelines, actions, communications, and post-incident reviews

Common Mistakes

  • Incident response plan exists but has not been tested through exercises, leaving the team unprepared
  • Incident response roles are not clearly defined, causing confusion during actual incidents
  • No playbooks exist for common incident types, forcing ad hoc responses
  • Post-incident reviews are not conducted, preventing the organization from learning from incidents
  • Communication protocols for customers and regulators are not defined, causing delays in notification

Related Controls Across Frameworks

Framework Control ID Relationship
ISO 27001 A.5.24 Equivalent
ISO 27001 A.5.26 Related
ISO 27001 A.6.8 Related
nist-csf RS.MA-01 Equivalent

Frequently Asked Questions

How often should we conduct incident response exercises?
At least one tabletop exercise annually with the full team and executive stakeholders. Add quarterly technical exercises that test specific capabilities - isolation procedures, forensic collection, backup restoration. Run extra exercises after significant changes to your team, technology, or threat landscape.
Do we need a retainer with a forensic investigation firm?
Strongly recommended, especially if you don't have deep forensic capabilities in-house. A retainer gets you rapid access to expert investigators when something serious happens, with pre-negotiated rates and SLAs. The cost is modest compared to scrambling to find help during an active breach.
When should law enforcement be notified of a security incident?
When there's evidence of criminal activity - data theft, extortion, fraud. Some regulations also mandate law enforcement notification for certain incident types. Include the engagement criteria in your IR plan and consult legal counsel before making the call. Be aware that law enforcement involvement can extend investigation timelines, so factor that into your planning.

Track SOC 2 compliance in one place

AuditFront helps you manage every SOC 2 control, collect evidence, and stay audit-ready.

Start Free Assessment