Building an Incident Response Plan That Satisfies CC7.3

The Test That Happens Without Warning

Six months into Orion's observation period, their monitoring system alerted on an unusual login pattern from a developer's account — multiple failed authentication attempts from an IP in Eastern Europe, followed by a successful login.

This was exactly the kind of event that would be tested in their SOC 2 audit. How the team responded — and critically, whether that response was documented — would directly affect their report.

What CC7.3 Actually Requires

The control requires that the entity evaluates security events to determine whether they could or have resulted in a failure to meet objectives — and that detected incidents are responded to per a defined incident response program.

Breaking that down:

1. Detection — You have monitoring that identifies potential security events
2. Evaluation — You assess whether events are incidents (false alarm vs. real issue)
3. Response — You follow a defined process to contain, investigate, and remediate
4. Documentation — The response is recorded so it can be demonstrated to auditors

The auditor will ask you to provide all security incidents logged during the observation period. For each incident, they'll review whether it was handled according to your documented plan.

The Anatomy of an Incident Response Plan

An IR plan that satisfies CC7.3 needs these sections:

Section 1: Purpose and Scope

What is an "incident" for purposes of this plan? Define it clearly. Typical definition: "Any confirmed or suspected unauthorized access to, disclosure of, modification of, or destruction of company systems or data — or any event that significantly degrades system availability."

Be specific about what's in scope: production systems, customer data, employee credentials, physical security events.

Section 2: Roles and Responsibilities

Who does what during an incident? For a small company, this is typically:

• Incident Commander: The person who takes charge and coordinates the response (usually CTO or head of engineering)
• Technical Lead: The person investigating and executing containment
• Communications Lead: The person managing customer and stakeholder communication (usually CEO or Head of Customer Success)
• Legal/Compliance: Called in if there's a data breach requiring notification

Document backup contacts for each role. What happens if the Incident Commander is on a flight?

Section 3: Severity Classification

Not all incidents are created equal. Define severity levels:

| Severity | Description | Response Time | |---|---|---| | P1 — Critical | Active breach, significant data exposure, service down | Immediate, 24/7 response | | P2 — High | Suspected breach, significant vulnerability, extended downtime | Within 4 hours | | P3 — Medium | Single account compromise, limited scope | Within 24 hours | | P4 — Low | Policy violation, minor security issue, no customer impact | Within 72 hours |

Section 4: Response Procedures (The Playbook)

The response process should cover five phases:

1. Identification

• How the incident was detected (monitoring alert, customer report, employee report)
• Initial triage: is this a real incident or false alarm?
• Severity classification

2. Containment

• Short-term containment: stop the bleeding (disable compromised account, block attacker IP, take affected system offline)
• Long-term containment: prevent recurrence while investigation continues

3. Investigation

• What happened? When? How? What systems were affected?
• What data, if any, was accessed or exposed?
• Root cause analysis

4. Remediation

• Fix the vulnerability
• Restore normal operations
• Verify the fix worked

5. Post-Incident Review (PIR)

• What happened?
• What did we do well?
• What should we do differently?
• What changes are needed to prevent recurrence?

Section 5: Communication Templates

Pre-drafted communication templates save critical time during a stressful incident:

• Customer notification: "We are notifying you of a security event that may have affected [description]. Here is what we know, what we have done, and what this means for you."
• Regulatory notification: Template for notifying relevant authorities if a data breach meets notification thresholds
• Internal escalation: How the incident commander notifies the CEO

Building the Incident Log

Every security event — even one that turns out to be a false alarm — should be logged. The incident log is one of the most important evidence items in your SOC 2 audit.

Minimum fields per incident:

| Field | Example | |---|---| | Incident ID | INC-2024-007 | | Date/time detected | 2024-11-14, 14:32 UTC | | Date/time resolved | 2024-11-14, 16:45 UTC | | Severity | P2 — High | | Description | Unusual login activity on developer account from unknown IP | | Systems affected | Okta, potentially production SSH | | Root cause | Developer's personal MacBook infected with infostealer malware | | Containment actions | Account suspended, MFA reset, reviewed SSH access logs | | Remediation | MacBook wiped, reinstalled, enrolled in MDM, additional monitoring enabled | | Data exposed | No customer data accessed (verified via audit logs) | | Incident commander | Arjun Mehta | | Post-incident review date | 2024-11-21 |

The Tabletop Exercise: How to Test Your Plan

Auditors expect that your IR plan has been tested. The standard way to do this: a tabletop exercise.

A tabletop is a structured discussion where you walk through a hypothetical incident scenario and talk through how your team would respond using the documented plan. No actual systems are involved — it's a facilitated discussion.

How to run a tabletop:

1. Designate a facilitator (can be you or an external consultant)
2. Choose a realistic scenario (ransomware, credential compromise, data breach, vendor incident)
3. Walk through the scenario: "At 9am on a Tuesday, your monitoring system alerts that..."
4. Ask each role what they would do, in what order, using what tools
5. Document gaps and follow-up actions
6. Complete follow-up actions and re-document

Evidence produced: A meeting record (agenda + attendees + date), scenario description, key discussion points, gaps identified, and follow-up actions assigned.

This is what Orion produced. 8 pages. Took 90 minutes. The auditor accepted it as evidence of IR plan testing.

Orion's Incident: How It Actually Played Out

Back to the suspicious login from Eastern Europe.

14:32: Monitoring alert fires in Datadog. On-call engineer sees it.

14:35: CTO (Incident Commander) is notified via PagerDuty. Severity assessed: P2.

14:40: Developer account suspended in Okta. SSH access logs reviewed.

15:15: Investigation complete. Log review shows no production data access. Developer confirmed they used their personal laptop for work email. Laptop flagged as potentially compromised.

15:45: Developer laptop wiped. New company-managed MacBook issued. MFA reset.

16:30: CEO informed. Decision made: no customer notification required (no customer data accessed, no breach threshold met). Legal counsel consulted.

16:45: Incident resolved.

Following Tuesday: Post-incident review completed. Finding: 3 employees were using personal devices for work tasks without MDM. Follow-up action: MDM enrollment required for any device accessing company systems. Implemented within 2 weeks.

What the Auditor Saw

When the auditor asked for security incidents during the observation period, Orion provided:

• The incident log entry for INC-2024-007
• The Okta suspension record (timestamp)
• The post-incident review document
• Evidence that follow-up actions were completed (MDM enrollment records for all employees)

The auditor's assessment: the incident was handled per the documented IR plan. Control operating effectively.

What Comes Next

You now have a comprehensive picture of Orion's control environment. In the next post, we'll step back and look at the big picture: the 12 most common SOC 2 gaps that auditors find, and how to check whether you have them before the audit starts.