Your Third-Party Sellers Are a NIS2 Art.21(2)(d) Supply Chain Risk — Here’s What Marketplace Operators Must Document

Most NIS2 supply chain guidance is written for software procurement — how to vet cloud vendors, assess SaaS providers, and add security clauses to enterprise IT contracts. If you operate an online marketplace, that guidance is necessary but not sufficient. Three supply chain vectors receive almost no coverage in published compliance material: your third-party sellers, who are legally and technically direct service providers to your platform under Article 21(2)(d); your fulfilment centre WMS partners, whose IT infrastructure sits at the threshold between a standard ICT supplier and an Annex I data centre service provider; and your payment processor integrations, where your NIS2 Art.21(2)(d) vetting obligation intersects with DORA, the separate EU framework governing those processors. This guide addresses all three, with the documentation requirements for each.

Online Marketplace Operators Under NIS2 Annex II — Who This Applies To

Under Annex II of the NIS2 Directive (EU) 2022/2555, “providers of online marketplaces” are classified as Important Entities in the Digital Providers sector. The size threshold is a two-limb OR test: meet or exceed 50 employees or €10 million in annual turnover and the Directive applies. Micro-enterprises below both thresholds are excluded unless they are the sole provider of a service critical to a member state’s economy.

“Online marketplace” is defined by cross-reference in Article 6(28) of the Directive — a digital environment where traders and consumers (or traders and traders) conclude contracts. If your platform hosts third-party sellers and enables transactions, you are in scope regardless of whether you take title to goods or operate purely as an intermediary.

As an Important Entity, your obligations include full implementation of the Article 21(1) and (2) risk management measures, incident notification to your national CSIRT under Article 23, and significant incident reporting thresholds under the Commission Implementing Regulation (CIR) 2024/2690. Penalties for non-compliance sit at €7 million or 1.4% of total worldwide annual turnover, whichever is higher. See the guides on essential vs important entity classification and the full NIS2 scope requirements for the broader compliance picture. The rest of this article focuses on Article 21(2)(d) because this is where marketplace operators most consistently underestimate their exposure.

Scope criterion	You are in scope if…
Entity type	You host third-party sellers and transactions conclude on your platform
Size (OR rule)	50+ employees OR €10M+ annual turnover
Annex II sector	Digital Providers — providers of online marketplaces
Supervision tier	Important Entity — reactive supervision, fines up to €7M or 1.4% of global turnover

Third-Party Sellers as Direct Service Providers Under Article 21(2)(d)

Article 21(2)(d) of the NIS2 Directive requires every in-scope entity to address “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” Article 21(3) adds specificity: the assessment must evaluate “vulnerabilities specific to each direct supplier and service provider” and consider “the overall quality of products and cybersecurity practices of their suppliers and service providers.” Entities must also take into account the results of any Article 22 coordinated security risk assessments of critical ICT supply chains conducted by the Cooperation Group and ENISA.

Published NIS2 compliance guidance applies Art.21(2)(d) to software vendors, cloud providers, and managed IT services. The vector that goes largely undiscussed is the third-party seller.

Consider the technical reality of your marketplace. A seller connecting to your platform authenticates through a seller portal, operates under API credentials that grant access to your systems, and may integrate third-party applications — repricing tools, inventory synchronisation software, fulfilment apps — that run against your API with the seller’s delegated permission scope. The seller is not a passive storefront user. They are a service provider operating inside your system boundary, with programmatic access and delegated permissions that differ fundamentally from a standard consumer session.

The attack surface this creates is a documented compliance gap. A compromised seller account or a malicious seller application operates under valid API credentials — it can exfiltrate buyer order data, inject fraudulent listings, or manipulate order flows without triggering anomaly detection that looks for external intrusion patterns. The NIS2 Article 22 coordinated risk assessment framework exists in part because the Cooperation Group and ENISA explicitly recognise that ICT supply chains, including third-party integrations, represent a primary attack vector.

What Article 21(2)(d) requires you to document for seller relationships:

• A Supplier Security Policy that explicitly covers seller-as-service-provider relationships, not only enterprise IT vendor relationships
• A Supplier Directory identifying all sellers granted API access above read-only tier, with access scope documented per seller
• Contractual minimum security requirements embedded in your seller agreement: an incident notification obligation (sellers must notify you within a defined window of any credential compromise or data breach involving your platform data), audit rights, and a security representation at onboarding
• A periodic review mechanism — the Art.21(3) language requires ongoing assessment of vulnerabilities specific to each direct supplier, not a one-time onboarding questionnaire

Your NIS2 supply chain security framework should map these seller-specific requirements alongside your standard IT supplier assessment process. The DSA Article 30 seller identity verification workflow (Know Your Business Customer — identity and VAT registration checks) can be unified with the NIS2 Art.21(2)(d) security assessment at onboarding, reducing compliance overhead if your legal and compliance functions manage both frameworks.

Seller API Permissions: Matching Assessment Depth to Access Level

Article 21(3) requires you to evaluate “vulnerabilities specific to each direct supplier.” For sellers, vulnerability profile correlates directly to API permission scope. The assessment obligation should scale accordingly — treating all seller integrations as equivalent risk is the most common gap in marketplace supply chain compliance, and the one most likely to surface in a supervisory review.

Access tier	Seller capability	Risk profile	Minimum assessment requirement
Read-only	View own orders and inventory reports	Low	Standard security representation clause at onboarding
Standard write	Create and edit listings, update inventory	Medium	Onboarding security questionnaire + contractual security clauses
Elevated write	Trigger fulfilment, generate shipping labels	High	Annual review, documented access justification, breach notification clause
Payment-adjacent	Access to transaction records or refund triggers	Critical	Contractual audit rights, breach notification within 24h, periodic security assessment evidence

A seller running an automated repricing system against your order management API has a fundamentally different risk profile from a seller who only uses a standard web browser to manage listings. The permissions matrix above translates Art.21(3)’s “vulnerabilities specific to each direct supplier” requirement into a proportionate, auditable framework — one that scales assessment effort to actual risk rather than applying uniform scrutiny across your entire seller base.

Fulfilment Centre WMS and the Annex I Data Centre Overlap

Your fulfilment partner is not a simple logistics provider. Modern fulfilment operations run warehouse management systems (WMS) that orchestrate inventory allocation, pick-and-pack automation, conveyor control, IoT barcode scanning, and real-time carrier API integrations. The WMS communicates with your marketplace platform continuously — order data flows in, fulfilment status flows back — and any disruption to that WMS directly and immediately affects customer orders.

Under NIS2 Article 6(13), an ICT service is “a fully or mainly ICT-based service.” A WMS provided to your marketplace as a B2B service meets that definition, making the WMS provider a direct ICT service provider assessable under Art.21(2)(d). That classification is settled. The more consequential compliance question is whether your fulfilment partner’s server infrastructure triggers Annex I classification as a data centre service provider.

Annex I lists “data centre service providers” as Essential Entities — subject to proactive supervision and higher penalties (€10 million or 2% of global annual turnover). Article 6(31) defines a data centre service provider as “structures, or groups of structures, dedicated to the centralised accommodation, interconnection and operation of IT and network equipment.” Whether your fulfilment partner’s server infrastructure meets this definition depends on the WMS deployment model:

WMS deployment model	Provider’s NIS2 classification	Your Art.21(2)(d) obligation
Cloud SaaS (vendor hosts WMS in their own data centre)	ICT service provider — Annex I or II depending on size and B2B model	Standard Art.21(2)(d) supplier assessment; request SOC 2 or ISO 27001 evidence
Vendor-managed on-premises at your fulfilment site	Vendor operates IT equipment within your operational facility	Vendor treated as critical ICT supplier; facility IT systems included in your own risk assessment scope
Operator-managed dedicated server room at the warehouse	Fulfilment partner may qualify as data centre service provider under Art.6(31)	Highest due diligence; consider whether the partner qualifies as an Annex I Essential Entity with independent NIS2 obligations

For most marketplace operators, the practical obligation is to classify the WMS provider as a high-criticality Tier 1 supplier — a fulfilment failure constitutes a significant service disruption — and to document that classification with contractual security clauses covering incident notification and access controls. The Annex I overlap question becomes material only where your partner runs significant dedicated server infrastructure on your behalf. In that scenario the partner may have its own NIS2 registration and reporting obligations, independent of your Art.21(2)(d) assessment of the relationship.

Payment Processor APIs at the NIS2/DORA Boundary

Payment processors — Stripe, Adyen, Worldpay, Mollie — are payment institutions under EU financial regulation. DORA, Regulation (EU) 2022/2554, entered into force in January 2025 and applies directly to payment institutions. Under NIS2 Article 4, where a sector-specific EU legal act requires cybersecurity risk management measures “at least equivalent in effect to those laid down in Article 21(1) and (2)” of NIS2, the NIS2 provisions do not apply to that entity for those obligations. DORA satisfies this equivalence threshold for the financial sector.

This lex specialis rule is consistently misread in two directions by marketplace compliance teams.

Misread 1: “Our payment processor is DORA-regulated, so we do not need to assess it under NIS2.”

This is incorrect. DORA’s lex specialis rule exempts the payment processor from complying with NIS2 Article 21 for its own operations. It does nothing to relieve you — the marketplace operator — of your own Art.21(2)(d) obligation to assess the payment processor as your direct service provider. You are the NIS2 Important Entity. Your Art.21(2)(d) obligation runs independently of your supplier’s own regulatory status.

Misread 2: “DORA does not apply to us as a marketplace.”

This is generally correct for marketplace operators functioning as pure intermediaries — unless your platform has been authorised as a payment institution or e-money institution in its own right. In that case, DORA applies to you directly, creating a dual-framework compliance situation that warrants specialist legal analysis.

What DORA standards mean for your Art.21(2)(d) assessment

DORA Articles 28 through 44 establish ICT third-party risk management requirements for financial entities — including how they must assess, monitor, and exit from critical ICT service provider relationships. These standards represent the regulatory floor for what resilient payment processing infrastructure must look like. For a marketplace operator assessing Stripe or Adyen under NIS2 Art.21(2)(d), referencing DORA’s third-party risk framework as part of your assessment methodology has a practical advantage: DORA-regulated payment processors already produce compliance documentation against these standards, making your evidence collection more efficient and your Art.21(2)(d) assessment record more defensible.

Documentation to collect from payment processor integrations under Art.21(2)(d):

• ISO 27001 certification or SOC 2 Type II report (Tier 1 evidence of security controls)
• Contractual incident notification SLA — obligation to notify you within 24h of any incident affecting your integration
• Data access scope documentation — what cardholder data does the processor handle versus what remains on your infrastructure?
• PCI-DSS v4.0 compliance attestation (parallel obligation for payment card data environments)
• Sub-processor disclosure list — payment processors use clearing houses and acquiring banks; obtain the current list and assess concentration risk
• API security specifications — TLS version, authentication requirements, webhook signature validation mechanisms

See the Article 23 incident notification guide for how a payment processor incident cascades into your own NIS2 reporting obligations.

Building the Three-Tier Supplier Register

Article 21(3) requires you to evaluate vulnerabilities specific to each direct supplier. In practice this means a register — not a spreadsheet of vendor names, but a documented criticality classification with corresponding assessment requirements and auditable evidence of periodic review. For online marketplace operators, a three-tier structure maps directly to the risk profile of each supplier category.

Tier 1 — Critical
Payment processors (cardholder data, transaction integrity, operational continuity); core cloud infrastructure (CDN, DNS, hosting platform); WMS providers with operational dependency; seller portal API platform if third-party managed.
Assessment cadence: Annual security review, contractual audit rights, breach notification clause within 24h, documented Art.21(3) vulnerability assessment, CIR 2024/2690 significant incident threshold alignment.

Tier 2 — Important
Seller identity verification and KYC services; logistics and carrier API integrations; fraud detection services; customer support platforms with access to transaction data.
Assessment cadence: Biennial review, security representation confirmed in contract, incident notification clause with 72h obligation.

Tier 3 — Managed Risk
Lower-criticality seller apps (analytics, marketing tools); review and rating platforms; email and notification infrastructure.
Assessment cadence: Onboarding security questionnaire, contractual minimum security terms, no fixed review cadence unless an incident occurs.

Register column	Purpose
Supplier name and service type	Identity and classification basis
Access to network/information systems (scope)	Art.21(2)(d) trigger and extent
Criticality tier (1/2/3)	Determines assessment intensity and cadence
Last assessment date	Review cadence evidence
Contractual security clauses confirmed (Y/N)	Compliance evidence
Next review due	Forward obligation tracking

What NIS2 Supervisors Look For — and the Penalty Exposure

As an Important Entity, online marketplace operators face reactive supervision under Article 32. A competent authority initiates a supervisory review when it has grounds to believe a compliance gap exists, or following a significant incident. The measures available include on-site inspections, security audits, and demands for documented compliance evidence.

For Art.21(2)(d) supply chain compliance specifically, a supervisory review is likely to request:

1. Your Supplier Security Policy — does it explicitly address the three marketplace-specific vectors discussed in this article: seller API relationships, WMS and fulfilment partners, and payment processor integrations?
2. Your supplier register with criticality classifications and evidence of periodic review against those classifications
3. Sample contractual security clauses from Tier 1 and Tier 2 supplier agreements, showing incident notification obligations and audit rights
4. Evidence of at least one supplier security assessment having been conducted — date, scope, and outcome documented
5. Article 20 management sign-off — senior management must formally approve your cybersecurity risk management measures; delegation to IT without documented management approval is a reviewable gap that shifts governance accountability

Penalties for non-compliant Important Entities are set at Article 34: at least €7 million or 1.4% of total worldwide annual turnover, whichever is higher. Article 20(2) of the Directive places formal governance responsibility for cybersecurity risk management measures on the management body and requires their explicit approval — boards that have not documented that sign-off face compounded enforcement exposure where a significant incident occurs. For jurisdiction-specific enforcement approaches across member states, see the NIS2 penalties and enforcement guide.

Frequently Asked Questions

Are micro-enterprises excluded from NIS2 supply chain obligations?

Yes. Article 2(2) of the Directive applies an explicit size floor. Micro-enterprises with fewer than 10 employees and under €2 million in annual turnover are excluded from NIS2 unless they are the sole provider of a service critical to a member state’s economy. Most marketplace operators above the €10M turnover or 50-employee threshold qualify as at least a medium enterprise and are fully in scope.

Does Art.21(2)(d) require an individual security assessment for every seller on my platform?

No. The assessment obligation targets sellers who function as direct service providers — specifically those with API access to your platform systems. Sellers operating only through your standard web interface without API integration have a substantially lower risk profile. A tiered approach based on API access level, as set out in the permissions matrix above, is the most proportionate approach and the one most likely to satisfy a competent authority reviewing your compliance framework.

Our fulfilment centre is outside the EU. Does NIS2 still apply to that supplier relationship?

The NIS2 Directive applies to entities established in the EU. Your own Art.21(2)(d) assessment obligation extends to all direct service providers regardless of their location. The supplier itself is only directly subject to NIS2 if it meets EU establishment and size criteria. Your obligation is to document the relationship and impose contractual security requirements appropriate to the criticality tier — the supplier’s own NIS2 status is a secondary consideration to your risk management documentation.

We use Stripe Connect with sub-merchants. Are sub-merchants also our Art.21(2)(d) supply chain risk?

Stripe is your direct service provider and the primary Art.21(2)(d) relationship to document. Sub-merchants transacting through your Stripe Connect implementation are generally customers or third-party sellers — not direct service providers in the Art.21(2)(d) sense. Your Stripe security assessment should document the sub-merchant data model and confirm what cardholder data flows through your integration versus what Stripe handles exclusively, since this also determines your PCI-DSS scope in parallel.

Sources

1. Directive (EU) 2022/2555 of the European Parliament and of the Council (NIS2 Directive) — EUR-Lex. Official Journal of the European Union. Canonical primary source for all article citations.
2. NIS2 Directive, Article 21 — Cybersecurity risk-management measures — NIS-2-Directive.com (readable mirror of EU primary text). Source for Art.21(2)(d) and Art.21(3) verbatim text.
3. NIS2 Directive, Article 6 — Definitions — NIS-2-Directive.com. Definitions for online marketplace (Art.6(28)), data centre service provider (Art.6(31)), ICT services (Art.6(13)).
4. NIS2 Directive, Article 22 — Coordinated security risk assessments of supply chains — NIS-2-Directive.com. (linked in body above)
5. NIS2 Directive, Article 4 — Sector-specific Union legal acts (lex specialis provision) — NIS-2-Directive.com. (linked in body above)
6. NIS2 Directive, Annex II — Other critical sectors: Digital Providers — enobyte.com. (linked in body above)
7. NIS2 Directive, Annex I — Sectors of high criticality — enobyte.com. Data centre service providers and ICT service management (B2B) Essential Entity classification.
8. NIS2 vs DORA: EU Digital Resilience Comparison — Standardful. Analysis of NIS2 Article 4 lex specialis and DORA scope for payment institutions.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.