Our own servers in Europe · GDPR · Support in your language

Templates and records · ISO 27701 · Clause A.3

ISO 27701 personal data breach log template

Every personal data breach is documented, whether or not it is notified. The log is what proves it was assessed in time and that the decision was reasoned.

In one sentence

The personal data breach log documents every security breach affecting personal data, with its facts, its effects and the remedial action taken, and the reasoned decision on whether to notify the authority within 72 hours, because GDPR article 33(5) requires all of them to be documented and ISO/IEC 27701 builds their handling into the common controls of table A.3.

Content reviewed on

Where the standard requires it
ISO 27701 · Clause A.3 The 2025 edition is cited: numbers 4 to 10 are clauses; A.1, A.2 and A.3 are the Annex A tables with the controls for the controller, for the processor and common to both.
Type of information
Mandatory record A record to be retained (GDPR art. 33(5); incident management controls in table A.3)
Who fills it in
PIMS manager, with IT and the officer Whoever detects the breach reports it immediately through the established channel
When
From the first alert The 72-hour clock starts when the organisation becomes aware of the breach
How long it is kept
Set by the organisation Neither the standard nor the GDPR sets a period for the record itself; the storage limitation principle (GDPR art. 5(1)(e)) means whatever period is chosen has to be justified.

What the standard requires


What ISO 27701 demands and what it leaves to your judgement

The standard asks for security incidents to be managed with their privacy dimension in view: detecting whether they affect personal data, assessing the consequences for individuals and meeting notification obligations. The processor must inform its customer without undue delay (GDPR art. 33(2)).

The controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to rights and freedoms (art. 33(1)). If the risk is high, the data subjects are informed as well (art. 34).

Article 33(5) requires every breach to be documented —facts, effects and remedial action—, including those that are not notified. That documentation is what allows the authority to verify compliance.

Structure


Fields the template should include

  • Reference number, date and time of detection and of awareness
  • Description of what happened and type: confidentiality, integrity or availability
  • Categories and approximate number of data subjects and records
  • Likely consequences for individuals
  • Measures taken and proposed to mitigate the effects
  • Risk assessment and decision on notification, with the reason
  • Date of notification to the authority and reference
  • Communication to data subjects, where applicable
  • Nonconformity or corrective action opened

Example


Example: an email sent with recipients visible at a fictitious training academy

Company, people and figures are fictitious: the example only shows what a properly completed record looks like.

Field Content
Reference and date BR-2026-004 · 10 March 2026, 11:20 (awareness at 11:45)
Description Email sent to 312 students with their addresses in the “To” field · Confidentiality
Data affected Email addresses of 312 adult students
Consequences Addresses exposed among students; no sensitive data
Measures Apology asking recipients to delete the email; bulk mailings only from the newsletter platform
Decision Not notified: unlikely to result in a risk to rights and freedoms · DPO’s reasoning on file
Action NC-2026-011 opened to block sends to more than 20 recipients from personal mailboxes · Lumen Academy (fictitious)

At the audit


Mistakes auditors commonly flag

  • Only notified breaches are logged.
  • The time of awareness is not recorded, so the deadline cannot be proved.
  • The decision not to notify has no written reason.
  • The processor contract does not set out how and when the processor must report.
  • The breach is closed with no corrective action even though it exposed a control that was not working.

In Kimobox


How this record is kept in Kimobox

  1. 1Breaches are logged as incidents with their classification and the time of awareness.
  2. 2The system shows the time left before the 72 hours run out and alerts those responsible.
  3. 3The notification decision sits in the same record with its justification.
  4. 4A nonconformity is opened from the breach, with root cause mandatory.

Frequently asked questions


What people ask us before getting started

Do all breaches have to be notified?

No. Those likely to result in a risk to rights and freedoms are notified, but every one is documented (GDPR art. 33(5)).

What if the 72 hours are missed?

You notify anyway, explaining the reasons for the delay (art. 33(1)). The information can be provided in phases if it is not yet complete (art. 33(4)).

Keep your ISO 27701 records without loose templates

We'll show you the module running with data similar to yours.

Request a demo

Sources


Where each figure comes from

References to the official text in force. If a standard is revised, this page is updated and the review date says so.

  1. Regulation (EU) 2016/679, General Data Protection Regulation (GDPR) EUR-Lex · 27 April 2016; applicable since 25 May 2018
  2. ISO/IEC 27701:2025 — Privacy information management systems. Requirements and guidance ISO/IEC · Second edition, October 2025
  3. ISO/IEC 27001:2022 — Information security management systems ISO/IEC · 25 October 2022