GDPR Documentation Review: Ensuring Compliance in Privacy Policies and Data Processing Records
GDPR requires extensive documentation — privacy policies, records of processing, DPIAs, breach procedures. Here's how to review your GDPR documentation for completeness and compliance.
GDPR compliance isn't a one-time project. It's an ongoing documentation obligation. Every organisation processing EU resident data must maintain specific documents — and those documents must be accurate, current, and complete. Regulators don't ask "are you compliant?" They ask "show me your documentation."
Since GDPR enforcement began, data protection authorities across the EU/EEA have issued billions of euros in fines. The most common finding in enforcement actions: inadequate or incomplete documentation. Not malicious data misuse — documentation failures.
Required GDPR Documentation
1. Privacy Policy / Privacy Notice
The public-facing document that tells data subjects how their data is processed. Required under Articles 13 and 14.
Must include:
| Element | Article | What to State |
|---|---|---|
| Controller identity and contact details | 13(1)(a) | Legal entity name, address, contact information |
| DPO contact details | 13(1)(b) | If applicable — name or role, contact method |
| Purposes of processing | 13(1)(c) | Specific, not vague ("to improve our services" is insufficient) |
| Legal basis for each purpose | 13(1)(c) | Consent, contract, legal obligation, vital interests, public task, or legitimate interests |
| Legitimate interests (if relied upon) | 13(1)(d) | Specific interests — not just "our legitimate business interests" |
| Recipients or categories of recipients | 13(1)(e) | Who receives the data — including processors and third parties |
| International transfers | 13(1)(f) | Whether data is transferred outside EEA, and the safeguard used |
| Retention periods | 13(2)(a) | Specific periods or criteria for determining them |
| Data subject rights | 13(2)(b-d) | Access, rectification, erasure, restriction, portability, objection |
| Right to withdraw consent | 13(2)(c) | If consent is the legal basis |
| Right to lodge a complaint | 13(2)(d) | With the supervisory authority |
| Whether provision is required | 13(2)(e) | Statutory/contractual requirement and consequences of not providing |
| Automated decision-making | 13(2)(f) | If applicable — logic, significance, envisaged consequences |
Common failures:
- Generic purpose statements ("to provide services") instead of specific purposes
- Missing legal basis for one or more processing activities
- No retention periods (or "as long as necessary" without criteria)
- Missing information about international transfers
- Written at grade 16 reading level instead of plain language
2. Records of Processing Activities (ROPA)
Required under Article 30 for controllers with 250+ employees (and for smaller organisations in many cases). The internal register of all processing activities.
Must include (for controllers):
| Field | What to Document |
|---|---|
| Controller name and contact | Legal entity details |
| DPO contact | If applicable |
| Purposes of processing | Per processing activity |
| Categories of data subjects | Customers, employees, website visitors, etc. |
| Categories of personal data | Name, email, financial, health, etc. |
| Categories of recipients | Internal departments, processors, third parties |
| International transfers | Countries and safeguards |
| Retention periods | Per processing activity |
| Security measures | Technical and organisational measures |
Common failures:
- Incomplete — not all processing activities documented
- Outdated — new processes added without updating ROPA
- Generic entries that don't distinguish between different processing activities
- Missing processor entries (Article 30(2))
3. Data Protection Impact Assessments (DPIAs)
Required under Article 35 when processing is "likely to result in a high risk" to data subjects.
Triggers for DPIA:
- Systematic and extensive profiling with significant effects
- Large-scale processing of special category data
- Systematic monitoring of publicly accessible areas
- New technologies
- Processing that prevents data subjects from exercising rights
DPIA must include:
- Systematic description of the processing
- Assessment of necessity and proportionality
- Assessment of risks to data subjects
- Measures to address risks
- DPO opinion (if applicable)
4. Data Breach Response Plan
Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a breach (where the breach is likely to result in a risk to data subjects).
Documentation required:
- Breach detection and assessment procedures
- Internal escalation process
- Notification templates (authority and data subjects)
- Roles and responsibilities
- Breach register (all breaches, including those not notified)
- Communication templates
5. Processor Agreements (DPAs)
Article 28 requires written contracts with all data processors.
Must include:
- Subject matter and duration
- Nature and purpose of processing
- Type of personal data and categories of data subjects
- Controller's obligations and rights
- Processor obligations (security, confidentiality, sub-processors, audits, deletion, assistance)
6. Consent Records
Where consent is the legal basis, you must demonstrate that consent was given.
Documentation required:
- What the data subject consented to (exact wording)
- When consent was given
- How consent was given (mechanism)
- Evidence that consent was freely given, specific, informed, and unambiguous
Reviewing GDPR Documentation
Privacy Policy Review Criteria
| Criterion | Weight | What to Check |
|---|---|---|
| Completeness | 3 | All Article 13/14 elements present |
| Specificity | 3 | Purposes, legal bases, and retention periods are specific, not generic |
| Plain language | 2 | Written clearly for a general audience (GDPR requires "clear and plain language") |
| Currency | 2 | Reflects current processing activities, not historical |
| Accessibility | 1 | Easy to find, properly formatted, available in relevant languages |
ROPA Review Criteria
| Criterion | Weight | What to Check |
|---|---|---|
| Completeness | 3 | All processing activities documented with all required fields |
| Accuracy | 3 | Entries match actual processing practices |
| Currency | 2 | Updated to reflect changes in processing |
| Consistency | 2 | Information aligns with privacy policy and DPAs |
Breach Response Plan Review Criteria
| Criterion | Weight | What to Check |
|---|---|---|
| 72-hour compliance | 3 | Procedures enable notification within 72 hours |
| Role clarity | 3 | Clear responsibilities for detection, assessment, notification |
| Template quality | 2 | Notification templates include all required information |
| Completeness | 2 | Covers detection, assessment, containment, notification, and post-incident review |
Common GDPR Documentation Failures
Failure 1: Vague Purpose Statements
Non-compliant: "We process your data to improve our services." Compliant: "We process your purchase history to recommend products similar to those you've previously bought (legal basis: legitimate interest in personalised marketing, assessed via LIA dated 15/01/2026)."
Failure 2: Missing Legal Basis
Every processing purpose needs a specified legal basis. "Marketing" isn't a legal basis — it's a purpose. The legal basis might be consent (for email marketing to prospects) or legitimate interest (for marketing to existing customers under the soft opt-in).
Failure 3: "As Long as Necessary" Retention
GDPR requires specific retention periods or the criteria used to determine them. "As long as necessary for the purpose" without further specification is insufficient. Define actual periods: "Customer data: 7 years after last purchase (tax compliance)" or "Marketing consent records: until consent is withdrawn plus 1 year."
Failure 4: Outdated Documentation
A privacy policy written in 2018 that doesn't reflect processing activities added since then is non-compliant. Documentation must be reviewed and updated regularly — particularly the ROPA and privacy policy.
Failure 5: Privacy Policy Readability
GDPR explicitly requires "clear and plain language" (Article 12). A privacy policy written in legal language at grade 16 reading level fails this requirement. Target grade 8-10 readability. Use short sentences, everyday vocabulary, and clear structure.
Documentation Review Schedule
| Document | Review Frequency | Triggered By |
|---|---|---|
| Privacy policy | Annually + when processing changes | New processing activity, new data type, new third party |
| ROPA | Quarterly | Any change in processing activities |
| DPIAs | Annually + when processing changes | New high-risk processing, significant changes to existing |
| Breach response plan | Annually + after each breach | Post-incident review, organisational changes |
| Processor agreements | At renewal + when scope changes | New processors, changed processing scope |
| Consent records | Continuously | New consent mechanisms, changes to consent wording |
Frequently Asked Questions
Does GDPR apply to my organisation outside the EU?
If you process personal data of EU/EEA residents — whether you're based in the EU or not — GDPR applies. This includes: offering goods/services to EU residents, monitoring behaviour of EU residents, or processing data on behalf of an EU-based controller.
Do I need a DPO?
Mandatory if: (a) you're a public body, (b) your core activities require regular and systematic monitoring of data subjects on a large scale, or (c) your core activities involve large-scale processing of special category data. Even if not mandatory, appointing a DPO is recommended.
How do I handle documentation for multiple EU countries?
GDPR is directly applicable across all EU/EEA countries, but some national variations exist (e.g., Germany's BDSG). If you operate in multiple countries, your documentation should meet GDPR requirements at minimum, with country-specific supplements where national law adds requirements.
Can I use AI to review my GDPR documentation?
AI can check for completeness (are all required elements present?), readability (is it in plain language?), and consistency (does the privacy policy align with the ROPA?). It cannot verify legal accuracy — whether your legal basis analysis is correct or whether your retention periods comply with applicable law. Use AI for structural review and qualified legal professionals for legal accuracy.
What happens if my documentation is incomplete during a regulatory investigation?
Incomplete documentation is itself a violation. Even if your actual data processing practices are lawful, the failure to document them properly can result in enforcement action. Documentation is both a compliance requirement and your evidence of compliance.
Key Takeaways
- GDPR compliance is a documentation obligation — regulators assess compliance by reviewing your documents.
- Six key documents: privacy policy, ROPA, DPIAs, breach response plan, processor agreements, and consent records.
- Specificity is critical — vague purposes, missing legal bases, and "as long as necessary" retention periods are the most common failures.
- Privacy policies must be in plain language — target grade 8-10 readability, not legal language.
- Review documentation on a schedule — annual minimum, plus triggered reviews when processing changes.
- AI review checks completeness, readability, and consistency — legal accuracy verification requires qualified professionals.
- Documentation failures are among the most common enforcement findings — and among the most preventable.
This article is for informational purposes only. It does not constitute legal advice. GDPR compliance requirements are complex and may vary by jurisdiction, processing activity, and organisation type. Consult a qualified data protection professional for advice specific to your organisation.