SOC 2 after a security incident: what the report must disclose

What must a SOC 2 disclose after a security incident?

Significant system incidents belong in management's system description under DC 200, which sets out the incident disclosure as one of its nine description criteria, and the incident response controls, CC7.3 to CC7.5, are tested against the events that actually happened during the period. An incident that occurred during the examination window is therefore not hidden by the report's structure. The question is how it is described, how the organization evaluated it and whether its response controls operated as designed. Your organization owns its controls and the description of its system. The independent CPA firm decides the opinion and is the only party that issues the report.

The effect on the opinion depends on three things: the nature of the incident, the control failures it exposed and how management responded. An incident that was detected, contained and remediated through a working program may leave the opinion unchanged, while one that exposed a failed access control or a missed escalation may produce an exception or a modified opinion on the affected criteria. Because the answer varies by organization and by incident, confirm early with your CPA how they will assess the event, which period they will examine and whether any control they planned to test was affected.

Start by pulling the incident record now: timeline, classification, who evaluated it under CC7.3, containment and recovery steps, root cause, the changes made to prevent recurrence and any customer communication. Check that the incident is also reflected in the system description and that management's representation letter, which the auditor requires under AT-C section 205, is accurate about it. An incomplete record is the most common reason a manageable event becomes a finding. For a tailored view, ask your CPA to walk through the incident against CC7.4 and CC7.5 before fieldwork begins.

How CC7.3 to CC7.5 are evaluated when an incident occurs

When a security incident falls inside the examination period, the auditor follows it through four linked steps: the evaluation of the event, the response program, the recovery, and the lessons that prevent a repeat. Each card below names what the auditor looks for in tickets, post-incident reviews and communications, and what a gap looks like.

Evaluating security events under CC7.3

CC7.3 asks whether the organization evaluates security events to decide if they could cause, or have caused, a failure to meet its objectives. The auditor looks for triage records that show each alert was assessed, with a documented decision on whether it became a security incident. A gap is an alert queue with no disposition, or events closed as false positives without a recorded rationale. Ask for a sample of alerts from the period and trace each one to its decision.

Responding through a defined program

CC7.4 asks whether the organization responds to identified incidents under a defined incident response program that covers understanding, containment, remediation and communication. The auditor checks that the written plan exists, that roles were assigned, and that tickets for the period follow its steps in order. A gap is a plan that was never used during the incident, or responders who acted outside it with no record of the deviation.

Recovery and restoration of the environment

The restoration points of focus under CC7.5 ask whether the affected environment was brought back to a known good state. The auditor looks for change tickets, backup restore logs, and sign-off that services were validated before they returned to production. A gap is a system restored from an undocumented snapshot, or a return to service approved verbally with nothing written down. Confirm which systems the incident touched before the auditor asks.

Root cause and preventing recurrence

Another set of CC7.5 points of focus covers determining root cause and implementing changes that prevent recurrence. The auditor reads the post-incident review for a stated root cause, linked corrective actions, and evidence that those actions were completed. A gap is a review that names a cause but has no tracked remediation, or corrective work that stays open past the end of the period. Link each finding to its change record.

Testing the incident recovery plan

CC7.5 also points to testing the incident recovery plan and improving response procedures based on the results. The auditor looks for exercise records, such as tabletop or restoration tests, with the findings and the updates that followed. A gap is a plan last tested before the period began, or a test whose findings never reached the procedures. Ask whether an incident in the period should trigger a test afterwards, and record that decision.

How an incident changes the examination timeline

This sequence shows how an incident that occurs during the examination period moves through detection, containment, assessment, disclosure and testing, and which record the auditor can inspect at each point before the final report is issued.

Detect and log the security event during the period
The security operations or on-call team identifies an event through monitoring, alerts or a report, and opens a ticket in the incident system with the time, systems involved and initial classification. Under CC7.3, the organization evaluates whether the event could cause or has caused a failure to meet its objectives. The output is a timestamped incident record that shows the event was logged and triaged, which the auditor can trace to the monitoring source.
Contain the incident and preserve evidence
The responders limit the impact, isolate affected components and capture logs, images and access records before they are overwritten or rotated. Preservation matters because the auditor will later ask how the incident was handled and whether the records support the account given. The output is a containment log and an evidence register showing what was collected, by whom, and where it is stored under chain-of-custody controls.
Assess whether the incident affected service commitments
Management, with security, legal and product input, decides whether the event caused or could have caused a failure to meet the principal service commitments and system requirements. This assessment feeds the incident program required by CC7.4 and identifies which trust services criteria the event touches. The output is a dated written assessment, signed or approved by a named owner, that explains the conclusion and the reasoning behind it.
Decide what to disclose in the system description
Management determines whether the incident is a significant system incident that must appear in the system description under DC 200. The description should state what happened, when, its effect on the system and the remediation taken, without overstating or hiding detail. The output is a draft of the incident disclosure, reviewed against the description criteria and approved by management, that the auditor can compare with the incident record.
Remediate, root cause and prevent recurrence
The team restores the affected environment, identifies root cause and implements changes that address it, consistent with the points of focus under CC7.5. Any control deficiency found during the response is evaluated and communicated under CC4.2 and tracked to closure. The output is a remediation record with root cause analysis, change tickets and deficiency tracking that link the fix to the original event.
Test the response and recovery controls
The auditor samples the incident and related records and tests whether the incident response program operated as designed throughout the period. Testing covers detection, escalation, containment, communication and recovery, and whether the team followed the defined procedures. The output is the auditor's workpapers and exception list, which show what was tested, the sample, and any deviations found.
Obtain management representations and issue the report
Management provides written representations to the service auditor, covering the completeness of incident disclosures and the accuracy of the system description, as required by AT-C section 205. The auditor then forms an opinion on the description and on the controls, with any exception or qualification stated in the report. The output is the signed representation letter and the issued report, whose disclosure and opinion the reader can compare against the incident record.

Management representations and the effect on the opinion

Management's written representations are part of the SOC 2 examination itself. AT-C section 205 requires the service auditor to obtain written representations from the responsible party, in a letter addressed to the auditor. The AICPA's illustrative Type 2 letter applies to reports dated on or after June 15, 2022, and the organization should ask its CPA firm which version it will use. Management signs that the system description is fairly presented, that the controls operated as described, and that it has disclosed all known instances of non-compliance, significant system incidents and control deficiencies that could affect the report. A security incident that occurred during the period, and the response to it, falls squarely within those representations. Confirm with the firm exactly which incident facts the letter asks management to state, and who in the company has authority to sign it.

An omitted incident is more damaging than a disclosed one. If an incident is left out of the system description or the representation letter, the auditor may find it through the incident tickets, customer escalations, or a review of CC7.3 and CC7.4 evidence. At that point the gap is no longer a control question alone: it becomes a question about whether management's statements can be relied on, and the engagement can stall or end. CC4.2 expects deficiencies to be evaluated and communicated promptly to the people responsible for corrective action, including senior management and the board as appropriate. Keep a dated record showing that the incident and its root-cause findings reached those people, because auditors often ask for it. Illustratively, a company whose board minutes show no discussion of a material incident will face harder questions than one whose minutes show a decision on remediation.

The opinion outcome depends on the auditor's judgment, and no organization can predict it. The auditor forms opinions on whether management's description is fairly presented and whether the controls were suitably designed and operated effectively over the period. An incident may lead to no exception, an exception on one control, or a modified opinion, depending on the severity, how the control performed, and whether the response was timely and documented. Ask the CPA firm early how it will treat exceptions, what evidence it will need on the incident and its recovery, and whether it expects to see the root-cause analysis before fieldwork closes. Plan for the report to describe the incident openly, and treat any statement that a particular outcome is assured as a warning sign.

Which incident situations change the report most

An incident is detected, contained and remediated without affecting service commitments, customer data or availability targets. It may still be a security event that the organization had to evaluate under CC7.3 and respond to under CC7.4, and the report has to show that the response program worked. The description must still reflect the incident if it qualifies as a significant system incident under DC 200, so the decision to disclose or omit should be documented with its reasoning.

Evaluation record: Keep the triage notes showing why the event did or did not cause a failure of objectives.
Response evidence: Tickets, timelines, containment actions and communications from the incident program.
Disclosure decision: A written judgment, approved by management, on whether the event is a significant system incident.
Follow-up: Root cause analysis and any change made to prevent recurrence, tied to CC7.5.
Exceptions: Gaps in triage documentation or late ticket creation are the usual source of findings even when the outcome was minor.

Illustrative example: a single phishing account is locked within minutes and no customer data is read. Check that the evaluation, containment and closure are all recorded and that the decision not to disclose is defensible on the record.

What must be in place before an incident happens

An incident that lands in the examination period is judged by the controls that existed before it. The cards below cover the artifacts an assessor will ask for first, and each one should be checked against the period, not against the day the report is written.

Written incident response program

The CC7.4 expectation is a defined incident response program that covers how events are understood, contained, remediated and communicated. Check that the document names owners, escalation paths and decision rights, and that it was approved and in force before the first day of the period. An assessor will compare what the team did during the incident with what the written program says should happen, so gaps between the two become exceptions in the report. Ask for the version history and the approval record.

Security event log linked to tickets

CC7.3 requires the organization to evaluate security events and decide whether they could cause or have caused a failure to meet its objectives. The evidence is a log of events with a documented disposition for each one, and a ticket that shows the triage, the decision and the follow-up action. Check that a sample of alerts traces forward to a ticket and that the ticket records who decided. Events that were dismissed without a recorded reason are a common source of questions.

Defined severity criteria

Without written severity criteria, the team cannot show consistent judgment about which events are significant system incidents and which are routine. The criteria should set thresholds for customer impact, data exposure, service availability and regulatory notice, and state who may reclassify an event. Check that the criteria were applied the same way across the period by sampling incidents of different severity. Inconsistent classification is hard to defend when the description of significant incidents under DC 200 is prepared.

Communication templates for customers and board

CC7.4 and the related points of focus expect communication about an incident, and CC4.2 expects deficiencies to reach the people who can act on them, including senior management and the board where appropriate. Pre-approved templates for customers, regulators and board updates show that communication was planned rather than improvised. Check that the templates name the approver, that they were used in past events, and that the board received updates on the dates recorded in the minutes.

Recovery testing records

The points of focus under CC7.5 include testing the incident recovery plan and improving response and recovery procedures after events. Recovery tests need dated records that show the scenario, the participants, the results and the corrective actions opened afterward. Check that tests were run during the period, not only before it, and that findings were tracked to closure. A plan that was never exercised gives an assessor little to test, and a test that found failures without follow-up raises the same question.

Who owns each part of incident disclosure

This table shows who decides, prepares and certifies each part of disclosing a significant incident in a SOC 2 report. Read the columns as a split of duties: the organization owns decisions and representations, the implementation partner prepares evidence and documentation, and the independent CPA forms and issues the opinion. The main takeaway is that a partner can make the evidence ready, but it does not decide what the report discloses.

Task	Organization	Implementation partner	Independent CPA
Classifying the incident	Decides whether an event is a significant system incident and documents the reasoning	Supplies incident logs, timelines and triage records for the decision	Tests whether the classification process under CC7.3 operated as described
Writing the description disclosure	Owns the wording of the significant incident disclosure under DC 200	Drafts supporting narrative from the evidence and checks it against system records	Evaluates whether the description is fairly presented and reads it for consistency
Preserving evidence	Sets retention rules and approves what is kept and who can access it	Configures log retention, snapshots and access controls that keep evidence intact	Requests the preserved records and tests that they are complete and unaltered
Root cause analysis	Determines root cause and approves corrective changes	Performs technical analysis and documents findings for management review	Reviews whether root cause work and follow-up changes are evidenced under CC7.5
Management representations	Signs the written representation letter to the service auditor, covering known incidents	Helps assemble the facts behind each statement so management can verify them	Requests the letter under AT-C section 205 and relies on it in forming the opinion
Issuing the opinion	Accepts the report and decides how it is shared with customers	Has no role in forming or signing the opinion	Forms and issues the opinion and any modification to it

Common mistakes that turn an incident into an exception

An incident during the period is not an exception by itself. Most of the damage comes from how the organization describes, classifies, investigates and evidences the event afterward. The five mistakes below are the places where a clean incident response becomes a qualified or hard-to-read report.

Leaving the incident out of the description

Management's system description must disclose significant system incidents that occurred during the period, under DC 200. An incident that was contained quickly still belongs there if it was significant. Before fieldwork, reconcile the incident log against the description draft and ask the auditor to confirm which events they consider significant. Omitting an event the auditor later finds in tickets damages trust in every other statement in the report.

Closing tickets without root cause

CC7.5 points of focus include determining root cause and implementing changes to prevent recurrence. A ticket closed as resolved with no root cause analysis leaves the auditor unable to show that the event was evaluated and corrected. Require a documented root cause, a linked corrective action and an owner before any incident ticket can move to closed. Sample a few closed tickets yourself before the auditor does.

Incomplete evidence of recovery testing

Under CC7.5, the organization should test its incident recovery plan. Teams often run a restore once during an incident and have no record of a planned test. Keep dated test records with scope, participants, results and the follow-up actions, including failed steps. Gaps in this evidence turn a recovered incident into a question about whether recovery works at all.

Inconsistent severity classification

The same type of event is often rated high in one ticket and low in another, and the description then reads as if the organization applied its own definitions loosely. Publish a severity scale that states which events count as security incidents and which count as significant. Record the rating rationale in each ticket, and check that incident, security and availability records agree with each other before the period closes.

Representation letters signed before the incident review

AT-C section 205 requires management's written representations to the service auditor, and the illustrative Type 2 letter asks management to confirm that it has disclosed known incidents and deficiencies. Signing before the incident review is complete means the letter may certify a picture that the review later changes. Finish the review, update the description and exceptions list, then have the responsible officers sign the letter against the final version.

Questions about SOC 2 and security incidents

Does a security incident void our SOC 2 report?

No. An incident does not automatically void a SOC 2 report, but it can change what the report says. The report covers a defined period, and the auditor looks at whether the incident exposed a control to failure, whether the controls operated as described, and how the organization handled the event. The service auditor evaluates security events under CC7.3, the response under CC7.4 and the recovery work under CC7.5, then reads the system description for significant system incidents under DC 200. If controls did not operate as described, the report may show exceptions, and in serious cases the opinion may be modified. Before relying on a report, read the examination period, the exceptions section and the description of incidents.

Must we disclose every security incident in our SOC 2 report?

Every event must be logged, but only significant system incidents must appear in management's description. Under DC 200, the system description covers significant system incidents that occurred during the period. Minor events that were contained and did not affect your service commitments usually do not need individual description, but you need a documented basis for that judgment. Keep a log of security events, your severity criteria, who classified each event and why. Auditors sample this log and compare it with tickets, alerts and customer complaints. Omitted incidents found later are a frequent source of trouble. Management makes the disclosure decision, so have counsel and the auditor review borderline cases before the report is finalized.

Will the auditor test our incident response if the incident was minor?

Yes, if the event falls within the examination period and the criteria apply to it. Auditors test CC7.3 and CC7.4 by sampling security events, and a minor event is still a candidate for the sample. Expect requests for the alert, triage notes, the classification decision, containment actions, the ticket and any customer communication. Severity changes how deep the review goes, not whether evidence is requested. For the root-cause and prevention points of focus under CC7.5, the auditor will look for a documented analysis and any change made as a result. A well-documented response often gives the auditor evidence that controls worked. The usual weak point is a missing record, not the event itself.

Can we fix the problem quietly and leave it out of the report?

Fixing the problem is required, and leaving the event out of the report is a separate and serious risk. Remediation is what CC7.4 and CC7.5 expect, including restoration of the environment, root-cause analysis and changes to prevent recurrence. Those steps are tested and become evidence. Omitting a significant system incident from the description creates an incomplete picture that management represents to the service auditor. AT-C section 205 requires written representations from management in a letter addressed to the auditor, and those representations must be accurate. An incomplete description can damage the engagement and the trust of customers who rely on the report. If you believe an event falls below the significance threshold, document that reasoning now and let the auditor test it.

Does a security incident increase our SOC 2 cost or delay our timeline?

It can, and the size of the effect depends on drivers you can identify. No researched figure is available for this, so ask for a written estimate. Costs usually come from additional testing of affected controls, extra sampling of security events, incident forensics or an outside investigator, legal review of disclosure wording and, where controls changed mid-period, a longer or separate testing window. Your own team pays for remediation and evidence work. The auditor charges for testing under its engagement letter. A forensic firm charges for investigation. Most of these costs are one-time for the event, but permanent monitoring added as a fix recurs. Ask each provider which items are inside the quoted scope and which would be additional work.

Can DeployOpen issue or change our SOC 2 report after an incident?

No. DeployOpen does not issue, sign or change a SOC 2 report. Only an independent CPA firm can express the examination opinions, and management owns the system description and its representations. Where DeployOpen is engaged, the work is preparing systems and evidence: reviewing logging and detection coverage, documenting the incident response program, rebuilding evidence for affected controls and organizing a timeline of events for management's review. This work is fixed scope and agreed in writing before it starts. Any change to the description or to disclosure is decided by your management and discussed with your auditor. Ask in writing what the engagement covers and confirm that your auditor will accept the evidence in the form it is delivered.

How DeployOpen prepares incident evidence for the audit

DeployOpen prepares the incident evidence that the CPA firm will examine. It does not issue SOC 2 reports, attestations or certifications. Only the independent CPA firm performing the examination can form and sign an opinion. Before any work starts, DeployOpen agrees the scope in writing, normally as a fixed-scope engagement, and that document should name the systems in the boundary, the trust services categories in scope, the period under review and the incident records to be covered. Ask for that written scope to state who owns each control, since the organization keeps responsibility for its controls and management's representations, and DeployOpen's role is to prepare systems and evidence.

Once scope is fixed, the work starts with the incident records themselves. DeployOpen reviews the ticketing and case history, alert and log records, containment and eradication notes, post-incident reviews and any customer or regulator notifications for each event in the period. The aim is to show whether each event was evaluated against the security objectives under CC7.3, whether the response followed the documented program under CC7.4, and whether recovery and root cause work under CC7.5 left traceable records. Where a record is missing or inconsistent, the gap is raised with the organization so it can be explained accurately rather than reconstructed after the fact. Inputs for the system description, including the significant system incidents field under DC 200, are drafted from these records and checked against them, and management reviews and approves the final wording.

The handover is a documented evidence package: an index of incident records mapped to the relevant criteria, the control descriptions and owners, and a log of open items. Confirm with DeployOpen and with the CPA firm which format the auditor expects, how samples will be pulled, and how evidence is retained after the report is issued. Also confirm that the CPA firm has agreed the examination approach before any evidence is finalized, since the auditor decides what is tested, how sampling works and how exceptions are assessed. Any future incident evidence work should be quoted from the same written scope, so the cost and timing of each phase is visible before it begins.