A ROPA that flags where the lawful basis is narrowest, not just what you process

What Article 30 requires

Article 30 requires a controller to maintain a record of its processing activities: the purposes, the categories of data subjects and personal data, the recipients, any international transfers, the envisaged retention periods, and a general description of the security measures (Art. 30(1)). A processor keeps its own record of the processing it carries out on a controller's behalf (Art. 30(2)).

A ROPA that is only an inventory answers 'what do we process'. The question that matters for compliance is narrower: which of these activities sit under a special regime where the lawful basis is not the ordinary Article 6 menu.

• Purposes, data-subject and data categories (Art. 30(1)(a)–(c))
• Recipients and international transfers (Art. 30(1)(d)–(e))
• Retention periods and security measures (Art. 30(1)(f)–(g))
• Processor records of controller-directed processing (Art. 30(2))

Where the lawful basis is narrowest — Articles 9, 10 and 22

Special-category data under Article 9 — health, biometric, genetic, racial or ethnic origin, political opinions, religious beliefs, sex life — is prohibited unless one of the Article 9(2) conditions applies. Ordinary consent under Article 6 is not enough; the condition has to come from Article 9(2).

Criminal-conviction and offence data under Article 10 is stricter still, and this is the point most tooling gets wrong: Article 10 has no consent route at all. It may be processed only under the control of official authority, or where authorised by Union or Member-State law providing appropriate safeguards. A ROPA that offers 'consent' as the basis for criminal-conviction data is recording an unlawful basis.

Automated decisions compound both. Under Article 22(4), a solely automated decision that produces legal or similarly significant effects and uses special-category data may rely only on Article 9(2)(a) explicit consent or Article 9(2)(g) substantial public interest — with suitable safeguards. The set of lawful bases collapses to two. Most ROPA tooling records the activity and stops; it does not surface that the basis has narrowed.

• Art. 9 special-category data — needs an Art. 9(2) condition, not ordinary consent
• Art. 10 criminal-conviction data — NO consent route; official authority or authorising law with safeguards
• Art. 22(4) automated decision on special-category data — only 9(2)(a) explicit consent or 9(2)(g) substantial public interest

What RINS.AI does about it

When a processing activity in the ROPA involves special-category data, criminal-conviction data, or a solely automated decision, RINS.AI flags it — so the recorded lawful basis is checked against the regime that actually applies, not the ordinary Article 6 menu. A criminal-conviction activity recorded against 'consent' is surfaced; an automated decision on health data is surfaced with the two-basis constraint attached.

Records link across the platform: a ROPA entry connects to the DPIAs, vendors, and evidence that relate to it, so the processing inventory stays a live system of record rather than a spreadsheet that ages the day it is filed.

• Art. 9 / 10 / 22 processing flagged in the ROPA
• Recorded lawful basis checked against the applicable regime
• ROPA entries linked to DPIAs, vendors and evidence

What it does not do

RINS.AI flags where a special regime applies and where the recorded basis looks wrong for it. It does not decide the correct lawful basis for you — whether a substantial-public-interest condition is met, or whether a Member-State law provides the safeguards Article 10 requires, is a legal determination the controller or its DPO makes. And it maps what is recorded: a ROPA is only as complete as the activities entered into it, and the platform does not discover processing happening in systems it cannot see.