ISO 27001 pentest for ecommerce: what auditors expect in 2026

ISO 27001:2022 is a common security certification for ecommerce companies selling into the EU and to B2B buyers. It does not explicitly require penetration testing. Read the standard literally and you will find no mandate. Read the auditor's report template and you will find that nobody passes certification without one.

This page explains the gap between what the standard says and what auditors actually check, specifically for ecommerce: the checkout and cart flows, the third-party payment integration, the customer PII that sits under GDPR, and the difference in scope between a single DTC brand and a multi-seller marketplace.

What ISO 27001 actually says about testing

ISO/IEC 27001:2022 Annex A is the control reference. The 2022 revision restructured controls into four themes (organisational, people, physical, technological) and reduced the count from 114 to 93. The relevant ones for ecommerce pentesting:

• A.8.8 Management of technical vulnerabilities. "Information about technical vulnerabilities of information systems being used shall be obtained, the organisation's exposure to such vulnerabilities shall be evaluated, and appropriate measures shall be taken." For ecommerce, the storefront and checkout are the systems in question.
• A.8.29 Security testing in development and acceptance. "Security testing processes shall be defined and implemented in the development life cycle." Ecommerce teams that ship daily have to show testing is part of the pipeline, not a once-a-year event.
• A.5.34 Privacy and protection of PII. Ecommerce processes personal data (names, addresses, order history, payment references), so testing must demonstrate that the technical and organisational measures protect that PII effectively. In the EU this control carries GDPR weight.
• A.8.25 Secure development life cycle and A.8.28 Secure coding. Custom checkout, cart logic, and pricing code sit under these controls. Auditors expect evidence that secure-coding practices and testing catch the classes of bug that hit ecommerce hardest (injection, broken access control, business-logic abuse).
• A.5.19, A.5.20, A.5.21, A.5.22 Supplier relationships. Ecommerce runs on payment providers, hosted checkouts, tag managers, and fulfilment APIs. Supplier security must be addressed, and auditors will check whether your integration points are tested.

None of these say "do an annual pentest." All of them collectively require that you have a documented process for finding and fixing vulnerabilities, with evidence. In practice, that means an annual pentest at minimum, with continuous vulnerability management between engagements.

What auditors actually look for

Three ecommerce examples from recent ISO 27001:2022 certification audits we have observed:

A direct-to-consumer skincare brand, first-time certification. €25M/year through a headless storefront with a hosted checkout. Their auditor spent most of a day on A.8.8 and A.5.34 evidence. The questions: which vulnerabilities did you find on the storefront in the last 12 months, how did you rate them, who owns remediation priority, and specifically, how do you protect customer address and order data (A.5.34) given you are the data controller under GDPR? The brand had one annual pentest report and a Notion remediation board, but no continuous scanning and no retest evidence. They passed with a minor non-conformity: implement continuous vulnerability management within 90 days. The annual snapshot alone did not satisfy A.8.8.

A multi-seller marketplace, second surveillance audit. €120M GMV/year, with seller onboarding, payouts, and a shared product catalogue. Their auditor focused on A.8.29 and the supplier controls. The scope question came first: is seller onboarding and the payout system in scope? The auditor pushed to include them because that is where the highest-risk PII and money movement live. Then the SDLC questions: which security tests run on every commit to the marketplace app, do they block merges or only warn, what is the time-to-remediation for high-severity findings on the checkout path. Warning-only tests were flagged as insufficient for full A.8.29 conformance.

A headless-commerce SaaS selling a storefront engine to other retailers. €8M ARR, part product vendor and part ecommerce platform. Their challenge was the supplier chain: their customers inherit their security posture, and their own stack pulls in a payment orchestrator, a CDN, and a tag manager. The auditor worked through A.5.19 to A.5.22: how do you assess each of these suppliers, and are the integration points (webhooks, API contracts, embedded checkout) tested? The company had strong internal testing but no evidence that the third-party integration surface had been probed. That gap became a corrective action.

The pattern: auditors care about the evidence chain, not the test itself. A perfect pentest report on the marketing site is useless if the checkout and payment integration are where the risk lives. A modest pentest on the in-scope checkout and PII flows, with documented remediation and retest, passes.

Where continuous AI pentest fits ecommerce specifically

ISO 27001 for ecommerce rewards continuous validation for three concrete reasons:

1. A.8.8 evidence quality against frequent deploys. Ecommerce teams ship daily: new promotions, A/B tests, checkout tweaks, new payment methods. A single annual snapshot is technically compliant, but auditors increasingly read it as insufficient when the site changed a hundred times since the test. Continuous validation with weekly or monthly evidence drops makes A.8.8 unambiguous.
2. A.8.29 SDLC integration for seasonal pressure. Peak seasons (Black Friday, holiday, launch drops) are exactly when code changes pile up and testing gets skipped. Pentest tied to CI/CD keeps A.8.29 satisfied even when the release calendar is at its busiest, instead of leaving a gap right before the highest-traffic window.
3. Supplier controls (A.5.19 to A.5.22) on payment and checkout integrations. Ecommerce depends on payment providers, hosted checkouts, tag managers, and fulfilment APIs. Continuous testing of these integration points (webhook handlers, redirect flows, tokenization boundaries) generates the evidence that a third-party integration is not the back door into customer data.

The version that works:

• Continuous validation on a production-equivalent staging storefront, against every release candidate
• Annual deep pentest on production, including checkout business logic and authorization edge cases (cart tampering, price manipulation, order-lookup IDOR)
• Supplier integration testing on a quarterly cadence, covering payment and checkout endpoints
• Evidence generated automatically into the ISMS evidence repository

The version that does not work: a vendor that gives you scanner output with no human triage, no retest, and no remediation tracking. Auditors recognise scanner output as "vulnerability identification" but not as the full Annex A.8.8 process.

Procurement checklist for ecommerce CISOs scoping ISO 27001 pentest

• Does the vendor produce evidence that auditors specifically accept for A.8.8 (process), A.8.29 (SDLC integration), and A.5.34 (PII protection under GDPR)?
• Does the vendor test the full checkout and cart flow, including business-logic abuse (price tampering, coupon abuse, order-lookup access control), not just surface scanning?
• Does the vendor cover third-party payment and checkout integration points, mapped to the supplier controls A.5.19 to A.5.22?
• Does the vendor integrate with your CI/CD pipeline natively (GitHub Actions, GitLab CI, CircleCI), or require manual report uploads?
• Does the vendor produce a continuous evidence stream, or a single PDF per engagement?
• Where is your testing data stored and under which jurisdiction? For EU ecommerce holding customer PII, US-hosted pentest data is a GDPR and audit concern.
• Does the vendor support a retest workflow with documented closure, so a High finding on the checkout path is provably fixed, not deferred to next year?

Where Fleuret fits

Fleuret runs continuous AI pentest on ecommerce environments. We produce ISO 27001:2022 Annex A-mapped evidence automatically, tied to the controls auditors actually check (A.8.8, A.8.29, A.5.34, and the supplier controls). Our findings stream into the ISMS evidence repository without manual export. We integrate with GitHub Actions and GitLab CI, and we test the checkout, cart, and payment-integration surface where ecommerce risk concentrates. EU data residency by default.

For ecommerce companies preparing ISO 27001:2022 certification or a surveillance audit, our typical engagement covers continuous validation against a production-equivalent staging storefront with every release candidate, a depth-pentest engagement once per certification cycle, and supplier integration tests on the quarterly cadence ISO auditors prefer.

If you are scoping pentest for ISO 27001:2022 ecommerce, book a demo.

Related compliance reading

• PCI DSS pentest for ecommerce: the payment-card counterpart, mandatory once card data touches your own systems, often required in parallel.
• ISO 27001 pentest for SaaS: the same framework applied to B2B software, useful if your ecommerce stack includes a headless or platform product.