© GDPR EU 2026. All rights reserved.
Ask a compliance team what the GDPR demands on paper, and the honest answer is short: the Regulation rarely names a “document” outright, but it imposes obligations that only documentation can satisfy. Seven artefacts do most of the heavy lifting — a privacy notice, a Record of Processing Activities, a controller–processor contract, an impact assessment, a breach procedure, a process for access requests, and a retention policy. Each one ties back to a specific provision of Regulation (EU) 2016/679, and each is something a supervisory authority can ask to see.
Transparency is the obligation that touches every data subject, and the privacy notice is how a controller meets it. Articles 13 and 14 distinguish between data collected directly from the individual and data obtained from another source — the disclosure list is broadly similar, but Article 14 adds the source of the data and gives a longer window to inform people.
A compliant notice should set out:
Language matters as much as content. Article 12 requires the notice to be concise, intelligible and in plain terms, which rules out burying the disclosures in dense legalese.
Article 30 obliges controllers and processors to maintain a written, internal inventory of their processing — purposes, categories of data subjects and data, recipients, transfers, retention periods and a general description of security measures. Crucially, the ROPA is not published; it is produced to the supervisory authority on request.
The much-cited 250-employee figure deserves care. Organisations with fewer than 250 employees are not automatically exempt. The derogation in Article 30(5) falls away when processing is likely to result in a risk to data subjects’ rights, when it is not occasional, or when it involves special categories of data or criminal-offence data. Most businesses that process customer or staff data on any continuing basis therefore keep records regardless of headcount. Treating “small” as “exempt” is one of the more common misreadings of the Regulation.
Whenever a controller hands personal data to a processor, Article 28 requires a contract — and it prescribes much of the wording. The contract must bind the processor to act only on documented instructions, ensure staff are under confidentiality, apply appropriate security under Article 32, assist the controller with data-subject rights and breach obligations, and either delete or return the data at the end of the engagement. The processor must also submit to audits and make available the information needed to demonstrate compliance.
Two clauses cause the most trouble in practice:
Drafting one of these from a blank page is rarely worth the risk; a well-structured data processing agreement template gives you the mandatory Article 28 clauses as a baseline to adapt. The point is to start from the statutory requirements, not to discover them after a contract is already signed.
Some processing is risky enough that the Regulation wants the analysis done before it begins. Article 35 requires a Data Protection Impact Assessment where processing is “likely to result in a high risk” to individuals — and it lists three triggers in particular: systematic and extensive profiling with significant effects, large-scale processing of special-category or criminal-offence data, and systematic monitoring of a publicly accessible area on a large scale. National authorities publish their own lists of operations that mandate a DPIA, and the EDPB’s guidelines set out nine criteria worth weighing.
A sound assessment runs through four stages:
Where high risk remains even after mitigation, Article 36 requires prior consultation with the supervisory authority. A DPIA is a living record, not a one-off form — revisit it when the processing changes.
Breaches are inevitable; the documentation that surrounds them is what regulators judge. Article 33 sets the headline rule: notify the competent supervisory authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to individuals’ rights and freedoms. Miss the deadline and the notification must explain the delay.
Two thresholds govern the response:
Article 33(5) also requires controllers to log every breach — facts, effects and remedial action — even those that are never reported. That internal register is the first thing many authorities request, so a standing breach procedure with named responders and a decision tree saves precious hours when the clock is already running.
The right of access is the most frequently exercised right under the Regulation, and handling it well is a discipline in its own right. Article 15 entitles individuals to confirmation of whether their data is processed, a copy of that data, and supporting information about purposes, recipients, retention and their other rights.
Process essentials to build into a workflow:
Giving staff a structured intake form and response template — for instance a ready-made GDPR data subject access request process — keeps the one-month deadline manageable and prevents accidental over-disclosure.
Storage limitation is a core principle: personal data must be kept in identifiable form no longer than necessary for the purposes of processing. A retention policy turns that principle into an operational schedule — what is held, why, for how long, and what happens at the end. Tie each retention period to a purpose or a statutory obligation (tax, employment, limitation periods), and define deletion or anonymisation as the default endpoint. A documented schedule also feeds directly into the privacy notice and the ROPA, closing the loop between principle and practice.
Build these seven documents as a connected set rather than isolated templates, review them when processing changes, and keep them ready for inspection. Supervisory authorities and the EDPB increasingly judge maturity by the quality of the paperwork — accountability under Article 5(2) means being able to show your reasoning, not merely assert it.
