AI Calling Compliance · Updated 16 July 2026

GDPR & CCPA Erasure on Request for Outbound Contact Data (2026)

When a contact asks to be erased, the obligation is to delete their personal data — not to flag it, hide it, or park it in a “deleted” state that still answers queries. GDPR Article 17(1) grants erasure “without undue delay”; Article 12(3) fixes that at one month from receipt. The CCPA grants the same right at Cal. Civ. Code § 1798.105, with 45 days to respond.

For outbound contact data the analysis is simpler than it looks. Article 21(2) gives an unconditional right to object to direct marketing — no balancing test, no legitimate interest to weigh — and Article 17(1)(c) converts that objection into an erasure obligation. On a marketing list, an opt-out and an erasure request are the same duty.

The hard part is not the deletion. It is the paradox underneath it: a promise never to contact someone again is itself a fact about that someone. Delete every trace and the next purchased lead list re-imports them tomorrow. Keep the record and you have not erased anything. The resolution — the ICO’s, and the one Veera implements — is to erase the person and retain a one-way hash: enough to recognise the identifier, not enough to reconstitute the human. Everything below is downstream of that distinction.

What Article 17 actually requires

Article 17(1) of Regulation (EU) 2016/679 states that the data subject “shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay,” and the controller “shall have the obligation to erase personal data without undue delay” where one of six grounds applies. The grounds that matter for an outbound contact list are three:

17(1)(a) — the data are no longer necessary for the purposes for which they were collected. A prospect who will never be contacted again is, definitionally, no longer necessary for outreach.
17(1)(b) — consent is withdrawn and no other legal ground supports the processing. Where a campaign runs on consent rather than legitimate interest, the withdrawal removes the floor the processing was standing on.
17(1)(c) — the data subject objects under Article 21. This is the one that governs marketing data, and it is the reason erasure in outbound is not a close call.

The distinction inside Article 21 is where most of the misreading happens. An objection under Article 21(1)— on grounds relating to the data subject’s particular situation — can be resisted: the controller may continue processing where it “demonstrates compelling legitimate grounds for the processing which override the interests, rights and freedoms of the data subject.” That is a balancing test, and controllers sometimes win it.

Article 21(2)works differently. “Where personal data are processed for direct marketing purposes, the data subject shall have the right to object at any time to processing of personal data concerning him or her for such marketing.” Article 21(3) supplies the consequence: “Where the data subject objects to processing for direct marketing purposes, the personal data shall no longer be processed for such purposes.” No compelling-grounds escape hatch appears anywhere in the paragraph. The objection is dispositive on receipt, and Article 17(1)(c) routes it straight into an erasure obligation.

Two further provisions carry operational weight. Article 12(3)turns “without undue delay” into a number: one month from receipt of the request, extendable by two further months where the request is complex or numerous — but only if the controller informs the data subject of the extension, with reasons, inside the first month. An unannounced extension is not an extension; it is a missed deadline. Article 19then pushes the request downstream: the controller “shall communicate any rectification or erasure of personal data … to each recipient to whom the personal data have been disclosed, unless this proves impossible or involves disproportionate effort,” and must identify those recipients to the data subject on request. For an agency whose contact data has been synced into a CRM, an enrichment tool, and a dialer, Article 19 is the provision that makes erasure a distributed problem rather than a local one.

Article 17(3) preserves the exceptions — processing necessary for freedom of expression, for compliance with a legal obligation, for public-health or archiving purposes, or for the establishment, exercise, or defence of legal claims. None of these rescue a marketing list. They rescue the invoice, the tax record, and the litigation hold, which is why erasure of contact data and retention of transaction records routinely coexist for the same person.

What the CCPA and CPRA require, and where they diverge

Cal. Civ. Code § 1798.105 gives a consumer the right to request that a business delete personal information the business collected from them. § 1798.105(c) extends the request outward: a business that receives a verifiable consumer request must delete the information from its own records and direct any service providers to delete it from theirs— and under the CPRA amendments a service provider or contractor must, at the business’s direction, delete the information and notify its own service providers and contractors to do the same. The implementing regulation, Cal. Code Regs. tit. 11, § 7022(b)(3), adds third parties: the business must notify all third parties to whom it sold or shared the data, unless that proves impossible or involves disproportionate effort.

Then comes the divergence that matters most for engineering. § 7022(b)(1) permits a business to comply by any of three methods: permanently and completely erasing the personal information from its existing systems except archived or backup systems, deidentifying it, or aggregating it. The GDPR offers no such menu. Article 17 says erasure, and the EDPB has explicitly flagged weak anonymisation offered in place of deletion as a compliance failure — not an alternative route to compliance.

The practical consequence is worth stating plainly: a deletion pipeline built to CCPA § 7022 can pass in California and still fail Article 17 in Europe. Deidentification and aggregation are compliant answers to a Californian request and insufficient answers to a European one. Building to the stricter obligation on each axis — GDPR’s method, GDPR’s clock, the CCPA’s explicit downstream notification duties — satisfies both without maintaining two pipelines.

Axis	GDPR	CCPA / CPRA
Governing rule	Article 17	Cal. Civ. Code § 1798.105
Deadline	1 month, +2 months if notified (Art. 12(3))	45 days, +45 if notified (§ 1798.130(a)(2))
Permitted method	Erasure only	Erase, deidentify, or aggregate (11 CCR § 7022(b)(1))
Backups	No express carve-out; documented, proportionate approach expected	Archived/backup systems expressly excepted
Downstream duty	Notify each recipient (Art. 19)	Direct service providers; notify third parties (§ 1798.105(c), 11 CCR § 7022(b)(3))
Marketing objection	Absolute; no balancing test (Art. 21(2)–(3))	Separate opt-out of sale/sharing (§ 1798.120)

Erased, not parked: what actually counts

“Parked” is the polite name for data that has been marked deleted and retained anyway. It is the default outcome of almost every deletion feature built without a compliance requirement, because soft deletion is the safer engineering choice everywhere else in a system — reversible, auditable, cheap. Under Article 17 it is the wrong one. Four shapes recur:

1.The soft delete. A deleted: true column. The personal data is intact, still resolves to a named individual, and is still processed every time a query touches the row. A retention decision wearing a deletion label.
2.The pseudonymisation swap. Fields masked to j***@acme.com and declared anonymous. The EDPB found controllers relying on exactly this and named it a failure: techniques that do not prevent re-identification are not erasure, whatever they are called internally.
3.The identifier in the key. The fields are cleared and the document id is csv__jane%40acme.com. Deleting the contents of a record whose primary key is the email address erases nothing — the identifier is recoverable with a URL-decode. Keys, indexes, and log lines are PII channels that field-level deletion never touches.
4.The resurrection. The record is genuinely deleted, and returns on the next CRM sync, CSV re-import, or purchased list. The deletion was real and the outcome is identical to never having deleted at all, because nothing in the system remembers that the erasure happened.

The fourth is the one specific to outbound, and the one that makes erasure architecturally different from a delete button. Contact data in an agency stack is not stored once. It arrives from a CRM, a scrape, a CSV, a partner, and a broker, and each of those sources will re-supply it. A deletion that does not survive the next sync is a deletion with a shelf life measured in hours.

Backups deserve an honest answer rather than a confident one. The GDPR contains no backup exception, and the EDPB’s February 2026 findings recorded difficulties with backup deletion among the most common problems controllers reported — ranging from having no procedure at all to relying on overwrite cycles with no documented rationale. The defensible position is not a claim that backups are instantly purged; it is a documented, reasoned, proportionate approach — erased from live systems immediately, aged out of backups on a stated cycle, and never restored to production without re-applying the erasure. The CCPA is more forgiving here and says so in the regulation text, which is precisely why a CCPA-shaped pipeline is not automatically a GDPR-shaped one.

The suppression paradox: remembering someone you erased

Here is the contradiction at the centre of erasure in outbound. The data subject asks for two things at once: delete my data, and never contact me again. Honouring the second requires remembering the first. If the system forgets the person completely, the next lead list containing their address will be imported, enrolled, and dialled — and the erasure will have caused the harm it was meant to prevent.

The ICO addresses this head-on in its direct marketing guidance. Where someone no longer wants their information used for direct marketing, the guidance is to put their details on a suppression or “do not contact” list instead of deleting them, retaining just enough information to ensure the preference is respected in future — and it warns explicitly that you must not simply delete their details altogether, because they could later be put back on a marketing list by mistake, for example if you buy more leads that include the same details. The ICO also notes that there is no automatic right to have information on a suppression list deleted, because the list is not used for direct marketing purposes: it is kept to comply with the objection.

That resolves the legal question and hands engineering a precise one: what is the least you can retain and still recognise an identifier you have never seen again? The answer is a one-way cryptographic hash of the normalised email address or phone number. Suppression asks exactly one question — have I seen this identifier before — and a hash answers it without storing the identifier. Nothing in the suppression record reads back as a person, enumerating the list yields nothing, and the check is a single lookup at write time and send time.

One honest caveat, because it is routinely overstated in vendor copy: a hash of an email address is pseudonymous, not anonymous. Anyone who already suspects a specific address can hash it and confirm the match. That is not a defect — it is the mechanism, since checking membership is the entire purpose — but it means a suppression hash is still personal data under the GDPR and still belongs inside the security and retention perimeter. What the hash buys is minimisation and non-recoverability from the record itself, which is what the ICO’s “just enough” means when it is written down in code.

Penalties and the 2026 enforcement climate

Erasure sits in the GDPR’s upper fining tier. Article 83(5) subjects infringements of the data subject rights in Articles 12 to 22 to administrative fines of up to €20,000,000 or, for an undertaking, up to 4% of total worldwide annual turnover of the preceding financial year — whichever is higher. Article 17 is in that range because it is a data subject right, not because regulators treat deletion as exotic.

Enforcement attention arrived on schedule. Throughout 2025 the European Data Protection Board ran its Coordinated Enforcement Framework action on the right to erasure — the most frequently exercised GDPR right, and one of the most complained about. The results, published 18 February 2026, cover 32 data protection authorities and 764 controllers from SMEs to large enterprises and public bodies. Nine authorities opened new formal investigations or continued existing ones; 23 carried out fact-finding exercises. The report identified seven recurring challenges, and the list reads like a specification for what to build: absent internal procedures for handling requests, insufficient information given to individuals, inefficient anonymisation used in place of deletion, inconsistent practices, difficulty determining retention periods, difficulty deleting from backups, and difficulty assessing the conditions and balancing tests for the right.

California runs two enforcement tracks that carry the same numbers under different labels, and the labels are not interchangeable. Cal. Civ. Code § 1798.155(a) sets an administrative fine of up to $2,500 for each violation, or $7,500for each intentional violation or violations involving the personal information of consumers the business “has actual knowledge are under 16 years of age” — assessed in an administrative enforcement action brought by the California Privacy Protection Agency. § 1798.199.90(a)is the Attorney General’s track: an injunction plus a civil penaltyat the same $2,500 and $7,500, assessed and recovered in a civil action brought in the name of the people of the State of California. The enhanced tier is not worded identically across the two — the Attorney General’s provision reaches “each violation involving the personal information of minor consumers,” without the actual-knowledge and under-16 qualifiers that narrow the Agency’s. Both figures adjust for inflation under § 1798.199.95(d); the adjustment effective 1 January 2025 raised them to $2,663 and $7,988. As with per-call TCPA damages, the arithmetic is per-violation, so a batch failure multiplies across every record in it.

Anyone sourcing outbound contact data should also track California’s Delete Act (SB 362). Its Delete Request and Opt-out Platform (DROP) opened to California residents on 1 January 2026, letting a consumer direct every registered data broker to delete their personal information through a single verifiable request. From 1 August 2026, registered data brokers must retrieve DROP requests at least every 45 days and process them, with failures carrying a $200 administrative fine per deletion request per day under Cal. Civ. Code § 1798.99.82(d)(1), in an administrative action brought by the Agency. The mechanism matters even to businesses that are not data brokers: it means purchased lead lists will increasingly carry deletion obligations that originated upstream, and a buyer who re-imports a record its broker was ordered to delete has reintroduced exactly the data the consumer removed.

How Veera erases contact data

Veera honours erasure requests on the data it holds, and the design target is the distinction this page is about: the request is honoured, not parked. An organisation owner can erase a contact by email address or phone number from Settings › Privacy, behind a typed confirmation, and the erasure is irreversible by design rather than by policy. Five properties do the work:

1.The tombstone is written first, before any deletion. A hashed erasure marker lands at both organisation and client scope before a single record is resolved or removed. Ordering is the safety property: a crash part-way through the cascade still leaves the identifier blocked at send time and at re-import time. The failure mode of a delete-first design is an identifier that is half-erased and fully contactable.
2.The cascade reaches every collection that holds their data, not one. Contacts, messages, calls — which hold the full call transcript — enrollments, sequence events, appointments, notifications, sync conflicts, un-imported discovered leads that were never promoted into the contact list, and the AI-inference and correction records tied to each contact. Leads are matched on both the raw and the normalised form of the identifier, because the discovery worker writes addresses verbatim and an equality-on-normalised query would silently miss them.
3.The document id is treated as PII. A CSV-imported contact can live under a key that encodes its own email address. Veera deletes the original document rather than blanking it, and writes the terminal marker under an opaque SHA-256 id — so no identifier survives in any field or in the id. This was a real defect caught by an internal red-team pass, not a hypothetical: the email was recoverable from the document id after a nominally successful erasure.
4.Re-ingestion is blocked at a single choke point. Every contact write path — CRM backfill, webhook, poll, Sync Now, CSV import, discovery promotion — funnels through one function that checks the erasure tombstone and refuses the write. This is the ICO’s warning implemented: buying more leads containing the same details cannot resurrect an erased person.
5.The tombstone cannot be lifted, and stores no identifier. It is keyed by a SHA-256 hash of the normalised identifier, and an operator attempting to remove an erasure suppression is refused before the delete executes — erasure is a right the data subject exercised, not an operator preference. The audit record carries hashes only; no raw identifier is persisted after the erasure. A second erasure of the same contact is a counted no-op.

Scope, stated honestly. Veera’s AI voice calling is live today; SMS, WhatsApp, and email outreach are being built and activated, with in-call WhatsApp document delivery — sending a brochure or quote during a live call — the one send path already running alongside voice. Erasure covers the contact data Veera holds. It does not reach into systems Veera does not control: because Veera syncs into the CRM an agency already runs rather than replacing it, an erasure in Veera blocks re-ingestion from that CRM but does not delete the record inside GoHighLevel or HubSpot. Under GDPR Article 19 and Cal. Civ. Code § 1798.105(c), propagating the request to those systems remains the controller’s responsibility, and Veera’s job is to make sure the record never comes back through the sync. Veera also enforces TCPA quiet-hours on every call and CAN-SPAM one-click unsubscribe with suppression checked before every send.

None of this is a certification. Veera does not claim to be GDPR-certified or fully GDPR-compliant — compliance is a property of an organisation’s whole processing operation, not of one vendor’s feature, and erasure is one obligation among many. This page describes a control Veera implements and the law it is built against. It is not legal advice. Veera is free to start.

Frequently asked questions

Does GDPR give a contact the right to be deleted from a marketing list?

Yes, and for direct marketing the right is unusually strong. Article 21(2) of the GDPR gives every data subject the right to object at any time to processing of personal data concerning them for direct marketing purposes, and Article 21(3) states that once they object, “the personal data shall no longer be processed for such purposes.” No balancing test applies — unlike an objection under Article 21(1), the controller cannot weigh its own legitimate interests against the request and keep processing. Article 17(1)(c) then converts that objection into an erasure obligation: where the data subject objects pursuant to Article 21(2), the controller must erase the personal data without undue delay. For an outbound contact list, an opt-out request and an erasure request therefore collapse into the same duty.

How long do I have to honour an erasure request?

Under the GDPR, one month. Article 17(1) says “without undue delay,” and Article 12(3) fixes that as one month from receipt of the request, extendable by two further months where the request is complex or numerous — but the extension only counts if you inform the data subject of it, with reasons, within the first month. Under the CCPA, the deadline is 45 days from receipt of a verifiable consumer request (Cal. Civ. Code § 1798.130(a)(2)), extendable once by a further 45 days where reasonably necessary and with notice to the consumer, for a 90-day ceiling. Missing the deadline is itself a violation, separate from any failure to delete.

Is a soft delete or a “deleted” flag enough to satisfy the right to erasure?

No. A soft delete is a retention decision wearing a deletion label: the personal data still exists, still resolves to a named individual, and is still processed every time a query touches the row. The EDPB made this a headline finding of its coordinated enforcement action on the right to erasure, published 18 February 2026, in which 32 data protection authorities examined 764 controllers across Europe — reliance on inefficient anonymisation techniques instead of actual deletion was one of seven recurring failures identified, alongside difficulties deleting personal data from backups. The CCPA is more permissive on method, and the difference matters: 11 CCR § 7022(b)(1) expressly lets a business comply by permanently and completely erasing the personal information from its existing systems except archived or backup systems, by deidentifying it, or by aggregating it. A system built to that menu can still fall short of Article 17, which offers no equivalent deidentify-instead option.

How can I promise never to contact someone again if I have erased their data?

By erasing the person and keeping a one-way hash of their identifier. This is the central paradox of erasure in outbound: a guarantee never to contact someone is itself a fact about that someone, so deleting every trace destroys your ability to honour the request — the next purchased list re-imports them. The ICO addresses this directly in its direct marketing guidance, advising that where someone no longer wants their information used for direct marketing you should put their details on a suppression or “do not contact” list instead of deleting them, retaining just enough information about them to ensure their preference is respected in future, and warning that you must not simply delete their details altogether because they could later be put back on a marketing list by mistake — for example if you buy more leads that include the same details. The ICO also notes there is no automatic right to have information on a suppression list deleted, because the list is kept to comply with the objection rather than for direct marketing purposes. Storing a cryptographic hash of the normalised email or phone number rather than the identifier itself is the engineering form of “just enough”: it answers the only question suppression needs answered — have I seen this identifier before — while leaving no record that reads back as a person.

What is the difference between GDPR erasure and the CCPA right to delete?

Three differences drive the engineering. Scope: GDPR Article 17 reaches all personal data on any of six grounds, while Cal. Civ. Code § 1798.105 covers personal information the business collected from the consumer and carves out a list of statutory exceptions. Method: 11 CCR § 7022(b)(1) lets a business erase, deidentify, or aggregate, and expressly excepts archived or backup systems from the erasure requirement; Article 17 offers no such menu. Clock: one month under Article 12(3) versus 45 days under Cal. Civ. Code § 1798.130(a)(2). Both laws push the request downstream — GDPR Article 19 requires the controller to communicate the erasure to each recipient to whom the personal data have been disclosed, unless this proves impossible or involves disproportionate effort, and Cal. Civ. Code § 1798.105(c) requires the business to direct its service providers and contractors to delete the information and to notify third parties that received it. Building to the stricter of the two on each axis satisfies both.

Does Veera erase contact data on request?

Yes — the request is honoured, not parked. An organisation owner can erase a contact by email address or phone number from Settings › Privacy. Veera writes a hashed erasure tombstone first, before any deletion, so a crash part-way through still leaves the identifier blocked at send time and at re-import time; only then does the cascade delete the contact and its personal data across every collection that holds their data — contacts, messages, calls (which hold the full call transcript), enrollments, sequence events, appointments, notifications, sync conflicts, un-imported discovered leads, and the AI-inference and correction records tied to them. The original contact document is deleted rather than flagged, because the document id can itself embed the email address, and a terminal marker is written under an opaque SHA-256 id so no identifier survives in any field or in the id. The tombstone cannot be lifted by an operator, and it blocks re-ingestion at the single choke point every contact write passes through, so a later CRM sync or CSV re-import cannot resurrect an erased person. The audit record stores hashes only. This describes a specific control that Veera implements; it is not a certification, and Veera does not claim to be GDPR-certified.

This page is part of Veera’s AI calling compliance guide, a reference for the rules that govern automated outreach. Legal citations are to Regulation (EU) 2016/679 (GDPR) Articles 12, 17, 19, 21, and 83; the EDPB Coordinated Enforcement Framework report on the right to erasure (published 18 February 2026); Cal. Civ. Code §§ 1798.105, 1798.130, 1798.155, 1798.199.90, and 1798.199.95; Cal. Code Regs. tit. 11, § 7022; the California Delete Act (SB 362), Cal. Civ. Code §§ 1798.99.82 and 1798.99.86; and ICO direct marketing guidance on suppression lists; reviewed 16 July 2026. This page describes the erasure behaviour Veera implements and the rules it is built against. It is not legal advice, it is not a claim of certification, and it is not a substitute for counsel who knows your program. See also: What is an AI Business Aide? and State of Outbound Business AI 2026.