Designing Systems That Can Honor Right to Be Forgotten Requests in Minutes

What Is the Right to Be Forgotten?

The right to be forgotten is the legal right of an individual to request that an organization erase their personal data. Under GDPR Article 17, a data subject can demand deletion when the data is no longer necessary for its original purpose, when consent has been withdrawn, when the data has been unlawfully processed, or when erasure is required to comply with a legal obligation. The controller must act "without undue delay," as required by the regulation.

This right to be forgotten definition matters because it is not simply a right to have a record removed from a single database. GDPR Article 17 requires the controller to take "reasonable steps" to inform other controllers processing the same data. In practice, this means erasure must cascade across every system, backup, replica, and third-party processor that holds the individual's data.

The EU right to be forgotten, as established in the 2014 Google Spain ruling and codified in GDPR, remains the most expansive version of this right globally. But it is not the only one. The right to be forgotten law now extends, in varying forms, across multiple jurisdictions.

Does the Right to Be Forgotten Exist in the USA?

The right to be forgotten in the USA does not exist as a single federal right. However, the California Consumer Privacy Act and its amendment, the CPRA, grant California residents a "right to delete" that functions similarly. The CCPA right to delete is narrower than GDPR Article 17, with multiple business exemptions that allow controllers to retain data for legal claims, security, and certain internal uses.

Virginia, Colorado, Connecticut, and several other states have enacted their own deletion rights with varying scope and exemption structures.

The practical consequence for any organization operating across borders is clear: deletion rights exist in multiple jurisdictions, each with different triggers, timelines, and exemption logic. A right to be forgotten request from a French data subject and a deletion request from a California consumer may arrive on the same day, governed by different rules, and both must be fulfilled correctly.

The Scale That Breaks Manual Processes

Most organizations treat right to be forgotten requests as a workflow. A request arrives and a ticket is created, then someone in privacy operations identifies the relevant systems, engineers are assigned to locate and delete the data, a confirmation is sent, and the ticket is closed.

This workflow-based approach has three structural weaknesses that compound at scale.

Data discovery is incomplete. When an organization receives a right to be forgotten request, the first task is identifying every system that holds the individual's data. In a typical Series B to D SaaS company, personal data may reside in a primary application database, an analytics warehouse, a CRM, a marketing automation platform, email logs, event streams, third-party integrations, and multiple backup systems. Manual discovery consistently misses secondary and tertiary data stores. Engineers search the systems they know about, not the systems that actually hold data.

Deletion is inconsistent. Even when data is located, manual deletion processes vary by system. One engineer may hard-delete records from a PostgreSQL database. Another may soft-delete from an analytics warehouse, leaving the data recoverable. A third may not have access to the backup system at all. The result is partial erasure that violates the "without undue delay" standard and leaves the organization exposed to regulatory scrutiny.

Verification is absent. After manual deletion, most organizations lack a systematic way to verify that erasure was complete. The ticket is closed based on engineer attestation, not technical confirmation. There is no audit trail that demonstrates, system by system, what was deleted, when, and whether any records remain.

The European Data Protection Board's enforcement actions have identified recurring implementation gaps in how organizations handle erasure requests. Among the most common: incomplete identification of data stores, failure to propagate erasure to processors, and inadequate verification of deletion. These are not policy gaps but infrastructure gaps that no amount of documentation can close.

How Does the Right to Be Forgotten Work in Practice?

The right to be forgotten works, in theory, through a defined sequence: the data subject submits a request, the controller verifies the subject's identity, determines whether an exemption applies, locates all relevant data, executes deletion across every applicable system, and confirms completion to the data subject. In practice, most organizations execute this sequence manually, with significant latency at every step. Identity verification alone can take days. Data discovery can take weeks, and confirmation is often a best-effort estimate rather than a verified fact.

Infrastructure-First RTBF: Designing for Erasure as a Native Capability

The reframe is straightforward. The right to be forgotten is not a compliance workflow to be optimized. It is an infrastructure capability to be built. When erasure logic is embedded in the data infrastructure itself, every step of the RTBF sequence becomes automated, verifiable, and repeatable.

Ethyca's privacy infrastructure, built on the Fides open-source framework, treats erasure as a first-class operation in the data layer. Rather than bolting deletion processes onto existing systems after the fact, Fides enables organizations to define erasure policies that execute natively across their entire data architecture. This is the difference between asking engineers to manually chase data across systems and having the infrastructure execute erasure programmatically, with full audit trails, every time a valid request is received.

When erasure and data subject request fulfillment are treated as infrastructure rather than as tickets, operational scale becomes possible. Organizations shift from reactive, engineer-dependent workflows to deterministic, policy-driven execution that can absorb growing request volumes without proportional increases in headcount.

Data Inventory and Classification: The Foundation for RTBF

You cannot delete what you cannot find. This remains the most basic and most frequently violated principle of right to be forgotten compliance.

Helios continuously inventories and classifies data across an organization's systems, ensuring that when a right to be forgotten request arrives, the infrastructure already knows where that individual's data lives. This is not a one-time data mapping exercise. Data environments change constantly as new services are deployed, new integrations are added, and data flows shift. A static data map becomes inaccurate within weeks. Continuous, automated discovery ensures that RTBF requests target all relevant records, not just the primary databases that engineers happen to remember.

Accurate classification also determines how erasure should be executed. Some records require hard deletion. Others require de-identification. Some are subject to legal holds or regulatory retention requirements that create valid exemptions under GDPR Article 17 or the CCPA. Without granular classification, organizations cannot make these determinations programmatically. They default to either over-deleting, which destroys data they are legally required to retain, or under-deleting, which leaves personal data in systems it should have been removed from.

Automating RTBF Requests Across Systems

Once data is inventoried and classified, the next infrastructure requirement is automated execution. Lethe automates data subject request fulfillment, including deletion and de-identification, across all connected systems. When a valid right to be forgotten request is received, Lethe orchestrates erasure across every data store identified by Helios, executes the appropriate deletion or de-identification action for each record type, and generates a verifiable audit trail of every action taken.

This automation eliminates the three structural weaknesses of manual processes. Discovery is handled by the data inventory, not by individual engineers. Deletion is consistent because the same erasure logic executes across every system. Verification is built into the process because every action is logged and auditable.

The operational impact is significant. Organizations that previously required days or weeks to fulfill a single right to be forgotten request can execute the same process in minutes. At enterprise scale, this translates directly into reduced operational cost and faster regulatory response times.

Policy Enforcement and Consent: Ensuring RTBF Is Respected Everywhere

Erasure is not a one-time event. After an individual exercises their right to be forgotten, the organization must ensure that the individual's data is not re-collected, re-processed, or re-shared in violation of the erasure request. This requires consent and policy logic that persists across every system and every data flow.

Janus orchestrates consent and preference logic across distributed systems, ensuring that when an individual's data is erased, their consent state is updated everywhere that data was previously processed. This prevents the common scenario where an individual's data is deleted from the primary database but continues to be processed by a downstream marketing system or analytics pipeline that never received the erasure signal.

Astralis applies policy enforcement directly to AI systems to ensure that right to be forgotten requests are respected even in dynamic or unstructured data environments. As organizations adopt more complex data architectures, including real-time event streams, machine learning pipelines, and multi-cloud deployments, the surface area for RTBF enforcement expands. Policy enforcement must operate at the infrastructure level, not as a manual check performed after the fact.

Together, these systems create a closed loop: data is inventoried, erasure is executed, consent state is updated, and policy enforcement ensures that the erasure decision is respected across every subsequent data operation. This is what it means to treat the right to be forgotten as infrastructure rather than process.

Why Is the Right to Be Forgotten Important?

The right to be forgotten matters because it operationalizes a foundational privacy principle: that individuals retain control over their personal data even after they have shared it. For organizations, honoring this right at scale is a direct signal of data governance maturity. It demonstrates that the organization knows where personal data lives, can act on it programmatically, and can verify that actions were completed. These same capabilities underpin every other privacy right, from access requests to data portability to consent management. An organization that can execute RTBF reliably has built the infrastructure to handle any data subject request.

When RTBF Infrastructure Works, What Becomes Possible

When the right to be forgotten is treated as an infrastructure capability, the immediate benefit is operational. Requests that previously consumed engineering hours are fulfilled automatically. Audit trails are generated without manual documentation. Regulatory timelines are met consistently, not aspirationally.

But the second-order effects are more consequential.

Organizations with infrastructure-level RTBF can commit to faster SLAs with confidence, because fulfillment is deterministic rather than dependent on individual engineer availability. They can enter new markets with different deletion requirements, because the same infrastructure adapts to different regulatory logic without rebuilding processes from scratch. They can respond to regulatory inquiries with complete, system-generated evidence of every erasure action taken, rather than assembling documentation after the fact.

Most importantly, they can build new products and data capabilities without accumulating governance debt. When erasure is a native capability of the data layer, every new system, integration, and data flow inherits that capability automatically. Teams can move quickly because they are operating within clearly defined boundaries that are technically enforced, not just documented in policy manuals.

The right to be forgotten is often discussed as an obligation. It is. But it is also a design constraint that, when met at the infrastructure level, produces better data architecture, faster operations, and genuine trust with the individuals whose data an organization holds.

The organizations that will operate with the most confidence in the years ahead are not those with the most detailed compliance documentation. They are the ones whose infrastructure can execute a right to be forgotten request in minutes, verify it completely, and ensure it is respected across every system every time.