EU compliance · optional · compliance team

Understand the record

Before you fill or sign anything, know what you are looking at. Regixo drafts a GDPR Article 30 Record of Processing Activities from the engineer’s real systems. It fills the parts a machine can measure and marks the legal calls that are yours. This page explains the fields, the line between the two, and who on your team does what.

Optional · EU compliance module You need this only if your company must keep a GDPR Article 30 RoPA or a DORA register — it is an optional module on top of the free data catalog. If that is not you, you can skip this section.

What a RoPA is

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.

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.

The fields on each activity

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:

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

Field	What it records	How it’s filled
Title	The short name of the activity.	suggested from the grouped tables
Role	Whether you are the controller (you decide the purpose) or a processor (you act for someone else) for this data.	auto-filled from the source’s declared role
Data categories	The kinds of personal data present — email, name, financial, health…	auto-filled from the scanned PII flags
Data subjects	Whose data it is — customers, employees, patients…	suggested, you can edit
Recipients	Who you share the data with.	suggested from cross-system lineage — needs you when no cross-system flow is known; you confirm
Purpose	Why you process the data.	suggested, you confirm
Lawful basis	The Art. 6(1) ground that makes it lawful.	suggested, you confirm
Retention	How long you keep the data.	suggested, you confirm
Transfers outside the EU	Whether the data leaves the EU, and the safeguards if it does.	suggested from the source region, you confirm
Security measures	The technical and organisational safeguards.	needs you — never auto-filled
Art. 9(2) ground	The condition for special-category data. Appears only when the activity carries Art. 9 data.	needs you ⚠ Art. 9
Art. 10 condition	The condition for criminal-offence data. Appears only when such data is present.	needs you
Controller	Your organisation’s registered legal name (record level).	needs you — factual identity you supply
Data protection contact	Who owns data protection — your Data Protection Officer if you have appointed one, otherwise a legal lead or director.	needs you

Data categories are fixed at the source The data categories are mechanical — derived from the personal-data flags on the scanned columns. You do not type them on the record. If a category is wrong, it is corrected where it came from: the engineer fixes the column on the map or with regixo classify (Classify & correct), and the record re-derives from the corrected map.

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. The record carries one of these per activity, each opening on Activity detail & gaps:

what you'll see — one activity on the record (RoPA), opened on Activity detail & gaps · every field badged found · suggested · needs you

Regixo data catalog · free & local

Record of Processing Activities

DRAFT

Manage customer accountsaccounts · customers · accounts · customer_accounts · customers · customers · ACCOUNTS · CUSTOMERS · CUSTOMER_ACCOUNTS · customer

Regixo found: Address, Date of birth, Email, Financial (card/IBAN), Identifier, Name, National ID, Phone · suggested basis Art. 6(1)(b) contract suggested

⚠ Needs you: confirm the legal fields (purpose, lawful basis, retention).

Processor-role activity. Shown in controller format — a statutory Art. 30(2) processor record (organised per controller) is a roadmap item.

Activity detail & gaps

Purpose	Create and run customer accounts and subscriptions so people can use your product or service. suggested
Personal data	Address, Date of birth, Email, Financial (card/IBAN), Identifier, Name, National ID, Phone found
Data subjects	Customers suggested
Recipients	HubSpot found
Lawful basis	You need it to provide your product or service.Art. 6(1)(b) contract suggested
Retention	Account lifetime + statutory minimum suggested
Transfers outside the EU	None identified from source regions suggested
Security measures	Describe them — or set once in your org profile needs you

A person confirms legal fields — not Regixo. Purpose, lawful basis, retention and recipients are legal calls only your compliance owner makes. Regixo drafts them from your data; a person reviews and signs. This part isn’t yours to finish.

example — one activity on the record

✓ Take and record payments                     invoices · charges · payment_methods

  Regixo found: Email, Financial (card/IBAN), Name · suggested basis Art. 6(1)(c) legal obligation
  ⚠ Needs you: confirm the legal fields (purpose, lawful basis, retention).

  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 beside 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.

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.

Mechanical — Regixo fills	Legal — a human confirms (never the engine)
Data categories · Role · Transfers suggestion · Recipients suggestion · the special-category (Art. 9) and criminal-offence (Art. 10) flags	Purpose · Lawful basis · Retention · Transfers decision · Security measures · Art. 9(2) ground · Art. 10 condition · Recipients · Data subjects

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.

The line, in the engine An agent — or Regixo itself — may verify and mark mechanical fields. It may never mark purpose, lawfulBasis, retention, or transfers confirmed. That is a hard rule enforced in the code, not a setting.

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:

On every DRAFT Regixo attests mechanical facts only — purpose, lawful basis and retention are confirmed and signed by you. This is not legal advice.

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.

Who does 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.

Two people, one record In practice a engineer forwards the draft and a compliance team claims it: a preparer fills the calls, an approver confirms and signs. The next two pages walk that path — Claim & review, then Fill the RoPA.

Two honest limits In this version, activities are grouped by rule only — table-name patterns and structure, no AI or language model deciding the grouping — and the shown confidence tells you how sure the rule is. Records also render in English today; a localized render is on the roadmap where a supervisory authority expects one.

← Back

Get started

Claim & review