What the GDPR actually requires from an authentication provider

Authentication is the densest concentration of personal data in most products. Every account is an identified natural person, every login is a processing operation, and the audit log is a behavioural record. It is also the system most often bought on a demo.

This is what the regulation actually says about that decision — not a summary of a summary, but the operative articles, quoted, with the practical consequence of each. No vendor here is named; the point is what to require of any of them.

You are the controller. The vendor is a processor.

This is not a formality — it decides who carries the obligations. You decide why users are authenticated and how; the provider acts on your instructions. That makes you the controller and them a processor, and Article 28 then governs everything between you.

Article 28(1) is unusually blunt about what choosing a processor obliges you to do:

“Sufficient guarantees” is a due-diligence duty on you, and it is not discharged by a vendor’s marketing page. It is discharged by documents: the processing agreement, the sub-processor list, the security measures, the certifications actually held.

Article 28: the seven things the contract must contain

Article 28(3) requires a written contract and specifies its content. A data processing agreement that omits any of these is not merely thin — it is non-compliant. In summary, the processor must:

1. process personal data only on the controller’s documented instructions, including on transfers to third countries;
2. ensure that persons authorised to process the data are under a duty of confidentiality;
3. take all measures required by Article 32 (security of processing);
4. respect the conditions in 28(2) and 28(4) for engaging another processor;
5. assist the controller in responding to data-subject requests;
6. assist with Articles 32 to 36 — security, breach notification, impact assessments;
7. delete or return all personal data at the end of the service, and make available the information needed to demonstrate compliance, including audits.

Sub-processors: the part nobody reads

Article 28(2) sets the rule:

Two practical tests follow. Is there a published sub-processor list, and is there a notice period and an objection right before it changes? A list without notice is a courtesy; a list with notice is a control. And read what is on it: an email provider, an error tracker or a support tool inside the authentication path is a sub-processor touching identity data, whatever the marketing calls it.

Article 32: what “appropriate security” means concretely

Article 32(1) does not leave the measures entirely to judgement — it names four, and each has a direct reading for a login system:

• Pseudonymisation and encryption of personal data. For authentication: credentials never stored recoverably, and identifiers not stored raw where a pseudonym would do.
• Ongoing confidentiality, integrity, availability and resilience of processing systems. Availability is in the regulation — an identity provider that is down is not merely inconvenient, it is a processing failure.
• The ability to restore availability and access in a timely manner after an incident. Tested restores, not just backups.
• A process for regularly testing, assessing and evaluating effectiveness. Penetration testing and audits on a cadence, with results you can see — not a badge on a website.

Note what Article 32 does not say: it never mentions a certification as sufficient. ISO 27001 and SOC 2 are evidence that a process exists. They are not a statement that your particular processing is appropriately secured, and no auditor has claimed otherwise.

Articles 17 and 20: erasure and portability are engineering requirements

Article 17 gives the data subject the right to obtain erasure without undue delay. For an identity system that is harder than it sounds: an account is not just a row. Sessions, refresh-token families, audit entries, MFA enrolments and recovery codes all reference the user, and an erasure that leaves live sessions behind has not erased anything meaningful.

Article 20 gives the right to receive personal data in a structured, commonly used and machine-readable format and to transmit it to another controller. This is the article that makes an export capability a legal matter rather than a feature request — and it is worth asking a prospective vendor to demonstrate the export, not describe it.

Article 33: seventy-two hours, and who starts the clock

The obligation is yours; the knowledge is often theirs. Article 33(2) requires the processor to notify the controller without undue delay — which is why the notification commitment in the contract matters more than the number in the marketing copy. A vendor that promises to tell you “promptly” has promised nothing measurable. Ask for a defined window, in writing.

Chapter V: the transfer question that will not stay settled

If any part of the authentication path — primary storage, a replica, a support tool, an on-call engineer’s access — puts personal data outside the EEA, Chapter V applies: an adequacy decision, or appropriate safeguards such as standard contractual clauses, plus an assessment of whether the destination’s law permits those safeguards to be honoured.

That last requirement is not an invention of cautious lawyers. It follows directly from the 2020 judgment that invalidated the Privacy Shield while upholding the standard contractual clauses — the combination that put the assessment burden on the exporter. The practical consequence is that a transfer you do not make is the only one you never have to defend.

The document checklist for a vendor review

Everything below is answerable from published documents. Where a vendor makes one hard to find, that is data too.

1. A data processing agreement covering all seven items of Article 28(3), available without a sales call.
2. A published sub-processor list, with a change-notice period and a stated objection right.
3. The governing-law clause of the terms of service — read it, do not assume it from the brand.
4. Where personal data is stored, and on which plan that guarantee applies.
5. A defined breach-notification window to you, in the contract.
6. A demonstrated export, including credential material, so Article 20 is real rather than theoretical.
7. Which certifications are held and their scope — and whether the certified entity is the vendor or their cloud provider.

We built Adetio so that most of that list is answered by architecture rather than by paperwork: processing under EU law, exports that include credential material so migration away from us is genuinely possible, and erasure that cascades through sessions and tokens rather than only the account row. The trust centre states what is in place today and what is planned, separately — because on this subject the difference between those two is the entire point.