Breach handling and privacy incident response

The breach handling and privacy incident response requirement under ISO/IEC 27701 expects you to detect, triage, investigate, and resolve privacy incidents with a documented assessment and a documented notification decision. To operationalize it quickly, implement a privacy-incident playbook, a decision record for notification rationale, and an evidence trail that ties each incident to actions, approvals, and communications. ¹

Key takeaways:

• You need a repeatable process that produces written incident assessments and notification decisions for every privacy incident. ¹
• Your auditors will look for evidence: playbooks, logs, decision records, and proof you tested the process. ¹
• Build the workflow to handle both controller and processor obligations, including coordination with third parties and customers. ¹

“Breach handling and privacy incident response” in ISO/IEC 27701 is an operational requirement disguised as a documentation requirement. The core test is simple: when something happens that could affect personal data, can you prove you assessed it, decided whether notification was required, and executed the decision consistently? ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to standardize your privacy incident lifecycle so it produces auditable artifacts by default. That means a single intake path, clear roles (privacy, security, legal, communications, product, and customer support), a defined severity model that includes privacy impact, and a “decision memo” template that captures your notification analysis and sign-offs.

ISO/IEC 27701 sits alongside your information security incident response (often ISO/IEC 27001-aligned). The privacy overlay changes what you track: data subjects, categories of personal data, processor/controller posture, downstream sharing, and notification triggers by contract and jurisdiction. This page focuses on making the breach handling and privacy incident response requirement executable in days, not quarters. ¹

Regulatory text

Provided excerpt (framework summary): “Baseline implementation-intent summary derived from publicly available framework overviews; licensed standard text is not reproduced in this record.” ¹

Implementation intent summary: “Respond to privacy incidents with documented assessment and notification decisions.” ¹

What the operator must do:
You must run a documented process for privacy incidents that (1) assesses the incident’s privacy impact and (2) records the decision on whether to notify (and who to notify), including the rationale and approvals. The requirement is not satisfied by having an IR plan alone; you need consistent, incident-by-incident evidence that the plan was followed and that notification decisions were made deliberately. ¹

Plain-English interpretation (what this requirement is really testing)

A privacy incident is any event that compromises, or could compromise, confidentiality, integrity, or availability of personal data, or otherwise violates your privacy commitments (policy, notice, contract, or processing instructions). Your program passes this requirement if:

• Staff can recognize and report privacy incidents fast.
• Security can investigate with privacy questions baked in.
• Privacy and Legal can make a notification decision using defined criteria.
• You can show your work afterward: timeline, scope, impact, and approvals. ¹

Who it applies to (entity and operational context)

Entity scope:

• Data controllers (you determine purposes/means of processing): you own most external notification obligations and data subject messaging in many scenarios. ¹
• Data processors (you process on behalf of a controller): you must assess and notify the controller per contract and support their notification duties, while managing your own regulator/contractual obligations as applicable. ¹

Operational scope (where this shows up):

• Security incidents that touch systems storing or transmitting personal data (cloud storage, data warehouses, SaaS apps, endpoints).
• Misdelivery, misconfiguration, or access-control failures (wrong recipient, public bucket, overly broad permissions).
• Third party incidents where your vendor/processor is the source, or where you are the processor for a customer.
• Product incidents (logging sensitive fields, analytics collecting more than intended, broken deletion requests that keep data longer than stated).

What you actually need to do (step-by-step)

1) Define “privacy incident” and align it to your incident taxonomy

• Update your incident classification to include a privacy impact flag and personal data involvement fields.
• Publish examples that trigger privacy review (exposed customer list, employee HR file access, production data in dev tools).
• Map privacy incidents to your existing security incident response workflow so teams do not run parallel processes. ¹

2) Establish roles, decision rights, and a single intake channel

Minimum roles to name in the playbook:

• Incident Commander (Security/IT): runs the timeline and containment.
• Privacy Lead (DPO/Privacy Counsel/Privacy Program): owns privacy assessment content.
• Legal: privilege strategy, regulatory interpretation, contractual notice.
• Comms/PR + Customer Support: message control and customer handling.
• Product/Engineering: remediation and prevention work. Define who can declare a privacy incident, who can approve notification, and who can speak externally. ¹

3) Build a documented privacy incident assessment template (make it mandatory)

Your assessment form should capture, at minimum:

• What happened and how it was detected.
• Systems, datasets, and environments affected.
• Categories of personal data and data subjects impacted.
• Whether data was accessed, exfiltrated, altered, deleted, or merely exposed.
• Whether encryption/controls were in place (facts only; avoid speculation).
• Third parties involved and contractual roles (controller vs processor).
• Containment steps taken and residual risk. This template is the backbone of “documented assessment.” ¹

4) Create a notification decision record (“decision memo”) with required sign-offs

For each privacy incident, create a decision record that answers:

• Notify or not? If not notifying, state the rationale and what evidence supports it.
• Who to notify? Customers (controllers), regulators (where applicable), affected individuals (where applicable), internal stakeholders, law enforcement (if applicable).
• Timing and channel: contractual notice windows, customer SLAs, and operational comms plan.
• Content control: approved facts, what is still unknown, and next update cadence. Include explicit approvals (name, role, date/time). Auditors want to see that the decision was made, reviewed, and owned. ¹

5) Operationalize coordination with third parties

You need two playbook branches:

• Your third party caused the incident: pull the vendor into your incident bridge, demand their timeline, scope, and impacted data, and preserve their communications as evidence.
• You are the processor for a customer: notify the customer/controller per contract, provide impact details, and track customer-specific instructions for containment and communications. ¹

Practical control: maintain a “who to call” roster for critical third parties (cloud, payroll, CRM, MSSP) with escalation paths and after-hours contacts.

6) Run post-incident activities that generate prevention evidence

Close the loop with:

• Root cause analysis that distinguishes technical cause from process cause (missed alert, unclear ownership, incomplete asset inventory).
• Corrective actions with owners and due dates.
• Updates to playbooks, training, and monitoring rules based on the incident. This matters because repeat incidents with the same failure mode often trigger tougher scrutiny. ¹

7) Test the process and keep proof you tested it

Run tabletop exercises that include privacy-specific decision points (processor/controller confusion, uncertain scope, vendor delays). Keep outputs: agenda, participants, scenarios, gaps found, remediation plan. ¹

Required evidence and artifacts to retain (audit-ready list)

Maintain these artifacts in a controlled repository:

• Privacy incident response policy and playbooks (including roles and escalation).
• Incident intake records (tickets) with timestamps and classification.
• Privacy incident assessment forms per incident.
• Notification decision memos per incident, including approvals and rationale.
• Communications logs: customer notices, internal updates, regulator drafts (if any), call notes.
• Forensics/technical evidence references: affected systems list, log preservation steps, containment actions.
• Third party correspondence and contractual notification tracking.
• Post-incident reports: root cause, corrective actions, prevention controls.
• Tabletop/test evidence and training records for relevant teams. ¹

Retention period should be set by your internal policy and legal hold practices; ISO/IEC 27701 expects you to have evidence available for assurance and audit. ¹

Common exam/audit questions and hangups

Auditors and assessors tend to probe:

• “Show me your last privacy incident. Where is the documented assessment and the notification decision?” ¹
• “How do you determine whether an incident is a privacy incident?”
• “Who approves notification decisions, and how do you avoid ad hoc judgments?”
• “How do you handle processor-to-controller notification and track contractual timelines?”
• “How do you ensure third parties escalate incidents to you promptly?”
• “How do you test this process, and what did you change after the last test?” ¹

Hangup: many teams can show a security IR ticket but cannot show privacy-specific rationale and sign-off. Your fix is the decision memo.

Frequent implementation mistakes (and how to avoid them)

1. No written rationale for “no notification.”
   Fix: require a decision memo for every privacy incident, even if the decision is “no notice.”

2. Confusing security severity with privacy impact.
   Fix: add privacy impact fields (data types, subjects, exposure) to the severity model.

3. Processor/controller roles are unclear during an incident.
   Fix: pre-tag key systems and customer relationships with role metadata; include it in the intake form.

4. Third party incidents are handled by Procurement only.
   Fix: route third party incidents into the same incident command structure; keep procurement as support, not owner.

5. Evidence scattered across chat, email, and tickets.
   Fix: designate the incident system of record and require uploads/links to supporting artifacts before closure.

Enforcement context and risk implications (how this fails in real life)

Even without citing specific enforcement cases in this record, the practical risk is consistent: regulators, customers, and auditors judge you by the speed and defensibility of your decisions and the completeness of your records. Poor documentation makes a reasonable decision look arbitrary. Weak third party coordination increases impact duration and reduces your confidence in scope, which directly degrades notification decision quality. ¹

Practical 30/60/90-day execution plan

Days 0–30: Stand up the minimum auditable workflow

• Publish a privacy incident definition and route it through the existing security IR intake. ¹
• Create two templates: Privacy Incident Assessment and Notification Decision Memo.
• Name the on-call roles and approval chain; create an escalation roster.
• Inventory the top systems that store personal data and the primary third parties connected to them.

Days 31–60: Add controller/processor and third party mechanics

• Add contract hooks: processor-to-controller notice workflow, customer-specific instructions tracking, third party escalation expectations. ¹
• Train Security, Support, and Legal on the templates and decision rights.
• Create a communications checklist for customers and internal executives.

Days 61–90: Test, measure, and harden evidence quality

• Run at least one tabletop that forces a notification decision under uncertainty and includes a third party. ¹
• Sample closed incidents for evidence completeness; fix gaps in the workflow.
• Automate artifact capture where possible (ticket fields, required attachments, approval steps).
• If you use Daydream, map the requirement to your control library and store playbooks, decision memos, and testing evidence in one audit-ready place, with ownership and review reminders tied to your privacy program cadence. ¹

Frequently Asked Questions

What counts as a “privacy incident” versus a normal security incident?

Treat it as a privacy incident if personal data may be impacted or if your privacy commitments may have been violated. Operationally, add a privacy impact review step to security incident triage so the classification is consistent. ¹

Do we need a notification decision record even if nothing was exposed?

Yes, because ISO/IEC 27701’s intent is documented assessment and documented notification decisions. A short “no notification” memo with rationale and approvals is usually enough. ¹

We are a processor. Is our obligation mainly to tell the customer?

As a processor, you typically need to notify the controller/customer per contract and support their investigation and notifications. Your playbook should still document your assessment and your notification decision path, including customer communications. ¹

How do we handle third party incidents where the vendor won’t share details quickly?

Pre-negotiate incident cooperation requirements in contracts and maintain escalation contacts. During the incident, document each request, what was provided, and how uncertainty affected your scope and notification decision. ¹

Can we keep incident documentation under legal privilege?

Coordinate with counsel on privilege strategy, but still ensure you can produce auditable evidence of assessment and decision-making. A common approach is a business record decision memo plus privileged legal analysis stored separately.

What’s the minimum evidence an auditor will accept?

A playbook, at least one completed incident assessment, and at least one notification decision record with approvals and supporting artifacts usually establishes operating effectiveness. Over time, auditors expect consistency across incidents and evidence of testing and improvement. ¹

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control lifecycle management

Footnotes

1. ISO/IEC 27701 overview