Article 5(2) GDPR is not satisfied by holding documentation. The accountability principle requires you to be able to demonstrate compliance. The practical difference between those two things is assembly time, and assembly time is what separates a mature privacy programme from a merely well-documented one.

Why 24 hours?

Twenty-four hours is not a statutory deadline. It is a stress test, and a realistic one, for three reasons.

Article 33 requires notification of a personal data breach to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it. Much of what follows has to be produced inside that window, during an incident, while the team is already stretched and while the authority is forming its first impression of how the organisation is run.

Article 58(1)(a) gives supervisory authorities the power to order a controller to provide any information they require. Formal information requests arrive with defined response windows, and those windows are rarely generous.

And where an inquiry begins with a complaint, the authority already has the complainant's account. The speed and coherence of your response is the only thing shaping the other half of the picture.

The eight things you should be able to produce

Each of these is a question a supervisory authority can reasonably ask about a single named processing activity. For each, the test is not whether a document exists somewhere, but whether you can put a defensible answer in front of a regulator quickly.

1. What personal data you hold, for what purpose, and for how long (Article 30). A record of processing activities that reflects the organisation as it operates today: categories of data subject and personal data, purposes, recipients, retention periods, and third-country transfers. Where it fails: the record was built properly during an implementation project and frozen on the day that project closed. The honest test is whether it reflects processing the business started in the last two quarters.

2. The lawful basis for each activity, and the reasoning behind it (Article 6). Not the conclusion, the analysis. Where legitimate interest is relied upon, that means a documented assessment covering the purpose, necessity and balancing tests for that specific activity. Where it fails: the lawful basis is recorded as a value in a dropdown. A basis selected without a documented analysis is an assertion, not a demonstration.

3. Every transfer outside the EEA, and the mechanism relied on (Articles 44 to 49). For each third-country transfer, the applicable Article 45 adequacy decision or Article 46 safeguard. Where the safeguard is contractual, that includes an assessment of whether it is effective in the destination jurisdiction. That assessment requirement derives from the Court of Justice's judgment in Schrems II and the EDPB's recommendations on supplementary measures, rather than from the text of Article 46 itself. Where it fails: the mechanism is recorded but the assessment was never performed, or was performed once for one country and applied to all of them.

4. Which processors act on your behalf, and on what terms (Article 28). A register mapping each processor to the activities it supports, the data it touches, the contractual terms in place, and any sub-processors authorised beneath it. Where it fails: the contracts are all signed and filed, but nobody can answer the question actually asked, which processors have access to this dataset, without a week of manual reconciliation.

5. What you identified as high risk, and what you did about it (Article 35). The screening decision for activities that did not require a DPIA, the completed assessment for those that did, and evidence that the mitigations identified in it were implemented. Where it fails: the assessment is complete and signed, and the mitigation column describes controls that no one can evidence as operating. A DPIA that identifies risks and proposes measures is only half a demonstration.

6. How you handle data subject rights, and how you actually performed (Articles 12 to 22). The documented process, plus the operational record: volumes received, response times against the Article 12(3) window, outcomes, and the requests you refused together with the reasons. Where it fails: there is a documented procedure and a monitored mailbox, but no data on performance. A procedure describes intent; the log demonstrates it.

7. Your full breach record, including what you decided not to notify (Article 33(5)). Article 33(5) requires documentation of any personal data breach: the facts, the effects, and the remedial action taken. That obligation covers incidents you assessed and reasonably decided not to notify. Where it fails: the register contains only notified breaches. The record of non-notified incidents is particularly revealing, because the reasoning behind the decision demonstrates how the organisation applied its judgement.

8. That your controls exist, are owned, and actually operate (Articles 5(2), 24 and 32). For any named control: who owns it, when it was last tested, what the test showed, and what happened to anything the test found. Where it fails: policy documents are offered as evidence of operation. A policy states what should happen. Evidence shows that it did.

The pattern in what fails

Across all eight, the failure is rarely a missing document. It is fragmentation and staleness.

The record of processing sits in one system. The impact assessments sit in another. Processor contracts sit with procurement, the breach register with security, and the evidence that controls operate sits in individual inboxes and shared drives. Each artefact may be perfectly adequate on its own. What does not exist is the connective tissue, the ability to start from one obligation and follow it through to the control that satisfies it and the evidence that the control ran.

That connective tissue is what a regulator is testing. An organisation that produces ten good documents in three weeks has demonstrated less than one that produces the chain between them in an afternoon.

What "demonstrate" actually requires

The accountability principle in Article 5(2) is the reason this distinction matters legally rather than only operationally. The obligation is to be able to demonstrate compliance with the principles in Article 5(1), not to hold records that would, on inspection by someone with enough time and context, support a finding of compliance.

A document you cannot connect to the obligation it satisfies demonstrates very little on its own. It is evidence in search of an argument, and assembling that argument under time pressure, during an incident, is the worst possible moment to discover the connection was never made.

What this means for your organisation

  • The meaningful test of a privacy programme is assembly time, not document count. An organisation can hold every relevant document and still struggle to respond coherently, if those documents cannot be assembled and connected quickly.
  • Article 33's 72-hour window means much of this is needed within hours, during an incident, rather than requested in advance with a comfortable deadline.
  • Article 33(5) requires documenting breaches you decided not to notify, with the reasoning. The record of non-notified incidents is particularly revealing, because the reasoning behind the decision demonstrates how the organisation applied its judgement.
  • A lawful basis without a documented analysis, and a DPIA without evidence its mitigations were implemented, are incomplete in the same way: the conclusion is recorded but the demonstration is not.

What you should do now

  1. Run the drill. Pick one significant processing activity, set a 24-hour clock, and attempt to produce all eight items for it. Record how long each takes and where you had to ask someone.
  2. Test your record of processing for currency against processing the business began in the last two quarters, rather than against the day it was written.
  3. For every activity relying on legitimate interest, confirm a documented assessment exists covering purpose, necessity and balancing, and that it is specific to that activity.
  4. For every third-country transfer, confirm both the Article 45 or 46 basis and the assessment supporting it, per destination.
  5. Pull your breach register and check that non-notified incidents are recorded with the reasoning that led to that decision.
  6. Pick three controls at random and try to establish ownership, last test date, and outcome. If that takes more than an hour, item eight is your weakest link.

How Priventia helps

Priventia is designed to hold these artefacts as one connected record rather than eight separate exercises. Its regulatory traceability model links obligations to controls, implementation and evidence, so that a compliance position can be reconstructed from the underlying regulatory source rather than reasserted.

In practice that means the Records of Processing module carries Article 30 structure with impact-assessment screening triggers and transfer flags built in. Impact Assessments cover DPIA, LIA and TIA with risk-scored outcomes and a structured approval workflow. The Controls Library links each control to the specific legal obligation it satisfies, and Monitoring schedules the testing that evidences operation, with findings and remediation tracked against the control.

The distinction this article rests on applies to compliance software as much as to compliance programmes. A policy states what should happen; evidence shows that it did. Start your assessment at priventia.com.