Fill the RoPA — the legal calls

The data work is done: Regixo mapped your systems and filled in the mechanical facts. What remains are the judgments only a person can make — a lawful basis for each activity, retention, and the sensitive-data grounds. This page walks you through every one of them, activity by activity, so you finish with a record you can sign. Regixo suggests a starting point for each; here you learn how to decide whether the suggestion is right, and confirm it.

Land here from: Claim & review (you've opened the record and signed in). Not sure the record is trustworthy yet? Is it safe to sign? If you are not in the EU / not required to keep a RoPA, you can skip this whole section.

Walk one activity all the way through (the worked example)

Before the reference, do one activity end to end so the loop is concrete. Regixo grouped your accounts and customers tables into an activity it named Manage customer accounts, and pre-filled its suggestions. Here is each of the seven steps for it:

Every activity in your record is that same seven-step loop. The reference below is what you use inside step 3, 4 and 5 to make each call with confidence.

Who already answered — the provenance on each field

You are not filling a blank form. Every field on the claim arrives in one of a few states, and its badge tells you which — so you always know whether a value is a measured fact, a starting point, or a decision a person already made:

The engineering side may still owe you the three facts it answers — security measures, recipients and data subjects. Usually they arrive provided; where one is blank it reaches you as a gap whose only fix is an email back to the engineer. You review theirs, you do not invent them. The legal calls — purpose, lawful basis, retention, transfers — are yours alone.

The fields you fill

Each processing activity has these fields. The mechanical ones (data categories, role, the transfers suggestion) are already filled from the map; three are facts the engineering side answers (“Your part” on their free record); the rest are yours.

Step 2 · Purpose

Purpose is the one-sentence why you hold this data (Article 30(1)(b)). Regixo suggests one from the activity's tables; you confirm it if it's true, or rewrite it. Two rules: it must be a real sentence, never the activity's name restated ("customer accounts" is not a purpose), and it must be specific — "operate customer accounts and billing", not "business purposes". If Regixo left it blank, write it yourself. To decide: finish the sentence "We hold this data in order to …" — that is your purpose.

Step 3 · Lawful basis (Article 6(1)) — the decision walk

Every activity needs exactly one Article 6(1) ground. Regixo suggests a starting point; to decide whether it's right (or pick one where it left the field blank), ask these five questions in order and stop at the first “yes”:

Two activities can share a basis; one activity has exactly one. If two questions both feel like “yes”, pick the one that is the primary reason you hold the data. Regixo's suggestion follows this same logic from your table names — this walk is how you confirm it.

How Regixo suggests one

Regixo reads the activity’s table names and offers a starting suggestion when it recognises a pattern. It’s a transparent heuristic, not a legal engine:

Step 5 · Special category — Article 9(2)

Some data is extra-sensitive: health, ethnicity, religion, political opinions, trade-union membership, biometrics, sexual orientation. When Regixo detects it (its own Art. 9 badge), the activity needs a second ground under Article 9(2) in addition to your Article 6 basis. The ten grounds, exactly as Regixo lists them:

The Art. 9 ground is a separate field from the lawful basis, so your Article 6 basis stays a clean single choice.

Criminal-offence data — Article 10

Data about criminal convictions or offences (its own Art. 10 class, never an Art. 9 ground) may only be processed under official authority or where authorised by Union or Member-State law. Regixo asks you to confirm that condition — it never proposes an Art. 9 ground for it.

Two machine claims to check before you rely on them

The Art. 9 badge and the activity grouping are the classifier’s guesses — it reads column names and types only. Sanity-check two things against what you know before you fill on top of them:

• “0 special-category (Art. 9)” means no column name or type looked sensitive — not that none is. A free-text notes field can carry health data behind a neutral name. Independently verify any system you know handles sensitive data, and add the Art. 9(2) ground yourself; the machine will not prompt you for what it could not see.
• “Uncategorised processing” holds tables that matched no recognised activity pattern. Read it — an activity the rules could not name is still one you may have to record. For a regulated firm it is often KYC / AML checks, which rarely look like the common table names.

Step 4 · Retention

How long you keep the data, and why. Regixo suggests a common default when the activity is recognisable — you confirm or replace it:

• Billing / invoices → 7 years (statutory tax retention)
• KYC / AML checks → 5 years after the business relationship ends (anti-money-laundering law; varies by member state)
• Employee records → 6 years after leaving (varies by member state)
• Marketing → until consent is withdrawn
• Logs / sessions → 30–90 days
• Customer accounts → account lifetime + statutory minimum

No recognisable pattern → the field is needs you. Set a concrete period tied to a reason, not “as long as necessary”.

Step 6 · The engineer’s three facts (+ transfers)

Transfers outside the EU

Auto-suggested from each source’s region — “None identified” when every source is in the EU, or “Yes — a source is hosted outside the EU” otherwise. Confirm or correct it, and note the safeguard (e.g. Standard Contractual Clauses) if data does leave.

Recipients

Who the data is disclosed to (processors, authorities). Regixo suggests the destination systems it can trace from cross-system lineage; you confirm those and add the rest. Enter categories, comma-separated.

Data subjects

Whose data it is — customers, employees, patients. Categories, not names.

Security measures

How the data is protected. Never auto-filled — describe your controls, or set them once in your organisation profile so they apply across activities.

Step 7 · Fill & confirm — exactly where to click

Filling and confirming happen on the claimed record. Read it signed out and every open legal call is already visible:

• the value slot holds a hint, not an answer
• the badge reads needs you
• a line beside it names who may act — A preparer can fill this

That last line is a label, not a button. The one way in is the Sign in to fill card in the rail; once you are signed in, each open row carries its own + Fill this editor, opened in place.

One activity, read signed out — Recipients and Security measures are still open, Retention was confirmed by a person, and the record names who:

Here is a legal-basis row mid-fill — the inline editor open on the lawful-basis call, with the approver's confirm checkbox:

Three fields usually arrive already answered: security measures, recipients and data subjects are facts about the systems, not legal calls, so the engineer answers them once on their own free Record page (“Your part”) and the answers travel with the record. Review and adjust them on the claim page like any other value. One left blank reaches you as a gap — and the only way to close it is an email back to the engineer. The legal calls — purpose, lawful basis, retention, transfers — remain yours alone.

Where each surface lands — and the honest limit of each:

$ regixo annotate set <activityKey> lawfulBasis "Art. 6(1)(b) contract" --confirm

Two ways to make the calls, depending on who you are:

In the portal (the compliance team)

Open each activity on your claimed record, choose the field’s value, and confirm. Roles apply: a preparer fills the fields; an approver confirms and signs. A confirmed field records who confirmed it and when.

From your project (the engineer, optional)

An engineer can pre-fill or confirm legal fields from the terminal with regixo annotate. Confirming requires a signer identity, so the record knows who made the call:

$ export REGIXO_SIGNER_EMAIL=dpo@acme.example
$ regixo annotate set <activityKey> lawfulBasis "Art. 6(1)(b) contract" --confirm

Rebuild the draft files — regixo report

regixo report re-reads the catalog and rewrites the draft files on disk, stamped DRAFT. You rarely need it — everything that reads the catalog live is already current the moment you save: the portal at regixo open, and the record regixo invite sends. Both rebuild the draft on the spot.

The files on disk do not. regixo start and regixo watch write RoPA_DRAFT.json. The human-readable RoPA_DRAFT.html — the one you would actually email someone — is written in one place only: here.

$ regixo report

RoPA DRAFT → ./RoPA_DRAFT.json (4 activities, stamped DRAFT)
auto-filled 14 fields · 10 need you · 0 special-category (Art. 9) · coverage 2/4 sources
read it: open RoPA_DRAFT.html

How you know your RoPA is finished

Run the loop until all three of these are true — then, and only then, the record is ready to sign:

• No activity shows a needs you badge any more — every legal call is filled and confirmed by a named approver.
• The Schedule — open items on this record index is empty — it reads Awaiting confirmation, with nothing left blank.
• You have sanity-checked the two machine claims (§ above): any system you know handles sensitive data has an Art. 9(2) ground, and nothing important sits unread in “Uncategorised processing”.

The record still says DRAFT — that is expected; it becomes OFFICIAL only when a named person signs it, which is the next step. Filling everything here does not sign anything.