GDPR names few documents outright. You need a record of processing activities, privacy notices, processor contracts, a breach record, impact assessments for high risk processing and evidence of your lawful bases. Policies for rights requests, retention and security are the practical way to prove accountability under Article 5(2).
Which documents does the text require?
Record of processing activities (Article 30). Controllers and processors keep one, with purposes, data categories, recipients, transfers, retention periods where possible and a general security description. The duty has a limited exemption for organisations under 250 staff, which falls away if processing is likely to risk people's rights, is not occasional, or involves special categories. Most companies keep one anyway.
Privacy notices (Articles 13 and 14). Tell people who you are, why you process, the legal basis, who gets the data, how long you keep it, their rights and any transfers abroad. Write one per audience: customers, website visitors, staff, applicants.
Processor agreements (Article 28). A written contract between controller and processor covering instructions, confidentiality, security, subprocessors, assistance with rights and breaches, and return or deletion.
Breach documentation (Article 33(5)). Record the facts, effects and remedial action for every personal data breach, including those you do not report.
Impact assessments (Article 35). Required for processing likely to result in high risk. Keep the assessment, the consultation outcome and the decision.
DPO designation (Article 37). If you must appoint a data protection officer, document the appointment and publish contact details.
Which documents prove accountability?
Articles 5(2) and 24 require you to be able to show compliance. The EDPB's small business guide lists keeping records of processing, data protection by design and impact assessments as ways to do that, and suggests recording assessments and measures. That is where policies come in.
Useful ones: a lawful basis register (with legitimate interest assessments where relied on), consent records and withdrawal handling, a data subject request procedure and log, a retention schedule, an information security policy plus Article 32 measures summary, an incident response plan, a vendor review procedure with a list of subprocessors, a transfer assessment where data leaves the EU, and a training record.
Which documents are over the top?
A fifty page master policy that nobody reads. Keep each document short, dated and owned. Do not create a policy you will not follow, since a missed promise is worse than no promise. Cookie banners and tracking rules sit under separate ePrivacy law, so keep that policy apart.
What does a minimal set look like for a small team?
Six files cover most of it. First, a spreadsheet with the processing record, one row per activity, with columns for purpose, lawful basis, data categories, recipients, location, retention and owner. Second, the privacy notices. Third, a folder of signed processor agreements and a one page processor list. Fourth, a single running log with two tabs, one for individual requests and one for breaches, each with dates and outcomes. Fifth, a short security and retention policy. Sixth, an impact assessment template, used when a new project looks high risk.
That set is small enough to keep current, and it matches what a supervisory authority or a customer's due diligence team will ask for first. Add documents only when a real question demands them, such as a transfer assessment when you start using a provider outside the EU.
How should you keep them?
One folder, one index, a review date per file, and a named owner. Version history matters, because you may need to show what the notice said on a given date. Link each document to the data map entry it supports.
What to do
- Build the processing record from interviews and system lists.
- Draft notices per audience, matching the record.
- Create a lawful basis register and consent records.
- Sign processor agreements and keep the subprocessor list.
- Start a breach register and a request log.
- Run impact assessments for high risk activities.
- Write short policies: security, retention, rights, incidents, vendors.
- Review every document yearly.
Quick check
Do small companies need a record of processing?
Often yes. The Article 30 exemption for organisations under 250 staff does not apply if processing is risky, regular or involves special categories.
Must I log breaches that I do not report?
Yes. Article 33(5) requires documentation of every personal data breach so the authority can verify compliance.
How Safeguard helps automate this
Documents age quickly unless something checks them against reality. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between reviews. That saves your team time for the writing and judgement only people can do. For the security measures you describe, technical evidence comes from your real code and dependencies, using scans, SBOMs and reachability. Safeguard's agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically. Safeguard helps prepare and keep evidence ready, and regulators decide compliance.
Try the framework mapping demo full screen.
Sources
- EUR-Lex, GDPR (Regulation (EU) 2016/679)
- EDPB, Data protection guide for small business
- ICO, Documentation guidance
Last reviewed: 18 October 2026.
