A record of processing activities, RoPA for short, is one of the core GDPR documents. Despite appearances, it is not a formality for an official. It is a map that shows what personal data the company collects, why, where it keeps it and to whom it passes it on. Without that map you cannot sensibly answer a data subject request, handle an incident or assess risk.

Who must keep a record

The rule in the GDPR is that the obligation applies to controllers employing at least 250 people, but there are broad exceptions to that. In practice almost every company should keep a record anyway, because the exceptions cover regular processing and special categories of data.

  • You process employee and candidate data: that is regular processing.
  • You run marketing or customer service: that is also regular processing.
  • You process health data, for example in HR: that is a special category.

The conclusion is simple. Instead of looking for a reason not to keep a record, it is better to simply have one.

What a RoPA must contain

For each processing activity the record should describe a few fixed elements.

  • The name of the activity, for example recruitment, complaint handling, newsletter.
  • The purpose of processing and the legal basis.
  • Categories of individuals and categories of data.
  • Categories of data recipients.
  • Information about transfer to a third country, if it occurs.
  • Planned erasure deadlines, that is retention.
  • A general description of the technical and organisational safeguards.

Start with processes, not systems

The most common mistake is listing IT systems instead of business processes. Data lives in processes. A single activity, such as recruitment, can touch a mailbox, a shared drive and an ATS system all at once.

In one audit a company had a beautiful record based on program names, and still could not say where the CVs of rejected candidates ended up. A record described by processes would have solved that in a minute.

How to build a record step by step

  1. Gather department heads and ask them about the real processes involving personal data.
  2. For each process, establish the purpose, legal basis and scope of data.
  3. Establish where the data physically sits and who has access to it.
  4. Identify recipients, including IT providers as processors.
  5. Set retention periods and the method of erasure.
  6. Describe the safeguards at a general level.

A spreadsheet is enough to keep the record, as long as it is up to date and has a single owner. The tool is secondary to diligence.

How to keep the record alive

The biggest threat to a RoPA is not an error while creating it, but the fact that after a month no one looks at it. A dead record is worse than none, because it creates a false sense of compliance.

  • Appoint an owner of the record, often the DPO or a person they designate.
  • Set a periodic review, for example once every six months.
  • Update the record on every significant change: a new system, a new provider, a new service.
  • Tie updates to the IT procurement process, so that new tools do not slip in quietly.

The record does not work in a vacuum. It should connect to data processing agreements, the risk analysis and the procedure for handling data subject requests. When a customer asks for access to their data or its erasure, a well kept RoPA immediately tells you where to look for that data.

Summary

A good record of processing activities is a practical tool, not an ornament for a binder. Build it around processes, assign it an owner and update it regularly. Then, in the event of an inspection, an incident or a data subject request, you have a ready answer instead of panic.

If you want to be sure your record covers everything and matches reality, take a look at our GDPR audit and DPO outsourcing. We will help you build the record and, more importantly, keep it in shape.