Handling DSARs for WooCommerce Stores: A Practical Guide

The WooCommerce Data Problem

A typical WooCommerce store holds more personal data than most store owners realise. When a customer submits a data access request, you need to locate and provide all of it within 30 days.

Here's what a single customer's data footprint typically looks like:

Data Type	Location in WooCommerce
Account details	wp_users, wp_usermeta
Billing address	wp_postmeta (order meta)
Shipping addresses	wp_postmeta (order meta)
Order history	wp_posts (post_type=shop_order)
Order line items	wp_woocommerce_order_items
Payment tokens	wp_woocommerce_payment_tokens
Customer notes	wp_comments
Subscriptions	wp_posts (WooCommerce Subscriptions)
Wishlist items	Plugin-dependent
Product reviews	wp_comments

What Must Be Included in a DSAR Response?

Under GDPR Article 15, the response to an access request must include:

1. Confirmation that you process their data
2. A copy of all personal data you hold
3. The purposes of processing
4. The categories of data
5. Recipients (third parties you share data with)
6. Retention periods
7. Information about their rights (rectification, erasure, etc.)
8. The right to complain to a supervisory authority

Simply exporting an order history CSV doesn't meet this standard.

Automating DSAR Collection

Manual DSAR collection across WooCommerce tables takes hours per request and is prone to missing data. The right approach is automation.

WordPress's Built-in Personal Data Export

WordPress 4.9.6+ includes a built-in personal data export tool under Tools → Export Personal Data. However, it has significant limitations:

• Limited to data from plugins that implement wp_privacy_personal_data_exporters
• Not all WooCommerce data is included by default
• Produces a basic HTML export, not a machine-readable format

Extending with DPOKit

DPOKit extends the DSAR data collection to include all WooCommerce data, formats it as both human-readable HTML and machine-readable JSON (for portability requests), and manages the entire workflow:

// Example: register a custom data exporter for a bespoke plugin
add_filter('wp_privacy_personal_data_exporters', function($exporters) {
    $exporters['my-loyalty-plugin'] = [
        'exporter_friendly_name' => __('Loyalty Points'),
        'callback'               => 'my_plugin_export_loyalty_data',
    ];
    return $exporters;
});

function my_plugin_export_loyalty_data($email_address, $page = 1) {
    $user = get_user_by('email', $email_address);
    if (!$user) return ['data' => [], 'done' => true];

    $points = get_user_meta($user->ID, 'loyalty_points', true);
    $history = get_user_meta($user->ID, 'loyalty_history', true);

    return [
        'data' => [[
            'group_id'    => 'loyalty-points',
            'group_label' => __('Loyalty Programme'),
            'item_id'     => 'user-' . $user->ID,
            'data'        => [
                ['name' => 'Points Balance', 'value' => $points],
                ['name' => 'Transaction History', 'value' => json_encode($history)],
            ],
        ]],
        'done' => true,
    ];
}

Handling Deletion Requests

Deletion requests are more complex than access requests because:

1. Some data cannot be deleted — tax records must be retained for 7 years (UK HMRC requirement)
2. Order data may need to be anonymised rather than deleted (to preserve inventory/accounting records)
3. Guest checkout data is harder to locate than account-based data

The Anonymisation vs. Deletion Decision

Situation	Recommended Action
Order within tax retention window (7 years)	Anonymise customer details, retain order for accounting
Order outside tax retention window	Delete entirely
Account data (no orders)	Delete
Newsletter subscription	Delete + unsubscribe from Mailchimp/Klaviyo
Product review (named)	Anonymise or delete per policy

Setting Up a DSAR Workflow

A good DSAR workflow includes these steps:

1. Intake — Collect the request via a form, email, or portal
2. Identity verification — Confirm the requestor is who they claim to be
3. Acknowledgement — Send confirmation within 24 hours with a reference number
4. Data collection — Automated search across all data sources
5. Review — Legal hold check, third-party data confirmation
6. Response — Send the export package or deletion confirmation
7. Record — Log the request and response for audit purposes

DPOKit manages all seven steps from within your WordPress dashboard, with automated deadline tracking and admin notifications at each stage.

Dealing with Third-Party Data

Your DSAR response must cover data held by your data processors too — or at minimum inform the requestor which processors hold their data so they can submit separate requests.

Common third-party processors for WooCommerce stores:

• Payment processors (Stripe, PayPal) — transaction records
• Shipping carriers (integration plugins) — delivery records
• Email platforms (Mailchimp, Klaviyo) — marketing data
• Analytics (Google Analytics) — behavioural data
• Support desks (Zendesk, Freshdesk) — support ticket history

Document these in your ROPA and ensure your privacy policy clearly lists all processors.

Conclusion

DSARs are a legal obligation, not optional. With WooCommerce holding extensive customer data across multiple database tables, automation isn't just convenient — it's the only practical way to respond accurately within the 30-day deadline at any scale.