Right-to-erasure is the most operationally consequential GDPR/CCPA requirement, and the one most WordPress sites haven't actually built for. The first deletion request usually arrives unexpectedly. The team scrambles to figure out what data exists, where it lives, and how to remove it without breaking anything. Building the flow in advance turns a fire drill into a routine. Here's what to put in place before someone asks.
Right-to-erasure (the GDPR phrasing) or right-to-delete (the CCPA phrasing) gives users the legal ability to request that a site remove their personal data. The site has 30 days to comply (GDPR) or 45 days (CCPA, sometimes extendable). The request itself is usually simple. The execution is almost always harder than expected, because personal data on a WordPress site is rarely in one place.
Most teams discover this on the day the first request arrives. The legal contact emails the engineering contact. The engineering contact realizes they don’t know what they’d need to delete. The next two weeks become a scramble to figure out where user data actually lives across the site’s plugins, integrations, and exports. Building the flow before the request arrives turns the 30-day deadline from a fire drill into a routine.
Where personal data actually lives on a WordPress site.
An incomplete inventory of where user data can end up:
- WordPress users table — account email, name, last login, anything in user meta
- Gravity Forms entries — every form submission ever, with whatever fields were collected
- WooCommerce orders — customer details, addresses, order history
- Comments — commenter name, email, IP address, comment content
- Newsletter integration — if connected to Mailchimp/ConvertKit/etc., user is in the third-party system too
- CRM integration — HubSpot, Salesforce, Pipedrive — whatever data the WordPress site pushes there
- Analytics — if using third-party analytics, the user’s behavior data is in Google’s/Meta’s/whoever’s database
- Email logs — if using a transactional email service (SendGrid, Postmark), email history may be retained
- Backups — every nightly backup contains all the above, frozen at that moment
- Server logs — access logs typically include IP addresses, sometimes for months
- Plugin-specific data — member directory plugins, event registrations, donation receipts, anything custom
An erasure request that only deletes the WordPress user account misses most of this. A complete erasure has to touch every system the user’s data reached.
Step 1: Map the data flow.
Before building the deletion flow, audit where user data goes. The deliverable is a single document that lists, for each type of user interaction with the site (account creation, form submission, purchase, comment), every system the data ends up in. This is the same exercise you’d do for a privacy policy, but with operational specificity — not “we share data with analytics providers,” but “form submissions go to: WordPress (Gravity Forms entries), HubSpot (contact + lead source), Slack (channel notification with name/email), email autoresponder (subject line includes name).”
This document needs to be maintained. Every new integration adds a row. Treat it as part of the data architecture, not as a one-time compliance artifact.
Step 2: Build the deletion process.
For each system in the inventory, identify how erasure happens:
- WordPress core:
wp_delete_user()or the admin Users screen. Choose whether to reassign content to another user or delete it entirely — for a customer, deletion is usually correct. - Gravity Forms entries: Natively integrates with the WordPress core privacy tools. When configured in a form’s Personal Data Settings, the core tool handles the entry deletion or anonymization automatically.
- WooCommerce orders: Has built-in personal-data eraser hooks (WordPress 4.9.6+). Configure them to actually run when invoked.
- Comments: Search by email, delete. Or anonymize (the moderation history is preserved, the personal data is removed).
- HubSpot/CRM: API call to delete the contact. Verify the deletion actually propagates — some CRMs “delete” by archiving, which doesn’t satisfy GDPR.
- Mailchimp/email lists: Different APIs; unsubscribing is not the same as deleting; check the documentation for actual erasure.
- Backups: This is the hard one. Most backup retention policies span months. The honest answer in your privacy policy is usually “data persists in backups until backup expiration; we won’t restore from a backup taken before your deletion request without re-running the deletion.” That’s a documented policy, not a deletion.
- Server logs: Rotate aggressively. Most sites don’t need 90-day log retention; 7-14 days is usually enough operationally and reduces exposure.
Step 3: Build the request handler.
Two surfaces:
- WordPress Erase Personal Data dashboard. This core WordPress feature natively handles Core users, WooCommerce, and Gravity Forms. The architectural work is writing custom callbacks for your CRM, newsletter, and custom plugins, and registering them to the wp_privacy_personal_data_erasers filter so the core tool orchestrates the entire multi-system wipe with a single click.
- A user-facing request form (or email address) that visitors can use to submit erasure requests. Doesn’t have to be self-service deletion — can be a request that lands in a queue for human review. Just needs to exist and be findable.
The internal tool is what turns a 30-day scramble into a 30-minute task. Without it, every request requires the team to rediscover the data inventory and execute the deletion manually, and inconsistency creeps in over time.
Step 4: Document and rehearse.
Two artifacts complete the system:
- A runbook for the legal contact. Plain-language steps: when a request arrives, here’s how to verify identity, here’s how to run the deletion, here’s how to respond to the user, here’s how to log it for compliance records.
- An annual rehearsal. Once a year, simulate a request — deletion against a test account that’s been seeded with data across every integrated system. Verify every system actually got cleared. The systems that fail are the ones that drifted since the original setup.
The site that has all of this in place treats erasure requests as routine work. The site that doesn’t treats each one as a small crisis. The difference is a few days of work before the first request arrives. See privacy built into the platform for the rest of the operational picture.