Review every client's DPAs against Article 28 — not one contract at a time

What Article 28 actually requires

Article 28 governs the relationship between a controller and its processors. A controller may only use processors that provide 'sufficient guarantees' (Art. 28(1)); a processor may not engage a sub-processor without the controller's prior authorisation (Art. 28(2)); and the processing must be governed by a written contract — the DPA — containing a specific set of terms (Art. 28(3)).

Those terms are not optional boilerplate. Article 28(3) requires, among others, that the processor act only on documented instructions (a), impose confidentiality (b), take Article 32 security measures (c), respect the conditions for engaging sub-processors (d), assist with data-subject requests (e), assist with breach notification and DPIAs (f), delete or return the data at the end of the engagement (g), and make available the information needed to demonstrate compliance — including submitting to audits and inspections (h).

• Art. 28(2) — no sub-processor without prior authorisation
• Art. 28(3)(g) — delete or return the data at the end of processing
• Art. 28(3)(h) — audit and inspection rights
• Art. 28(4) — sub-processors bound by the same obligations

What goes wrong in real contracts

Most DPAs are not missing — they are quietly weakened, and the failures repeat across a client book. That consistency is why reviewing at scale finds more than spot-checking one vendor.

One example is worth naming because it is so common: a '24-hour breach notification' clause is frequently attributed to the GDPR. It is not a GDPR requirement — Article 33 gives a controller 72 hours to notify a supervisory authority, and a processor's notification deadline is whatever the contract sets. A DPA that cites 'the GDPR's 24-hour rule' is quoting a rule that does not exist, which tells you the drafter worked from a template rather than the text.

• Sub-processors permitted without prior authorisation (contradicts Art. 28(2))
• Indefinite retention — no deletion or return at the end (contradicts Art. 28(3)(g))
• Audit rights refused, or narrowed to a self-assessment questionnaire (contradicts Art. 28(3)(h))
• International transfers allowed 'where commercially practicable' — wording that defeats Chapter V
• A 24-hour breach clause misattributed to the GDPR (the GDPR sets 72 hours for the controller, not 24)
• Automated decision-making on individuals with no right to human review (contradicts the Art. 22 safeguards) — the clause a template-based review most often misses

What RINS.AI does about it

RINS.AI reads each DPA and checks it clause by clause against the Article 28(3) requirements. Where a required clause is absent it is flagged as a gap; where it is present but weakened — a sub-processor 'general authorisation' with no notification mechanism, an audit right reduced to a questionnaire, a transfer clause hedged with 'commercially practicable' — it is flagged as a finding, quoting the clause text that triggered it.

Each finding becomes a control in that client's library, so a book of fifty clients produces fifty control sets from fifty scans rather than fifty manual reviews. The output is a review summary and a risk score with an auditable record of what was accepted, rejected, or sent back for negotiation.

• Clause coverage checked against Art. 28(3)(a)–(h)
• Findings quote the clause text that triggered them
• Per-client control library built from the findings
• Auditable record of accept / reject / renegotiate

What it does not do

RINS.AI reviews the text of the agreement. It does not verify the processor's actual practice: a clause granting audit rights tells you the contract is sound on paper, not that the processor would pass an audit. It does not negotiate or sign — it produces the findings a privacy lawyer or DPO uses to make the call, and the decision, with its rationale, is recorded against the client. It is a review tool, not legal advice.