GDPR Documentation Requirements 2026 — What Every Organisation Actually Needs

What Organisations Get Wrong About GDPR Documentation

Most organisations think GDPR compliance is about having a privacy policy on their website. It isn't. The General Data Protection Regulation is fundamentally a documentation regulation — it requires you to demonstrate compliance, not just claim it.

Article 5(2) of the GDPR lays this out explicitly: the controller shall be responsible for, and be able to demonstrate compliance with the data protection principles. This is the accountability principle, and it means that if you can't show it on paper, you aren't compliant — regardless of what you actually do in practice.

After working with dozens of organisations on GDPR compliance programmes, the pattern is consistent. The ones that fail supervisory authority audits aren't necessarily the ones with poor data protection practices. They're the ones that can't produce the documentation to prove their practices are sound.

This guide covers every piece of documentation the GDPR actually requires — not a summary, not a checklist of five items, but the full set of records, policies, procedures, and assessments that supervisory authorities expect when they come knocking.

What Is GDPR and Who Does It Apply To

The General Data Protection Regulation (Regulation (EU) 2016/679) is the European Union's primary data protection law. It came into effect on 25 May 2018 and replaced the 1995 Data Protection Directive. The UK retained the GDPR as the UK GDPR post-Brexit, with the Data Protection Act 2018 providing supplementary provisions.

Before diving into documentation requirements, it's worth clarifying the key definitions that underpin everything:

• Personal data — any information relating to an identified or identifiable natural person (the "data subject"). This includes names, email addresses, IP addresses, location data, online identifiers, and any factor specific to the physical, physiological, genetic, mental, economic, cultural, or social identity of that person.
• Controller — the entity that determines the purposes and means of processing personal data. If you decide why and how personal data is processed, you are a controller.
• Processor — the entity that processes personal data on behalf of the controller. Your cloud hosting provider, your email marketing platform, your payroll provider — these are typically processors.
• Data subject — the individual whose personal data is being processed. Your customers, employees, website visitors, job applicants.

Territorial Scope

GDPR applies to organisations established in the EU/EEA, regardless of where the processing takes place. It also applies to organisations outside the EU/EEA that offer goods or services to individuals in the EU/EEA or monitor their behaviour. This means a SaaS company based in the United States with European customers is subject to GDPR.

The regulation applies to organisations of all sizes, though some obligations (such as appointing a DPO or maintaining ROPA) have limited exemptions for organisations with fewer than 250 employees — and those exemptions are narrower than most people think.

The Real Cost of Getting This Wrong

GDPR enforcement has teeth. The regulation provides for two tiers of administrative fines:

These aren't theoretical numbers. Since 2018, supervisory authorities across Europe have issued fines totalling well over €4 billion. Major enforcement actions have targeted organisations of all sizes — from Big Tech companies receiving nine-figure fines to SMEs receiving five-figure penalties for basic documentation failures.

The most common reasons organisations get fined are not exotic data breaches. They are:

• Insufficient lawful basis for processing
• Inadequate or missing privacy notices
• Failure to implement appropriate technical and organisational measures
• No records of processing activities
• Missing or inadequate data processing agreements
• Failure to conduct required DPIAs
• Late or inadequate breach notification

Every single one of these is a documentation failure. The controls might exist — but without documentation, you can't demonstrate compliance.

1. Records of Processing Activities (ROPA)

Article 30 of the GDPR requires both controllers and processors to maintain written records of their processing activities. This is arguably the most fundamental documentation requirement — it's the foundation on which everything else is built.

Controller ROPA Requirements (Article 30(1))

If you are a controller, your ROPA must contain:

• The name and contact details of the controller and, where applicable, the joint controller, the controller's representative, and the data protection officer
• The purposes of the processing
• A description of the categories of data subjects and the categories of personal data
• The categories of recipients to whom the personal data has been or will be disclosed, including recipients in third countries or international organisations
• Where applicable, transfers of personal data to a third country or an international organisation, including the identification of that country or organisation and the documentation of suitable safeguards
• Where possible, the envisaged time limits for erasure of the different categories of data (retention periods)
• Where possible, a general description of the technical and organisational security measures referred to in Article 32(1)

Processor ROPA Requirements (Article 30(2))

If you are a processor, your ROPA must contain:

• The name and contact details of the processor(s) and each controller on behalf of which the processor is acting, and where applicable, the controller's or processor's representative and the data protection officer
• The categories of processing carried out on behalf of each controller
• Where applicable, transfers to a third country or international organisation, including the identification of that country or organisation and the documentation of suitable safeguards
• Where possible, a general description of the technical and organisational security measures referred to in Article 32(1)

The 250-Employee Exemption Myth

Article 30(5) provides an exemption for organisations with fewer than 250 employees — but only if the processing is not likely to result in a risk to the rights and freedoms of data subjects, the processing is occasional, and the processing does not include special categories of data or data relating to criminal convictions. In practice, almost every organisation processes employee data regularly, which means the processing is not "occasional." Most supervisory authorities have confirmed that the exemption has very limited practical application. Maintain ROPA regardless of your size.

2. Lawful Basis Documentation

Article 6 of the GDPR requires that every processing activity has a valid lawful basis. There are six lawful bases:

• Consent (Article 6(1)(a)) — the data subject has given clear consent for processing their personal data for a specific purpose
• Contract (Article 6(1)(b)) — processing is necessary for the performance of a contract with the data subject or to take steps at their request prior to entering a contract
• Legal obligation (Article 6(1)(c)) — processing is necessary to comply with a legal obligation to which the controller is subject
• Vital interests (Article 6(1)(d)) — processing is necessary to protect the vital interests of the data subject or another natural person
• Public task (Article 6(1)(e)) — processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority
• Legitimate interests (Article 6(1)(f)) — processing is necessary for the legitimate interests of the controller or a third party, except where overridden by the interests, rights, or freedoms of the data subject

Documenting Lawful Basis

For each processing activity in your ROPA, you must document which lawful basis you are relying on. This is not optional — Article 13(1)(c) requires you to inform data subjects of your lawful basis in your privacy notice.

Where you rely on legitimate interests, you must conduct and document a Legitimate Interest Assessment (LIA). The LIA should cover:

• Identify the legitimate interest — what are you trying to achieve and why?
• Necessity test — is the processing actually necessary for that purpose, or could you achieve it another way?
• Balancing test — do the individual's interests, rights, or freedoms override your legitimate interest?

Where you rely on consent, you must be able to demonstrate that consent was freely given, specific, informed, and unambiguous. You need records of when consent was given, what the individual was told, and how they gave consent. Consent must be as easy to withdraw as it was to give.

3. Privacy Notices

Articles 13 and 14 of the GDPR set out comprehensive information requirements — what you must tell data subjects about your processing. Article 13 applies when you collect personal data directly from the data subject. Article 14 applies when you obtain personal data from a source other than the data subject.

Required Elements (Article 13)

When collecting personal data directly from the data subject, your privacy notice must include:

• The identity and contact details of the controller (and the controller's representative, where applicable)
• The contact details of the data protection officer, where applicable
• The purposes of the processing and the lawful basis for each purpose
• Where the lawful basis is legitimate interests — what those legitimate interests are
• The recipients or categories of recipients of the personal data
• Details of any international transfers, including the safeguards in place
• The retention period, or the criteria used to determine the retention period
• The right to request access, rectification, erasure, restriction of processing, data portability, and the right to object
• Where processing is based on consent — the right to withdraw consent at any time
• The right to lodge a complaint with a supervisory authority
• Whether the provision of personal data is a statutory or contractual requirement, and the consequences of not providing the data
• The existence of any automated decision-making, including profiling, and meaningful information about the logic involved, the significance, and the envisaged consequences

Additional Requirements (Article 14)

When obtaining personal data from a source other than the data subject, you must also include:

• The categories of personal data concerned
• The source of the personal data and whether it came from publicly accessible sources

You must provide this information within a reasonable period — no later than one month — or, if the data is used to communicate with the data subject, at the latest at the time of the first communication.

Layered Notices

The EDPB and ICO both recommend a layered approach to privacy notices: a short-form notice at the point of data collection with the most critical information, linking to a comprehensive privacy notice that covers all required elements. This helps balance the transparency requirement with actual usability.

4. Data Processing Agreements (DPAs)

Article 28 of the GDPR requires a written contract between every controller and processor. If you use any third-party service that processes personal data on your behalf — cloud hosting, email marketing, CRM, analytics, payment processing — you need a DPA in place.

Required DPA Provisions (Article 28(3))

The DPA must stipulate that the processor:

• Processes personal data only on documented instructions from the controller
• Ensures that persons authorised to process personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality
• Takes all measures required pursuant to Article 32 (security of processing)
• Respects the conditions for engaging sub-processors (prior specific or general written authorisation from the controller)
• Assists the controller in responding to data subject rights requests
• Assists the controller in ensuring compliance with Articles 32–36 (security, breach notification, DPIAs, prior consultation)
• At the choice of the controller, deletes or returns all personal data after the end of the provision of services
• Makes available to the controller all information necessary to demonstrate compliance and allows for audits and inspections

Sub-Processor Management

If your processor uses sub-processors (and most do — think of a SaaS vendor using AWS for hosting), the DPA must address this. The processor must either obtain specific authorisation for each sub-processor or have general written authorisation with an obligation to inform the controller of any intended changes.

You should maintain a register of all processors and sub-processors, including what data they process, where they are located, and what safeguards are in place.

5. Data Protection Impact Assessments (DPIAs)

Article 35 of the GDPR requires a Data Protection Impact Assessment before any processing that is "likely to result in a high risk to the rights and freedoms of natural persons." A DPIA is mandatory when:

• Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, which produces legal effects or similarly significant effects
• Processing on a large scale of special categories of data (Article 9) or data relating to criminal convictions (Article 10)
• Systematic monitoring of a publicly accessible area on a large scale

Supervisory authorities have also published their own lists of processing operations that require DPIAs. As a practical rule: if you're doing something new, at scale, involving sensitive data, or using new technology — do a DPIA.

What a DPIA Must Include (Article 35(7))

• A systematic description of the envisaged processing operations and the purposes of the processing, including where applicable the legitimate interest pursued by the controller
• An assessment of the necessity and proportionality of the processing in relation to the purposes
• An assessment of the risks to the rights and freedoms of data subjects
• The measures envisaged to address the risks, including safeguards, security measures, and mechanisms to ensure the protection of personal data and demonstrate compliance

If the DPIA indicates that the processing would result in a high risk that cannot be mitigated, Article 36 requires the controller to consult the supervisory authority before proceeding (prior consultation).

6. Data Subject Rights Procedures

Chapter III of the GDPR establishes eight data subject rights. You must have documented procedures for handling each of them:

• Right of access (Article 15) — the right to obtain confirmation of whether personal data is being processed and, if so, access to the data and supplementary information
• Right to rectification (Article 16) — the right to have inaccurate personal data corrected without undue delay
• Right to erasure / right to be forgotten (Article 17) — the right to have personal data erased in certain circumstances
• Right to restriction of processing (Article 18) — the right to restrict processing in certain circumstances
• Right to data portability (Article 20) — the right to receive personal data in a structured, commonly used, machine-readable format
• Right to object (Article 21) — the right to object to processing based on legitimate interests or public task, including profiling
• Rights related to automated decision-making and profiling (Article 22) — the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects
• Notification obligation regarding rectification, erasure, or restriction (Article 19) — the obligation to notify recipients of any rectification, erasure, or restriction

Timeline and Process Requirements

You must respond to data subject requests without undue delay and within one month of receipt. This can be extended by a further two months where necessary, taking into account the complexity and number of requests — but you must inform the data subject of the extension within the first month and explain the reasons for the delay.

Your procedures should document:

• How data subjects can submit requests (channels, contact details)
• How you verify the identity of the data subject
• How you log and track requests
• Who is responsible for handling each type of request
• How you search for and compile the relevant personal data
• Exemptions and restrictions that may apply
• How you communicate the outcome to the data subject
• Escalation procedures for complex or disputed requests

7. Data Breach Response Procedure

Articles 33 and 34 of the GDPR impose strict obligations for responding to personal data breaches. A personal data breach is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.

The 72-Hour Rule (Article 33)

When a personal data breach is likely to result in a risk to the rights and freedoms of natural persons, you must notify the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of it. If notification is made after 72 hours, you must provide reasons for the delay.

The notification must include:

• The nature of the breach, including where possible the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned
• The name and contact details of the data protection officer or other contact point
• A description of the likely consequences of the breach
• A description of the measures taken or proposed to address the breach, including measures to mitigate its possible adverse effects

Communication to Data Subjects (Article 34)

When a breach is likely to result in a high risk to the rights and freedoms of natural persons, you must also communicate the breach to the affected data subjects without undue delay. The communication must describe the nature of the breach in clear and plain language and provide the same information as the supervisory authority notification (minus the technical detail about record counts).

What Your Procedure Should Cover

• How breaches are detected and reported internally
• How you assess whether a breach is notifiable (risk assessment criteria)
• Roles and responsibilities — who makes the notification decision, who drafts the notification, who communicates with data subjects
• Templates for supervisory authority notification and data subject communication
• Internal breach register (Article 33(5) requires you to document all breaches, not just notifiable ones)
• Post-incident review process
• Escalation paths and out-of-hours procedures

8. Data Retention and Deletion Policy

Article 5(1)(e) of the GDPR establishes the storage limitation principle: personal data must be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data is processed.

What Your Retention Policy Should Document

• Retention periods for each category of personal data, cross-referenced to your ROPA
• The legal, regulatory, or business justification for each retention period
• How data is securely deleted or anonymised when the retention period expires
• How retention periods interact with legal holds and litigation preservation obligations
• Automated deletion mechanisms where applicable
• Responsibilities for reviewing and enforcing retention periods
• How retention applies across backup systems and archives

Common retention periods you'll need to define include:

9. International Data Transfer Documentation

Chapter V of the GDPR (Articles 44–49) restricts transfers of personal data to countries outside the EU/EEA unless adequate safeguards are in place. Following the Schrems II decision in 2020, transfer documentation requirements have become significantly more demanding.

Transfer Mechanisms (Article 46)

The most commonly used transfer mechanisms are:

• Adequacy decisions (Article 45) — the European Commission has determined that the third country ensures an adequate level of protection. Currently includes the UK, Japan, South Korea, and others. The EU-US Data Privacy Framework provides a mechanism for certified US organisations.
• Standard Contractual Clauses (SCCs) (Article 46(2)(c)) — pre-approved contractual terms adopted by the European Commission. The current SCCs (adopted June 2021) are modular and cover controller-to-controller, controller-to-processor, processor-to-processor, and processor-to-controller transfers.
• Binding Corporate Rules (BCRs) (Article 47) — internal rules adopted by multinational groups for intra-group transfers, approved by the competent supervisory authority.

Transfer Impact Assessments (TIAs)

Post-Schrems II, organisations relying on SCCs must conduct a Transfer Impact Assessment for each transfer to evaluate whether the laws of the recipient country provide essentially equivalent protection. The TIA should document:

• The specific transfer circumstances (data types, purposes, recipients)
• An assessment of the relevant legislation in the recipient country (particularly regarding government access to data)
• Any supplementary measures needed (encryption, pseudonymisation, contractual provisions)
• Your conclusion on whether the transfer can proceed with adequate protection

10. DPO Designation and Tasks

Article 37 of the GDPR requires the designation of a Data Protection Officer (DPO) in three cases:

• The processing is carried out by a public authority or body (except courts acting in their judicial capacity)
• The core activities of the controller or processor consist of processing operations which, by virtue of their nature, scope, and/or purposes, require regular and systematic monitoring of data subjects on a large scale
• The core activities consist of processing on a large scale of special categories of data (Article 9) or data relating to criminal convictions and offences (Article 10)

Documentation Requirements

If you designate a DPO, you must document:

• The DPO's contact details (published and communicated to the supervisory authority)
• The DPO's position within the organisational structure
• Evidence that the DPO reports to the highest management level
• Evidence that the DPO operates independently and does not receive instructions regarding the exercise of their tasks
• Resources allocated to the DPO function

DPO Tasks (Article 39)

The DPO's tasks as defined by the GDPR include:

• Informing and advising the controller/processor and employees on their GDPR obligations
• Monitoring compliance with the GDPR, including awareness-raising, training, and audits
• Providing advice on DPIAs and monitoring their performance
• Cooperating with the supervisory authority
• Acting as the contact point for the supervisory authority on issues relating to processing

Even if you are not required to appoint a DPO, you should document who within your organisation is responsible for data protection compliance and what their responsibilities are.

Special Categories of Data — Additional Requirements

Article 9 of the GDPR prohibits the processing of special categories of personal data unless one of ten specific conditions applies. Special categories include:

• Racial or ethnic origin
• Political opinions
• Religious or philosophical beliefs
• Trade union membership
• Genetic data
• Biometric data (for the purpose of uniquely identifying a natural person)
• Data concerning health
• Data concerning a natural person's sex life or sexual orientation

If you process any special category data, your documentation must include:

• The Article 9(2) condition you are relying on (in addition to your Article 6 lawful basis)
• An appropriate policy document (required under UK law by Schedule 1, Part 4 of the Data Protection Act 2018)
• A DPIA (processing special category data at scale always requires one)
• Enhanced security measures proportionate to the sensitivity of the data

Building Your GDPR Documentation Programme

If you're starting from scratch or overhauling an existing programme, here's the order that makes practical sense:

• Step 1: Data mapping and ROPA — you can't document what you don't understand. Map your data flows first, then build your ROPA. Everything else depends on this.
• Step 2: Lawful basis analysis — for each processing activity in your ROPA, determine and document the lawful basis. Conduct LIAs where you rely on legitimate interests.
• Step 3: Privacy notices — update your privacy notices to reflect your ROPA and lawful basis analysis. Ensure they cover all Article 13/14 requirements.
• Step 4: DPAs — audit your processor relationships and ensure DPAs are in place. Review existing DPAs against Article 28(3) requirements.
• Step 5: DPIAs — identify processing activities that require DPIAs and conduct them. Prioritise high-risk processing.
• Step 6: Procedures — document your data subject rights procedures, breach response procedure, and retention policy.
• Step 7: Governance — document your DPO designation (if applicable), data protection responsibilities, training programme, and audit schedule.

This isn't a one-time exercise. GDPR documentation must be maintained as a living system — reviewed regularly, updated when processing changes, and kept aligned with your actual data practices.

How GRCadia Helps

Building GDPR documentation from scratch takes hundreds of hours. Most of that time goes into researching requirements, drafting templates, and structuring documents to match what supervisory authorities expect. The GDPR Compliance Toolkit ($299, one-time purchase) gives you the complete documentation set — ready to customise for your organisation.

The toolkit includes:

• ROPA template with pre-built processing activity examples
• Lawful basis documentation templates including LIA framework
• Comprehensive privacy notice templates (customer-facing, employee, recruitment)
• Data Processing Agreement template aligned to Article 28(3)
• DPIA template with risk assessment methodology
• Data subject rights request procedures and tracking templates
• Data breach response procedure with notification templates
• Data retention schedule template
• International data transfer documentation including TIA template
• DPO designation and task documentation
• Data protection policy and acceptable use policy
• Training and awareness programme framework

Every template is fully editable, practitioner-built, and structured to match regulatory expectations. No subscriptions. No recurring fees. Download, customise, and deploy.

Frequently Asked Questions

What documentation does GDPR require?

GDPR requires Records of Processing Activities (ROPA), lawful basis documentation, privacy notices, data processing agreements with all processors, Data Protection Impact Assessments for high-risk processing, data subject rights procedures, a data breach response procedure, a data retention policy, international data transfer documentation (including SCCs and TIAs where applicable), and DPO designation records if a DPO is required. Article 5(2) — the accountability principle — means you must be able to demonstrate compliance with all data protection principles through documented evidence.

Do small businesses need GDPR documentation?

Yes. GDPR applies to organisations of all sizes that process personal data of individuals in the EU/EEA. The Article 30(5) exemption for organisations with fewer than 250 employees is extremely narrow — it only applies if the processing is occasional, does not include special category data, and is unlikely to result in a risk to data subjects. In practice, most organisations process employee data regularly, which means the exemption does not apply. All organisations should maintain ROPA, privacy notices, and data processing agreements at minimum.

What is the penalty for not having GDPR documentation?

Failure to maintain required documentation can result in administrative fines of up to €10 million or 2% of global annual turnover (whichever is higher) for ROPA and processing record failures, and up to €20 million or 4% of global annual turnover for violations related to data processing principles, lawful basis, and data subject rights. Beyond fines, supervisory authorities can issue warnings, reprimands, orders to comply, temporary or permanent processing bans, and orders to communicate a breach to data subjects.

How often should GDPR documentation be reviewed?

There is no specific review frequency mandated by the GDPR, but best practice is to review your core documentation — ROPA, privacy notices, DPAs, and procedures — at least annually. Documentation should also be reviewed and updated whenever there is a material change to your processing activities, a new system or processor is introduced, a data breach occurs, or regulatory guidance changes. DPIAs should be reviewed when the nature, scope, context, or purposes of processing change.

What is the difference between a controller and a processor under GDPR?

A controller determines the purposes and means of processing personal data — they decide why and how data is processed. A processor processes personal data on behalf of the controller — they act on the controller's instructions. The distinction matters because controllers have broader obligations including determining lawful basis, providing privacy notices, conducting DPIAs, and responding to data subject rights requests. Processors must act only on the controller's documented instructions and assist the controller in meeting their obligations. Both must maintain ROPA and implement appropriate security measures.

Key Takeaway

GDPR compliance is not a technology problem — it's a documentation problem. The regulation is built on the accountability principle: if you can't demonstrate it, you're not compliant. The organisations that pass supervisory authority audits are not necessarily the ones with the most advanced privacy technology. They're the ones that can produce clear, complete, and current documentation showing that they understand their data, have a lawful basis for processing it, protect it appropriately, and respect the rights of data subjects.

Start with your ROPA. Build outward from there. Document everything. And remember — this isn't a one-time project. It's an ongoing programme that must evolve with your organisation.

Written by the GRCadia Team — practitioner-built templates and frameworks for governance, risk, and compliance professionals.