EvidenceSheet

A.3.12 Response to information security incidents

For a PII controller, any incident touching PII shall prompt an assessment of whether a PII breach calling for action has happened; a mere event does not by itself prompt that assessment. Where a breach is established, the organization's reply shall include the required notices and records. Jurisdictions set the conditions for informing the supervisory authority and the PII principals. The organization shall keep a record detailed enough to support regulatory or forensic reporting, covering: what happened; over what period; the effects; who reported it and to whom; the steps taken to resolve it and any data restored; whether PII became unavailable, was lost, disclosed or changed; which PII was affected; and the notices sent. For a PII processor, the customer contract shall address: how breaches are notified; how the organization will give the customer what it needs to inform authorities; that breaches for which the customer or the PII principal is to blame, or which arise in parts of the system those parties are responsible for, are excluded; and the anticipated and legally imposed deadlines for notification. Some jurisdictions oblige a processor to tell the controller promptly, and some oblige it to inform a regulator directly.

Source: ISO/IEC 27701:2025, A.3.12. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open ISO/IEC 27701:2025 in the compliance library.

4
artefacts
0
held by a system
1
at each review
hard
to go live
Document repository
where the evidence lives
teal = a system already holds it · olive = produced at each review. To go live: easy when half or more of the artefacts are already held by a system, moderate from a quarter to a half, hard below a quarter.

These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.

system holds itEvidence a system already holds

none for this control

periodic reviewEvidence produced at each review

  • Breach determination records for incidents involving PII · Document repository

governing documentDocuments that govern the control

  • Breach register carrying every field the standard names · Policy repository / GRC workspace
  • Notifications made to authorities, PII principals or customers with timing against the legal limit · Document repository
  • Processor contracts carrying the notification provisions and response time limits · Vendor register / contract repository

First move

No system holds this evidence for you: it is people and documents. Reminders and routing to the owner still save time. Put the document under version control with an owner and review date, and log each review as a record with reviewer and date.

Common gaps auditors find

Do this for your whole sheet

Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.

Build my evidence sheet

A.3.11 Information security incident management planning and preparation · A.3.13 Legal, statutory, regulatory and contractual requirements