Most of us here build the store rather than run it, so the security checklist we get handed is usually written for the merchant instead of the person with commit access. Here is the same ground covered from the implementation side, where the work actually lands.
Access Control Is a Schema Decision, Not a Policy Document
Least privilege sounds like something that lives in a PDF and ends up being a schema decision. A support rep needs order history and shipping addresses. They do not need the admin panel or full card records. A marketing seat needs aggregate analytics, not individual customer rows.
The failure mode is permission creep. Roles get widened for a one time task and never narrowed again, and two years later half the team can export the customer table. Quarterly access audits catch that, and revoking access on departure has to be a step in offboarding rather than something someone remembers.
GDPR Is Three Capabilities You Have to Build
Right of access, right to erasure, right to rectification. Export everything you hold on a customer, delete everything on request, correct what is wrong. If you sell to anyone in the EU, which includes any EU visitor regardless of where the business sits, those are system capabilities, not a paragraph in the privacy policy.
Most platforms ship tooling for the core store. The gap is almost always the custom integrations: the analytics warehouse, the help desk, the email provider, each holding copies that nobody wired into the erasure path.
The Dependency Tree Is the Attack Surface
Platform, plugins, themes, operating system, PHP version, database, and every third party integration. Each one has vulnerabilities that get discovered and patched on someone else's schedule. WooCommerce stores carry more of this than most, since the WordPress plugin ecosystem varies enormously in maintenance quality.
Supply chain compromise is the case worth planning for specifically. A trusted tool gets taken over upstream and your store executes it with full trust. File integrity monitoring is what turns that from an unknown into an alert.
Fraud Scoring Is an Integration, Not a Model You Build
Automated scoring reads IP against billing location, order velocity, proxy use, email age and reputation, device fingerprint continuity, and returns accept, reject or review. Signifyd, Sift and Stripe Radar all sell this as a service at per decision pricing low enough that building it in house is rarely the right call. The tradeoffs between those, along with PCI scope and incident response, are laid out in this ecommerce security guide.
What you do own is the manual review rules: first time orders above a threshold, shipping and billing mismatches, expedited shipping from new accounts, several orders from one IP in a short window. Those rules decide your human review volume, which is the difference between a queue that gets worked and one that gets ignored.
Takeaway
None of this is exotic. It is access boundaries, a patch story, an erasure path, and a review queue. All four are owned by developers rather than merchants, which is exactly why they get skipped when the security conversation only ever happens with the business side.