Is my ecommerce business directly in scope for NIS2?

It depends what you are. Online marketplaces are named in NIS2 Annex II as important entities, so a marketplace above the size thresholds (medium-or-larger, 50+ staff or over EUR 10M turnover) is directly in scope. A pure single-brand DTC shop is usually NOT a directly regulated entity, but is frequently pulled in as a supplier to an in-scope essential or important entity through the supply-chain obligations in Article 21.2(d).

Does NIS2 require penetration testing?

Not literally. NIS2 never uses the word pentest. Article 21.2 lists risk-management measures, and pentest serves as evidence for two of them: 21.2(e) security in acquisition, development and maintenance including vulnerability handling, and 21.2(f) policies to assess the effectiveness of measures. Article 24 also lets Member States require certification against European schemes.

What are the NIS2 size thresholds for ecommerce?

NIS2 uses the medium-enterprise threshold from Recommendation 2003/361/EC as the size-cap floor: 50 or more staff, or annual turnover and balance sheet above EUR 10M. An online marketplace at or above that size is an important entity. Below it, you are generally out of direct scope unless a Member State designates you, but supply-chain pressure still reaches you.

When did NIS2 take effect?

NIS2 is Directive (EU) 2022/2555. The transposition deadline for Member States was 17 October 2024. National laws vary in detail, but the Article 21 risk-management baseline and the Article 23 reporting timelines are uniform across the directive.

We are a DTC brand, not a marketplace. Why are we being asked about NIS2?

Because one of your customers is an essential or important entity, and Article 21.2(d) makes them responsible for the security of their supply chain. They pass that obligation down through contract. You end up producing pentest evidence and vulnerability-handling attestations even though you are not directly regulated.

NIS2 pentest for ecommerce: scoping Article 21 testing for online marketplaces and suppliers

NIS2 (Directive (EU) 2022/2555) reorganised EU cybersecurity regulation around sectors and entity sizes. Ecommerce sits in an awkward place. Some ecommerce is directly regulated, most is not, and a large share gets pulled in sideways through the supply chain. Getting that scope nuance right is the whole game, because scoping a pentest programme as if you were an essential entity when you are actually a mid-market supplier wastes budget, and scoping it too narrowly leaves you unable to answer your customers' security questionnaires.

This page explains where ecommerce actually lands under NIS2, what the directive requires by way of testing, and how to scope pentest as evidence rather than as a checkbox. The transposition deadline was 17 October 2024, so competent authorities and in-scope customers are already asking these questions.

Where ecommerce actually lands under NIS2

NIS2 regulates named sectors above size thresholds. The size floor is the medium-enterprise threshold from Recommendation 2003/361/EC: 50 or more staff, or turnover and balance sheet above EUR 10M. Three cases matter for ecommerce:

Online marketplaces. Named in NIS2 Annex II (digital providers) as an important entity. A marketplace above the size threshold is directly in scope and must implement Article 21 measures, register with its competent authority, and meet Article 23 reporting timelines.
Digital infrastructure and cloud providers. A headless-commerce platform, a hosting-adjacent commerce provider, or a cloud-computing service serving retailers can fall into Annex I digital infrastructure or the cloud category, which pushes it toward important or even essential status depending on the exact service and size.
Single-brand DTC shops. A pure direct-to-consumer store selling its own goods is usually NOT a directly regulated entity under NIS2. It is not a marketplace, not digital infrastructure, not cloud. It is a retailer.

The honest distinction: most DTC ecommerce is out of direct scope. But out of direct scope is not out of reach. Article 21.2(d) makes every in-scope entity responsible for supply-chain security, and they discharge that duty by pushing testing and attestation requirements down to suppliers through contract. A DTC brand that sells fulfilment, data, or a white-label storefront to an essential or important entity will be asked for pentest evidence regardless of its own regulatory status.

What NIS2 actually requires for testing

NIS2 does not literally say "penetration testing." It never uses the word. What it requires is a set of risk-management measures in Article 21, and pentest is the practical evidence for several of them:

Article 21.2(e). Security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure. This is the closest anchor. A documented vulnerability-handling process, with testing that finds vulnerabilities and evidence that they get fixed, is exactly what 21.2(e) asks for.
Article 21.2(d). Supply-chain security, including security-related aspects of the relationships between each entity and its direct suppliers or service providers. This is why suppliers get tested.
Article 21.2(f). Policies and procedures to assess the effectiveness of cybersecurity risk-management measures. Pentest is how you demonstrate the measures actually work rather than merely exist on paper.
Article 24. Member States may require entities to use certified products, services and processes under European cybersecurity certification schemes. Where this applies, testing evidence feeds the certification.

The mapping to hold in your head: pentest is evidence for 21.2(e) and 21.2(f), and supply-chain assurance under 21.2(d) is what forces that evidence to travel down to suppliers.

What supervisors and auditors actually look for

Three plausible ecommerce shapes, each with a different posture.

An online marketplace above the size threshold, important entity. The competent authority treats it as directly regulated. The questions centre on 21.2(e): what is your vulnerability-handling process, how are vulnerabilities in your seller-facing and buyer-facing platforms triaged and remediated, what is your disclosure policy, and where is the evidence that findings from the last twelve months were actually closed. They also probe 21.2(f): how do you know your measures are effective, and where is the independent testing that proves it rather than self-attestation.

A DTC fashion brand pulled in as a supplier to an essential entity. The brand runs a co-branded storefront and shares customer data with a large retailer that is itself an essential entity. The brand is not directly regulated, but its customer's Article 21.2(d) obligation lands as a contract clause. The retailer's security team sends a questionnaire asking for annual pentest evidence on the shared integration, a vulnerability-handling attestation, and incident-notification commitments. The brand has to produce supplier-grade evidence it never had to before.

A headless-commerce platform serving in-scope retailers. The platform sells API-first commerce to dozens of retailers, several of which are important or essential entities. Every one of those customers passes down a 21.2(d) expectation. The platform's supervisors and its customers both ask the same thing: how do you handle vulnerabilities in the APIs and admin surfaces your customers depend on, how quickly, and how do you assess the effectiveness of those controls under 21.2(f). Here the platform is answering supply-chain questions in bulk.

The pattern: directly regulated entities are asked to prove vulnerability handling and effectiveness on their own surface, and suppliers are asked to prove the same thing to satisfy their customers' supply-chain duty. The evidence is nearly identical; only the reason for producing it differs.

Where continuous AI pentest fits ecommerce specifically

Continuous AI pentest maps cleanly onto the NIS2 provisions that actually touch ecommerce, for three concrete reasons:

Frequent deploys and 21.2(e) vulnerability handling. Ecommerce ships constantly: new promotions, new payment methods, new landing pages, new third-party pixels and tags. Annual testing leaves long windows where new vulnerabilities live unexamined. Continuous validation gives 21.2(e) a live vulnerability-handling record instead of a stale annual snapshot.
Supplier-assurance evidence under 21.2(d). When your customer is an in-scope entity, you need to hand them ongoing assurance, not a one-year-old PDF. Continuous testing produces a fresh, repeatable evidence stream you can package for each customer's supply-chain review without re-running a bespoke engagement every time.
Payment and checkout integration surfaces. Checkout is the highest-value surface and the one that changes most through third-party integrations (payment SDKs, fraud tools, tag managers). Continuous validation of the checkout and payment-integration boundaries keeps the riskiest part of the estate under constant watch, which is where both supervisors and customers focus.

The version that does not work: a vendor that hands you raw scanner output with no triage or retest. That identifies vulnerabilities but does not evidence a handling process, and 21.2(e) is about the process, not the scan.

Procurement checklist for ecommerce CISOs scoping NIS2 pentest

Have you established your actual scope first: directly regulated marketplace or digital provider, or supplier pulled in via 21.2(d)? The scope determines everything downstream.
Does the vendor produce evidence mapped to specific Article 21 measures (21.2(e) vulnerability handling, 21.2(f) effectiveness), not a generic report?
Can the vendor package supplier-assurance evidence you can hand to in-scope customers under their 21.2(d) obligation, repeatably and without cross-customer leakage?
Does the vendor test the checkout and payment-integration surface specifically, including third-party tags and SDKs?
Does the vendor support a documented vulnerability-handling and retest workflow with closure evidence, rather than one-shot identification?
Where is your testing data stored and under which jurisdiction? For an EU entity or an EU customer's supply chain, US-hosted pentest data is a finding waiting to happen.
Can the vendor produce evidence aligned to your national competent authority's NIS2 inspection expectations where you are directly regulated?

Where Fleuret fits

Fleuret runs continuous AI pentest on ecommerce environments. We produce evidence mapped to NIS2 Article 21 measures, specifically 21.2(e) vulnerability handling and 21.2(f) effectiveness assessment, so directly regulated marketplaces and pulled-in suppliers can both answer the questions they face. We continuously validate the checkout and payment-integration surfaces where ecommerce risk concentrates, and we package supplier-assurance evidence you can hand to in-scope customers discharging their 21.2(d) supply-chain duty.

Fleuret data residency is EU by default. Customer data samples, order identifiers, and any extract from your commerce stack stay in EU infrastructure, which is what an EU entity or an EU customer's supply chain will expect.

If you are scoping NIS2 pentest for ecommerce, book a demo.

PCI DSS pentest for ecommerce: the payment-security parallel, mandatory where card data touches your own systems, and the framework that governs the checkout surface NIS2 also cares about.
NIS2 pentest for telecom: the same Article 21 framework applied to an essential-entity sector, useful for seeing how directly regulated scoping differs from supplier scoping.