P6.6 Breach and incident notification: SOC 2 requirements

What SOC 2 P6.6 breach notification asks for in plain terms

P6.6 asks whether your organization notifies affected data subjects, regulators and other parties when a breach or incident involving personal information occurs, and whether that notice follows the privacy objectives you have committed to. If your SOC 2 includes the privacy category, an assessor will expect you to show two things: that you identified which notification duties apply to you, and that you carried them out. The criterion is not satisfied by a generic incident response plan alone. The assessor will look for a documented list of who must be told, what they must be told, and by when, tied to the commitments in your privacy notice and customer contracts.

The difficulty is that the reporting requirements rarely come from one source. A single incident can trigger obligations written into customer contracts, data processing terms, sector rules and privacy laws in several jurisdictions, each with its own recipients, content and deadlines. Many of these clocks start when the organization detects or reasonably should have detected the event, not when the investigation concludes. Late, missing or inconsistent notice is the failure an assessor is most likely to find, because it shows the control did not operate when it mattered. Confirm with counsel which regimes apply to your customer base before you write the matrix, since the assessor will test against the list you choose, not one they supply.

P6.6 sits in the privacy category, so it applies only when you include privacy in scope. The points of focus under the criterion help you design the control, such as identifying reporting requirements and giving notice of breaches and incidents, but they are not separate requirements and you do not need to address every one. Practically, the control is a maintained register of notification obligations linked to your incident response procedure and tested through a tabletop exercise or a real event. Ask your auditor early which evidence they expect to see for the register, the notice drafts and the timing records, so the control is designed to produce that evidence from the start.

Which systems, data, teams and contracts fall under SOC 2 P6.6 notification

P6.6 notification work is only as wide as the scope it sits in. The decisions below determine which personal information the notice duty covers, which systems and teams must detect and report, and which contracts and third parties add their own deadlines. Settle them before writing the procedure, because each one changes what the auditor will test.

Personal information in the privacy commitments

Start with the personal information named in the privacy notice and commitments in scope for the privacy category. A notification procedure that covers only customer account data misses any other category the commitments promise to protect, such as support tickets, analytics identifiers or employee records if they are in scope. List each data category, its purpose and where it is held. Then ask whether each category triggers a notice duty under the contracts and laws that apply to it. Ask for a written data inventory that the auditor can trace back to the commitments.

Systems that store or process it

Every system that holds the in-scope personal information must feed detection and escalation into the same incident process. That usually includes production databases, object storage, logging pipelines, backups, data warehouses and support tools. Map each system to its owner, its logging source and its alerting path. A system that is missing from the map can hold a breach that nobody reports, so the auditor will test whether the inventory matches what is actually running.

Customer contracts with notice duties

Customer agreements often set their own notice periods, required content and contact routes for security incidents and unauthorized disclosures, sometimes separate from statutory deadlines. Collect every contract clause on incident or breach notice and convert it into a register with the trigger, the recipient, the deadline and the approver. Illustrative example: a contract requiring notice to a customer's security contact within a fixed window would need an escalation step that starts the clock at detection, not at legal sign-off. Ask legal to confirm each entry.

Regulations that set notice duties

Privacy and sector regulations that apply to the organization or its customers can require notice to regulators, affected individuals or both, each with its own content rules and timing. Identify which laws apply by data subject location, customer sector and role (controller, processor or service provider). The GDPR breach notification duties are one example that many SaaS vendors meet through their customers, so confirm with counsel which duties fall on the organization directly and which fall on the customer. Document the result as a decision table the incident team can use under pressure.

Teams that decide and send notices

Notification is a decision that spans security, legal, privacy, customer success and communications. Scope must name who detects, who classifies an event as a breach or incident, who approves notice, who drafts it and who sends it. Each role needs a named backup. The auditor will look for evidence that these roles were assigned and that the people in them knew their responsibilities before an event occurred, so record the roster, the approval steps and the contact lists as part of the scope.

Subservice organizations and vendors

Third parties that hold or process personal information must be able to pass suspected or actual unauthorized disclosures back to the organization quickly enough to meet its own deadlines. Scope should list each subservice organization, its contract clause on incident notice, its notice window and the contact route into incident response. Cloud providers and SOC reports from them can inform this work, but the organization still owns the commitment it makes to its own data subjects and customers. Confirm the vendor notice terms and test them before relying on them.

How a SOC 2 assessor tests P6.6 notification

This table compares what an assessor does, what evidence they ask for, and where organizations commonly fall short when testing P6.6 notification. Read each row as one step in the test, with the right-hand column showing what a clean result looks like. The main takeaway is that notification is tested end to end, from detection through the notice decision to the notice itself.

Test step	Evidence requested	Common findings
Review reporting requirements	Documented list of breach and incident reporting requirements, mapped to privacy commitments and the data types and jurisdictions they cover	No reporting requirements identified, or requirements exist in legal memos but not in the privacy commitments the auditor is testing
Sample past incidents and breaches	Incident register, tickets and investigation records for the period, selected by the auditor from the full population	Incident population is incomplete, so the sample cannot show that every relevant event was considered
Trace detection to notice	Timeline showing when the event was detected, classified, escalated and assessed for notice	Gaps between detection and assessment with no record explaining the delay
Check notice content and recipients	Copies of notices sent to data subjects, regulators and other named parties, compared with the content and recipients the requirements name	Notices omit required content, or a recipient named in the requirement never received one
Test timing against the documented process	Documented notification deadlines or triggers, and the send dates recorded for each sampled notice	Deadlines exist on paper but no send date is recorded, so timing cannot be tested
Confirm the notice decision	Recorded decision for each incident, with the reasoning and approver, including decisions not to notify	Incidents closed without a notice decision, leaving the auditor unable to tell whether notice was considered
Check third-party notices feed the process	Vendor notification commitments and examples of vendor notices routed into the same incident workflow	Vendor notices arrive by email or phone and are not logged, so they never reach the notice decision

Implementing P6.6 notification in six steps

This sequence turns the P6.6 notification duty into a documented procedure with named owners, tested templates and a record of rehearsal, so the organization can show an assessor how it notifies affected parties when a breach or incident occurs.

Inventory reporting requirements by data category
List every obligation that could require notice of a breach or incident: applicable laws, regulator rules, customer contract clauses, and commitments made in the privacy notice. Group them by the category of personal information involved, such as payment data, health data or employee records, because each category often carries different recipients. Ask legal counsel to confirm each entry and the jurisdictions it covers. The step is complete when every requirement has an owner, a source document and a version date.
Map each requirement to its notice elements
For each inventoried requirement, record who must be notified (data subjects, regulators, customers, other parties), what the notice must contain, what event triggers the duty, and what timing the source text sets. Where the source does not state a deadline, record that gap and ask counsel to confirm the expectation rather than assuming one. Illustratively, a customer contract may trigger notice on suspected exposure while a statute triggers on confirmed loss, and the matrix should show both. The output is a requirement matrix that incident responders can read without legal training.
Write the notification procedure with decision owners
Draft a procedure that states who decides whether an event is a reportable breach, who approves each notice, who speaks for the organization, and who keeps the clock. Link each decision point to the matrix from the previous step and define what evidence the decision relies on. Assign a backup for every owner so that absence does not stop a notice. The procedure is finished when each decision has a named role, an approver and a written record format, and leadership has signed it off.
Build templates and the approval path
Prepare notice templates for each recipient type identified in the matrix, with fixed sections for facts known, data affected, actions taken and contact details, plus blank fields for details still under investigation. Set the approval path, including legal review and any sign-off that a regulator or customer contract requires. Store templates under version control with an owner and a review date. The output is a template library and an approval record that shows who may release each notice type.
Connect notification to incident response and vendor commitments
Join the notification procedure to the incident response process so that a detected event opens a case that tracks scope, affected data categories and notice decisions in one place. Confirm that notice commitments obtained from vendors and other third parties route actual or suspected unauthorized disclosures into this same process, and that your own contracts say what you must send to customers. The check is a walkthrough showing that an alert from monitoring reaches the notification owner with the data needed for each template. Case management tools such as DFIR-IRIS can hold that record, but confirm the fit with your own workflow.
Rehearse with a tabletop exercise and keep the record
Run a tabletop exercise built on a realistic but invented scenario in which personal information is exposed, and walk the team through decisions, templates and approvals in sequence. Record attendance, the decisions taken, the time each decision took, gaps found and the corrective actions assigned with owners. Update the matrix, procedure and templates from the findings, then repeat the exercise on a set schedule. An assessor will look for this record as evidence that the procedure works in practice, so retain it with the policy and evidence set.

Evidence that passes P6.6 and how to keep it current

An auditor testing P6.6 looks for a chain of records: the reporting obligations the organization identified, the procedure it follows, and proof that it applied both to real incidents. The cards below cover the artifacts that form that chain and how to keep them accurate between examinations.

Register of reporting requirements

This register lists each notification obligation the organization has identified, including the recipient, the trigger, the deadline and the source of the requirement, such as a customer contract, a data processing agreement or a regulation. Each row needs a named owner and a review date. Check that the register reflects the jurisdictions where data subjects live and the contracts that carry notice clauses, since the P6.6 points of focus ask the organization to identify these requirements first.

Documented notification procedure

The procedure explains who decides that an event is a notifiable breach, how legal and privacy staff are engaged, what content each notice must contain and who sends it. Auditors compare this document with what actually happened in incident records. Confirm that it names roles rather than individuals only, that it maps to the register, and that the version and approval date are visible.

Incident case records with notice decisions

For each incident, the case file should show the facts considered, the requirements tested against them, and a written decision to notify or not notify, with the reasoning. A decision not to notify is evidence too, and auditors look for it. DFIR-IRIS can hold these decisions in the same case as assets, evidence and the investigation timeline, which keeps the reasoning attached to the record it describes.

Copies of issued notices

Keep a copy of every notice as sent, with the recipient list, delivery method and date. For regulators and customers, the record should show that the notice included the content the register requires. Store the sent version rather than a later draft, and reconcile the count of notices against the incident log so that no notice exists without a corresponding case.

Approval records

Approvals show that someone with authority reviewed the notice decision and the wording before release. Record the approver, the date and any changes requested. Auditors often sample notices and check that the approval predates the send date, so timestamps in the approval workflow must be reliable and retained for the review period.

Tabletop exercise reports

A tabletop exercise walks the team through a hypothetical breach to test the register and procedure. The report should state the scenario, the participants, the gaps found and the corrective actions with owners. Illustrative example: a scenario involving a vendor's breach would test whether the third-party notification commitments route into the same procedure. Update the register after each exercise and record that change.

What meeting P6.6 notification costs in money and effort

This table compares the cost components of building and running P6.6 notification, who is typically paid for each, whether it is one-time or recurring, and what moves it up or down. No figures are given because none are supplied for this topic, so use the questions in the final column to request comparable quotes. Most of the recurring effort sits in keeping the requirement register and notice templates current.

Cost component	Who is paid or who spends time	One-time or recurring, and what drives it	What to ask for in a quote
Legal review of the requirement register	Outside privacy counsel or in-house legal	Mostly one-time to build the register, then recurring on each change. Driven by the number of contracts, jurisdictions and data categories in scope.	Written list of laws and contracts reviewed, assumptions on jurisdictions, and what triggers a re-review.
Engineering time for case records and alert routing	Internal engineers or the implementation partner	One-time to configure case records and routing, then recurring for tuning. Driven by alert volume and the number of source systems feeding incidents.	Named deliverables for case fields, routing rules and evidence logging, plus who owns changes afterward.
Drafting and template upkeep	Privacy, legal and communications staff	Initial drafting is one-time. Template updates recur whenever a notice requirement or contract term changes.	Confirmation of which templates are drafted, who approves them, and the review cycle.
Tabletop exercises	Incident response leads, legal, privacy and executives	Recurring, usually at a set interval. Driven by team size, number of scenarios and whether third parties join.	Facilitator role, scenario scope, and whether the exercise output is written up as evidence.
Third-party notice commitment reviews	Vendor management, procurement and legal	Recurring with each vendor and each contract renewal. Driven by the number of processors with access to personal information.	Review checklist, how notice clauses are tracked, and how gaps are escalated and closed.
Auditor sampling of incidents and notices	Independent CPA firm, with staff time from the organization	Recurring each examination period. Driven by the number of incidents and notices in the period and the sample the auditor selects.	Auditor's fee basis, the evidence list requested, and the sampling approach for the period.

Who owns P6.6 notification, who can help, and where the auditor stops

Your organization owns the P6.6 control. That means it decides which breaches and incidents trigger notice, identifies every reporting requirement that applies to its personal information, and approves the wording and timing of each notice. Legal counsel and the privacy lead sign off on these decisions, and the people accountable for the control must be able to show the auditor who made them and when. A SOC 2 cannot be outsourced in this sense: the service organization asserts its own controls, and the auditor tests the assertion.

Requirement register: Maintain a documented list of notification duties by jurisdiction, contract and data type, with a named owner and a review date.
Decision rights: Name who declares an incident reportable, who can approve a notice, and who can delay one while facts are gathered.
Legal sign-off: Keep counsel's review of templates and triggers on record, including changes after new customer contracts.
Notices sent: Your staff or counsel send every notice under your name, and retain copies, recipients and timestamps.
Management assertion: Leadership signs the system description and representations that cover this control.

Check that each requirement in the register traces to a named owner who can produce the decision record on request.

Where P6.6 notification usually fails and how to close each gap

Most P6.6 failures are not failures to send a notice. They are gaps in the decisions and records that should come before a notice goes out. The cards below cover the gaps assessors most often find and a closing action for each.

Reporting requirements never listed

Many teams know they must notify customers but have never written down which regulators, contracts and data subjects apply to them, or what triggers each duty. P6.6 starts with identifying those reporting requirements. Build a register that names each obligation, its trigger, its recipient, its deadline and its owner, then review it when products, regions or customer contracts change. Confirm each entry against the contract or regulation text rather than memory.

No link between incident response and privacy

Security responders often handle an incident without involving the people who decide whether personal information was affected. The result is a late notification decision made after the technical facts are already settled. Add the privacy lead to the incident response roster with a defined point of entry, and require a privacy impact check at the first triage meeting. Record when that check happened so the timeline is provable.

Notices sent without a documented decision

A notice that goes out with no recorded reasoning is hard to defend. An assessor will ask who decided that an incident did or did not require notice, on what facts, and when. Require a written notification decision for every incident that touches personal information, including decisions not to notify. Store the decision, its approver and the facts relied on in the case record, so the reasoning survives staff turnover.

Third-party notices not routed into incident handling

Vendors and processors often learn of a problem first, and their notices may arrive in a sales inbox or a generic support queue. Under P6.5 the organization must have committed vendors to notify it, and under P6.6 those notices must reach the incident process. Map each vendor notice channel to the incident intake, test it with a tabletop exercise, and confirm contract terms cover both actual and suspected unauthorized disclosures.

Templates that omit required content

Pre-written notice templates often describe what happened but leave out elements that a regulator or contract requires, such as the categories of data involved, contact details or recommended steps for the individual. Build one template per recipient type, map each required element to the register entry it satisfies, and have counsel review the mapping before an incident. Keep templates versioned so the version used in a real notice can be shown later.

No evidence retained after closure

Once an incident is closed, the notices, timestamps, approvals and delivery records often scatter across email, chat and shared drives. An assessor testing P6.6 across the audit period will ask for them, and a gap in the trail reads as a control failure. Keep the complete case in one incident record with an audit trail, retain copies of each notice as sent and proof of delivery, and set retention rules aligned with the organization's privacy objectives.

How incident case records support a defensible notice decision

A case-management platform does not decide whether a breach must be reported, but it can make that decision traceable. The organization still decides who must be notified, and under P6.6 it must do so in line with its own privacy objectives and the reporting requirements it has identified. A tool such as the open-source DFIR-IRIS (LGPL-3.0-or-later) can hold each incident as one case containing its assets, indicators of compromise, tasks and evidence, with an audit trail of who changed what and when. That single record gives the privacy, legal and security leads one place to see the facts behind each notice decision, rather than reconstructing them from chat threads and inboxes.

Triage is where the record starts. DFIR-IRIS can take alerts from SIEM, EDR and REST sources and group related alerts into cases, so the affected systems and data stores are linked to the incident early. For notice purposes, the team needs to know which personal information was in scope, which data subjects and third parties it concerned, and when the organization first became aware of the event. A consolidated investigation timeline built from case data helps answer those questions with dated entries instead of recollection. Evidence logged with SHA-256 verification and chain of custody supports the claim that the facts relied on were not altered after collection.

Reports generated from case data are the artifact a reviewer will ask for. Before relying on any of this, the team should confirm in its own environment which connectors, field mappings, case templates and report formats are available in the version it deploys, and whether the audit trail meets its retention needs. The team should also decide who may close a case, who approves a notice, and how the rationale for notifying or not notifying is recorded inside the case. An independent auditor will test whether the notice decisions were consistent with the stated requirements, so the case record should show the decision, its basis and its approver.

Questions buyers ask about SOC 2 P6.6 notification

How much effort does SOC 2 P6.6 take, and what drives it?

The effort depends mostly on how many notification obligations the organization has and how many customer contracts and jurisdictions they span. P6.6 asks the organization to notify affected data subjects, regulators and others of breaches and incidents in line with its privacy objectives. The work has two parts: mapping every reporting requirement that applies, and building a procedure that meets each one within the time it allows. Organizations with a single customer base and one jurisdiction have a short list to maintain. Those with contracts in several countries, sector regulators and processor roles carry a longer list, and each entry needs an owner, a trigger and a template. The cost is mostly internal staff time, plus any legal review and any outside help you buy. Ask any provider to break its quote into mapping, procedure design, tooling and testing of the notice process.

Can a team meet SOC 2 P6.6 without outside help?

Yes, a capable internal team can meet P6.6 without an implementation partner, because the criterion is about the organization's own obligations and decisions. The team needs a current list of reporting requirements, a documented notification procedure, named decision owners, and records showing that notices were issued when required. Outside help is most useful for the technical parts: wiring detection and case records into a repeatable workflow, and producing evidence in a form the auditor can sample. Legal interpretation of which regulators and individuals must be told, and within what period, should come from counsel. Confirm with your CPA firm what evidence it expects before you design the process, since the examination tests whether the controls operated, not only whether they were written down.

How long does P6.6 work take, and who must be involved?

The timeline depends on how much of the notification process already exists and how many parties must sign off. Typically the work touches three groups. Legal or privacy counsel identifies the reporting requirements and drafts notice content. Security leads define triggers, severity levels and the decision path from detection to notice. Engineering supplies the technical facts that go into a notice, such as affected systems, data categories and timeline, and maintains the logging and case records that prove the process ran. Ask any provider for a schedule that shows when each group is needed, and check whether it assumes a Type 1 or Type 2 examination, because a Type 2 report needs the process to operate over the observation period. The exact duration is not something this page can state; confirm it with your auditor and the people who will own the work.

Can an implementation partner decide whether a breach notice is sent?

No. The organization decides whether a notice is required, to whom, what it says and when it goes out. An implementation partner can prepare the systems, workflows and evidence that support that decision, but it does not make the legal determination or act as the notifying party. Independent auditors and certification bodies issue reports and certificates, and they do not make these decisions either. In a written scope, the organization should keep sole authority over notice decisions and approvals, and the partner's role should be limited to configuring tools, documenting the procedure, and keeping records of how each incident was handled. If a provider offers to take over notifications, treat that as a reason to check its legal and regulatory standing with your counsel before signing.

What will the SOC 2 auditor sample for P6.6?

The auditor will typically ask for the list of reporting requirements, the notification procedure, and records from actual incidents or breaches during the examination period. If there were none, the auditor will look for evidence that the procedure was reviewed and that tabletop exercises or test notices were run. For any sampled event, the auditor generally checks whether the organization identified the relevant reporting requirement, made the decision on time under its own procedure, sent notices with the required content to the right recipients, and recorded the timeline. Expect requests for case records, approval trails, copies of issued notices and correspondence with regulators or customers. Ask your CPA firm early which samples it expects, how far back it will look, and how it treats events that fell outside the examination period.

How does P6.6 relate to P6.3 and P6.5?

P6.3, P6.5 and P6.6 form one chain of incident handling around personal information. P6.3 requires a complete, accurate and timely record of detected or reported unauthorized disclosures, including breaches. P6.5 requires commitments from vendors and third parties to tell the organization about actual or suspected unauthorized disclosures, and to route those notices into incident response. P6.6 then requires the organization to notify affected data subjects, regulators and others based on its identified reporting requirements. In practice, a vendor notice under P6.5 creates a case that is recorded under P6.3, and that case drives the P6.6 decision. Test the chain end to end: a notice from a third party should be traceable through the record to the outbound notification, with the same timeline and owners at each step.

How DeployOpen prepares P6.6 notification controls and evidence

DeployOpen prepares the systems, documented procedures and evidence that show how an organization identifies its breach and incident reporting requirements and gives notice when it must. The organization owns its notification decisions and obligations, and an independent SOC 2 auditor decides whether the controls operated as described.

How we scope

The written scope lists which notification obligations apply, such as customer contracts, regulators and affected data subjects.
Scope defines which incident sources, case records and communication channels the P6.6 controls must cover.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We configure self-hosted case management so each privacy incident keeps its timeline, affected assets and decision records.
We document a reporting-requirements register and link each requirement to the people and triggers that start notice.
We test alert triage and report generation with sample incidents to confirm the evidence is complete and retrievable.

How we hand over

Handover includes the procedures, notification templates, control descriptions and sample evidence packages for the auditor.
We walk the client's responsible staff through running a case from intake to closure and recording notice decisions.
Evidence is delivered in the client's own infrastructure, so the organization keeps custody of every record.

How we support

Ongoing support is available as a retainer for upgrades, reviews of reporting requirements and changes in notice obligations.
Continuous security testing can check whether incident records and notification workflows still hold up over time.
Before an audit period, we can help confirm the evidence list with the client, with the CPA firm making its own determinations.