Manage every client's processors against Article 28 — with an honest account of what a finding proves

What Article 28 requires of the controller

A controller may use only processors that provide sufficient guarantees to meet the GDPR (Art. 28(1)), governed by a data processing agreement carrying the Article 28(3) terms. Sub-processing is not free: a processor may not engage a sub-processor without the controller's prior authorisation (Art. 28(2)), and any sub-processor must be bound by the same data-protection obligations (Art. 28(4)).

For an MSP or consultancy this is the work — you are managing your clients' processors, one book of vendors at a time, and the exposure concentrates in the supply chain: most privacy failures originate with a sub-processor no one authorised.

• Art. 28(1) — sufficient guarantees before onboarding
• Art. 28(2) — prior authorisation for sub-processors
• Art. 28(3) — the required DPA terms
• Art. 28(4) — sub-processors bound by the same obligations

What goes wrong across a vendor base

At portfolio scale the failures are ones a single review misses. A vendor cleared once drifts out of date at renewal, when new sub-processors are added and terms are re-negotiated without another look. A DPA weakness — a general sub-processor authorisation with no notification, an audit right reduced to a questionnaire — is rarely unique to one vendor; it repeats across a book because vendors reuse the same templates. And the highest-risk vendors are not always the largest: a small processor handling special-category data for one client can outweigh a large one that never touches it.

Continuous re-assessment exists for exactly this: a vendor is not compliant because it passed once.

• Vendors drift out of date at renewal — new sub-processors, re-negotiated terms
• The same DPA weakness repeats across many vendors on shared templates
• Risk follows the data, not the vendor's size

How RINS.AI manages it

Vendors are created in a registry — you record the processors a client uses — and linked to the findings from that client's DPA scans and assessments. Risk is scored, DPA status is tracked, and re-assessment runs on a schedule so a vendor reviewed once does not quietly drift out of date. The registry is the system of record; findings attach to the vendors in it, and you see the highest-risk vendors first with clear remediation tasks and audit trails.

• Vendors created in the registry, then linked to findings
• DPA status and contract controls tracked per vendor
• Risk scoring and scheduled re-assessment
• Portfolio view across a client's whole vendor base

What a finding can and cannot tell you

This is where honesty matters more than marketing. When RINS.AI flags a sub-processor issue, the finding tells you one specific thing: the DPA is silent about its sub-processors — it does not name them, does not require prior authorisation, or does not bind them to Article 28(4). The evidence is prose about an absence in the contract.

It cannot tell you who the sub-processors are. A contract's silence is not a list; discovering that a vendor actually uses a particular sub-processor is a different exercise the document does not contain. Vendors are created in the registry by you and linked to findings — they are not discovered from the findings. A tool that claimed to surface an unnamed sub-processor's identity from a silent contract would be inventing it.