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.
Primary ISO listing for the 2025 edition of ISO/IEC 27018.
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.
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.