NIS2 Compliance Checklist for Digital Providers: What Online Marketplaces, Search Engines, and Social Networks Must Do Under Annex II

Under NIS2 Directive (EU) 2022/2555, online marketplaces, search engines, and social networking platforms qualify as digital providers under Annex II — subject to Article 21 security measure obligations since October 18, 2024. This checklist covers four questions in sequence: whether your platform is in scope, what Article 21 requires for a platform architecture, where generic compliance frameworks miss the platform API access control obligation, and how to reuse DSA documentation for NIS2 efficiency. For the full dual-regulation framework and CIR 2024/2690 technical mapping, see our digital providers compliance guide.

Who Qualifies as a NIS2 Digital Provider?

NIS2 Annex II, point 6 covers three platform types, each defined in Article 6 of the directive [3]:

Platform type	NIS2 Article 6 definition
Online marketplace	A service enabling consumers and traders to conclude contracts online (Art. 6(28), referencing Directive 2005/29/EC on unfair commercial practices)
Online search engine	A digital service enabling users to input queries and receive results from, in principle, all websites (Art. 6(29))
Social networking services platform	A platform enabling end-users to connect, share, discover, and communicate across devices, including via chats, posts, videos, and recommendations (Art. 6(33))

Matching one of these definitions is necessary but not sufficient. Under Article 2(1), NIS2 applies to entities meeting the medium-enterprise threshold from EU Recommendation 2003/361/EC: 50 or more employees, or annual turnover or balance sheet exceeding €10 million [1]. Either criterion independently brings an entity into scope: a platform with 48 staff and €12 million revenue qualifies; a platform with 35 staff and €4 million revenue does not.

Article 2(2) allows member states to bring smaller digital providers into scope when the entity is the sole provider of a service essential to societal or economic activities [1]. Platforms below the standard size threshold should verify their position with the relevant competent authority rather than assuming exemption.

Scope self-assessment: three steps

Step 1: Does your service match an Article 6(28), 6(29), or 6(33) definition? → No: NIS2 digital provider rules do not apply — check other Annex I or II sectors. → Yes: continue to Step 2.

Step 2: Do you have 50 or more employees, or annual turnover or balance sheet exceeding €10 million? → No: likely outside mandatory scope — verify Article 2(2) with your competent authority. → Yes: you are an important entity under NIS2 Annex II, point 6.

Step 3: Are you established in the EU? → No: you must designate an EU legal representative under Article 26(3). The representative’s member state determines the competent authority with jurisdiction over your platform.

The 45M EU User Threshold: A Scope Confirmation for Large Platforms

DSA Article 33 designates platforms as Very Large Online Platforms (VLOPs) or Very Large Online Search Engines (VLOSEs) when they reach 45 million average monthly active recipients in the EU — approximately 10% of the EU population [6]. For platforms above that threshold, VLOP or VLOSE designation functions as a de facto NIS2 scope confirmation: any platform operating at that scale almost certainly exceeds NIS2’s medium-enterprise size threshold by a substantial margin.

The first round of VLOP designations (April 2023) included Amazon Store, Apple AppStore, Booking.com, Facebook, Google Play, Google Maps, Google Shopping, Instagram, LinkedIn, Pinterest, Snapchat, TikTok, X (formerly Twitter), Wikipedia, YouTube, Zalando, and Alibaba AliExpress; Bing and Google Search were designated as VLOSEs [6]. All are unambiguously within NIS2 digital provider scope. For platforms below the 45M EU user line, scope determination relies on Article 2’s employee and revenue thresholds — the DSA threshold is a practical indicator for large platforms, not a formal NIS2 criterion.

Important Entity Status and Penalty Exposure

Under Article 3, digital providers in NIS2 Annex II are classified as important entities rather than essential entities (Annex I). Classification determines supervision model and penalty ceiling, not the security obligation level [2]:

Classification	Supervision model	Maximum penalty (Art. 34)
Essential entity (Annex I)	Proactive, ongoing audits	€10M or 2% of global annual turnover, whichever is higher [10]
Important entity (Annex II, incl. digital providers)	Reactive, following incidents or complaints	€7M or 1.4% of global annual turnover, whichever is higher [10]

Reactive supervision means competent authorities investigate following reported incidents or external complaints rather than conducting scheduled proactive audits. Article 21’s security measures apply identically to both classifications — the supervision model determines how often regulators look, not what they expect to find [4]. Member states were required to establish initial entity lists by April 17, 2025, with biennial reviews thereafter [2]. Platforms not yet identified should treat self-registration as a priority.

The NIS2 Article 21 Compliance Checklist for Digital Providers

Article 21(1) requires “appropriate and proportionate technical, operational and organisational measures” calibrated to risk exposure, the probability and severity of incidents, and the entity’s size [4]. For platforms with significant user bases and complex third-party integrations, proportionality typically means full implementation across all 10 Article 21(2) categories. Commission Implementing Regulation (EU) 2024/2690, which entered force on November 7, 2024, adds legally binding technical and methodological requirements specifically covering online marketplaces, search engines, and social networking platforms [5]. For the full CIR Annex I technical requirements mapping, see our guide on the implementing regulation for covered entities.

Art. 21(2)	Security measure	Platform-specific implementation
(a)	Risk analysis and information security policies	Annual platform-wide risk assessment covering marketplace transaction integrity, search index manipulation risks, and social graph data security; documented treatment decisions; written information security policy tailored to platform architecture
(b)	Incident handling	Documented detection, containment, and recovery procedures; notification pipeline for 24-hour early warning → 72-hour formal notification → one-month final report to competent authority under Art. 23(4)
(c)	Business continuity and disaster recovery	Backup and recovery plans for platform-critical infrastructure; recovery time and recovery point objectives defined and tested
(d)	Supply chain security	All direct API integrators — sellers, advertisers, developer partners — classified by criticality; documented security requirements enforced at onboarding; high-criticality integrators reviewed annually
(e)	Security in acquisition, development, and maintenance	Secure software development lifecycle; vulnerability disclosure programme; patch management SLAs for critical vulnerabilities in platform components
(f)	Effectiveness assessment	Periodic review of security measure effectiveness; documented KPIs; evidence of review methodology retained for competent authority
(g)	Cyber hygiene and training	Platform-specific baseline training for all staff; documented cyber hygiene standards; phishing simulation programme
(h)	Cryptography and encryption	Encryption at rest and in transit for all user and transaction data; key management policy; algorithm standards reviewed against current ENISA guidance
(i)	HR security, access control, and asset management	Access control policy governing internal admin interfaces and external API access tiers; asset register covering platform infrastructure; screening for privileged-access roles
(j)	MFA and secure communications	MFA mandatory on all internal admin interfaces; MFA enforced or strongly recommended for seller, advertiser, and developer accounts; emergency communication systems documented

Platform API Access Controls: The Supply Chain Gap

Article 21(2)(d) requires digital providers to address supply chain security “taking into account the vulnerabilities specific to each direct supplier and service provider” [4]. For platform operators, every entity accessing the platform through an API — marketplace sellers, advertisers, social network app developers, and search engine data partners — is a direct supplier relationship within the meaning of this provision. Generic compliance frameworks typically apply Art. 21(2)(d) to software vendors and cloud infrastructure providers, overlooking the platform API ecosystem entirely.

API and third-party access control checklist (Art. 21(2)(d) and Art. 21(2)(i)):

• Documented API access policy distinguishing seller APIs, advertiser APIs, and third-party developer APIs by data access level and permitted operations
• OAuth 2.0 or equivalent for all external API authentication — API key-only access to sensitive data does not meet the Art. 21(2)(i) access control standard
• Rate limiting and anomaly detection for unusual data extraction patterns from API integrators
• Seller and advertiser onboarding: documented identity verification and security review as supply chain controls under Art. 21(2)(d)
• Third-party developer app review: security questionnaire, data minimisation confirmation, and incident notification SLA before API access is granted
• MFA required for seller and advertiser account access in line with Art. 21(2)(j)
• API deprecation procedure: credentials revoked for inactive integrators on a defined review schedule
• API access logging at the authentication layer — prerequisite for the incident detection component of Art. 21(2)(b)

Onboarding a marketplace seller or advertiser without documented security requirements is a verifiable supply chain security gap under Article 21(2)(d). An auditor reviewing evidence for this measure will expect both a criticality classification methodology and records of its application to individual integrators. For marketplace-specific supply chain obligations, see our online marketplace supply chain guide.

Reusing DSA Risk Assessments for NIS2 Art. 21(2)(a)

VLOPs and VLOSEs face an annual systemic risk assessment obligation under DSA Article 34, covering illegal content risks, fundamental rights impacts, democratic process integrity, and personal welfare risks [7]. This documentation overlaps substantially with NIS2 Article 21(2)(a)’s requirement for documented risk analysis and information security policies — and represents a meaningful efficiency opportunity for platforms required to produce both.

A DSA Article 34 assessment that includes: analysis of how platform vulnerabilities could be exploited to distribute harmful content (maps to NIS2 cybersecurity risk identification); evaluation of algorithmic integrity risks in recommender systems (maps to NIS2 information system security risk analysis); and failure mode documentation for content moderation (maps to NIS2 incident likelihood documentation) — can contribute directly to the NIS2 risk register without a separate parallel exercise.

Three steps to operationalise this overlap:

1. Add a cybersecurity-specific section to the DSA Article 34 assessment covering NIS2 Art. 21(2)(a) risk elements: network security threats, access control failure scenarios, and service disruption risks
2. Cross-reference the DSA assessment in the NIS2 information security policy using explicit document references, so competent authorities can trace the evidence chain without separate documentation
3. Maintain a cross-mapping table — DSA risk category → NIS2 risk type → Art. 21(2) measure — as an annex to either document

DSA Article 34 requires assessments to be retained for three years and made available to competent authorities on request [7]. Applying the same retention standard to the combined NIS2 risk analysis record satisfies both obligations without maintaining parallel archives. This approach does not automatically satisfy every competent authority’s specific evidence format, but it eliminates two separate annual risk assessment cycles for platforms already under DSA obligations. For NIS2-specific risk assessment methodology, see our risk assessment guide.

Registration, Incident Notification, and the EU Representative Requirement

Under Article 27, digital providers must register with the competent authority of the member state of their main EU establishment [11]. The initial registration deadline of January 17, 2025 has passed; entities not yet registered should treat this as an urgent compliance action. Registration includes: entity name, Annex II sector classification (point 6 — digital providers), member states where services are provided, IP address ranges used in the EU, and contact details for the security point of contact.

For significant incidents — with significance criteria for digital providers defined in CIR 2024/2690 [5] — the Article 23(4) notification timeline applies [9]:

• 24 hours: Early warning to the competent authority. Must state whether unlawful or malicious activity is suspected and whether cross-border impact is possible
• 72 hours: Formal incident notification with initial severity assessment and available indicators of compromise
• One month: Final report with full impact description, threat classification, mitigation measures applied, and cross-border impact assessment

Non-EU platforms offering services to EU users must designate an EU legal representative under Article 26(3) [11]. The representative’s member state determines the competent authority. This applies to any marketplace, search engine, or social platform with EU users regardless of where the company is headquartered.

Frequently Asked Questions

Does NIS2 apply to free-to-use or ad-supported platforms?

Yes. Scope is determined by entity size — employee count or revenue — not monetisation model. Platforms generating revenue through advertising, data licensing, or any other means are in scope when they meet the Article 2(1) medium-enterprise threshold [1].

Are mobile app stores covered as online marketplaces?

Based on ENISA’s Technical Implementation Guidance published in June 2025 [8], app stores fall within the digital providers category. Google Play and Apple AppStore were among the first VLOP designations under DSA in April 2023, which is widely understood to confirm Annex II, point 6 scope for these platforms.

Which competent authority supervises digital providers?

The NIS2 authority of the member state of the entity’s main EU establishment — for example, the BSI (Germany), ANSSI (France), or NCSC (Netherlands). Jurisdiction follows Article 26’s framework: where cybersecurity decisions are predominantly made, then where cybersecurity operations run, then the member state with the largest EU employee count. Non-EU entities are supervised by the authority of the member state where their EU representative is established [11].

How does NIS2 interact with GDPR Article 32 for platform operators?

Both require documented technical and organisational security measures. The most efficient approach is a single cross-mapped framework: document the control set once, referencing both the relevant NIS2 Article 21(2) sub-paragraph and the GDPR Article 32 risk-based requirement in each control’s implementation record.

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.

Sources

1. “Article 2: Scope” — NIS2 Directive (EU) 2022/2555, nis2resources.eu
2. “Article 3: Essential and Important Entities” — NIS2 Directive (EU) 2022/2555, nis2resources.eu
3. “Article 6: Definitions” — NIS2 Directive (EU) 2022/2555, nis2resources.eu
4. “Article 21: Cybersecurity Risk-Management Measures” — NIS2 Directive (EU) 2022/2555, nis2resources.eu
5. “Commission Implementing Regulation (EU) 2024/2690” — European Commission
6. “Article 33: Very Large Online Platforms and Search Engines” — Digital Services Act (EU) 2022/2065, eu-digital-services-act.com
7. “Article 34: Risk Assessment” — Digital Services Act (EU) 2022/2065, eu-digital-services-act.com
8. “NIS2 Technical Implementation Guidance” (June 2025) — ENISA
9. “Article 23: Incident Reporting Obligations” — NIS2 Directive (EU) 2022/2555, nis2resources.eu
10. “Article 34: Administrative Fines” — NIS2 Directive (EU) 2022/2555, nis2resources.eu
11. “Article 27: Registration” — NIS2 Directive (EU) 2022/2555, nis2resources.eu