For retail and e-commerce businesses
Cyber insurance for retail and e-commerce businesses
The short answer
Retailers and online sellers answer the standard cyber insurance questions with payment card scope on top. Carriers ask how you take card payments, what systems touch card data, and whether your storefront and point-of-sale software are patched. PCI DSS obligations come from your merchant agreement, and they overlap heavily with what the application asks.
What's different about retail and e-commerce businesses
Your scope is the question. Whether card data touches your systems at all decides how much of PCI DSS applies and how nervous an underwriter gets. A business that hands the entire payment step to a hosted processor has a much smaller story to tell than one running its own checkout or storing card numbers for repeat orders.
Account takeover is the loss retailers underestimate. Saved logins and stored payment methods make your storefront worth attacking for its customer accounts alone, and a wave of fraudulent orders creates chargebacks, angry customers and a support queue you cannot staff. Carriers reach this through the identity questions, which is why multi-factor authentication on your admin accounts is not the only identity answer that matters.
Public-facing software is your exposure. A storefront, plugins, a point-of-sale system and whatever integrations glue them together are all reachable from the internet, all updated by someone else's release schedule, and all asked about in the patching section of the form. Unpatched internet-facing software is now a leading way in.
Cards are not the only data you hold. Order history, shipping addresses, phone numbers, loyalty accounts and saved logins all live in your platform, and none of it is covered by PCI. Several states now give consumers rights over that data, including access and deletion, which means a breach brings requests as well as notifications. Carriers ask about data classification and retention to find out whether you know what you're keeping and why.
Seasonality bites here too. The weeks when an outage costs the most are the weeks nobody wants to touch production, which is how a known vulnerability sits unpatched through a whole peak season. Carriers ask for a patch cadence partly to find out whether yours has exceptions nobody wrote down.
What already applies to you, before any insurer asks
These aren't insurance requirements. They're obligations that exist whether you buy a policy or not, and the paperwork they call for is most of what an application wants to see.
PCI DSS v4.0.1
This comes from your merchant agreement, not a statute, and it applies if you accept card payments. What you must do depends on how you accept them, and reducing scope (letting a hosted processor handle the card entry) is usually cheaper than expanding controls to cover it.
State privacy and breach-notification laws
Consumer-facing businesses collect personal data across state lines, and several states now grant access and deletion rights on top of breach-notification duties. Which laws reach you depends on where your customers live rather than where you are, so a small seller with national shipping can be inside several at once.
Your merchant agreement
The obligations that bite first are usually contractual: your processor's rules, the self-assessment you attest to annually, and the fees or liability shifts that follow a card-data incident. Read what you signed, because it often requires more than you remember agreeing to.
General information, not legal advice. Whether a rule applies to your business turns on facts we don't know about it, so confirm with your own advisor.
The questions carriers weight hardest here
Every application covers the same ten control areas. All of them are written out here. These are the ones an underwriter reads twice for retail and e-commerce businesses.
How are security updates applied to your systems and software?
Why it's weighted here: Internet-facing storefronts, plugins and point-of-sale software are where unpatched software actually gets exploited.
If the answer is no: Have whoever manages IT produce a list of what's patched automatically vs. manually. That list becomes your patch-management policy's appendix.
Your written evidence: Patch & Vulnerability Management Policy §3 Patch timelines
Do you run any systems that no longer receive security updates (end-of-life)?
Why it's weighted here: Point-of-sale hardware and back-office machines outlive their support windows, and carriers ask about unsupported systems by name.
If the answer is no: Replace what you can; isolate what you can't (separate VLAN, no internet). Either path turns a 'no' answer into a defensible one.
Your written evidence: Patch & Vulnerability Management Policy §4 End-of-life (EOL) systems
How is your critical business data backed up?
Why it's weighted here: An encrypted order system during peak season is a revenue event, not an IT event.
If the answer is no: Stand up automatic off-site backup for critical systems this week, then schedule a restore test.
Your written evidence: Backup & Recovery Policy §3 How we back up (the 3-2-1 rule)
Do you review the security of vendors who access your systems or data?
Why it's weighted here: Your platform, payment processor, fulfilment and marketing tools all touch customer data.
If the answer is no: Start with the inventory: every vendor with system or data access, what they touch, and whether they have MFA. Ten vendors, one page, one hour.
Your written evidence: Vendor & Third-Party Risk Policy §3 Before we sign: proportionate diligence
Evidence to have ready
- How you accept card payments, and which systems (if any) touch card data
- Your current PCI self-assessment questionnaire type, and when you last completed it
- A patch cadence in writing, including who updates the storefront and its plugins
- An inventory showing nothing internet-facing is running an unsupported version
The written half of that list is what the Readiness Pack is: Patch & Vulnerability Management Policy, Data Protection & Classification Policy, Backup & Recovery Policy, Vendor & Third-Party Risk Policy, each personalized to your business and mapped to the question it answers.
Common questions
Our payments go through a hosted checkout. Does PCI still apply?+
Yes, but far less of it. Using a hosted or redirected payment page keeps card data out of your systems, which reduces what you have to do and usually means a shorter self-assessment. Say so on the cyber application, because it genuinely lowers your risk profile and underwriters read it that way.
Does PCI compliance mean we'll pass the cyber application?+
No, though it helps. PCI is about card data. The cyber application asks about the whole business: MFA, endpoint protection, backups, training, incident response. A PCI-compliant retailer with no tested backup still has a gap the form will find.
Do we have to answer for our marketing and fulfilment tools?+
Yes. Anything with access to customer records counts as a third party holding your data, and the vendor question on the application covers all of it: email marketing, reviews, chat widgets, analytics, fulfilment. Keep an inventory with what each one can see. Removing two tools you stopped using is often the fastest way to shrink the answer.
We run our store on a popular platform with plugins. What's the risk?+
Plugins are the usual answer. Each one is third-party code with its own update cycle and its own abandonment risk, and an out-of-date plugin on a live storefront is an exposed, well-documented target. Keep a list of what's installed, remove what you don't use, and put someone's name against updating the rest.
Sources
See where your practice stands, free
Sixteen questions, five minutes, a score across the ten control areas underwriters probe, and your three biggest gaps with the fix for each. No email needed for the score.