The answer in brief
The most common mistake with a records of processing activities is not that it is missing, but that it is filled in once and never updated again. A records of processing activities should be a living overview of what happens to personal data in your company. Whenever you acquire a new tool, switch payroll processors, or install a camera at the entrance, that overview should change too — but in practice, this often doesn't happen.
Besides this, we see three other mistakes recurring: only the obvious systems are recorded, purpose and retention period are formulated too vaguely, and the records of processing activities is confused with a data processor agreement when it is something different. Below, we explain each mistake and show how to prevent it in practice.
Mistake 1: the records of processing activities becomes a snapshot instead of a living document
Many companies fill in the records of processing activities at the moment they start — often following a request from a customer or accountant — and then consider it complete. But a processing activity today often looks different a year from now: a new accounting package is added, the HR tool is replaced, or a newsletter is started via a different platform. If the records of processing activities doesn't change with it, a gap emerges between what is on paper and what actually happens. This gap usually only becomes apparent when someone needs the records of processing activities: after a data subject request, during a tender process, or following a personal data breach.
The core of this mistake is that records of processing activities is often treated as a project when it is actually a process. There is no fixed moment built in to review it, and no one is structurally responsible for it. read how such records of processing activities automatically stays current when it is linked to the tools you already use, instead of being maintained separately in a Word document.
Mistake 2: only the conspicuous systems end up in the records of processing activities
A second recurring mistake is that only the "large" processing activities are recorded: the CRM system, payroll administration, perhaps the webshop. Smaller or less visible processing activities are skipped, even though they fall equally under the GDPR. Think of an Excel list with customer data that is maintained alongside the CRM, a WhatsApp group that also contains customer telephone numbers, or a separate booking system for a showroom. Commonly used SaaS tools such as a scheduling app, an e-signature service, or a time tracking tool also belong in the records of processing activities, even if they were "just quickly" introduced.
This mistake usually arises not from carelessness, but from unfamiliarity: many entrepreneurs don't know exactly which tools within their organization process personal data. An overview of known SaaS tools helps reduce this blind spot; in the knowledge base you will find explained per topic when a tool falls under the GDPR.
Mistake 3: purpose and retention period are formulated too vaguely
The third common mistake is in the content of the records of processing activities itself. For each processing activity, there should be a concrete purpose, a lawful basis, and an indication of how long the data will be kept. In practice, this is often filled in with formulations such as "business operations" or "as long as needed". This is not a mistake in the sense that the records of processing activities becomes invalid because of it, but it makes the records of processing activities less useful: it doesn't answer the question of why data is being kept and when it should be deleted.
The GDPR itself operates on the principles of purpose limitation and storage limitation, without prescribing fixed retention periods — those periods vary depending on the type of data and the sector. A register that makes this concrete for each processing activity is therefore more valuable than a register that uses the same general wording everywhere.
How to prevent this in practice
The common thread behind these errors is that a register is viewed as a one-time task rather than as part of business operations. A good practice is to link the register to moments that are already happening: purchasing a new tool, switching a supplier, or the annual conversation with your accountant. At those moments, it makes sense to also check whether the register is still accurate.
It also helps to establish in advance who within your organization is responsible for maintaining it, even if that is one person in addition to other tasks. Without an owner, updating remains dependent on chance. If you get stuck on a specific situation, for example whether a particular tool should or should not be in the register, you will often find a short and concrete answer in the frequently asked questions with the source reference in the official text.
Would you like to see what your own register would look like based on the tools you already use, without having to manually figure everything out first? Do the free quick-scan or create a business account to see what would rightfully appear in the register for your situation.