Someone on your prospect list emails back with “please delete my data” — or files a formal erasure request through whatever channel your process uses. What actually has to happen next isn’t obvious, and getting it wrong in either direction causes real problems: erase too little and you’re non-compliant; erase too much and you accidentally destroy the aggregate numbers you need to run the business, or worse, lose the record that this person opted out at all — which is exactly how they end up re-contacted six months later.

This post is about the decision, not the API call. If you’re looking for the exact endpoint and request shape, that’s covered separately in the erase vs. delete endpoint breakdown. This is the “how do I think about this” version, for whoever is deciding what an erasure request actually means for a specific contact.

Erasure is not the same operation as delete

The instinct when someone asks to be removed is to reach for the same “delete contact” button you’d use to clean up a bad record. That’s the wrong tool. Ordinary deletion in Norbelys is a soft delete — the row gets archived, not destroyed, specifically so mistakes and accidental clicks are recoverable. An erasure request is the opposite intent entirely: someone is exercising a legal right to have their personal data actually gone, and “gone but recoverable with a restore button” doesn’t satisfy that. Erasure needs to be its own explicit, audited operation — not a side effect of the same delete path everything else uses — precisely because the two requests mean opposite things.

What has to go, and what’s allowed to stay

The part people get wrong most often is treating erasure as “delete the entire history of this person from every system.” That’s both more destructive than the request requires and actively harmful to how the erasure gets enforced. The useful split is:

Personal data goes. Email address, name, and any custom fields tied to the contact are scrubbed from the record. This is the identifying information — the part a data subject’s erasure request is actually about.
Anonymized aggregate counts stay. Event history — this person’s opens, clicks, replies — doesn’t need to vanish from your analytics as raw, identity-linked rows to satisfy an erasure request. What matters is that the identifying link is broken. Keeping anonymized counts means your campaign performance numbers, reply rates, and deliverability metrics from before the erasure remain accurate. Deleting those counts wholesale doesn’t make you more compliant — it just makes your historical analytics quietly wrong, for no privacy benefit, since the data no longer identifies anyone.

The step that actually protects the person: suppression

This is the detail that’s easy to miss and matters the most. Erasing a contact’s PII without also suppressing their address solves the wrong problem. If the email address is simply removed from the database, nothing stops that same address from being re-imported in a CSV six months later — from a different list, a different campaign, a colleague who didn’t know about the earlier request — and re-contacted as if the erasure never happened. That’s not a hypothetical edge case; stale lead lists and CRM exports get re-imported constantly in cold outreach operations, often by someone with no memory of a prior opt-out.

The fix is: erasure adds a hash of the erased address to the platform’s suppression (do-not-contact) list, alongside the same trigger sources as a hard bounce or an unsubscribe. Suppression is checked both when a contact is enrolled into a program and again immediately before a message actually sends — so even if that address slips back into an import file later, it gets blocked at both of those checkpoints before another message reaches it. Storing a hash rather than the plaintext address is what makes this retention itself defensible: you’re not keeping the person’s identifying data around, you’re keeping a one-way fingerprint whose only function is “never send here again.”

This is the part that makes erasure actually protective rather than just a data-hygiene exercise. Scrubbing PII satisfies the letter of a deletion request. Suppression-hashing the address is what stops the same person from being harvested and re-emailed by a future, unrelated import — which is the outcome the person asking to be erased actually cares about.

Who the request is really landing on

Cold email tooling sits in a specific spot in the data-protection picture: you, the operator running campaigns, are almost always the data controller — the party who decided to collect and use someone’s contact details. Norbelys, as the platform, is the processor executing your instructions on that data. That distinction matters for erasure requests in practice, because it means a request that arrives at your inbox (“stop emailing me, delete my data”) is a request directed at you as the controller, and translating it into the actual erasure action inside the platform is your responsibility, not something that happens automatically because someone complained. The platform gives you the tool to execute the request correctly — scrub the PII, retain the anonymized counts, suppress-hash the address, all in one audited action — but recognizing that a given email is an erasure request, and acting on it, is a step that happens before the tool gets used.

It’s also worth being precise about scope. An erasure request from one person is about that person’s record — it isn’t a signal to scrub your entire list, and treating it as one either under-serves the request (if you interpret it too narrowly and miss related records for the same person under a different email) or wildly over-corrects (if you start erasing unrelated contacts out of caution). The operation is scoped to a specific address for a reason: acting on it that way keeps the response proportional to what was actually asked.

Deciding whether a request applies to you

Cold B2B outreach generally runs on a legitimate-interest basis rather than prior opt-in — relevant, business-context contact with an easy way out, recorded against the contact’s source. That basis doesn’t exempt you from erasure requests; it affects what you need on file to justify contacting someone before an erasure request arrives, not your obligation to honor one once it does. This post deliberately doesn’t work through country-by-country legal thresholds — GDPR, CCPA, CASL, and the rest each have their own specifics that are better covered on their own — but the operational pattern above (scrub identifying fields, retain anonymized counts, suppress-hash the address) is the same regardless of which regime triggered the request.

Don’t let the request sit

Every privacy regime that grants an erasure right also expects a reasonably prompt response — the exact clock varies by jurisdiction, and that’s genuinely outside this post’s scope (worth checking against the regional-law specifics for wherever your contact is based). What’s true regardless of jurisdiction is the operational failure mode: an erasure request that sits unactioned in an inbox for weeks is a request that a subsequent campaign send can still hit, because nothing about receiving the email itself protects the contact — only actually running the erasure operation does. Treat the request as time-sensitive the moment it’s identified, not once someone gets around to it during a quarterly cleanup.

What this looks like end to end

A request arrives — directly from the contact, or via a formal channel.
You confirm which record it applies to (the email address, matched to the contact row).
You run the erasure operation rather than a normal delete — this scrubs the identifying fields on the contact and adds the hashed address to suppression in the same audited action, so the two don’t drift apart from each other.
Aggregate event history for that contact’s prior activity remains in analytics, anonymized — your historical reporting doesn’t silently lose data.
The person is now structurally protected from re-contact through Norbelys, even if their address resurfaces in a future import, because suppression is enforced at both enrollment and send time.

That’s the operational shape of the decision. For the exact request format, the fields it touches, and how it differs from the standard people:archive call at the API level, see the erase vs. delete endpoint breakdown.