Is Your Article 30 Record of Processing Activities Audit-Ready, or Just a Spreadsheet You Update Once a Year?

Most records of processing activities are not records. They are archaeology.

A spreadsheet built for a data-mapping exercise two years ago, updated the week before an audit, and otherwise untouched while the actual processing underneath it drifts. New vendors. New purposes. A marketing team that started enriching a mailing list. None of it reflected in the file.

GDPR Article 30 does not ask for a snapshot. It asks for a record you can hand to a regulator on request, and that record has to be true on the day you hand it over. That is the gap between a document and evidence.

This piece walks through what Article 30 actually requires, where the once-a-year approach breaks, and what it takes to turn a data processing inventory into something that updates as your processing changes instead of once a year in a panic.

What does GDPR Article 30 actually require in a record of processing activities?

Article 30(1) is direct. Each controller, and where applicable the controller's representative, "shall maintain a record of processing activities under its responsibility." That record "shall contain all of the following information," and the word to notice is all.

The controller record has to hold:

→ The name and contact details of the controller, and where applicable the joint controller, the controller's representative, and the data protection officer (Article 30(1)(a)) → The purposes of the processing (30(1)(b)) → A description of the categories of data subjects and of the categories of personal data (30(1)(c)) → The categories of recipients to whom the data have been or will be disclosed, including recipients in third countries or international organisations (30(1)(d)) → Where applicable, transfers to a third country or international organisation, identifying that destination and, for transfers under the second subparagraph of Article 49(1), the documentation of suitable safeguards (30(1)(e)) → Where possible, the envisaged time limits for erasure of the different categories of data (30(1)(f)) → Where possible, a general description of the technical and organisational security measures referred to in Article 32(1) (30(1)(g))

Two of those fields carry the qualifier "where possible" — erasure timelines and the security-measures description. The other five do not. Purposes, categories of data subjects and data, recipients, and the identity block are not best-effort. They are mandatory content, and a record missing any of them is an incomplete record under GDPR Article 30.

Article 30(3) adds that the record "shall be in writing, including in electronic form." A spreadsheet satisfies the medium. It is the freshness and completeness, not the file format, that the article turns on.

Why does a once-a-year RoPA spreadsheet fail the moment a supervisory authority asks under Article 30(4)?

Article 30(4) is the clause that decides whether your record is real. The controller or processor, and where applicable the representative, "shall make the record available to the supervisory authority on request."

On request. Not on notice. Not after a remediation window.

A supervisory authority request does not arrive on your refresh schedule. It arrives after a complaint, a breach notification, or a sector sweep, and it asks for the record as it stands. If your last update was ten months ago and three processing operations have changed since, the document you produce is not the record Article 30 requires. It is a description of a past state.

This is where the annual spreadsheet fails structurally, not occasionally. The obligation in 30(4) is continuous availability of an accurate record. An update cycle that runs once a year guarantees that for most of the year the record is out of date by construction. You are not one refresh behind. You are, on any given day, however many months of undocumented change behind.

The failure is not that the spreadsheet is a spreadsheet. It is that nothing connects the spreadsheet to the processing it describes. When a new recipient is added or a purpose shifts, the record does not know. A human has to remember to edit it, and humans forget between audits.

Which fields must every controller record, and how do the processor obligations in Article 30(2) differ?

Article 30 defines two records, not one, and they are not interchangeable.

The controller record under 30(1) is organised around purposes. It answers why you process, whose data, what categories, who receives it, where it goes, and how long you keep it.

The processor record of processing under 30(2) is organised around activities carried out on behalf of a controller. A processor "shall maintain a record of all categories of processing activities carried out on behalf of a controller," and its required content is deliberately narrower:

→ The name and contact details of the processor and of each controller on whose behalf it acts, plus any representatives and the DPO (30(2)(a)) → The categories of processing carried out on behalf of each controller (30(2)(b)) → Where applicable, transfers to a third country or international organisation, with the same Article 49(1) safeguards documentation (30(2)(c)) → Where possible, a general description of the technical and organisational security measures referred to in Article 32(1) (30(2)(d))

Notice what the processor record does not require: it does not carry the purposes of processing or the categories of data subjects in the way the controller record does. That is by design. The processor acts on the controller's instructions, so the processor documents the categories of processing per controller, not the underlying purpose it does not set.

Most organisations are both. You are a controller for your own employee and customer data and a processor for services you run on behalf of clients. That means two record structures under one roof, and a data processing inventory that treats them as one field set will misstate your role on half your entries. Getting the controller-versus-processor line right is the difference between a defensible record and one a supervisory authority will read as confused about its own obligations.

Does the fewer-than-250-employees exemption in Article 30(5) really let you off the hook?

This is the clause everyone reaches for and almost nobody actually qualifies under.

Article 30(5) says the obligations in paragraphs 1 and 2 "shall not apply to an enterprise or an organisation employing fewer than 250 persons." That is the headline. Read to the end of the sentence.

The exemption falls away "unless the processing it carries out is likely to result in a risk to the rights and freedoms of data subjects, the processing is not occasional, or the processing includes special categories of data as referred to in Article 9(1) or personal data relating to criminal convictions and offences referred to in Article 10."

Those three conditions are joined by or. Any one of them reinstates the full obligation. So walk it through for a normal business under 250 people:

→ Do you run payroll, a CRM, a customer database, or a recurring mailing list? That processing is not occasional. Exemption gone. → Do you hold health data, trade-union membership, or other special categories under Article 9(1)? Exemption gone. → Does any processing pose a likely risk to rights and freedoms? Exemption gone.

Occasional processing means genuinely one-off or irregular. Any systematic, ongoing operation — which is to say the core data flows of essentially every operating company — is not occasional. The practical reading is that the 250-person threshold exempts almost no one who processes personal data as a routine part of business. It is a narrow carve-out for genuinely incidental processing, not a small-business pass on records of processing activities.

Treat 30(5) as a reason to keep a record, not a reason to skip one. If a supervisory authority ever tests the exemption against your actual processing, you want to have documented why it did or did not apply, and the only way to do that credibly is to have kept the record.

How does your Article 30(1)(g) entry stay tied to the Article 32(1) security measures it describes?

Article 30(1)(g) asks for "a general description of the technical and organisational security measures referred to in Article 32(1)." The cross-reference is explicit. The RoPA does not invent its own security vocabulary. It points at Article 32.

And Article 32(1) is not a static checklist. It requires measures "appropriate to the risk," taking into account the state of the art and the nature of processing, and it names specific capabilities as examples: pseudonymisation and encryption of personal data; the ability to ensure ongoing confidentiality, integrity, availability, and resilience of systems; the ability to restore availability and access after an incident; and "a process for regularly testing, assessing and evaluating the effectiveness" of those measures.

Read 30(1)(g) and 32(1)(d) together and a problem appears. Article 32 requires that your security measures be regularly tested and re-evaluated. Article 30 requires that your record describe those measures. If the measures change after a test and the record does not, the two articles are now out of sync, and the description in your RoPA is describing controls you no longer run.

This is the core reason a static RoPA decays. The security description is a live pointer into a live control set. When encryption scope expands, when a restoration process is redesigned, when a control fails a test and is replaced, the 30(1)(g) entry should move with it. In a spreadsheet, it does not move at all until someone retypes it.

The fix is not to write a better paragraph. It is to make the 30(1)(g) description reference the actual control state rather than restate it from memory, so that when the control changes, the record's view of it changes too.

What turns a RoPA from a static document into living evidence that updates as processing changes?

The difference between a document and evidence is provenance. Evidence can show where each field came from and when it was last true.

A living RoPA has three properties a spreadsheet cannot fake:

Each entry traces to a source. The purpose, the categories, the recipients, the transfer basis, the retention period — each should point to the system, contract, or decision it derives from, not sit as free text a human typed once. When the source changes, the record has something to react to.

Changes are timestamped, not overwritten. Article 30(4) can arrive at any moment. If your record keeps a dated history of what changed and when, you can show a supervisory authority not just today's state but that the record has been maintained continuously. Overwriting a cell destroys exactly the evidence that proves the record is alive.

The security description binds to the control, not to a paragraph. As covered above, the 30(1)(g) entry should reference the Article 32 measures as they actually stand, so a control change surfaces in the record instead of silently invalidating it.

This is the same principle Aegis GRC applies across every framework: every obligation traced to a verbatim quote from the legal text, and every claim traceable back to the control and evidence that satisfies it. A RoPA built this way stops being a thing you rebuild before each audit and becomes a query against the current state. The audit pack is a query, not a project.

How should a RoPA connect to DPIAs, breach records, and your wider audit trail?

Article 30 does not live alone. It is the index the rest of your GDPR evidence hangs off.

The clearest link runs to the DPIA. Article 35(1) requires a data protection impact assessment before processing "likely to result in a high risk to the rights and freedoms of natural persons," and Article 35(7) sets out what that assessment must contain, including a systematic description of the processing and the measures envisaged to address the risks. That description overlaps directly with the RoPA's purposes, categories, and security fields. If the two disagree, one of them is wrong, and a supervisory authority reading them side by side will notice.

Article 35(11) adds that the controller shall, where necessary, review the DPIA "at least when there is a change of the risk represented by processing operations." A change in processing that triggers a DPIA review is the same change that should update the RoPA. If your record and your DPIAs are maintained in separate silos, that shared trigger fires in one place and not the other, and the two drift apart.

Article 35(2) also requires the controller to seek the advice of the data protection officer when carrying out a DPIA. The DPO is the same role Article 30(1)(a) names in the record's identity block. The record, the impact assessment, and the person accountable for both should reference each other rather than repeat each other.

Wire it together and the RoPA becomes the spine: processing operations map to purposes, purposes to the risk assessments they trigger, security descriptions to the Article 32 controls under test, and every change to a dated audit trail. That is a posture you can defend in front of a regulator, because every line traces to its source.

See your processing inventory mapped to obligations and evidence in one place at aegis-grc.com. One data processing inventory, connected to the evidence that satisfies each field and the audit trail that proves it stayed current.

FAQ: RoPA format, retention, who signs off, and how often to review

What format does a RoPA have to be in? Article 30(3) requires the record to be "in writing, including in electronic form." There is no mandated template. A spreadsheet, a database, or a purpose-built tool all satisfy the medium. What matters is that it contains all the fields required by Article 30(1) for controllers or Article 30(2) for processors, and that it is accurate when a supervisory authority asks under Article 30(4). A RoPA template is a convenient starting structure, but the format is not the compliance question. Completeness and currency are.

How long do you keep a record of processing activities? Article 30 does not set a retention period for the record itself. The obligation is to maintain a current record for as long as the processing continues and to make it available to the supervisory authority on request under Article 30(4). Keeping a dated history of prior states is good practice, because it demonstrates continuous maintenance rather than a single point-in-time snapshot.

Who has to sign off on the RoPA? Article 30 places the obligation to maintain the record on the controller or processor, and where applicable the representative. Article 30(1)(a) requires the record to name the data protection officer where one is designated. The article does not prescribe a sign-off ceremony, but in practice the DPO, who Article 35(2) also involves in DPIAs, is the natural owner of the record's accuracy.

How often should you review a RoPA? Article 30 does not fix a review interval. But because Article 30(4) can require production at any time, and because Article 32(1)(d) requires the security measures the record describes to be regularly tested and re-evaluated, a fixed annual review is structurally too slow. The right cadence is event-driven: the record should update when processing changes, when a new recipient or transfer is added, or when the underlying Article 32 controls change, rather than on a calendar.