For a SOC 2 Type 1, your incident response plan must show that a defined program exists to understand, contain, remediate and communicate security incidents. Write it as a short document with roles, severity levels, steps and contacts, then run a tabletop exercise so you know the plan works. Type 1 reports on design at one point in time.
What does the auditor look for?
A Type 1 report describes the design of controls at a point in time and gives no opinion on operating effectiveness. So the auditor asks: is there a plan, is it approved, is it suitable for the criteria? The relevant criteria in the AICPA Trust Services Criteria are CC7.3 (evaluate security events to decide whether they are incidents), CC7.4 (respond by executing a defined incident response program to understand, contain, remediate and communicate), and CC7.5 (recover from incidents). CC7.2 on monitoring for anomalies feeds the front of the process.
The points of focus under CC7.4 are a useful outline. They include assigning roles and responsibilities (using external resources when necessary), containing incidents that actively threaten objectives, mitigating ongoing incidents, resolving them by closing vulnerabilities and removing unauthorized access, restoring operations, and communicating with affected parties in a timely manner. CC7.5 adds restoring the affected environment, communicating about the incident and recovery, and determining root cause.
What goes in the plan?
Use these sections, one page each at most.
- Purpose and scope: systems and data covered.
- Roles: incident lead, technical lead, communications owner, an executive sponsor, and a deputy for each. Name external help such as a forensic firm or counsel if you have one.
- Definitions and severity levels: for example four levels from critical to low, each with an example, a response time target and who must be notified. Pick targets you can meet.
- Detection and reporting: how staff report a suspected incident, the single channel to use, and which alerts feed it.
- Evaluation: who decides whether an event is an incident and how that decision is recorded (CC7.3).
- Response steps: understand, contain, eradicate, recover, in plain order, with preservation of logs before changes.
- Communication: who tells customers, regulators and staff, using what template, and who approves it. Check contractual and legal notice duties for your customers and regions.
- Recovery and root cause: restoring service, verifying the fix, and a post incident review with owners and dates.
- Testing and review: a schedule for exercises and plan updates.
- Contact sheet: names, phones and backups, tested for accuracy.
How do you run a tabletop?
A tabletop is a facilitated discussion, not a technical test. Plan 60 to 90 minutes.
Pick a realistic scenario, such as a leaked source control token found in a public repository. Invite the people named in the plan. A facilitator reads the scenario in stages: an alert arrives, the situation worsens, a customer asks a question. At each stage, ask who does what, with which tool, and how they would know. Record decisions and the time each took in the discussion.
Close with three questions: where did the plan fail us, what did we assume, what will we change? Write down actions with owners and dates.
What evidence do you keep?
Keep the approved plan with version and date, the roles list, the exercise agenda, attendee list, notes, and the action list. Keep a record of the plan approval by management. For a Type 1, this documents design. If you later move to Type 2, you will need proof that the plan ran, including real incident records if any occur and exercise records across the period.
What mistakes do first timers make?
Plans copied from the internet with roles nobody holds, response times no one can meet, and no tested contact list. Another is skipping the communication section. A plan that says nothing about who speaks to customers fails the CC7.4 communication point.
What to do
- Draft the ten sections, in plain language, in two to four pages.
- Assign real names to every role.
- Set severity targets you can honestly meet.
- Get management approval and record the date.
- Test the contact sheet by calling everyone.
- Run a tabletop and write up the actions.
- Fix the plan from what you learned and version it.
- Schedule the next exercise before the auditor asks.
Quick check
Does a Type 1 need a real incident to be on file?
No. Type 1 looks at design at a point in time. A tabletop record shows the plan has been exercised.
Which criteria cover incident response?
CC7.3, CC7.4 and CC7.5, with CC7.2 covering the monitoring that detects anomalies.
How Safeguard helps automate this
A plan on paper is not the same as being ready. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs between audits so your team can focus on other work. Technical evidence comes from your real code and dependencies, using scans, SBOMs and reachability, which helps you triage a vulnerable dependency or leaked secret scenario with facts. The agent can open tested fix pull requests, but it is off by default, every category starts on Manual, and you choose which categories run automatically. Safeguard helps prepare evidence; an independent auditor issues the report. Book a call.
Sources
- AICPA, 2017 Trust Services Criteria with revised points of focus (2022), criteria CC7.2 to CC7.5: AICPA Trust Services Criteria
Last reviewed: 18 October 2026.
