A cosmetics retailer we spoke with passed its internal GDPR audit with a clean checklist: privacy policy published, cookie banner in place, data processing agreements signed with every vendor. Four months later, an employee's laptop with unencrypted database exports was stolen from a car. The audit hadn't asked whether exports were encrypted – it asked whether a policy existed saying they should be. That gap between paperwork and practice is where most real GDPR-related breaches happen, and it's worth closing before it closes on you.
The Audit That Passed and the Breach That Followed
GDPR (Regulation (EU) 2016/679) is often treated as a documentation exercise – policies, consent banners, a register of processing activities. Those things matter, but Article 32 specifically requires "appropriate technical and organisational measures" to ensure security, and that's a substantive, not procedural, obligation. A store can have every document in order and still fail Article 32 if its actual technical controls don't hold up.
Article 32: Security of Processing Isn't a Checkbox
Encryption at Rest and In Transit
TLS on the storefront is table stakes and most stores have it. What's less consistently handled is encryption at rest – database backups, exported customer lists, and archived order data sitting unencrypted on a laptop or a forgotten cloud bucket. Article 32 explicitly names encryption and pseudonymisation as example measures, and regulators increasingly expect both where personal data volume or sensitivity justifies it.
Pseudonymisation in Practice
Pseudonymisation – replacing directly identifying fields with tokens in datasets used for analytics, testing, or third-party integrations – reduces the blast radius if that dataset leaks. A common gap: staging or test environments running with a full, unmasked copy of production customer data, accessible to more people than production itself.
Ongoing Testing and Evaluation
Article 32(1)(d) requires "a process for regularly testing, assessing and evaluating the effectiveness" of security measures. In practice this means periodic vulnerability scans, module audits, and – for stores with meaningful transaction volume – an occasional third-party penetration test, not a one-time setup step.
The 72-Hour Reality of Article 33
Article 33 requires notifying the relevant supervisory authority within 72 hours of becoming aware of a personal data breach, unless it's unlikely to result in a risk to individuals' rights. Seventy-two hours sounds generous until you're inside it: identifying scope, containing the incident, and drafting a notification that meets the required content (nature of the breach, categories and approximate number of data subjects, likely consequences, measures taken) is genuinely hard to do from a standing start.
Building a Breach Response Timeline
A workable approach is a pre-written template covering the mandatory notification fields, a named internal owner for breach response, and a tested escalation path from "we noticed something odd" to "we've confirmed a breach." Stores that only think about this after an incident routinely miss the 72-hour window – not from bad faith, but from not having the pieces ready.
Data Minimisation as a Security Control, Not Just a Privacy Principle
Every field a store collects and retains is a field that can be breached. A store that keeps ten years of order history with full card-adjacent metadata "just in case" carries more risk than one that purges old data on a defined retention schedule. Data minimisation, driven by GDPR's Article 5(1)(c), doubles as a practical security measure: less data means less to lose.
Vetting Processors and Data Processing Agreements
A DPA is a legal document, but the underlying question it's supposed to answer is operational: does this payment gateway, email platform, or fulfillment partner actually protect the data you're handing them? Ask processors for their own Article 32 measures, not just a signature on a template contract. This matters even more for smaller integrations – a marketing plugin with API access to customer emails is a processor too, whether or not it feels like one.
Access Control and the Principle of Accountability
Article 5(2) puts the burden of proof on the controller – it's not enough to be compliant, a store has to be able to demonstrate it. That distinction matters most around access control. Who inside the business can view unmasked customer data, and can that be shown with a role list rather than a guess? A common finding in real audits is that far more staff accounts than necessary have full customer database access, simply because nobody revisited permissions after the initial setup. Tying access to specific roles, logging who viewed or exported personal data, and reviewing that access list on a set schedule turns accountability from an abstract principle into something a store can actually point to if a regulator asks.
Compliance Checkbox vs Real Security Practice
| Area | Checkbox Compliance | Real Security Practice |
|---|---|---|
| Encryption | Policy states data "should be encrypted" | Backups, exports, and archives actually encrypted, keys managed properly |
| Access control | Access policy document exists | Role-based access enforced in the admin panel and database |
| Breach response | Incident response policy on file | Tested runbook, named owner, notification template ready |
| Vendor management | DPA signed | Processor's technical measures actually reviewed |
| Data retention | Retention schedule documented | Automated purging enforced, not manual and inconsistent |
A GDPR Security Hardening Checklist
- [ ] Encrypt database backups and customer data exports, not just the storefront connection
- [ ] Pseudonymise or mask personal data in staging and test environments
- [ ] Schedule recurring vulnerability scans and periodic penetration tests
- [ ] Pre-write a breach notification template covering Article 33's required fields
- [ ] Name an internal breach-response owner and test the escalation path annually
- [ ] Enforce a data retention schedule with automated purging, not manual review
- [ ] Review processor DPAs for actual technical measures, not just signatures
For the broader compliance picture beyond security specifically, see our /blog/complete-eu-compliance-checklist-online-stores/ guide, and for how these security measures intersect with fraud controls, see /blog/preventing-fake-orders-with-ai/.
The cosmetics retailer's incident ended up being reportable – the laptop had roughly 40,000 unencrypted customer records on it, an illustrative figure but not far off what a mid-size store accumulates in exports over a year. Full disk encryption on that laptop would have made the same theft a non-event instead of a supervisory authority notification. That's the concrete next step worth taking this week: check whether your last three data exports were encrypted, and if you can't answer confidently, that's your starting point.
Frequently asked questions
Related reading
- Complete EU Compliance Checklist for Online Stores
- Future Cybersecurity Threats Facing eCommerce
- Preventing Fake Orders with AI
- How the EU AI Act Will Affect Online Stores
- How Zero Trust Security Can Protect eCommerce Businesses
