Understand the record

Before you fill or sign anything, know exactly what you are looking at. This record is your GDPR Article 30 Record of Processing Activities, drafted from your engineering team’s real systems — not a blank template. This page orients you completely: what the record is, every field and who owns it, the line between the facts a machine can measure and the calls only a person makes, and how to judge whether the record is complete enough to sign. You act on nothing here — you read, so the pages that follow go quickly.

Also process data for clients? That needs a second, separately-shaped record — GDPR Art. 30(2), organised per client. See The processor record →.

Land here from: the whole journey, or the email your engineering team forwarded. The next step, once you understand the record, is to check who Regixo is: Is it safe to sign?

Read one record and reach a verdict (the worked example)

Before the reference, walk one estate through all six reads, so the shape is concrete. Say your record opens with 7 datasets · 11 personal-data columns · 4 activities, and the coverage line reads 5 of 6 sources reached — one warehouse was unreachable at the last scan. Here is each read, and the verdict it builds toward:

The verdict: the record is real and mostly mapped, but not ready to sign — the legal calls are unconfirmed and one system is unreached. That is the normal starting state. The rest of this page is each of those six reads in full, so you can reach the same verdict on your own record.

1 · What a RoPA is — and the three counts you’ll see

A RoPA — Record of Processing Activities — is the register GDPR Article 30 requires most organisations to keep: for each thing you do with personal data, it records why you hold the data, on what lawful basis, who it concerns, who you share it with, and how long you keep it. It is the first document a supervisory authority asks for.

GDPR Article 30 requires this record, and Art. 30(5) exempts firms under 250 persons unless any one of these is true: the processing is likely to result in a risk to people's rights and freedoms, it is not occasional, or it involves special-category or criminal-offence data. Regular processing such as payroll or a CRM meets the “not occasional” limb, so in practice the exemption rarely applies.

Regixo builds the draft from your data itself, not a blank template. The scan reads the structure of your databases and SaaS — table and column names, types, owners, lineage — and turns it into a set of activities (“Take and record payments”, “Employment administration”), each with the Article 30 fields below. Nothing is guessed about the values in your tables; Regixo reads metadata only.

Datasets, columns and activities — three zoom levels on one estate

The record is built from three things the scan found, and the claim shows a count of each. On this example estate they read 7 datasets · 11 personal-data columns · 4 activities. The three are three zoom levels on the same estate:

• Datasets — the tables and files in your systems (a customers table, an invoices table). A dataset is the whole table; the scan reads its name and structure, never its rows.
• Personal-data columns — the individual fields inside those datasets that the classifier flagged as personal data (an email field, a national-ID field). The count is of columns, not of people: one column can hold data on millions of subjects.
• Activities — your datasets grouped by the job they serve (“Manage customer accounts”, “Take and record payments”). An activity is the unit Article 30 records, so the RoPA carries one entry per activity, not one per table. Several tables usually roll up into one activity.

So a handful of activities can sit on top of many datasets and columns. Reading the record, you work at the activity level — one entry per job — and the datasets and columns are the evidence underneath each one.

2 · One activity, field by field

Every activity carries the Article 30(1) items plus the lawful basis every supervisory-authority template adds. Each field is badged so you can see at a glance what Regixo could fill and what it could not — read the badge before you read the value, because the badge tells you whether it is a measured fact, a starting point, or a gap:

auto-filled Regixo measured it from your data · suggested a starting point Regixo proposes, you confirm · needs you only a human can supply it · ⚠ Art. 9 special-category data — a stricter call

Whose processing this record covers — Art. 30(1)(a)

The record opens with the identity of the organisation it is for. It is factual, not a legal judgement. The engineer fills it headlessly in regixo.yml and it travels with the draft; the record displays it. The record shows six rows.

controller:
  name: Northwind SaaS Ltd                       # registered legal name
  contact: privacy@northwind.example             # a reachable data-protection contact
  address: 12 Clover Court, Dublin 2, Ireland
  dpoName: Aoife Byrne                           # where a DPO is appointed
  dpoContact: privacy@northwind.example
  representative:                                # Art. 27 — where applicable
    none: true
    by: dpo@northwind.example
  jointControllers:                              # where applicable
    - Northwind Analytics Oy

• The two where-applicable slots take an answer either way, in regixo.yml. representative and jointControllers accept a name (or a list), or a recorded “does not apply” — { none: true, by: <who@org> }. The record then reads None · confirmed by that address, which is an answer. Leaving them blank is not — it stays an open ask.
• An official record cannot be sealed without the name and a reachable contact. The unlock gate refuses a placeholder, with the coded CONTROLLER_REQUIRED.
• None of it is a secret — it is the record’s own content — so it belongs in regixo.yml, which is safe to commit.
• It is exempt from redaction. This block is legal content of the record, so it is never masked on the way out — see the redaction policy.

Here is one activity as it reads in the draft — the mechanical facts Regixo found, the legal calls it only suggests, and the gaps it leaves open for you.

Every activity is a numbered section with a badge counting its open calls, and every field stays on the page:

2 / 4  Take and record payments                                    2 open calls
       invoices · charges · payment_methods

  ⚠ Needs you: confirm the legal fields (purpose, lawful basis, retention); add
    who you share this data with (recipients) — none could be detected from the schema.

  Purpose            Process orders and payments, issue invoices…   [suggested]
  Personal data      Email, Financial (card/IBAN), Name             [found]
  Data subjects      Customers                                      [suggested]
  Recipients         — none detected from your schema             [needs you]
  Lawful basis       Art. 6(1)(c) legal obligation / (b) contract   [suggested]
  Retention          7 years (statutory tax retention)              [suggested]
  Transfers          None identified from source regions            [suggested]
  Security measures  —                                              [needs you]

The tables listed under the title are the ones Regixo grouped into this activity — a mechanical judgement about your schema, never a judgement about a legal call. If the grouping is wrong, say so when you review: the legal calls below it are yours either way.

3 · Mechanical vs legal — the line Regixo won’t cross

This split is the whole honesty of the product. Regixo fills the mechanical fields — the ones it can read from your systems. It only ever suggests the legal ones; a human confirms them, and the engine never marks a legal field confirmed on its own.

In practice the human side splits again — the product draws three lines, not two:

• Mechanical facts — Regixo fills them from your schema.
• Engineer facts — security measures, recipients and data subjects: the “Your part” questions on the engineer’s own free record (is the data encrypted? which outside services get a copy? whose data is it?), answered once and travelling with the record.
• Legal calls — purpose, lawful basis, retention, transfers and the Art. 9/10 grounds; only the compliance team confirms these.

The table keeps everything a person supplies on the right.

Transfers appears on both sides, and that is deliberate: Regixo suggests whether data leaves the EU from the source region it knows (mechanical), but the decision — and the safeguard behind it — is a legal call you confirm. Recipients works the same way: Regixo suggests the destination systems from cross-system lineage (a mechanical read of where your data flows), and you confirm the disclosure — a suggestion is never confirmed on its own. The same holds for the Art. 9 and Art. 10 flags: Regixo can tell you a column looks like health or conviction data, but only you pick the ground that permits it.

4 · Two machine claims to sanity-check

Two lines on the draft are the classifier’s guesses, not proof. The classifier reads column names and types only, so a blandly-named column can hide personal data and a suggestive name can false-flag. Before you rely on either line, check it against what you know:

• “0 special-category (Art. 9)” is a machine claim to sanity-check, not a clean bill of health. It means no column name or type looked like health, ethnicity, religion, political opinion, trade-union, biometric or sexual-orientation data — not that none is present. If you know a system holds sensitive data behind a neutral name (a free-text notes field, a scanned form), say so: the ground that permits it is a legal call only you can make.
• “Uncategorised processing” is where Regixo puts tables it could not fit to a recognised activity pattern — it groups them plainly rather than invent a name. Do not skip it: an activity the rules did not recognise is still one you may have to record. In a regulated firm this is often your KYC / AML processing, which rarely matches the common table-name patterns. Read what landed there and name it.

DRAFT vs OFFICIAL

The free record is always stamped DRAFT. The stamp is permanent until a human confirms the legal fields and a named person signs — it is not a nag you can dismiss, it is the honest state of the document. Every DRAFT surface (the PDF, the on-screen record, the machine-readable JSON) carries the same line, word for word:

Need the drafts as one file? regixo evidence assembles them — the RoPA DRAFT, the DORA register DRAFT when in scope, the change-log and the sources — into one verifiable JSON with a sha256 fingerprint per artifact; free and DRAFT-only, it attests nothing (command reference).

OFFICIAL is the paid version of the same record: the DRAFT stamp comes off, the legal fields read confirmed, and an immutable snapshot is sealed under a real signature and date. It is the version you can put in front of an auditor. What signing does, and what the seal proves, is covered in Unlock, sign & maintain.

The signature appears in full capacity — name, role and organisation — wherever it is shown, so a reader always knows who stands behind the record and in what authority.

5 · Who owns what on your team

A claimed record has four roles. They separate filling a legal field from confirming and signing it — so no single person quietly turns a suggestion into an official fact.

viewer

Reads the record. Makes no changes. Anyone you share the record with can review it in this role.

preparer

Fills the legal fields — purpose, lawful basis, retention, recipients and the rest. A preparer’s value is provided, not yet confirmed.

approver

Confirms the filled fields and signs the official record. Only an approver or an admin may sign. A field an approver has confirmed is locked — a preparer cannot overwrite it; only an approver can re-open it.

admin

Everything an approver can do, plus managing the team and the machine tokens. The first person to sign in on a claim becomes its admin.

6 · Is it complete enough to sign? — the decision walk

This is the read the other five build toward. A RoPA is only as defensible as it is true and complete, so before anyone signs, walk the record against a fixed bar — the minimum-viable-estate test. Ask these five questions in order; each “no” is a reason the record is not yet ready to sign, and names exactly what to close first:

All five “yes” → the record is complete enough to sign (signing itself is a later, deliberate act — Unlock, sign & maintain). Any “no” names the work left. How to read the coverage: the claim states how much of the estate the draft is built on and names any source it could not reach, so a partial scan is never quietly passed off as the whole picture. That honesty is also a warning — if you sign while systems are unscanned, you have sealed an accurate record of part of your processing, and an auditor reads the gap as missing activities, not as a smaller company.

Short of the bar you can still sign — the seal lists the open items as flagged gaps rather than hiding them — but you are signing a record that says so on its face. Close the gaps you can before the signature, and carry the rest openly.

How you know you’ve understood the record

You are done reading this page when you can answer all six reads on your own record without guessing:

• You can say what the three counts mean, and that you read the record at the activity level.
• For any field, you can name its badge — measured fact, suggestion, or a gap that needs you.
• You can point to the mechanical-vs-legal line: which fields Regixo fills, and which are yours alone.
• You have sanity-checked the “0 Art. 9” and “Uncategorised processing” claims against what you know.
• You know who on your team will fill (preparer) and who will confirm and sign (approver).
• You can run the sign-readiness bar and say, in one sentence, why the record is or is not signable today.

Nothing here signs or changes the record — understanding it is the whole job of this page. The record still reads DRAFT, exactly as it should.