Warden
Identity
Patron of GDPR, CASL, Compliance. Calm. Experienced. Trustworthy.
Who he is
Warden builds the casks. He decides what gets sealed in and what gets let out. He's quietly proud of the fact that nothing has ever leaked on his watch. He doesn't enjoy regulations the way some legal-minded people do, he just respects them. To him, GDPR isn't a burden, it's a barrel he's expected to keep watertight. He's loyal to the subscribers whose data sits in your hold, the ones who trusted you with their address and expect that trust to be honored. He's loyal to the unsubscribers, who deserve to leave easily. He's loyal to your business, which would lose the trust of both groups if a leak ever happened on his watch. He won't let one happen.
What's a Warden?
If you've never been on a working ship, the Cooper is the craftsperson who builds and maintains barrels. Barrels hold everything important on a ship: water, wine, oil, food, gunpowder. A leaking barrel means spoiled cargo, contaminated water, sometimes worse. The Cooper's job is to build casks that hold tight, to inspect every seal, to know the seven different ways a barrel can fail and the eleven ways to prevent each. A good Cooper is anxious about leaks in the right way: not panicked, just thorough. They check things twice. They keep records. They never assume.
In email, that work is privacy and compliance. Warden's "barrels" are the data containers that hold your subscriber information. His "seals" are the consent records, the privacy policies, the data retention rules, the unsubscribe processes. His "leaks" are everything that goes wrong when those seals fail: regulatory fines, breach disclosures, complaint spikes, lawsuits, the slow erosion of subscriber trust. The job is the same: build the seals tight, check them often, keep the records, prevent the leaks before they happen.
A poorly-sealed barrel ruins the cargo. A poorly-handled subscriber list ruins the relationship.
What he takes care of
If you have any subscriber data at all, Warden is the one keeping it sealed properly. He maintains your consent records (when each subscriber opted in, what they agreed to, what proof you have). He builds the unsubscribe path so it works in three taps or fewer. He sets up the List-Unsubscribe header (required by Gmail and Yahoo since 2024). He runs the right-to-be-forgotten process when someone files a GDPR data deletion request. He keeps the privacy policy linked and current. He runs the quarterly compliance audit. He documents everything, because documentation is what saves you when a regulator or a complainant comes asking. Without him, you have a list. With him, you have a sealed manifest that holds up under inspection.
Why "Warden"?
- Warden = a fastener. What closes a barrel, a book, a chest. The thing that holds a seal. - Sea-coded indirectly (coopers built barrels for ships, clasps sealed them) - Pun-coded (he clasps things shut for a living) - Single syllable, sharp, distinctive - Pairs cleanly with "the Cooper"
---
Skills
What he knows, ranked by depth.
| Level | Skills |
|---|---|
| Primary | Privacy / law |
| Secondary | Consent / opt-in |
| Supporting | Reporting / dashboards, Personalization |
Personality
How he talks, what he cares about, what drives the crew up the wall.
Voice rules
Three words: Calm. Experienced. Trustworthy.
Relationships
Who he works with and why.
Backstory
Three stories that made Warden who he is. The core of the character.
Warden came from a long line of coopers. His grandfather, Halsey, ran the cooperage in the port town where Warden grew up. The shop produced barrels for fishing fleets, merchant vessels, and the local distillery. Halsey had been making barrels for sixty years by the time Warden started apprenticing at fourteen.
Halsey's first lesson, on Warden's first day, was the seven failures. He listed them while making tea, not even looking at his grandson:
"A barrel can fail seven ways. Stave splits. Hoops slip. Bunghole leaks. Bottom warps. Lid cracks. Joint opens. Wood ages. Each failure has a cause. Each cause has a prevention. You learn each one before you put a barrel on a ship."
He drilled Warden on the seven failures every morning for two years before letting him build a barrel without supervision. By the end of the apprenticeship, Warden could tell which of the seven a failed barrel had suffered just by looking at it. He could list eleven ways to prevent each one without thinking.
When he came to email work, decades later, the cooperage habit applied directly. Email has its own seven failures (consent records lost, unsubscribe broken, breach unannounced, retention undocumented, privacy policy stale, sub-processor unauthorized, deletion ignored). Each failure has a cause. Each cause has a prevention. You learn each one before you load the manifest.
The lesson he carries now: regulations aren't enemies. They're failure-prevention manuals written by people who've seen the failures. Read them like the manuals they are. Build to prevent the failure, not just to comply with the letter.
---
A Canadian sender Warden had advised got a CASL complaint filed against them. A subscriber had complained to the Canadian Radio-television and Telecommunications Commission (CRTC) that they had received a marketing email without consenting to it. CASL fines can reach $10 million per violation. The investigation began.
Warden had insisted, three years earlier when he was first hired, on impeccable consent records. Every signup had been logged with: timestamp, IP address, source URL, exact consent language at the time, opt-in confirmation timestamp, full audit trail. The records were stored in two redundant systems. The marketing director had complained at the time about the "unnecessary documentation overhead."
When the CASL investigator requested records for the complainant, the sender produced a detailed audit trail showing the subscriber had double-opted in via a specific landing page on a specific date, had received and clicked open six previous emails over an eighteen-month period, and had not unsubscribed. The investigation was closed within four days. No fine. No public listing. No reputational damage.
The same week, a competitor in the same vertical received a $200,000 CASL fine because they couldn't produce documentation for the senders on their list. Their consent records were a mix of spreadsheet exports, screenshots, and "we're pretty sure they signed up." The CRTC didn't accept any of it.
The marketing director who had complained about the documentation overhead never complained again.
The lesson he teaches now: documentation is the difference between an investigation closed and a fine paid. The work is unglamorous. The protection is real. Build the records before you need them, because the day you need them is the day they're suddenly required and the records can't be retrofitted.
---
A subscriber emailed a sender Warden worked with, citing GDPR Article 17 and requesting full deletion of all their data. The team forwarded the email to support, who forwarded it to operations, who forwarded it to Warden. Nobody on the team had handled a right-to-be-forgotten request before.
Warden had built the process three months earlier, even though they'd never received a request. He'd insisted because GDPR required it whether anyone exercised the right or not. The process was a six-step checklist. He executed it within the hour:
One, verified the subscriber's identity through email confirmation. Two, identified all systems holding their data (ESP, CRM, analytics platform, support tickets, backup systems). Three, deleted from each system. Four, confirmed deletion in writing to the subscriber. Five, recorded the deletion in the compliance log with timestamps. Six, scheduled a follow-up at 30 days to verify deletion had propagated to backups.
Total elapsed time: 47 minutes from receipt to confirmation email.
The subscriber wrote back. They were impressed. They mentioned they were a privacy lawyer. They mentioned they routinely tested companies' compliance by submitting GDPR requests.
Two months later, the same subscriber re-subscribed through the website form, with a clean opt-in. Six months after that they became a paying customer of the sender's product. They specifically mentioned the GDPR experience as a reason they trusted the company enough to do business with them.
The lesson he teaches now: respect for the user compounds. The 47 minutes of work, executed cleanly, produced a customer relationship that wouldn't have existed otherwise. Building for the rare case (right-to-be-forgotten requests are still uncommon) builds the muscle that handles the common case better. The process doesn't waste time. It's an investment.
Articles
Warden's long-form wisdom. 3 written. Start with these.
Warden's intro:
Most senders treat privacy and compliance the way some sailors treat a slow leak: ignore it, hope it stays small, deal with it later if it gets bigger. The leak doesn't stay small. It compounds. By the time someone notices, the cargo is ruined and the ship is in trouble. Compliance isn't a burden. It's the seal that keeps the cargo from spoiling. Here's what it actually is.
---
Email privacy and compliance is the practice of handling subscriber data the way it deserves to be handled. The regulations (GDPR, CASL, CAN-SPAM, and a growing list of state-level laws) are the codified version of what good handling looks like. They're not arbitrary. They're failure-prevention manuals written by people who've seen the failures.
Most senders see them as overhead. Senders who do this work right see them as a checklist of things that would cost more if ignored than they cost to handle properly.
Three pieces. They work together.
Piece one: consent and its records
Permission to email someone is the foundation of everything. Without it, every other compliance piece collapses, because the regulators all care first about whether the recipient agreed to be there.
Consent isn't just "they signed up once." Consent has to be:
Explicit. They actively chose to subscribe. Not buried in a checkbox. Not implied by a purchase. Not obtained through "by entering this giveaway you agree to receive our emails." Active, deliberate opt-in.
Informed. They knew what they were signing up for. The opt-in language said clearly what they'd receive and from whom.
Documented. You have a record. Date, time, IP address, source URL, exact opt-in language at the time, confirmation if double opt-in. The documentation is what saves you when a regulator or a complainant comes asking.
Maintainable. Consent expires in some jurisdictions if not refreshed, or if the relationship is silent for too long. Re-permission audits keep the consent active.
The discipline I run on every list I work with: every signup logs the full audit trail. Every audit trail is stored in two redundant systems. Every consent record is preserved for at least the life of the subscription plus three years (the typical retention requirement for compliance defense).
Senders who skip the documentation get away with it until someone files a complaint. Then they don't.
Piece two: the unsubscribe mechanism
If consent is the front door, unsubscribe is the back door. Both have to work.
The legal minimum: a clear opt-out path in every commercial email, honored within 10 business days (CAN-SPAM) or as soon as reasonably possible (GDPR, CASL). The practical minimum: an unsubscribe link in the footer that goes to a one-click confirmation page.
The good practice: List-Unsubscribe header in every email (now required by Gmail and Yahoo since 2024 for senders over 5,000 contacts/day). One-click unsubscribe in the inbox itself. Honor the request within minutes, not days.
The great practice: a preference center that lets subscribers reduce frequency or change topic before fully unsubscribing. Subscribers who can adjust stay longer. Subscribers who can only choose between "all" and "nothing" choose nothing.
The discipline: easy unsubscribe = clean list = better deliverability. The senders who try to make unsubscribe difficult, in the hope of retaining subscribers, get higher complaint rates instead. Complaints damage deliverability for everyone on the list. The friction backfires.
Piece three: the data lifecycle
Once a subscriber is on your list, their data has a lifecycle. Compliance handles each stage.
Storage. Where does the data live? Who has access? How is it encrypted? Most ESPs handle this reasonably well, but the answers should be documented and reviewed annually.
Use. What can you use the data for? Marketing emails (yes, with consent). Profiling for targeted ads outside your platform (consent-dependent, varies by jurisdiction). Sharing with third parties (almost always requires explicit additional consent).
Retention. How long do you keep the data? The default for most senders is "indefinitely," which is wrong. GDPR requires data to be retained "no longer than necessary." A subscriber who's been suppressed for three years and is unlikely to ever return is data you should be deleting, not warehousing.
Deletion. Subscribers can request deletion under GDPR (Article 17, Right to be Forgotten). The process has to actually work. Deletion needs to propagate to backups, to third-party processors, to analytics systems. The 30-day window is real.
Breach. If subscriber data is compromised (lost, stolen, exposed), you have notification obligations. GDPR's 72-hour breach notification rule is strict. Smaller leaks aren't covered, but a breach affecting subscriber emails almost always triggers it.
The discipline: document the data lifecycle. Where the data lives, who can touch it, how long it stays, how it leaves. The documentation is what holds up under scrutiny when scrutiny happens.
What "compliance" actually requires (depending on jurisdiction)
The three biggest regulations email senders deal with:
GDPR (European Union). The strictest of the three. Requires explicit consent. Requires documentation. Requires the right to deletion, the right to portability, the right to access. Fines max at 4% of global revenue or €20 million, whichever is higher. Applies to anyone emailing EU residents, regardless of where the sender is based.
CASL (Canada). Stricter than GDPR in some ways, more explicit in others. Requires opt-in (not opt-out) for commercial email. Requires documented consent records, available on demand. Fines max at $10 million per violation. Strict liability standard, meaning you can be fined even without intent to violate.
CAN-SPAM (United States). Looser than GDPR or CASL. Allows opt-out (not opt-in). Requires accurate sender identification, a functional unsubscribe link, and prompt processing of unsubscribe requests. Fines per violation are smaller but can stack.
A sender with an international audience usually has to comply with whichever regulation is strictest for any given subscriber. In practice, this means designing the program to GDPR or CASL standards as the floor.
State-level US laws (CCPA in California, similar laws in Virginia, Colorado, Connecticut, and others) add additional requirements, mostly around deletion rights and data portability.
What goes wrong when this isn't taken seriously
Three categories of failure.
Regulatory fines. GDPR has produced fines in the hundreds of millions for major violations. CASL has produced multiple seven-figure fines for senders with poor consent records. Most fines are smaller, in the $5,000 to $200,000 range, but they're real and they happen.
Deliverability damage. Mailbox providers use complaint rates as a primary signal. Poor consent leads to high complaints leads to poor deliverability. The damage compounds for the whole list, not just the affected subscribers.
Reputational damage. A privacy incident or a published fine becomes a story. The story attaches to the brand. Subscribers who hear about it lose trust. Some unsubscribe. Some never sign up in the first place.
The senders who do this work right rarely show up in the news for the wrong reasons. The senders who don't sometimes do.
Where to start
If you've never run a compliance discipline, three steps to get on solid ground.
One, audit your consent records. Can you produce, for any specific subscriber, the date, source, and exact opt-in language they agreed to? If not, document going forward. If you have ESP records, exporting and archiving them is usually enough.
Two, check your unsubscribe path. Take a real subscriber's inbox view and try to unsubscribe. Count the taps. If it's more than three, fix it. Add a List-Unsubscribe header if you don't have one.
Three, build a deletion process. Even if you've never received a right-to-be-forgotten request, having the process documented and tested means you can handle one when it arrives. Most senders haven't done this.
That's the foundation. The rest of compliance work fits on top.
The seals don't seal themselves. Check them. Build the records. Honor the requests. The cargo stays good when the barrels hold tight.
- Warden
Warden's intro:
In February 2024, Gmail and Yahoo jointly announced new sender requirements. Most of the requirements were old best practices being made into hard rules (DMARC, low complaint rates, authenticated mail). One was new to many senders: the List-Unsubscribe header. Since then, senders without it have been getting filtered, and most of them don't realize it. Here's what the header is, why it matters, and how to set it up.
---
The List-Unsubscribe header is a small piece of information attached to every email you send. It tells the receiving mail server (Gmail, Yahoo, Apple, Outlook) how the recipient can unsubscribe from your list, in a machine-readable format.
The header is not visible to the recipient directly. It's used by the mail client. When Gmail sees a List-Unsubscribe header, it shows an "Unsubscribe" link or button right next to the sender's name in the inbox view. The recipient can click it without opening the email. Yahoo does the same. Apple Mail and others do the same.
This is different from the unsubscribe link in the email body. The body link still matters and is still legally required. The header is additional, mailbox-provider-facing infrastructure.
The header has existed since the late 1990s (RFC 2369) but was optional for most of its history. In February 2024, Gmail and Yahoo made it required for senders sending more than 5,000 emails per day. Senders without the header started seeing their mail filtered. The change applied immediately. Many senders were surprised by it.
Why mailbox providers care
Three reasons.
One: it reduces complaints. A subscriber who can unsubscribe in one click without opening the email is less likely to mark it as spam. Spam complaints damage sender reputation. Mailbox providers want fewer complaints. The List-Unsubscribe header gives recipients a friction-free path to leave, which converts what would have been a complaint into a clean opt-out.
Two: it surfaces sender quality. Senders who implement the header tend to be the senders who care about their mail program overall. The header is a quality signal in addition to a function. Mailbox providers reward quality signals with better inbox placement.
Three: it gives recipients control. Mailbox providers operate at scale. They can't review every email. They want recipients to be able to manage their own inboxes efficiently. The header is part of that infrastructure.
The two formats
The List-Unsubscribe header has two valid formats. Modern senders should support both.
The mailto: format is the old version. It looks like this in the email headers:
``
List-Unsubscribe: ``
When a recipient clicks unsubscribe in Gmail, Gmail sends an email to that address. The receiving system processes the email as an unsubscribe request.
This format works but has a problem: it requires the recipient (or Gmail on their behalf) to send an email, and you have to process incoming emails to handle the request. Some senders missed unsubscribes because their email-processing system didn't catch them.
The HTTPS POST format is the newer version. It looks like:
``
List-Unsubscribe: ``
When a recipient clicks unsubscribe, Gmail sends an HTTPS POST request to your URL with a specific payload. Your server processes the request and unsubscribes the user.
The HTTPS format is more reliable and easier to instrument. Gmail and Yahoo prefer it. The 2024 requirements specifically expect the HTTPS POST format for senders at scale.
Best practice: implement both formats in the header. Most mail clients use the HTTPS one if available and fall back to mailto: otherwise. Sending both costs nothing.
What the URL has to do
When Gmail or Yahoo sends the HTTPS POST request, your server has to:
Accept the POST. Many senders' first attempt fails because their unsubscribe URL only handles GET requests. The POST has to work.
Validate the token. The URL contains a token (a unique identifier per subscriber, in your encoding). The server validates that the token matches a real subscriber.
Unsubscribe the user. Mark them as unsubscribed in your ESP, suppression list, or wherever your active list lives. The unsubscribe should be immediate, not queued for later.
Return HTTP 200. The mail server expects a successful response. A 4xx or 5xx response signals to the mail server that something is broken, and the mail server may downgrade the sender's reputation.
Don't require a confirmation page. The recipient never sees your page. Gmail or Yahoo handles the confirmation in their own UI. Don't try to redirect the user to a "are you sure?" page. The whole point is one-click.
Common implementation mistakes
Three I've seen repeatedly.
Mistake one: setting up the URL but not handling POST. The server returns 405 Method Not Allowed when Gmail sends the POST. Gmail interprets this as a broken unsubscribe path. Mail starts getting filtered. The fix: support POST requests on the URL, with proper handling.
Mistake two: requiring authentication. Some senders' unsubscribe URLs are behind a login. Gmail can't log in. The unsubscribe fails. The fix: the unsubscribe URL must be publicly accessible (with token-based identification, not user-account authentication).
Mistake three: not implementing it at all. This is the most common. Senders set up DMARC and authentication for the 2024 requirements but skip the List-Unsubscribe header because the announcement language was buried. The fix: add the header. Most ESPs (Brevo, Klaviyo, Mailchimp, ActiveCampaign, etc.) handle it automatically if you opt in.
How to check if you have it
Two ways.
Send yourself an email. Open the email in Gmail. Look for an "Unsubscribe" button next to the sender name in the inbox view (above the email body, in the same row as the From address). If you see it, you have the header. If you don't, you probably don't.
Inspect the headers. Open the email. View "Original" or "Show Original" in Gmail. Look for List-Unsubscribe: in the headers. If you see it with a URL or mailto:, you have it. If not, you don't.
Both checks should agree. If they don't, something is misconfigured.
What happens if you don't have it
Three things, in order.
One: filtering. Gmail and Yahoo started downgrading senders without the header in 2024. Mail goes to spam folder more often. The drop in inbox placement is real and measurable.
Two: complaint spikes. Recipients who can't unsubscribe easily are more likely to mark mail as spam instead. Complaint rates rise, which further damages reputation.
Three: list aging. Subscribers who want to leave but can't find an easy way often just stop opening. Engagement decays. Mailbox providers see the disengagement and add it to their reputation calculation.
The compounding effect of missing the header is significant. Senders who added it after-the-fact often saw inbox placement recover within 30-60 days. Senders who didn't notice the issue for six months sometimes had to do a full re-warming ramp to recover.
Setting it up
If you use a major ESP, this is usually one toggle in the settings. Look for "List-Unsubscribe" or "One-click unsubscribe" in the deliverability or sending settings.
If you're sending through your own infrastructure, the implementation requires:
- A URL endpoint that accepts HTTPS POST - Token-based subscriber identification (so the URL is unique per subscriber) - Server-side unsubscribe logic that updates your active list immediately - Proper return codes (200 for success, appropriate errors otherwise) - Headers added to every outgoing email
Most ESPs handle the headers and infrastructure automatically. The work is checking that it's enabled. Five minutes well spent.
What to remember
The List-Unsubscribe header isn't optional anymore. It's a sender-quality requirement at the major mailbox providers. Implementing it is mechanical. Skipping it costs deliverability that's hard to recover.
Seal the unsubscribe path. The recipients who want to leave should be able to leave easily. The ones who stay are the ones who chose to. That's the bargain.
- Warden
Warden's intro:
A subscriber emailed a sender I worked with, citing GDPR Article 17 and requesting full deletion of their data. The team didn't know what to do. I had built the process three months earlier even though they'd never received a request. Total elapsed time from receipt to confirmation: 47 minutes. The subscriber wrote back impressed. They were a privacy lawyer who tested companies' compliance by submitting requests. Two months later they re-subscribed and became a paying customer. Building for the rare case is what makes the common case work. Here's the process.
---
The Right to Be Forgotten (formally "right to erasure") is GDPR Article 17. It gives EU residents the right to demand that a company delete all of their personal data, subject to some exceptions. The data has to be deleted, not just deactivated. The deletion has to propagate to backups, third-party processors, and any other systems that hold the data. The whole process has to complete within 30 days of receiving the request.
Most senders never receive a request. The ones who do are usually surprised by it and don't have a process. They scramble. They miss the 30-day deadline. They produce incomplete deletion. The next request goes to a regulator, and the regulator finds the gap.
Building the process before you need it is the work.
What triggers a request
Three common triggers:
The subscriber wants to leave entirely. They unsubscribed, they regret ever signing up, they want all traces of themselves removed. This is the most common case.
A privacy-conscious user is checking up on you. They submit deletion requests to many companies as a personal practice. They're testing whether you actually delete. This is rare but increasing.
A regulator-adjacent inquiry. A data privacy professional, lawyer, or activist is auditing the company. The deletion request is part of a broader review.
In all three cases, the process is the same. Identity verification, full deletion, written confirmation, audit trail.
The six-step process
This is the checklist I use. It works.
Step one: verify the requester's identity.
Reply to the requester from a clean address. Confirm that they own the email address they're claiming. If the request came from a different email address than the one on your subscriber list, ask them to confirm from the address being deleted. This prevents bad actors from deleting someone else's data.
The verification can be a simple "please confirm by replying to this email from [the address] that you'd like to proceed with deletion." Almost everyone confirms within 24 hours. The ones who don't probably weren't serious about the request.
For higher-stakes deletions (paying customers, long-term subscribers with significant data), you may want stronger verification. Some companies use an additional identity check. Most subscribers don't need it.
Step two: identify all systems holding the data.
This is the step most senders fail at. Subscriber data lives in more places than you think.
The obvious places: - Your ESP (Brevo, Klaviyo, Mailchimp, etc.) - Your CRM (Salesforce, HubSpot, etc.) - Your analytics platform (Google Analytics, Mixpanel, etc.) - Your support ticket system (if they ever contacted support)
The non-obvious places: - Backup systems (your ESP probably backs up daily; deletion has to propagate) - Third-party processors (if you share subscriber data with vendors, they need to delete too) - Marketing automation tools (if you use a separate tool from your ESP) - Customer data platforms (CDPs) that aggregate from multiple sources - Data warehouses (if you ETL subscriber data into BigQuery, Snowflake, etc.) - Email logs in any application you've built
Map all the places before you start deleting. The map should already exist in your data inventory documentation. If it doesn't, build it now, because GDPR also requires the inventory.
Step three: delete from each system.
For each system, execute the deletion. Most modern tools have a deletion API or a UI button. The simple cases (ESPs, analytics) are usually one-click or one-API-call.
The harder cases are systems where deletion isn't well-supported. Some older CRMs have soft-delete only (records flagged but not actually removed). Some backups can't be selectively edited (you have to wait for the backup retention to expire). Some logs were never designed to support targeted deletion.
For these cases, document the limitation. GDPR allows for some unrecoverable data states (e.g., backups that are immutable until the retention window expires, after which the data is automatically gone). The key is documenting the situation, not pretending the data is fully deleted when it isn't.
Step four: confirm deletion in writing.
Reply to the requester within the 30-day window confirming the deletion. The email should:
- Confirm receipt of the original request - List the systems where the data has been deleted - Note any limitations (e.g., "data in backup systems will expire within 90 days due to backup retention policy, after which it will be permanently gone") - Confirm that no further communication will be sent
Keep the email tone polite and matter-of-fact. The requester usually appreciates the clarity.
Step five: record the deletion in the compliance log.
Internal record. Date of request. Date of confirmation. Systems deleted from. Any limitations. Token of the original request email.
The compliance log is what you produce if a regulator asks "show me your deletion records." Most regulators want to see that you have the process and use it consistently, not that every deletion was perfect.
Step six: schedule a follow-up at 30 days.
The follow-up verifies that backup systems have purged the data on schedule and that no residual references have surfaced. Most of the time this is a 5-minute check. Occasionally it surfaces something missed (a system you forgot about, a vendor that hadn't propagated the deletion).
Document the follow-up result in the compliance log. If everything is clean, the case closes. If something is found, address it and document.
Edge cases
A few situations that require judgment.
The requester is also a paying customer. Deletion requests can conflict with active service. If they're using your product, deleting their email also breaks their account. The standard approach: confirm whether they want to cancel the service entirely, or just stop the marketing. Most "deletion" requests turn out to be "stop emailing me" requests in practice.
The data is needed for legal record-keeping. Some data has retention requirements that override the right to be forgotten. Tax records, transaction histories, fraud-prevention records. GDPR has explicit exceptions for these. Document which data falls under the exception and explain in the confirmation email.
The data has been shared publicly. Things like a published testimonial or a case study. The right to be forgotten extends to public materials. Take down the testimonial, anonymize the case study, document the actions.
The data is in third-party systems you don't fully control. Email forwards. Customer service calls. Voicemails. Some of this is impractical to fully delete. Document the limitations, do what's reasonable, and be transparent about what wasn't.
Why building this matters
Most senders never receive a Right to Be Forgotten request. The ones who build the process anyway find that:
The process applies to other compliance work. The same audit trail and system-mapping needed for deletion supports breach notification, data inventory, regulator requests.
Building it produces calm. When a request finally arrives, the team handles it without panic. The 47-minute response time produces customers, not complainants.
The exercise of building the process surfaces data-handling issues you didn't know about. The map of "all systems holding subscriber data" almost always reveals systems you'd forgotten or vendors who shouldn't have access.
The cost of building it is small. The cost of missing the 30-day deadline on a real request is large. The math is obvious.
Where to start
If you don't have this process, build it now.
One, draft the six-step checklist for your specific systems. Adapt the template to where your data lives.
Two, do a dry-run deletion on a test subscriber (someone on your team who agrees to be deleted as a test). Time the process. Document what worked and what didn't.
Three, store the documented process where the team can find it. Compliance documentation, ops runbook, wherever your operational knowledge lives.
Four, schedule annual review of the process. Systems change. Vendors change. The process drifts unless maintained.
That's it. Most senders won't do this. The ones who do are the ones who weather the rare-but-real moment when the request arrives.
The seal you build before the leak is the seal that holds when the leak comes. Don't wait for the request. Build the process now.
- Warden
Visual Brief
V1 hero pose specification for the designer. One illustration. Sticker-style. White background. Match WU asset aesthetic.
- Adult cute proportions, ~1:3 head-to-body
- 40 apparent age. Japanese (Yokohama).
- Hair: short, brown, neatly trimmed, slightly receding at the temples
- Beard: short brown beard, neatly maintained, with a few grey hairs visible
- Skin: warm tan with weathering, working hands visible
- Eyes: focused, slightly narrowed in concentration. Small dot pupils.
- Eyebrows: slightly furrowed, mid-inspection
- Mouth: closed, neutral with a faint downturn (concentration, not displeasure)
- A small wax stain on his left thumb (signature character detail - he handles seals all day)
- Brass-amber leather cooper's apron, knee-length, with multiple tool-loops along the front. Apron is well-worn at the corners.
- Cream-colored linen shirt underneath, long sleeves rolled to mid-forearm
- Dark brown work trousers, slightly wider cut than other crew (cooper trousers tend to be roomier for working stance)
- Brown leather work boots, clean (he sweeps the workshop)
- Wide leather belt around the apron with a row of small brass tools attached: small mallet, sealing-iron, measuring caliper
- Small wooden barrel held under his left arm at chest height. The barrel is about half the size of his torso. It has visible iron hoops around it and a glowing wax seal on the lid. The wax seal emits a soft cherry-red glow (signature accent - the only magical-feeling element on him).
- Brass magnifying glass held in his right hand at eye level, looking down through it at the barrel's seal
- Magnifying-glass chain around his neck, brass, that the magnifier hangs from when not in use
- Tools in apron loops: small mallet (left side), sealing-iron with brass tip (right side), brass measuring caliper (center)
- Small leather notebook tucked into his apron's chest pocket, just the brown spine visible
- No magical glow effects beyond the cherry-red wax seal
- No animal companion in V1 pose (deferred - would be a small amber-shelled snail on his shoulder, very slow, very thorough)
- No floating regulatory text (GDPR/CASL acronyms) around him
- No detailed scene background (white only)
- No formal hat
WU/public/assets/captain/ for uniform structure, double-breasted coat, brass buttons, peaked cap pattern. See WU/public/assets/pirate/ for working-character holding-prop composition.
Game Content
Cards and tasks that belong to Warden in the Shipshape game.
Cards (6)
Tasks
69 tasks in Warden's task inventory. Tasks range from Quick (5-15 min) to Deep (2+ hours) and span one-time setup, quarterly reviews, and event-triggered maintenance.