Data Retention Policies

Data Retention Policies

Overview

Data retention policies define how long each category of data is kept, when it is archived, and when it is purged. E-commerce stores must balance legal obligations (tax records must typically be kept 5–7 years) against privacy regulations (GDPR's data minimization principle requires deleting data that is no longer needed). The right approach depends on your platform — Shopify handles some retention automatically, while WooCommerce/custom stores require explicit implementation.

When to Use This Skill

• When implementing GDPR data minimization requirements for a new or existing e-commerce platform
• When legal or compliance teams request a documented data retention policy
• When preparing for a data protection audit or SOC 2 Type II assessment
• When storage costs are growing due to uncontrolled data accumulation
• When a customer submits a Subject Access Request and you need to know exactly where their data lives

Core Instructions

Step 1: Document your retention schedule first

Before configuring any tool, document a retention schedule. Legal, compliance, and engineering must agree before implementation. This Register of Processing Activities (RoPA) is required under GDPR Article 30 for large processors and recommended for all:

Key principle: Never delete what the law requires you to keep. For orders, anonymize the customer's PII (name, email, address) while preserving the financial record (amounts, tax, payment method brand/last 4).

Step 2: Platform-specific retention configuration

---

Shopify

Shopify stores order data indefinitely by default and handles platform-level data retention for infrastructure components.

Customer data export and deletion (GDPR compliance): Shopify provides built-in GDPR webhooks: 1. Go to Settings → Customers → Customer privacy 2. Shopify automatically sends customers/data_request and customers/redact webhooks to any installed apps when a customer requests their data or deletion 3. For your own app or custom code, register webhook handlers for these events

Manual customer anonymization: 1. Open a customer record → More actions → Anonymize this customer 2. Shopify replaces PII with anonymized placeholders while keeping order records 3. This is irreversible — confirm before proceeding

Automated email list cleanup: Use Klaviyo (or your email provider) to automatically suppress or delete contacts who haven't opened an email in 12+ months. Most email providers have "sunset" automation features built in.

Data export for archiving: 1. Go to Customers → Export to download customer data as CSV for archival 2. For orders: Orders → Export 3. Store exports in encrypted cold storage (e.g., AWS S3 with Glacier lifecycle policy)

---

WooCommerce

WooCommerce does not enforce data retention automatically. You need to configure it via plugins and scheduled tasks.

WooCommerce's built-in cleanup: 1. Go to WooCommerce → Status → Tools 2. Use Clean up WooCommerce sessions to delete expired session data 3. Use WooCommerce tracker cleanup to clear tracking data

GDPR / data retention plugin: Install WP GDPR Compliance or GDPR Cookie Consent (by WebToffee): 1. Go to WP GDPR Compliance → Settings → Data Retention 2. Configure retention periods per data type 3. The plugin creates scheduled cleanups via WP-Cron

Manual scheduled cleanup (WP-Cron):

// Add to your theme's functions.php or a custom plugin
// Schedule a daily cleanup job
if (!wp_next_scheduled('wc_data_retention_cleanup')) {
    wp_schedule_event(time(), 'daily', 'wc_data_retention_cleanup');
}

add_action('wc_data_retention_cleanup', 'run_data_retention');

function run_data_retention() {
    // Delete WooCommerce sessions older than 90 days
    global $wpdb;
    $wpdb->query(
        $wpdb->prepare(
            "DELETE FROM {$wpdb->prefix}woocommerce_sessions WHERE session_expiry < %d",
            time() - (90 * DAY_IN_SECONDS)
        )
    );
    // Log the cleanup
    error_log('WC data retention: cleaned sessions older than 90 days');
}

Order PII anonymization for tax compliance: Do not delete orders (required for tax records). Instead, anonymize PII while keeping financial data. Install WooCommerce GDPR (WebToffee) which adds an "Anonymize" action to orders.

---

BigCommerce

BigCommerce provides customer data management tools in the admin panel.

Customer data export: 1. Go to Customers → Export → All Customers (CSV) 2. Use for archival before deleting customer accounts

Customer deletion: 1. Go to Customers → find the customer → Delete 2. BigCommerce retains associated order records when a customer account is deleted

Automated retention: BigCommerce does not have built-in scheduled data retention. Use the BigCommerce Customers API and Orders API to: 1. Query customers inactive for more than 3 years 2. Archive their data 3. Delete or anonymize their accounts

This requires a custom script or a third-party integration (e.g., via Zapier or a custom app).

---

Custom / Headless

For custom storefronts, implement automated purge and anonymization jobs that run on a schedule.

Key principle: batch small, run off-peak, always log:

// Run nightly at 2 AM UTC
import { CronJob } from 'cron';

new CronJob('0 2 * * *', runRetentionJobs).start();

async function runRetentionJobs() {
  const jobs = [
    { name: 'purge_sessions', fn: purgeSessions },
    { name: 'purge_abandoned_carts', fn: purgeAbandonedCarts },
    { name: 'anonymize_old_orders', fn: anonymizeOldOrders },
    { name: 'purge_inactive_customers', fn: purgeInactiveCustomers },
  ];

  for (const job of jobs) {
    try {
      const result = await job.fn();
      await db.retentionAuditLog.insert({ job: job.name, ...result, runAt: new Date() });
    } catch (err) {
      await alertOps(`Retention job failed: ${job.name}`, err);
    }
  }
}

// Paginated delete — avoids table locks
async function purgeSessions(): Promise<{ deleted: number }> {
  const cutoff = new Date(Date.now() - 90 * 86400_000);
  let deleted = 0;
  while (true) {
    const batch = await db.sessions.findExpired(cutoff, { limit: 1000 });
    if (batch.length === 0) break;
    await db.sessions.deleteBatch(batch.map(s => s.id));
    deleted += batch.length;
    await new Promise(r => setTimeout(r, 100)); // yield between batches
  }
  return { deleted };
}

// Anonymize order PII but keep financial data (7-year tax requirement)
async function anonymizeOldOrders(): Promise<{ anonymized: number }> {
  const cutoff = new Date(Date.now() - 7 * 365 * 86400_000);
  const orders = await db.orders.findWhere({ created_at: { lt: cutoff }, pii_anonymized_at: null }, { limit: 500 });
  for (const order of orders) {
    await db.orders.update(order.id, {
      customer_email:   `anon_${order.id}@deleted.invalid`,
      customer_name:    'Anonymous Customer',
      shipping_name:    'Anonymous',
      shipping_street:  null,
      shipping_city:    order.shipping_city,    // Keep for tax jurisdiction
      shipping_country: order.shipping_country,
      billing_name:     'Anonymous',
      billing_street:   null,
      // Financial data (total_amount, tax_amount, payment_method_last4): UNCHANGED
      pii_anonymized_at: new Date(),
    });
  }
  return { anonymized: orders.length };
}

Cross-service customer deletion: When deleting a customer, purge data from every system that holds it:

async function purgeCustomer(customerId: string, reason: 'gdpr_request' | 'inactivity') {
  // 1. Anonymize orders (keep for tax, remove PII)
  await anonymizeOrdersForCustomer(customerId);
  // 2. Delete from email platform (Klaviyo, Mailchimp)
  await emailPlatform.deleteContact(customerId);
  // 3. Delete from search index (Algolia, Elasticsearch)
  await searchIndex.deleteCustomer(customerId);
  // 4. Delete analytics identifier
  await analytics.deleteUser(customerId);
  // 5. Delete the customer profile
  await db.customers.anonymize(customerId);
  // 6. Log for compliance evidence
  await db.retentionAuditLog.insert({ action: 'customer_purged', customerId, reason, executedAt: new Date() });
}

Best Practices

• Document before implementing — legal, compliance, and engineering must agree on the retention schedule; unilateral engineering decisions create compliance gaps
• Anonymize financial records, never delete them — orders must be retained for the tax statutory period; replace PII fields with anonymized placeholders
• Keep a separate, append-only retention audit log — this is your evidence for compliance auditors; never delete from this log
• Run purge jobs in small batches off-peak — use SELECT ... LIMIT n batches to avoid table locks that impact live traffic
• Handle cross-service deletion as a checklist — purges spanning multiple services (database, email platform, analytics) must be resilient; log completion for each system separately
• Respond to GDPR deletion requests within 30 days — build automated workflows with reminders and escalations; track all requests with deadlines

Common Pitfalls

Related Skills

• @gdpr-ecommerce
• @account-security
• @financial-audit-trail
• @financial-compliance-sox

Customer Right-to-Erasure Implementation

Problem/Feature Description

Your company's data protection officer has received an uptick in GDPR "right to erasure" (Article 17) requests from customers asking to have their accounts deleted. The current process is entirely manual: someone on the team finds the customer in the database and deletes their profile row, but this often misses data in the search index, email marketing platform, analytics warehouse, and CDN-cached pages. Auditors flagged this as a gap because there is no evidence the deletions were actually completed across all systems.

The engineering team needs to build a TypeScript function purgeCustomerData that handles the full deletion workflow for a single customer. The function must be resilient: if it is interrupted halfway through (e.g. the analytics API times out), it should be possible to tell which systems were already cleaned and which still need work. The function also needs to handle edge cases — for example, a customer who has an unresolved chargeback dispute cannot be legally deleted yet.

Additionally, the team needs a lightweight mechanism to track incoming erasure requests so that nothing falls through the cracks past the statutory deadline.

Output Specification

Produce a TypeScript file lib/data-retention/purge-customer.ts that implements:

• purgeCustomerData(customerId: string, reason: string) — the main purge function
• Any helper interfaces or stub service clients needed

Also produce a short DESIGN.md explaining:

• How partial failures are handled (what state is recorded)
• How the legal hold check works
• What the 30-day deadline tracking mechanism looks like (data model or pseudocode is fine)

Order Data Cleanup for Tax Compliance

Problem/Feature Description

A European e-commerce company is preparing for a GDPR compliance review. Their legal team has confirmed that they must retain all order financial records for 7 years to satisfy EU VAT and tax audit requirements — but they are not permitted to hold customer personal information beyond what is strictly necessary. Orders older than 7 years that still contain identifiable customer data need to have that personal information removed, while the underlying financial record must remain intact and accurate.

The engineering team has been asked to write a TypeScript function that processes these old orders. The challenge is that the financial data (amounts, payment method summary, tax figures) is critical for audits and must survive unchanged, while name and address fields should be cleared. The city and country must be preserved for tax jurisdiction purposes. The job may run monthly and must be safe to re-run — it should never double-process a record.

Output Specification

Produce a TypeScript file jobs/anonymize-old-orders.ts that:

• Implements an anonymizeOldOrders(cutoffDays: number) function
• Includes stub types/interfaces for db and the order model as needed
• Has a brief inline comment explaining why city/country are preserved

The output does not need to compile against a real database driver. Focus on the logic: what fields get cleared, how atomicity is ensured, what prevents re-processing.

Implement Data Retention for an E-Commerce Backend

Problem/Feature Description

A fast-growing online marketplace has been accumulating data since launch without any formal data cleanup process. The engineering team has been asked by legal and compliance to implement a proper data retention system before an upcoming SOC 2 audit. The platform stores customer sessions, abandoned shopping carts, browsing history, fraud detection logs, analytics events, and customer account records in a PostgreSQL database.

The legal team has reviewed applicable regulations (US tax law, EU VAT, GDPR) and signed off on a retention policy document. Engineering needs to translate this into running code: a TypeScript module that defines the retention schedule and a nightly background job that enforces it. The compliance team specifically needs evidence that the jobs are actually running and purging data — they want an audit trail they can show to auditors.

The system must be safe for production: it cannot lock database tables during business hours, and it must handle large tables gracefully without timing out.

Output Specification

Produce a TypeScript implementation with the following files:

• lib/data-retention/schedule.ts — defines the retention schedule as a typed constant
• jobs/data-retention.ts — the nightly retention job runner (cron scheduling, all purge functions, execution tracking)
• README.md — a brief explanation of the cron schedule chosen and the approach used to avoid database table locks

The output does not need to compile or connect to a real database — stub the db and CronJob imports as needed. Focus on the logic, structure, and configuration values.