GDPR shared-responsibility matrix

Draft. This page draws the GDPR legal-role and shared-responsibility line for the identity platform: who is the controller, who is the processor, and how each obligation splits between the two delivery models. It complements the infra-oriented shared-responsibility table on the security index — that table covers who runs the substrate; this one covers who owns which GDPR obligation. Every row is grounded in the code or ADR named in the sources above.

The controller-vs-tooling boundary

The single most important thing a compliance reviewer needs to understand about Thoryn's role:

• The tenant is always the data controller. The tenant decides the purposes and means of processing its users' personal data. That decision is the controller's, and Thoryn does not make it.
• Thoryn provides tooling, not the controllership. The platform is the instrument the controller uses to authenticate its users, honour data-subject rights, retain and age out records, and demonstrate accountability. On the managed sovereign SaaS, Thoryn also acts as a processor — it processes personal data on the tenant's documented instructions under an Art. 28 processing agreement. On a self-managed deployment the tenant runs the identical artefacts itself, so the tenant is both controller and (internal) processor, and Thoryn is neither.
• The generated Art. 30 record is a starting point, never a substitute. The GET /api/v1/compliance/records-of-processing export is generated from platform configuration and derivable facts (OAuth scopes, retention windows, the configured sub-processor list). It gives the controller a grounded first draft of its record of processing activities — the controller reviews and completes it. It does not discharge the controller's own Art. 30 duty.

This boundary is why the platform never claims to erase data it does not hold: when a relying party (a separate controller) stores personal data downstream, only that party can erase it. The platform erases the state it controls and can signal offboarding, but it does not assert control it does not have.

Where personal data lives

Because the hub is a pure identity broker, it owns no user profiles — personal data lives with the identity member that owns it. That is data-minimisation by architecture (Art. 5(1)(c)), not by policy, and it shapes every row below: the platform's processor surface is deliberately small.

The obligation matrix

GDPR obligation	Legal roles	Managed sovereign SaaS	Self-managed
Controllership — purposes and means of processing	Tenant = controller	Tenant decides; Thoryn never does	Tenant decides
Processor role (Art. 28)	Thoryn = processor (managed only)	Thoryn processes on the tenant's documented instructions, under a processing agreement	Tenant operates the platform itself; no external processor
Lawful basis and purposes (Art. 6, 30(1)(b))	Controller	Tenant sets the basis; the platform surfaces derived purposes from OAuth scopes	Same tooling, tenant-operated
Records of processing (Art. 30)	Controller	Platform generates a grounded draft (/api/v1/compliance/records-of-processing); tenant reviews and completes	Same tooling, tenant-operated
Right of access / DSAR (Art. 15)	Controller decides; platform executes	Tenant initiates; the multi-source DSAR fan-out assembles a tenant-signed bundle	Tenant initiates; tenant runs the fan-out
Right to erasure (Art. 17)	Controller decides; platform executes	Tenant initiates; the platform erases the state it holds and writes an erasure receipt	Tenant initiates; tenant-operated
Consent lifecycle (Art. 7)	Controller	Tenant records and withdraws consent through the platform	Same tooling, tenant-operated
Retention / storage limitation (Art. 5(1)(e))	Controller sets the window	Tenant configures the per-tenant retention window; the platform ages data out on schedule	Tenant configures; tenant-operated schedules
Security of processing (Art. 32)	Both, per role	Thoryn operates the crypto backend, per-tenant signing keys, tamper-evident audit, TLS	Tenant operates the identical hardened artefacts
Key custody	Processor (managed) / controller (self-managed)	Vault/OpenBao Transit operated by Thoryn; keys never leave it; production seal is KMS/HSM auto-unseal	Tenant operates the backend; must use a KMS/HSM production seal (not the staging Secret-stored key)
Sub-processors (Art. 28(2)/(4))	Controller authorises; processor discloses	Thoryn declares its sub-processors (config-driven, in the Art. 30 export)	Tenant chooses its own infrastructure; declares its own
International transfers (Art. 44–46)	Controller	Processing in the configured EU/EEA region; transfers covered by declared safeguards	Tenant chooses its region and safeguards
Breach / incident reporting (Art. 33/34; NIS2)	Controller notifies authority	Shared — Thoryn detects and logs incidents (SecurityIncident, reportedToAuthority); tenant owns the supervisory-authority notification	Tenant detects, logs, and notifies

What the platform provides as tooling

Each obligation above is backed by a real product surface, not a promise:

• Art. 30 records of processing — GET /api/v1/compliance/records-of-processing (scope tenant:compliance.read) generates the tenant's record from platform config and derivable facts. Purposes derive from the OAuth scope catalogue today; tenant-specific, purpose-based consent enrichment (ISO/IEC TS 27560) is a follow-up under SSO-2500.
• Art. 15 access / DSAR — the multi-source fan-out and tenant-signed bundle (DsarOrchestrator), described on the privacy & compliance page.
• Art. 17 erasure — the identity-member erasure with a hash-of-id receipt, plus the conditional two-phase erasure workflow (SSO-2509).
• Art. 5(1)(e) retention — the per-tenant TenantAuditRetentionService window, aged out by the retention sweep.
• Accountability (Art. 5(2), 30) — the tamper-evident, hash-chained, signed audit trail.
• Incident lifecycle (NIS2) — the per-tenant SecurityIncident record with a reportedToAuthority flag.

The GDPR Trust Center aggregates these into one per-tenant view.

Sources: ADR 2026-08-11-gdpr-trust-center-and-consent-records.md; RecordsOfProcessingService.kt, RecordsOfProcessingProperties.kt (product-api); DsarOrchestrator.kt, TenantAuditRetentionService.kt, compliance/incident/SecurityIncident.kt; CLAUDE.md → "Reproducible deployments" and the customer-plane boundary.