Which legal design options exist for giving an IAM a data-protection basis, and where does each fit?
IAM as a processor (only for simple set-ups), joint controllership (suited to large groups but little practice yet), explicit consent (mostly B2C), and other contractual arrangements (employment contracts for B2E, cooperation agreements for B2B).
| Option | What it means | Fits | Caveat |
|---|---|---|---|
| IAM as processor (Auftragsverarbeiter) | The IAM processes data on behalf of and on instruction from each data owner | Simple, single-client set-ups | Unsuitable for larger, cross-cutting scenarios; the IAM has no room to act on its own |
| Joint controllers (Gemeinsame Verantwortliche, Art. 26 GDPR) | The parties jointly decide purpose and means and lay down who does what in an arrangement | Large groups with a central IAM | Relatively new for IAM, little practical experience |
| Explicit consent (Einwilligung) | Each person agrees to the processing | Mostly B2C (customer accounts) | Must be voluntary, informed and can be withdrawn |
| Other contractual arrangements | Employment contract (B2E), cooperation agreement (B2B) | Employees, partners | Do they actually cover IAM processing, or do they need additions? |
For the contract-based options the crucial question is whether the existing regulation really covers the IAM or needs to be supplemented, because those contracts were usually written for payroll or for the business deal, not for central identity management.
The overall advice is pragmatic: analyse the data-protection situation thoroughly, then get legal advice. The options are legal constructions with real liability attached, not configuration choices.
Go deeper:
EDPB Guidelines 07/2020 on controller and processor — the EU regulators' guidance on telling controllers, joint controllers and processors apart.- ICO: What are controllers and processors? — a plain-language explanation of the roles.