The GDPR right to erasure on sovereign infrastructure is the principle that an organisation can only guarantee complete and verifiable deletion of personal data when it retains full technical control over every storage layer involved, including live databases, file stores, AI inference logs, and encrypted backup snapshots. In a public cloud environment operated by a US-based hyperscaler, that control is structurally incomplete: the controller cannot inspect every replica, cannot guarantee that backup retention policies are honoured, and cannot produce technical proof of erasure that will satisfy a supervisory authority under Article 17 GDPR.
What Article 17 GDPR Actually Requires of a Controller
Article 17 GDPR imposes an obligation to erase personal data without undue delay when one of its grounds applies, including withdrawal of consent, completion of a contract, or a successful objection to processing. The obligation extends to all copies, all processors, and all sub-processors. Article 12(3) sets the deadline at one calendar month from receipt of the request, extendable by two further months in complex cases, with written notification required.
The most frequent misconception is that erasure means deleting a record from a primary database. In a modern infrastructure, a single personal data record may exist in a Nextcloud file share, a database, a full-text search index, an object storage backup, an AI context cache, and a centralised log. Each of these layers must be addressed individually, and the controller must be able to demonstrate that each was addressed. That demonstration is only reliable when the organisation controls the infrastructure directly.
EDPB CEF 2025 Findings: Where Organisations Are Failing
The EDPB Coordinated Enforcement Framework (CEF) is the mechanism by which national supervisory authorities conduct aligned investigations across EU member states. The CEF 2025 round focused specifically on the right of erasure under Article 17 GDPR.
The EDPB CEF 2025 Right to Erasure Report identified a consistent set of failure modes across audited organisations. The most prevalent were: absence of a documented erasure procedure, inability to identify all systems in which a data subject’s information resided, failure to extend erasure requests to processors and sub-processors, and no mechanism to verify that backup copies had been addressed. These failures are not primarily legal oversights; they are infrastructure gaps.
As Andrea Jelinek, former Chair of the European Data Protection Board, stated: “The right to erasure is not a paperwork exercise. Controllers must be able to demonstrate, with technical evidence, that data has been removed from every system in which it was stored.”
Sovereign infrastructure addresses each of these failure modes directly. A centralised identity and access management layer maps every data subject to every system where their data exists. Automated workflows trigger deletion requests across all connected services simultaneously. Audit logs capture each deletion event with a timestamp and a system identifier, producing a complete evidence chain for supervisory review.
Retention Schedules Across Nextcloud, Private AI, and S3-Compatible Backup Tiers
Defining and enforcing retention schedules under Article 5(1)(e) becomes significantly more complex when personal data flows across multiple sovereign system components. A practical sovereign architecture for a regulated organisation typically includes a Nextcloud file store, a relational database, a private AI inference layer running models such as Mistral or Llama, and an S3-compatible object storage tier with immutable backup snapshots locked via S3 Object Lock.
Each layer requires a distinct retention control, but all must be governed by a single retention policy. In Nextcloud, file-level metadata tags combined with automatic expiry rules enforce per-category retention periods. In the AI pipeline, inference logs and prompt histories are written to a structured log store governed by the same retention engine. The critical complication is the immutable backup tier: S3 Object Lock prevents deletion of objects during the lock period, which is a ransomware resilience measure, but creates a conflict with Article 17 if personal data sits in a locked snapshot.
The resolution is cryptographic erasure. Each backup object is encrypted with a unique per-object key managed by a key management server that the organisation operates on-premises. When an erasure request is received, the key management server deletes the key material for the objects associated with that data subject. The encrypted ciphertext remains in the immutable bucket but is computationally irretrievable without the key. This approach, implemented via S3 Object Lock cryptographic erasure, satisfies Article 17 without requiring modification of the immutable storage layer and preserves backup integrity for all other data subjects.
Proving Compliance Within the Article 12(3) One-Month Deadline
A supervisory authority examining an erasure complaint will look for a specific evidence set: the timestamped receipt of the request, a record of the systems queried, confirmation from each system that erasure was performed, handling of any backup copies, and the response sent to the data subject. Generating this evidence set within one month requires automation, not manual coordination across vendors.
Sovereign infrastructure operators implement this through a Data Subject Rights (DSR) workflow engine integrated with the identity directory. When a request arrives, the engine queries the data map, dispatches deletion commands to each registered system, collects confirmation receipts, and generates a consolidated evidence report. The same report is archived in a tamper-evident audit log that can be exported directly for supervisory submission. The one-month clock is visible in the system, and escalation triggers fire automatically if any sub-system has not confirmed within twenty days.
Ulrich Kelber, former Federal Commissioner for Data Protection and Freedom of Information in Germany, has noted: “Organisations that rely on third-party cloud services frequently discover, during an audit, that they cannot produce a complete map of where personal data resides, which makes meaningful erasure impossible.” This observation captures precisely why the data mapping precondition is not optional: without it, the erasure workflow has no defined scope.
Swiss FADP Article 32 and Dual-Jurisdiction Compliance
The revised Swiss Federal Act on Data Protection (FADP), in force since September 2023, introduced Article 32, which requires controllers to delete personal data when the purpose of processing has ended or when the data subject withdraws consent, mirroring the GDPR Article 17 structure closely. For organisations hosting infrastructure in Switzerland, both regimes apply concurrently when Swiss residents and EU residents are data subjects in the same system.
| Dimension | GDPR Article 17 | Swiss FADP Article 32 |
|---|---|---|
| Legal basis for erasure request | Six enumerated grounds including consent withdrawal, contract completion, objection | Purpose fulfilment or consent withdrawal; controller may also act on own initiative |
| Response deadline | One month under Article 12(3), extendable to three | No fixed statutory deadline, but without undue delay is required |
| Third-party processor notification | Explicit obligation under Article 17(2) | Implicit through general accountability principle |
| Supervisory authority | National DPA in relevant EU member state | Federal Data Protection and Information Commissioner (FDPIC) |
Swiss-hosted sovereign infrastructure satisfies both regimes through a single deletion workflow with dual-jurisdiction logging. The audit trail records which legal basis triggered the deletion (GDPR, FADP, or both), enabling the controller to respond to either supervisory authority with jurisdiction-specific evidence without maintaining parallel systems.
Account Deletion, Anonymisation, and Cryptographic Erasure: Which Satisfies Article 17?
These three approaches are frequently conflated, but they carry very different legal weight under GDPR.
Account deletion removes the authentication record and user profile but does not address the personal data that was created or processed while the account was active. It does not satisfy Article 17 on its own. Anonymisation, where personal identifiers are irreversibly removed or replaced such that re-identification is not reasonably possible, can satisfy Article 17 because the resulting data falls outside the GDPR’s material scope. However, genuine anonymisation is technically difficult to achieve: pseudonymisation, which replaces identifiers with tokens while retaining the mapping, does not qualify. The EDPB has consistently held that the anonymisation bar is high.
Cryptographic erasure, as described above in the context of S3 Object Lock, occupies a middle position. It does not produce anonymised data; the structure of the data remains intact but unreadable. Regulators in several member states have accepted it as a valid technical measure for backup tiers where physical deletion is structurally incompatible with immutability requirements, provided the key destruction is irreversible and documented.
The NIS-2 Directive (Directive 2022/2555) and DORA (Regulation 2022/2554) both impose audit log retention requirements that create a direct tension with Article 17: security logs containing personal data such as IP addresses and user identifiers must be retained for incident investigation, but they also fall within the scope of erasure rights. The resolution in a sovereign environment is to apply pseudonymisation to log entries at the point of writing, retaining the security event but breaking the link to the identifiable individual. The pseudonymisation key is stored separately and subject to the same erasure controls, meaning an Article 17 request can destroy the key without destroying the security audit trail itself.
According to the IBM Cost of a Data Breach Report 2023, the average cost of a data breach globally reached USD 4.45 million, the highest on record at that time. A significant portion of that cost in European cases derives from regulatory fines and remediation requirements directly related to failure to demonstrate adequate data governance, including erasure controls. The CMS GDPR Enforcement Tracker Report 2023 found that over 40 percent of GDPR fines cited insufficient technical or organisational measures as a contributing factor, a category that squarely covers erasure infrastructure failures.
FAQ
Does deleting a user account satisfy the GDPR Article 17 right to erasure?
No. Account deletion removes login credentials and a profile record, but leaves personal data in file stores, logs, AI caches, and backup snapshots. Article 17 requires erasure of the personal data itself, not the account container. Sovereign infrastructure allows organisations to trace and delete all data instances across every layer.
Can cryptographic erasure satisfy Article 17 GDPR for immutable backup tiers?
Yes, under specific conditions. If backup data is encrypted with a unique key that is then securely destroyed, the ciphertext becomes computationally irretrievable. This approach, implemented via S3 Object Lock combined with per-object key deletion, is recognised as an effective technical measure, provided the key management system is fully under the controller’s control and destruction is logged with a tamper-evident record.
How does Swiss FADP Article 32 differ from GDPR Article 17 in practice?
Both require deletion when purpose ends or consent is withdrawn. FADP Article 32 does not specify a fixed response deadline, whereas GDPR Article 12(3) mandates one month. For dual-jurisdiction deployments on Swiss-hosted sovereign infrastructure, a single deletion workflow with jurisdiction-tagged audit logging satisfies both laws without requiring parallel processes.
What evidence must an organisation present to prove it met the Article 12(3) one-month deadline?
Supervisory authorities expect a timestamped erasure request log, a workflow record covering each system queried, confirmation receipts from each storage layer including backups, and the response notification sent to the data subject. Sovereign infrastructure with centralised audit logging generates this evidence automatically; dispersed public cloud environments require manual cross-platform reconciliation that rarely produces a clean record within the deadline.
How should a private AI pipeline handle erasure requests for personal data used in prompts?
Prompt history, model context caches, and any fine-tuning datasets containing personal data must be covered by the same retention and erasure schedule as other personal data. In a sovereign deployment running models such as Mistral or Llama on-premises, the organisation controls inference logs and can delete them per data subject. Public cloud AI services may retain prompt data under terms that conflict directly with Article 17 obligations.