Responsibilities and procedures for PII breaches

“Responsibilities and procedures for PII breaches” is a governance requirement with teeth: if a breach happens, your response will be judged as much by your execution discipline as by the technical root cause. ISO/IEC 27701 expects two things to be true before the incident: (1) management responsibilities are explicitly established, and (2) procedures exist that drive a fast and controlled response, including notifications where required. ¹

For a CCO, CISO, or GRC lead, the operational goal is simple: you must be able to show that you can detect, assess, contain, and communicate a PII breach with defined authority, defined steps, and defined records. That means you need a decision structure (who can declare a PII breach, who approves notifications, who engages outside counsel, who coordinates third parties), and a playbook that works during an event, not just on paper.

This page translates the clause into a practical implementation package: applicability, step-by-step procedures, evidence to retain, audit questions, common failure modes, and an execution plan you can run immediately.

Regulatory text

ISO/IEC 27701 Clause 6.13.1.1: “Management responsibilities and procedures shall be established to ensure a quick, effective and orderly response to PII breaches, including notification to supervisory authorities and PII principals as required.” ¹

Operator meaning (what you must be able to prove):

• You pre-assigned management responsibility for PII breach response (accountability and decision rights).
• You have documented procedures that produce a controlled response (triage → containment → assessment → notification → recovery → improvements).
• Your process includes notifications to regulators and affected individuals when applicable law/contract requires it.
• Your response is timely and organized, with an evidentiary record that supports your decisions. ¹

Plain-English interpretation

A PII breach is a privacy incident with potential obligations. ISO/IEC 27701 expects you to run it like a managed business process, not an ad hoc scramble. The “quick, effective and orderly” test is met by (a) named owners, (b) repeatable steps, (c) pre-built communications paths, and (d) documentation that shows what you knew, when you knew it, and why you acted. ¹

Who it applies to

Entity scope

• PII controllers: organizations determining purposes/means of processing PII. You typically own notification decisions and communications to PII principals. ¹
• PII processors: organizations processing PII for a controller. You must be able to detect and escalate promptly, coordinate evidence, and support the controller’s notification duties where required. ¹

Operational contexts where this becomes urgent

• Cloud/SaaS and managed services (breach facts are split across you and third parties).
• Distributed data ownership (product teams control logs and data flows).
• Cross-border processing (notification may vary by jurisdiction and contract).
• High-volume customer support operations (risk of misdirected PII, account takeover fallout).

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

1) Assign management responsibilities (RACI + decision rights)

Build a PII breach response RACI that is unambiguous in a crisis. Minimum roles:

• Accountable executive (final authority for declaring a PII breach, approving external notifications).
• Incident commander (runs the operational bridge, drives timelines).
• Privacy lead (assesses PII impact, regulatory/contract notification triggers, drafts notices).
• Security lead (forensics, containment, eradication).
• Legal counsel liaison (privilege strategy, regulatory communications support).
• Comms/customer support lead (inbound/outbound messaging readiness).
• Third-party manager (coordinates processors/subprocessors, collects their incident details). Document explicit decision rights: who can (a) declare severity, (b) approve regulator contact, (c) approve notifying individuals, (d) engage outside counsel/forensics, (e) approve public statements. ¹

2) Define what qualifies as a “PII breach” internally

Write an internal definition and examples to prevent under-reporting. Include:

• Loss/theft of devices with PII.
• Unauthorized access to PII (including by insiders).
• Misdelivery/misconfiguration exposing PII.
• Processor/subprocessor incident affecting your data. Tie this definition to your incident severity model so the SOC/helpdesk knows when to escalate to privacy leadership. ¹

3) Build the breach-response procedure as a runnable playbook

Your procedure should be written in “do this, then that” format. A workable structure:

A. Intake and triage

• Capture initial report, reporter, time, systems, suspected PII elements.
• Start an incident ticket and open an evidence log.
• Initiate a cross-functional bridge if PII is suspected.

B. Containment and preservation

• Contain exposure (disable access, rotate credentials, isolate systems).
• Preserve evidence (logs, snapshots, access records) with chain-of-custody notes.

C. Impact assessment

• Identify data subjects affected, PII types, volume categories (keep qualitative if exact counts are unknown).
• Determine scope: which products, regions, third parties, and data stores.
• Assess likelihood of harm and misuse based on what is known (document assumptions).

D. Notification decisioning

• Run a documented decision workflow for “notification to supervisory authorities and PII principals as required.” Maintain a jurisdiction/contract trigger register so the team doesn’t improvise. ¹
• Draft regulator and individual notices from templates; route approvals per RACI.

E. External coordination

• If a third party is involved, require their incident summary, timelines, and remediation actions under contract terms; align on who notifies whom.

F. Recovery and remediation

• Eradicate root cause, patch, harden configurations, and validate fixes.
• Reset credentials and keys where relevant.
• Add monitoring for recurrence.

G. Post-incident review

• Run a lessons-learned session with actions assigned to owners and due dates.
• Update playbooks, training, and technical controls based on what failed. ¹

4) Prepare notification capability (not just a promise)

ISO/IEC 27701 explicitly calls out notification to authorities and PII principals “as required.” Operationalize this with:

• Notification matrix: mapping of common breach scenarios to likely notification paths (regulator, individuals, customers, partners), plus who signs off.
• Templates: regulator notice, customer notice, individual notice, FAQ for support agents.
• Contact directories: supervisory authority contacts (where you operate), key customer contacts, third-party incident contacts.
• Call center and inbox readiness: a documented intake script and escalation workflow for data subject inquiries. ¹

5) Exercise the process and fix the gaps

Run tabletop exercises focused on PII breach scenarios and third-party incidents. Capture findings and update the RACI, templates, and technical logging gaps. Your goal is not a perfect tabletop; it is a playbook that survives real stress.

Practical note: most teams discover during the first exercise that no one “owns” deciding whether an incident is a PII breach, and security and privacy use different severity language. Fix the vocabulary mismatch early.

6) Use tooling to keep execution tight (without losing auditability)

A common operational failure is scattered evidence across chat, email, and tickets. If you can, route incident tasks, approvals, and artifact capture through a system of record. Daydream can help centralize third-party incident communications and due diligence follow-ups so processor/subprocessor facts do not get trapped in email threads during a breach.

Required evidence and artifacts to retain

Auditors look for proof that responsibilities and procedures exist and were followed. Maintain:

• Approved PII breach response policy and procedure/playbook (versioned).
• RACI with named roles and delegates; on-call/backup assignments.
• Incident register marking which incidents were PII breaches and why.
• For each PII breach:
  • Timeline (detection, declaration, containment, notification decisions).
  • Evidence log and preservation notes.
  • Impact assessment and decision memo (why you did or did not notify).
  • Copies of regulator and data subject notifications (if sent).
  • Third-party communications and incident attestations (if applicable).
  • Remediation plan, completion evidence, and lessons learned output.
• Training and exercise records (agenda, attendees, findings, action items). ¹

Common exam/audit questions and hangups

Expect these:

• “Show me who is accountable for declaring a PII breach and approving notifications.”
• “Walk me through your last PII breach end-to-end. Where is the evidence trail?”
• “How do you ensure processors notify you promptly and provide required details?”
• “Where are your notification templates and decision criteria?”
• “How do you prove the response was orderly, not improvised in chat?”
• “How are corrective actions tracked to closure after the incident?” ¹

Audit hangup to preempt: teams show an IR plan that is security-only and does not address data subject/regulator communications or privacy-specific decisioning.

Frequent implementation mistakes (and how to avoid them)

1. No single decision owner for notifications
   Fix: put a named accountable executive in the RACI; document delegation rules for after-hours.

2. Procedures exist, but evidence capture is missing
   Fix: add a required “documentation bundle” checklist to the playbook; make it part of incident closure criteria.

3. Third-party incidents handled informally
   Fix: require processors to use a standard incident intake form; store third-party timelines and attestations alongside your incident record.

4. Templates are written but not executable
   Fix: pre-approve template language blocks (where possible) and define the approval workflow so comms does not start from scratch.

5. The organization cannot tell what data was involved
   Fix: treat data mapping and logging gaps as post-incident corrective actions; track them like security vulnerabilities until resolved.

Enforcement context and risk implications

This ISO clause does not itself impose fines, but it is often used as an assurance yardstick. If your response lacks clear ownership, documented procedures, or notification capability, you create avoidable regulatory exposure under applicable privacy laws and breach-notification contracts. The operational risk is also commercial: enterprise customers frequently request evidence of breach readiness during security reviews, and weak documentation turns a manageable incident into a credibility problem. ¹

Practical execution plan (30/60/90)

First 30 days (Immediate stabilization)

• Assign the breach-response RACI and decision rights; get executive sign-off.
• Publish a PII breach definition and escalation triggers.
• Stand up notification templates and a contact directory.
• Decide your system of record for incident artifacts (ticketing + repository). ¹

By 60 days (Operational readiness)

• Finalize the end-to-end playbook with checklists for evidence, decision memos, and third-party coordination.
• Align contracts and third-party processes: add a standard incident intake form and escalation path for key processors.
• Run a tabletop that includes privacy, legal, comms, and a realistic processor breach scenario; track corrective actions.

By 90 days (Proof and continuous improvement)

• Close the highest-risk tabletop action items (logging gaps, data inventory blind spots, approval bottlenecks).
• Train front-line intake teams (support, IT helpdesk, SOC) on escalation criteria.
• Implement recurring exercises and post-incident review governance; ensure actions are tracked to closure. ¹

Frequently Asked Questions

Do we need separate procedures for “security incident” and “PII breach”?

Keep one incident response framework, but add a privacy breach lane with explicit notification decisioning and privacy-owned artifacts. Auditors will expect privacy-specific steps tied to PII principals and supervisory authorities. ¹

We’re a processor. Are we responsible for notifying individuals?

ISO/IEC 27701 requires procedures that include notification “as required,” which often means supporting the controller’s obligations and notifying the controller promptly. Your process must cover escalation, evidence sharing, and coordination so the controller can meet its duties. ¹

What’s the minimum evidence auditors will ask for after a breach?

Expect to produce a timeline, impact assessment, notification decision record, copies of notifications (if sent), and proof of remediation and lessons learned. If you cannot show decision rationale, auditors will treat the process as uncontrolled. ¹

How do we handle breaches that involve a third party where facts are incomplete?

Your procedure should require an initial containment and risk assessment based on known facts, plus a structured request to the third party for incident details and their remediation status. Keep a written record of what was unknown and how that uncertainty affected notification decisions. ¹

Who should approve regulator notifications: legal, privacy, or security?

Assign final approval to a management role in the RACI and document legal and privacy review steps; security should provide the technical facts and containment status. The key is that approval authority is pre-defined and repeatable. ¹

How do we prove our response was “orderly”?

Use a consistent system of record: incident ticket, decision memo, evidence log, and a checklist-driven closure package. Orderliness is demonstrated by a coherent timeline and controlled approvals, not by how fast people responded in chat. ¹

Footnotes

1. ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management