ROPA & GDPR Documentation for SMEs - Records of Processing Activities, Privacy Notice & TOM Done Right

Data protection authorities demand evidence. So do clients, investors and procurement teams. Most SMEs know they need GDPR documentation - few have it in a state that would survive an audit. This guide walks you through exactly what to build, in what order, with reviewed templates at every step.

Why Solid GDPR Documentation Is Non-Negotiable for SMEs

Regulators and clients are asking for proof - not good intentions.

GDPR has been in force since 2018. Data protection authorities across the EU have moved beyond simply reacting to reported breaches - they actively request documentation during routine investigations and client-driven due diligence processes. A company that cannot produce complete, up-to-date documentation has no defence, even if the underlying data processing is technically correct.

What are the real consequences?

GDPR fines reach up to €20M or 4% of worldwide annual turnover - whichever is higher. The Managing Director can additionally be personally liable where supervisory duties are breached (under German law: §130 OWiG, §43 GmbHG). Beyond fines there is reputational damage, and the practical impact is often felt earlier: prospective clients, investors and technology partners routinely request GDPR documentation before contracts are signed. Missing documentation creates delays that cost more than compliance would have.

What does structured documentation actually give you?

Good documentation is not just a regulatory shield - it creates internal clarity. You know which data lives where, who is responsible for it, and which systems carry which risks. That is the foundation for handling customer data responsibly, not just legally, and it builds customer trust in your company.

ETHYX brings structure to your documentation - with templates instead of blank pages, and an external DPO who reviews the output.

What Is the Record of Processing Activities (ROPA)?

I keep hearing about a "processing register" - what exactly is it?

The Record of Processing Activities (ROPA) is the central document in your GDPR documentation. It lists every process in your organisation that involves personal data - with the purpose of processing, data categories, recipients, retention periods and technical safeguards. Article 30 GDPR formally requires a ROPA for organisations with 250 or more employees, but with a critical exception: smaller organisations also need one when they process personal data regularly, or when the processing could pose a risk to individuals. In practice, that covers almost every SME.

What goes into the ROPA - and what doesn't?

Everything involving personal data: your email marketing platform, CRM, applicant tracking system in HR, support ticketing tool, website analytics. External service providers who process data on your behalf - cloud hosts, payment processors, AI tools - also need to be documented. If it touches personal data, it belongs in the ROPA.

What is the difference between a Controller and a Processor?

As a Controller, your organisation determines the purpose and means of processing - the decisions are yours. As a Processor, a third party processes data on your behalf - for example an email service provider or a cloud host. For every Processor, you need a Data Processing Agreement (DPA agreement) and a corresponding entry in your ROPA. Both perspectives must be documented. A processor also needs a ROPA of its own (Art. 30(2) GDPR), covering not only its own processing activities but also those it carries out on behalf of its clients.

Step by Step: Building Your ROPA

Step 1 - Map all processes first

Do not start with the template. Start with a list. Ask department heads: which tools are in use? Which processing purposes are pursued? Which customer or employee data ends up where? Check your IT landscape: which SaaS tools are active, including unofficial ones? Shadow IT - tools employees use without IT approval - is present in virtually every SME. You can only document what you actually know is running.

Step 2 - Complete the mandatory fields under Article 30 GDPR

For each processing activity, record:

• Purpose of processing - why is this data being processed? (e.g. "sending marketing newsletters")
• Categories of data subjects - whose data? (e.g. customers, prospects, job applicants)
• Categories of personal data - which data? (e.g. name, email, purchase history)
• Recipients - who receives the data? (e.g. email service provider, sub-processors)
• Third-country transfers - is data transferred outside the EU/EEA?
• Retention periods - how long is the data kept?
• Technical and organisational measures (TOM) - how is the data protected?

No field left blank. Gaps are as problematic as a missing ROPA during an inspection.

Step 3 - Maintain and update the ROPA

A ROPA created once and never touched again is outdated within months. Establish from the start: who owns this document? When is the next scheduled review? What triggers an unplanned update - for example the introduction of a new tool or a change in processing purpose?

Creating Your Privacy Notice (Website, App, Customer Communications)

What information must go into a privacy notice?

A privacy notice informs individuals how your organisation processes their personal data. Articles 13 and 14 GDPR set the minimum content - in plain language, not legal boilerplate.

Required content:

• Name and contact details of the Controller
• Contact details of the Data Protection Officer (if appointed)
• Purposes and legal bases for each processing activity
• Recipients and sub-processors
• Third-country transfers
• Retention periods
• Data subject rights (access, rectification, erasure, objection)
• Right to lodge a complaint with a supervisory authority

Common mistakes when creating a privacy notice

Most privacy notices at SMEs have one or more of these problems:

• Copy-pasted from a privacy notice generator: Generators produce standard text. If your organisation uses HubSpot, Intercom, OpenAI or any specific CRM, those tools must be named explicitly - a generic template will not cover them.
• Missing processing activities: The notice covers the website but not the CRM, newsletter platform or support chat.
• Never updated: Every new tool, every new vendor, every new processing activity requires an update to the notice.
• Wrong or missing legal basis: "We process your data based on our legitimate interest" is not a sufficient justification when consent is actually required.

How do I keep the privacy notice current as tools change?

Build a lightweight process: when a new tool or a new processing activity is introduced, one designated person checks whether it processes personal data. If yes, the privacy notice gets updated within two weeks. No committee, no approval chain - one person, one process, one deadline.

Technical and Organisational Measures (TOM) - A Practical Checklist

Which technical measures do I need?

TOM are the concrete safeguards that protect personal data from unauthorised access, loss or misuse. Technical measures include:

• Encryption - data in transit (TLS) and at rest (AES-256 or equivalent)
• Access controls - only those who need access have it; roles and permissions documented
• Backups - regular, tested backups with defined recovery time objectives
• Logging - audit trails showing who accessed which data and when
• Pseudonymisation - separating identifiers from content data wherever feasible

Which organisational measures do I need?

• Roles and responsibilities - who is accountable for which processing activity?
• Staff training - employees must understand how to handle personal data in their role
• Deletion policy - what gets deleted, when, and by which process?
• Internal policies - BYOD, clean desk, password management
• Incident response - what happens when a data breach occurs? Who is notified, and when?

How do TOM connect to the ROPA and to contracts?

In the ROPA, each processing entry should reference the applicable TOM - either inline or as a link to a separate TOM document. In Data Processing Agreements, GDPR requires that the Processor's technical and organisational measures are described in sufficient detail. A DPA agreement without specific TOM is incomplete - and legally vulnerable.

ETHYX also functions as a TOM documentation tool: all technical and organisational measures are referenced directly within each ROPA entry and flagged for review when they become outdated.

Data Processing Agreement (DPA) - Getting Sub-Processor Relationships Right

When do I need a Data Processing Agreement?

Any time an external vendor processes personal data on your behalf, you need a Data Processing Agreement - also referred to as a DPA agreement or, in US-origin contracts, a Data Processing Addendum. The data processing addendum format is common in SaaS vendor contracts and is legally equivalent to a DPA under GDPR. If a vendor processes your customers' or employees' data and there is no signed agreement in place, that processing is unlawful. Typical examples:

• Hosting and cloud providers (AWS, Google Cloud, Hetzner)
• Email marketing platforms (Mailchimp, Brevo, HubSpot)
• CRM systems (Salesforce, Pipedrive)
• Support tools (Zendesk, Intercom)
• AI tools (ChatGPT via API, Microsoft Copilot, Notion AI)
• HR software (Personio, Workday)

If a vendor cannot provide a Data Protection Agreement or refuses to sign one, you cannot lawfully use their services for processing personal data.

What must a DPA agreement contain as a minimum?

A legally sound data processing agreement includes:

• Subject matter, duration and nature of the processing
• Purpose of the processing
• Type of personal data and categories of data subjects
• Obligations and rights of the Controller
• Technical and organisational measures of the Processor
• Rules governing sub-processors
• Return or deletion of data at end of contract
• Audit rights of the Controller

Common mistakes in DPA agreements

• Vague or missing TOM: "Appropriate measures" is not a description - it is a placeholder.
• Sub-processors not addressed: Many SaaS vendors use further sub-processors. That chain must be documented and approved.
• Audit rights not clearly defined: If you need to demonstrate in a dispute that your Processor acted correctly, you need a documented right to inspect.
• Outdated versions: If processing activities change, the DPA must be updated accordingly.

Data Protection Impact Assessment (DPIA) - When the Stakes Are Higher

What is a DPIA, and when is it mandatory?

A Data Protection Impact Assessment (DPIA) - sometimes called a DPIA GDPR assessment - is a formal process for identifying and mitigating privacy risks before a high-risk processing activity begins. DPIA meaning in practice: it is not a checkbox exercise. It is a structured analysis of what could go wrong, for whom, and what you are doing to prevent it.

A DPIA is mandatory when processing is likely to result in a high risk to individuals' rights and freedoms. Supervisory authorities have published lists of processing types that trigger this obligation. Common examples in SME contexts:

• AI-assisted scoring or profiling of customers or employees
• Biometric data (facial recognition, fingerprint scanning)
• AI in HR decisions (automated candidate screening, performance evaluation)
• Large-scale behavioural tracking or analytics
• Special category data (health, political opinions, religious beliefs)

If your organisation uses AI tools that make or prepare decisions about individuals, a DPIA is very likely required - even for smaller companies. → How to document AI processing correctly

How does a DPIA connect to the ROPA?

The ROPA is the starting point. Every high-risk processing entry in your ROPA should trigger a DPIA. A dedicated field in the ROPA for risk level makes this automatic: when a process is flagged as high-risk, a DPIA is initiated. The DPIA then documents the risks in detail, the measures taken to reduce them, and - where a high residual risk remains - the prior consultation with the supervisory authority.

DPIA Checklist: Six Steps

A practical DPIA checklist covers the following steps:

1. Identify - which processing activity triggers the DPIA requirement?

2. Describe - document the processing flow, systems involved and data flows in detail.

3. Assess risks - what could go wrong? For whom? How likely, how severe?

4. Define measures - which TOM, contractual or organisational measures reduce the risk?

5. Obtain sign-off - the DPO reviews and approves; if high residual risk remains, consult the supervisory authority before starting.

6. Schedule review - a DPIA is not a one-time document; repeat it when the processing changes.

Connecting the Dots: ROPA, Privacy Notice, TOM & DPA in One System

How do all the documents relate to each other?

The ROPA is the master record. Everything else connects to it:

• The privacy notice reflects the processing activities documented in the ROPA externally - what is in the ROPA must appear in the notice.
• TOM are referenced against each ROPA entry as the protection layer for every process.
• DPA agreements cover every external sub-processor listed as a recipient in the ROPA.
• A DPIA is triggered for every high-risk process in the ROPA.

A processing activity missing from the ROPA will also be absent from the privacy notice, have no DPA, and have no DPIA - leaving it unprotected on every level simultaneously.

How does ETHYX handle this in the platform?

The ETHYX platform guides you through ROPA setup, TOM assignment and DPA tracking in one integrated workflow. When you create a new processing entry, the system automatically checks whether a DPA is missing and whether a DPIA obligation exists. Changes to existing ROPA entries trigger automatic review tasks - so documentation stays current without manual tracking.

Common GDPR Documentation Mistakes at SMEs

What do we see most often?

• ROPA created once, never updated. Every new tool, every new vendor, every new process changes the data landscape. An outdated ROPA is worthless during an inspection.
• Only the website is documented. CRM, HR system, support tool, email marketing platform - all of these process personal data and all of them belong in the ROPA.
• No mapping to actual tools in use. Documentation lists generic categories but not the specific systems. Regulators ask for specific tools by name.
• No defined ownership. Who maintains the ROPA? Who approves new processing activities? Without clear accountability, nothing gets done.
• DPA agreements missing for obvious vendors. Cloud hosts, email services and AI tools are Processors - without a signed DPA, every data transfer to them is unlawful.
• TOM entries are too vague. "We secure our systems appropriately" is not a TOM. Specific measures, specific systems, specific configurations.
• DPIA never assessed. Any organisation using AI tools that influence decisions about individuals and has never checked whether a DPIA is required has an open exposure.
• Privacy notice from a generator, never touched since. If three new tools have been introduced since the notice was last updated, it is incomplete - and a regulator will notice.

How ETHYX Supports Your GDPR Documentation

Templates + Guided Workflows (ROPA, TOM, DPA, DPIA)

ETHYX is a GDPR documentation tool and ROPA software built for SMEs - not a blank spreadsheet to fill in alone. Every documentation step comes with plain-language explanations, real-world examples from marketing, HR and customer support, and automated checks that flag gaps before they become audit findings. The records of processing activities template is pre-structured around Article 30 GDPR requirements, with fields for TOM references and DPA status on each entry.

Download Free GDPR Documentation Bundle (Bundle: ROPA Excel · Privacy Notice DOCX · TOM Checklist PDF · DPA Agreement Template DOCX · DPIA Template DOCX)

Review by a Certified External DPO

ETHYX clients get access to a certified external Data Protection Officer who reviews their completed documentation and signs off on it. This is not a general advisory call - it is a structured review with written feedback against your specific processing activities.

EU AI Act Integration

Organisations using AI tools - ChatGPT, Copilot, Notion AI or others - are not only dealing with GDPR processing obligations. They also have deployer obligations under the EU AI Act, which phase in through 2027-2028. ETHYX maps both in one integrated workflow: ROPA entry for the AI processing activity, DPIA plus FRIA where required, and Deployer documentation under Article 26 AI Act - in a single process.

30-Day Action Plan for Your SME

How do I get fully documented in one month?

Years of documentation debt cannot be cleared in a day. But one structured month builds the documentation foundation - the first stage of the full 90-day GDPR compliance path.

Week 1 - Current State Mapping & Initial ROPA

Build a complete tool inventory: which systems are in use and which of them process personal data? Create the first ROPA entries for the highest-volume processes: marketing, HR and customer support.

Week 2 - Privacy Notice & TOM Checklist

Review your existing privacy notice for completeness: are all tools, all processing activities and all legal bases covered? Document TOM for each process.

Week 3 - DPA Agreements

Check every external vendor: is there a signed DPA agreement or data processing addendum? Request missing agreements. If a vendor cannot provide one, escalate the decision on whether to continue using that service.

Week 4 - DPIA Review, Gap Closure & Ownership Assignment

For each ROPA entry, assess whether a DPIA is required. Close open items from weeks 1-3. Assign a named owner for ROPA maintenance and set the first scheduled review date.

Sources & further reading