FAQGlobalISO/IEC 27018

ISO/IEC 27018 FAQ Breach Support

Define how a public-cloud PII processor detects a PII breach, promptly informs the affected customer, supplies useful facts, preserves records, and supports the customer's legal assessment.

The current edition is ISO/IEC 27018:2025; the detailed control explanations here use the prior 2019 edition and should be checked against the edition named in a contract or assurance report. ISO/IEC 27018 is voluntary guidance, while applicable law and contracts can impose separate or stricter duties.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Questions
4

Structured answer sets in this page tree.

Primary sources
3

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 25, 2026
Overview

Under ISO/IEC 27018:2019 Annex A.10.1, a public-cloud PII processor should promptly notify the relevant customer when unauthorized access to PII, or unauthorized access to processing equipment or facilities, results in loss, disclosure, or alteration of PII. This notice trigger is narrower than the standard's general definition of a . The contract should define the notice process and maximum delay. Applicable law determines any separate regulator or individual notification duty.

Search this module

Find a question or answer quickly

4 of 4 questions
Question 1

What breach support does ISO/IEC 27018 describe?

First classify the event. ISO/IEC 27018:2019 says an information security incident should trigger a review to determine whether a occurred. Routine events such as port scans, unsuccessful logons, or denial-of-service attempts do not necessarily trigger that review when they create neither actual nor a significant probability of unauthorized PII access. If the breach trigger is met, notify the affected customer as the contract requires and supply the facts the customer needs for its own legal assessment and notifications.

The 2019 control does not extend its processor-to-customer notice to a breach caused by the customer or , or within components for which they are responsible. Record the service-model boundary, such as whether the customer controls application access in an IaaS or PaaS deployment, before relying on that exclusion. Other laws or contract terms may still require cooperation.

  • Define the affected-customer test, primary and backup contacts, authenticated notice channels, severity-independent escalation path, and maximum contract delay.
  • Do not wait for a complete forensic investigation when the contract or applicable law requires earlier notice; send verified facts and label unknowns.
  • Flow the required incident reporting and evidence duties to subprocessors.
Citations
ISO/IEC 27018:2019 standard page

ISO/IEC 27018:2019 Clause 3.1 defines a data breach broadly, while Annex A.10.1 states the narrower processor-to-customer notice trigger and incident-record requirements summarized here.

GDPR consolidated text

Article 33(2) requires a processor to notify the controller without undue delay after becoming aware of a personal data breach; Articles 33 and 34 assign separate notification assessments to the controller.

Question 2

Which incident record and customer information are needed?

For every confirmed breach, record the incident description and period, consequences, reporter, recipients, resolution steps, person in charge, recovered data, and whether loss, disclosure, or alteration occurred. Add the compromised data if known and the steps taken to notify the customer or regulators.

The record should also preserve detection and notice times, affected service and responsibility boundary, changing facts, decision rationale, copies of notices, subprocessor input, containment and recovery evidence, and follow-up actions. Do not turn an estimate into a confirmed fact.

  • Retain the original alert, investigation timeline, breach classification, notices, delivery evidence, decision approvals, and closure record produced during the response.
  • Record facts as confirmed, estimated, or unknown, with the source and time of each material update.
  • Link unresolved containment, notification, supplier, or evidence gaps to corrective action and a named owner.
Citations
ISO/IEC 27018:2019 standard page

ISO's withdrawn 2019 listing identifies the prior edition; its detailed clauses remain relevant only when that edition is the stated criterion.

Question 3

Who owns the processor-to-customer decision?

Incident response owns containment and the fact record; privacy and legal assess PII impact and legal duties; the service owner sends authenticated customer communications; cloud and supplier teams provide system and subprocessor facts.

The provider's customer notice is not the customer's decision about notifying a regulator or affected people. For GDPR-covered processing, the processor must notify the controller without undue delay after becoming aware of a personal data breach; the controller separately applies Articles 33 and 34.

  • Name the incident commander, privacy or legal decision owner, customer-communications owner, supplier contact, and backups before an incident.
  • Separate the factual breach classification from the customer's regulator and affected-person notification decisions.
  • Keep notice approval and delivery records in the incident file rather than in disconnected email threads.
Citations
ISO/IEC 27018:2019 standard page

ISO's withdrawn 2019 listing identifies the prior edition; its detailed clauses remain relevant only when that edition is the stated criterion.

GDPR consolidated text

Article 33(2) requires a processor to notify the controller without undue delay after becoming aware of a personal data breach; Articles 33 and 34 assign separate notification assessments to the controller.

Question 4

When should the breach process be reviewed?

Review after exercises and incidents and whenever services, responsibility splits, subprocessor response duties, customer contacts, notice channels, contract timing, or applicable law changes.

Test whether responders can identify the affected customer and service, reach the correct contact, assemble the 2019 edition's incident record, and meet the shortest applicable notification commitment.

  • Schedule recurring exercises and retest after a material incident, service-boundary change, new subprocessor, or shorter contractual notice commitment.
  • Use exercise and incident findings to update the response procedure, customer contacts, contract terms, evidence fields, and responder training.
  • Assign every unresolved notification or evidence gap to corrective action, management review, or documented risk acceptance.
Citations
ISO/IEC 27018:2019 standard page

ISO's withdrawn 2019 listing identifies the prior edition; its detailed clauses remain relevant only when that edition is the stated criterion.

Primary sources

References and citations

eur-lex.europa.eu
Referenced sections
  • Article 33(2) requires a processor to notify the controller without undue delay after becoming aware of a personal data breach; Articles 33 and 34 assign separate notification assessments to the controller.
"The processor shall notify the controller without undue delay after becoming aware of a personal data breach."
iso.org
Referenced sections
  • ISO's withdrawn 2019 listing identifies the prior edition; its detailed clauses remain relevant only when that edition is the stated criterion.
"Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors"
iso.org
Referenced sections
  • Primary ISO listing for the 2025 edition of ISO/IEC 27018.
"Guidelines for protection of personally identifiable information (PII) in public clouds acting as PII processors"
Related guides

Explore more topics

ISO/IEC 27018 Audit Evidence FAQ
How to assess ISO/IEC 27018 audit evidence by edition, service scope, criteria, audit period, exceptions, and independent assurance.
ISO/IEC 27018 Cloud Privacy FAQ
ISO/IEC 27018 FAQ on public-cloud PII processor scope, customer instructions, subprocessors, disclosures, breaches, deletion, audit evidence, and GDPR.
ISO/IEC 27018 Customer Instructions FAQ
What counts as a customer instruction under ISO/IEC 27018, how a cloud PII processor should validate it, and what evidence shows it was followed.
ISO/IEC 27018 DPA Clause Review Workflow
Review cloud data-processing terms for instructions, purpose limits, controls, subprocessors, disclosures, incidents, rights support, and deletion.
ISO/IEC 27018 GDPR Overlap FAQ
How ISO/IEC 27018 can support GDPR processor controls without replacing Article 28 terms, controller accountability, transfers, or breach duties.
ISO/IEC 27018 Government Access Evidence Guide
Build a controlled government-access case record showing request authentication, legal review, notice, approval, minimized disclosure, transfer, and closure.
ISO/IEC 27018 Government Access Evidence Workflow
Triage a government request for customer PII, validate authority, decide notice and challenge options, minimize disclosure, and preserve the decision record.
ISO/IEC 27018 Government Access FAQ
How ISO/IEC 27018 addresses legally binding law-enforcement requests: validation, customer consultation or notice, limited disclosure, and records.
ISO/IEC 27018 PII Return and Deletion FAQ
How to plan and prove PII return, transfer, deletion, anonymization, or archival across live systems, backups, temporary files, and subprocessors.
ISO/IEC 27018 Privacy Control Checklist
A practical ISO/IEC 27018:2025 checklist for public-cloud PII processors, with verifiable conditions, owners, evidence, exceptions, and edition controls.
ISO/IEC 27018 Processor Duties FAQ
What ISO/IEC 27018 expects from a public-cloud PII processor: customer instructions, purpose limits, security, transparency, incident support, and disposal.
ISO/IEC 27018 Public Cloud PII Processor Scope Guide
Decide whether a service fits ISO/IEC 27018's public-cloud PII processor scope, separate processor and controller activities, and document the boundary.
ISO/IEC 27018 Subprocessor Evidence Guide
Build subprocessor evidence that proves who processed customer PII, where, under which terms and controls, after which notice and approval, and with what exit result.
ISO/IEC 27018 Subprocessor Evidence Workflow
Assess and approve a cloud subprocessor, disclose its use and countries before processing, handle customer objections, and retain operating and exit evidence.
ISO/IEC 27018 Subprocessor Notice FAQ
What an ISO/IEC 27018 subprocessor notice should disclose, when customers should receive it, and what evidence should support consent and objections.
ISO/IEC 27018 Vendor Contract Requirements Guide
Contract guide for ISO/IEC 27018 public-cloud PII processing: scope, instructions, security, subprocessors, disclosures, incidents, rights support, audits, and exit.
ISO/IEC 27018 vs GDPR Comparison
Compare ISO/IEC 27018 cloud-processor guidance with GDPR legal duties, including scope, Article 28 contracts, breaches, transfers, evidence, and assurance limits.
ISO/IEC 27018 vs ISO/IEC 27701 Comparison
Compare ISO/IEC 27018:2025 cloud-processor guidance with the independent ISO/IEC 27701:2025 privacy management system, including scope, evidence, and assurance.
ISO/IEC 27018 vs SOC 2 Privacy Comparison
Compare ISO/IEC 27018 cloud-processor guidance with a SOC 2 examination that includes Privacy, including scope, Type 1 vs Type 2, evidence, and limits.
Using ISO/IEC 27018 for Public-Cloud PII Processing
Decide whether ISO/IEC 27018:2025 applies to a public-cloud PII processor, how it fits an ISMS, what evidence to keep, and which claims the evidence supports.