What does control A.3.12 require?
Responses to information security incidents related to PII processing shall be according to the documented procedures.
This control sits within the Shared security controls annex (A.3) and works hand-in-hand with A.3.11 Incident Management, which covers planning and preparation. Where A.3.11 Incident Management ensures you have a plan, A.3.12 ensures you follow it when a real incident occurs.
What does the Annex B implementation guidance say?
Annex B (section B.3.12) provides separate guidance for controllers and processors:
For PII controllers
- Breach assessment — A PII incident should trigger a review to determine whether a breach requiring a formal response has occurred
- Clear notifications — Notifications to supervisory authorities and affected individuals should be clear, include a contact point for further information, describe the nature and consequences of the breach, and outline the measures taken or proposed
- Comprehensive breach record — Maintain a record containing: description of the breach, time period, consequences, who reported it, steps taken to address it, and the PII that was compromised
For PII processors
- Contract-driven notification — Follow the notification provisions agreed in the customer’s (controller’s) contract
- Scope limitations — The notification obligation does not extend to breaches caused by the customer (controller) themselves
- Defined response times — Agree and document response time limits for breach notification to the controller
How does this map to GDPR?
Control A.3.12 maps to GDPR Articles 33(1-5) covering notification of personal data breaches to supervisory authorities, and Articles 34(1-2) covering communication of breaches to data subjects. The GDPR requires that breach notifications include the nature of the breach, categories and approximate number of data subjects affected, the likely consequences, and the measures taken to address the breach.
What changed from ISO 27701:2019?
For a step-by-step approach, see the Transition from 2019 to 2025.
In the 2019 edition, this requirement was covered by Clause 6.13.1.5, which addressed response to information security incidents. The 2025 edition retains the core requirements as A.3.12 with clearer separation of controller and processor responsibilities in the B.3.12 guidance. See the Annex F correspondence table for the full mapping.
Get started easily with a personal product demo
One of our onboarding specialists will walk you through our platform to help you get started with confidence.
What evidence do auditors expect?
When assessing compliance with A.3.12, auditors will typically look for:
- Breach register — A maintained log of all PII incidents, including those assessed and found not to constitute a reportable breach
- Notification records — Copies of notifications sent to supervisory authorities and affected individuals, with timestamps demonstrating compliance with required deadlines
- Assessment documentation — Records showing how each incident was assessed for severity and whether it met the threshold for notification
- Lessons learned — Evidence that incidents are reviewed post-resolution and that improvements are fed back into the incident management process
- Processor notifications — Where applicable, records of breach notifications received from or sent to processors, with evidence that contractual timelines were met
What are the related controls?
| Control | Relationship |
|---|---|
| A.3.11 Incident planning | Establishes the documented procedures that A.3.12 requires you to follow |
| A.3.14 Protection of records | Breach records must be protected from loss, destruction or unauthorised access |
| A.3.13 Legal and contractual requirements | Notification obligations are driven by applicable legal requirements |
| A.3.10 Supplier agreements | Processor breach notification timelines should be defined in supplier agreements |
| A.3.15 Independent review | Reviews should assess whether incident response procedures are effective |
Who does this control apply to?
A.3.12 is a shared control that applies to both PII controllers and PII processors, though with different responsibilities. Controllers are responsible for assessing breach severity, notifying supervisory authorities and communicating with affected data subjects. Processors must notify their controllers promptly and within agreed timelines, but are not typically responsible for notifying supervisory authorities or data subjects directly, although some jurisdictions may require processors to notify regulatory authorities of PII breaches.
Manage all your compliance, all in one place
ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.
Why choose ISMS.online for PII incident response?
ISMS.online provides practical tools for managing PII breaches from detection through to resolution:
- Guided incident workflows — Step-by-step response workflows that ensure nothing is missed, from initial triage through assessment, notification and closure
- Breach register — A comprehensive log meeting the standard’s record-keeping requirements, including breach description, timeline, consequences, PII affected and remediation steps
- Notification deadline tracking — Automated countdown timers against regulatory deadlines such as GDPR’s 72-hour window, with escalation alerts
- Evidence collection — Attach supporting documents, screenshots and communications to each incident record for a complete audit trail
- Post-incident review — Capture lessons learned and link corrective actions to your risk register and improvement plan
- Controller-processor coordination — Structured notification workflows between controllers and processors with timestamp tracking
FAQs
What is the difference between a PII incident and a PII breach?
A PII incident is any event that may affect the security of personal data. A PII breach is a confirmed incident where PII has been compromised through unauthorised access, disclosure, alteration, loss or destruction. Not every incident results in a breach. The assessment step in A.3.12 is specifically designed to determine whether an incident has crossed the threshold into a reportable breach.
What must a breach notification include?
According to the implementation guidance and GDPR Article 33(3), a breach notification should include: a description of the nature of the breach, a designated contact point for further information, a description of the likely consequences, and a description of the measures taken or proposed to address the breach. Information can be provided in phases if it is not all available at the time of initial notification.
Does a processor need to notify data subjects directly?
No. The processor’s obligation is to notify the controller without undue delay. The controller then assesses the breach and determines whether notification to supervisory authorities and data subjects is required. However, the processor must document the breach and the notification sent to the controller, and should have agreed response time limits in the processing contract.
