Notification of a data breach involving PII

ISO/IEC 27018 Annex A.10.1 requires a public cloud PII processor to promptly notify the relevant cloud service customer whenever unauthorized access to PII (or to processing equipment/facilities) causes loss, disclosure, or alteration of PII. To operationalize it, you need a contract-backed breach notification playbook, clear incident-to-notification triggers, and retained evidence that you detected, assessed impact, and notified customers without avoidable delay.

Key takeaways:

• The trigger is unauthorized access plus impact to PII (loss, disclosure, or alteration), including access via compromised equipment or facilities.
• “Promptly” is operational: define internal decision rights, customer contact paths, and minimum notification content so you can send an initial notice fast.
• Auditors will look for repeatable execution: documented criteria, ticket evidence, communications logs, and post-incident corrections.

“Notification of a data breach involving PII” is a requirement you operationalize long before an incident. ISO/IEC 27018 treats you, the public cloud provider, as a PII processor and makes customer notification a mandatory action when specific conditions occur: unauthorized access to PII, or unauthorized access to processing equipment or facilities, that results in loss, disclosure, or alteration of PII.

For a CCO or GRC lead, the work breaks into three concrete deliverables: (1) define what events meet the notification trigger and who decides, (2) ensure your contracts and customer communication channels support rapid outreach to the “relevant cloud service customer,” and (3) create an evidence trail that proves timely detection, triage, and notification.

This page translates Annex A.10.1 into an execution-ready procedure, an artifact checklist you can hand to incident response and customer support, and an audit-ready set of controls that stand up under scrutiny. Source: ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors

Regulatory text

Requirement (operator view): You must notify the relevant cloud service customer promptly if either (a) PII is accessed without authorization, or (b) processing equipment/facilities are accessed without authorization, and the outcome is loss, disclosure, or alteration of PII. Source: ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors

Exact excerpt: “The public cloud PII processor shall promptly notify the relevant cloud service customer in the event of any unauthorized access to PII or unauthorized access to processing equipment or facilities resulting in loss, disclosure or alteration of PII.” Source: ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors

What this means in practice

• The standard is not limited to “confirmed exfiltration.” If unauthorized access results in loss (availability/integrity issues), disclosure (confidentiality exposure), or alteration (integrity compromise) of PII, the notification duty is triggered.
• The trigger includes unauthorized access to “processing equipment or facilities,” which captures scenarios where PII exposure is a downstream result of infrastructure compromise (for example, a compromised hypervisor management plane or unauthorized data center access), as long as the result is loss, disclosure, or alteration of PII.

Plain-English interpretation (what you must be able to do on demand)

You need a repeatable way to:

1. Detect and classify a suspected security event that could affect PII.
2. Determine whether the event meets the Annex A.10.1 trigger.
3. Notify the correct customer contact quickly with accurate, minimally sufficient information.
4. Keep proof that you did it and that you improved controls after the fact.

“Promptly” is the operational pressure point. The easiest way to fail this requirement is not malice; it’s ambiguity. If your teams debate whether an incident “counts,” or can’t find customer contacts, you will delay notification.

Who it applies to (entity and operational context)

Applies to: Public cloud providers acting as PII processors for customer-controlled workloads, storage, applications, or managed services that process PII. Source: ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors

Operational contexts where this commonly triggers

• Multi-tenant infrastructure incidents affecting customer environments that contain PII.
• Managed services (managed databases, managed endpoints, hosted SaaS components) where you administer underlying systems that store or process customer PII.
• Physical or logical access compromises involving systems that process PII, including admin consoles, orchestration planes, and storage layers.

Who must execute: Security operations, incident response, privacy/compliance, customer support/account management, and legal (for customer communications). The CCO/GRC lead should own governance: criteria, evidence standards, and audit readiness.

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

1) Define your notification trigger criteria (write it down)

Create a short, testable trigger definition aligned to the text:

• Unauthorized access to PII OR unauthorized access to processing equipment/facilities
• AND the result is loss, disclosure, or alteration of PII
• THEN notify the relevant cloud service customer promptly. Source: ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors

Operationalize this with a decision record in your incident ticketing system: “Annex A.10.1 notification required: Yes/No,” plus the rationale.

2) Assign decision rights and escalation paths

You need a named decision-maker (role-based is fine) who can authorize outbound customer breach notifications. Typical pattern:

• Incident Commander: drives technical triage and timeline.
• Privacy/Compliance Duty Officer: confirms the trigger, ensures required customer notification occurs.
• Customer Comms Lead: sends notice, tracks delivery, routes inbound questions.

Document backups. If your primary approver is unavailable, “prompt” becomes “stuck.”

3) Maintain customer notification contacts and routing

Create a customer contact registry that is:

• Tied to the customer account record
• Includes security incident notification addresses, escalation contacts, and after-hours paths
• Tested periodically by sending a non-incident verification message (avoid content that could be misread as a breach notice)

If you run through third parties (resellers, MSPs), define which party is the “relevant cloud service customer” in your contracts and account maps so you don’t notify the wrong entity.

4) Prepare minimum viable notification content (templates)

Build templates for an initial notice and a follow-up notice. Your initial notice should work even if facts are incomplete:

• What happened (high-level), what systems were involved
• Whether PII was lost, disclosed, or altered (or is suspected), and why you believe that
• What you have done to contain/mitigate
• What the customer should do next (credential resets, key rotation, log review)
• How you will provide updates (cadence and channel)
• A point of contact for incident coordination

Avoid speculation. Stick to what you can support with evidence.

5) Integrate detection-to-notification into incident response

Add a specific step to your incident runbook:

• “Assess for PII impact and Annex A.10.1 trigger”
• “If triggered, send customer notification and log proof”

Make it a required field in the post-incident review: if the incident involved unauthorized access to systems that process PII, the team must explicitly state why notification was or was not required.

6) Run tabletop exercises that test “prompt notification”

Do at least one scenario that forces ambiguity, because real incidents are messy:

• Unauthorized access to an admin console with uncertain data access
• Physical access event at a facility, later correlated to PII integrity anomalies
• A logging gap that delays certainty, requiring an initial notice based on risk

Your goal is to verify your decision rights, customer contacts, templates, and evidence capture work under time pressure.

7) Retain evidence, then close the loop

After notification:

• Capture what was sent, when, by whom, and to what contact(s).
• Record customer acknowledgments and any escalations.
• Document remediation actions and residual risk decisions.

If you use Daydream to manage third-party risk and compliance workflows, treat this requirement as a mapped control with mandatory artifacts: incident ticket, trigger assessment, notice copies, and communications log. That makes audits less about recollection and more about pull-from-system evidence.

Required evidence and artifacts to retain (audit-ready)

Maintain an evidence bundle per incident, plus standing program artifacts.

Standing artifacts (program-level)

• Breach/incident response policy section covering customer notification for PII processor obligations.
• Annex A.10.1 trigger criteria and decision tree.
• Roles and responsibilities (RACI) for notification approvals and sending.
• Customer notification templates (initial and follow-up).
• Customer security contact registry process (how contacts are created, updated, verified).
• Tabletop exercise reports showing notification workflow was tested.

Incident-level artifacts (case file)

• Incident ticket with timeline, severity, impacted services, and customer scope.
• Determination record: why the event is (or is not) unauthorized access to PII or processing equipment/facilities with loss/disclosure/alteration of PII.
• Forensics summaries or log extracts supporting the determination.
• Copy of notifications sent (email, portal messages, letters) and delivery evidence (timestamps, message IDs, portal audit logs).
• Customer communications log (questions, responses, requested data).
• Corrective action records and closure approval.

Common exam/audit questions and hangups

“Show me how you decide whether an incident involves PII.”
Auditors expect a documented criterion and a completed assessment per incident, not informal chat logs.

“Who approves customer notifications, and what happens after-hours?”
If you can’t demonstrate backup approvers and an on-call path, “promptly” becomes unprovable.

“How do you ensure you notify the relevant customer(s) in multi-tenant events?”
You need a defensible customer-scoping method tied to your asset/service map.

“Prove the notice went out promptly.”
They will look for timestamps: detection time, triage time, decision time, send time, and customer receipt/acknowledgment where available.

Frequent implementation mistakes (and how to avoid them)

1. Waiting for perfect certainty before notifying.
   Fix: use a two-stage approach: an initial notice once the trigger is reasonably met, then updates as facts mature. Keep your language evidence-based.

2. No documented rationale when you decide not to notify.
   Fix: require a written “no-notify” decision record with approver name/role and supporting logs.

3. Customer contact data is stale or incomplete.
   Fix: make security contact verification part of onboarding and renewals; add periodic checks tied to account reviews.

4. Incident response and customer support operate in separate tools with no shared timeline.
   Fix: mandate a single source of truth for incident timeline and store outbound comms artifacts in the case file.

5. Over-notifying the wrong party (resellers, subsidiaries) or under-notifying (missing impacted customers).
   Fix: define “relevant cloud service customer” per account structure and contract; maintain an account hierarchy map.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions. Practically, failure modes still create material risk: delayed notification escalates customer harm, triggers contractual breaches, and increases the chance of termination, claims, or audit findings tied to your ISO/IEC 27018 commitments. Anchor your program on provable execution and tight evidence.

Practical execution plan (30/60/90)

First 30 days (stabilize the basics)

• Publish the Annex A.10.1 trigger criteria and decision tree aligned to your incident categories. Source: ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors
• Assign decision rights (primary + backup) for notification approval and sending.
• Create initial/follow-up notification templates and a comms log format.
• Identify where customer security contacts live and how they’re updated.

By 60 days (make it executable under pressure)

• Integrate “PII breach notification assessment” as a required step in incident runbooks and ticket workflows.
• Implement a customer contact registry process with ownership and quality checks.
• Run one tabletop that starts with ambiguous indicators and tests whether you can draft and send an initial notification cleanly.

By 90 days (make it auditable and scalable)

• Standardize the incident evidence bundle and retention location.
• Add post-incident review checkpoints: notification decision quality, timing proof, customer feedback, and remediation tracking.
• If you manage compliance evidence in Daydream, set this requirement to require specific attachments per incident (ticket, decision record, notice copy, delivery proof, comms log) and block closure until complete.

Frequently Asked Questions

What counts as “unauthorized access” for this requirement?

The text covers unauthorized access to PII and unauthorized access to processing equipment or facilities that leads to loss, disclosure, or alteration of PII. Treat both logical compromise (accounts, systems) and relevant physical access as in-scope if they result in PII impact. Source: ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors

Do we have to notify if we can’t prove PII was exfiltrated?

Annex A.10.1 is triggered by unauthorized access resulting in loss, disclosure, or alteration of PII, not only confirmed exfiltration. If your evidence supports that disclosure or alteration occurred (or PII was lost), treat it as notifiable and document the basis. Source: ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors

Who is the “relevant cloud service customer” in reseller or MSP models?

Define this contractually and reflect it in your account hierarchy so incident teams don’t guess during an event. Your operational registry should identify the notification recipient(s) for each account and service relationship. Source: ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors

What should we send in the first notification if facts are incomplete?

Send an initial notice with confirmed facts, the suspected PII impact type (loss, disclosure, alteration) if you have a basis, containment actions taken, and what the customer should do next. Keep a clear promise for follow-up updates and document why you could not yet provide more detail. Source: ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors

How do we prove we notified “promptly” if ISO/IEC 27018 doesn’t specify a time window?

Prove promptness through a complete incident timeline and decision record: detection, triage, determination, approval, and send timestamps, plus delivery evidence. Auditors look for avoidable delays caused by missing approvals, missing contacts, or unclear triggers.

Do we need to retain a copy of the notice content?

Yes, retain the exact content, recipients, and timestamps, along with the incident assessment that triggered notification. Without this, you can’t demonstrate conformance to the requirement under audit. Source: ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors