Skip to main content

NL-P-02: Essential Entity Requirements

NL-P-02: Essential Entity Requirements

Download PDF (3.4 MB, 176 pages)Read the full text218 requirements
Cover page of the document, as printed
Document referenceNL-P-02
VersionRC1.0
StatusWorking Document
Date31/10/206 (as printed on the cover)
Document typeResilience Requirements in support of N-P-P/W
Parent frameworkNL-SYS-01 NL-P-P/W
Scheme OwnerKingdom of the Netherlands Minister of Economic Affairs
Certification targetNL PID Providers NL EUDI Wallet Providers
Primary audienceScheme Owners, CABs, EUDI PID Providers EUDI Wallet Providers
Secondary audienceEUDI Wallet ecosystem stakeholders
Assurance levelHigh/High
How to read this page

This page summarises the document. Every statement points to the section and page of the authoritative PDF it comes from: click a reference such as §6.1, p. 10 to open that page. If this summary and the PDF differ, the PDF applies.

What this document is​

NL-P-02 specifies the common cybersecurity risk-management and cyber-resilience requirements for Wallet Providers and PID Providers that are treated, for the purposes of the NL EUDI Wallet Certification System, as NIS2 essential entities, and translates the required outcomes for essential entities into certifiable provider requirements for the Wallet Provider and PID Provider certification schemes (§1.1, p. 6). The requirements address organisational, technical, operational and physical measures to manage risks to network and information systems used for wallet and PID services and to prevent or minimise the impact of incidents (§1.1, p. 6). Certification does not by itself constitute a regulatory determination of NIS2 compliance or remove the powers of competent supervisory authorities (§1.1, p. 6).

Scope and object of certification​

  • Applies to the provider organisation and the people, processes, information, facilities, network and information systems, cloud and hosting services, cryptographic services, interfaces, suppliers, service providers and operational controls used to provide or support wallet and PID services (§1.2, p. 6).
  • Wallet Provider scope: systems and operational processes supporting wallet onboarding, activation, wallet-unit lifecycle management, security monitoring, incident handling, continuity and recovery (§1.2, p. 6).
  • PID Provider scope: identity proofing, PID issuance and binding, status services, suspension, revocation, lifecycle management, security monitoring, incident handling, continuity and recovery (§1.2, p. 6).
  • The requirements apply across the complete provider service lifecycle (§1.2, p. 6).
  • Wallet Provider and PID Provider certifications are separate subordinate certifications contributing assurance evidence to top-level certification and the national admission decision; NL-P-02 does not define those, nor product-functional or wallet-solution cybersecurity certification (§1.2, p. 6-7).
  • The certification scope "shall be documented by the applicant and agreed with the CAB" and shall identify essential services, critical systems, material locations, organisational units, outsourced functions, direct suppliers and service providers, interfaces and dependencies (§1.2, p. 7).

Who it applies to​

  • Wallet Providers and PID Providers: assessed "against the resilience expectations applicable to an essential entity"; this classification is the assurance baseline of the NL provider certification schemes and does not replace the legal classification under national NIS2 legislation (§3.1, p. 10).
  • Management bodies: "shall approve the cybersecurity risk-management measures, oversee their implementation and maintain sufficient knowledge and training"; evidence of these duties forms part of the provider assessment where it relates to the certified scope (§3.1, p. 10).
  • Applicant: documents the certification scope (agreed with the CAB) (§1.2, p. 7); identifies the competent authority, applicable reporting obligations and sector-specific cybersecurity requirements (§2.1, p. 8).
  • CAB: agrees the certification scope (§1.2, p. 7). The assessment shall distinguish between conformity with this specification and statutory supervision; CAB findings, certificates and surveillance results may support regulatory assurance but do not limit the powers of the competent NIS2 authority or replace mandatory notifications (§3.1, p. 10).
  • Centre for Cybersecurity Belgium (CCB): owner of the CyberFundamentals (CyFun®) Framework (§3.2, p. 10); not responsible for this adaptation, its completeness, its use in conformity assessment or any certification decision made under the NL EUDI Wallet Certification System (§3.3, p. 11).

Contents​

  • 1 Introduction — foreword and scope (p.6) (TOC, p. 4).
  • 2 Legal Basis & References — legal basis, normative references, parent & related documents, informative references (p.8) (TOC, p. 4).
  • 3 Relation to NIS2 & CyFun — NIS2 essential-entity baseline, CyberFundamentals Framework, copyright and disclaimer (p.10) (TOC, p. 4).
  • 4 Resilience-area1 - GOVERN — categories GV.OC, GV.RM, GV.RR, GV.PO, GV.OV, GV.SC (p.12) (TOC, p. 4).
  • 5 Resilience-area2 - IDENTIFY — categories ID.AM, ID.RA, ID.IM (p.43) (TOC, p. 4).
  • 6 Resilience-area3 - PROTECT — categories PR.AA, PR.AT, PR.DS, PR.PS, PR.IR (p.79) (TOC, p. 4).
  • 7 Resilience-area4 - DETECT — categories DE.CM, DE.AE (p.138) (TOC, p. 4).
  • 8 Resilience-area5 - RESPOND — categories RS.MA, RS.AN, RS.CO, RS.MI (p.153) (TOC, p. 4).
  • 9 Resilience-area6 - RECOVER — categories RC.RP, RC.CO (p.163) (TOC, p. 4-5).
  • 10 ANNEX (p.169), with: 10.1 Annex A key measures for assurance level 'Basic' (p.169); 10.2 Annex B additional key measures for 'Important' (p.171); 10.3 Annex C additional key measures for 'Essential' (p.173); 10.4 Annex D controls linked to the management aspects for 'Important' (p.174); 10.5 Annex E controls linked to the management aspects for 'Essential' (p.176) (TOC, p. 5).

Key points​

  • Framework basis: the document is based on NIS2 (Directive (EU) 2022/2555, in particular Articles 20, 21 and 23) as legal context and uses the CyberFundamentals (CyFun®) Framework control structure (§2.1, p. 8; §3.2, p. 10-11; §3.3, p. 11).
  • Assurance level: the normative reference is "The CyberFundamentals Framework, Essential assurance level, including the cumulative Basic and Important requirements, key measures and management-aspect controls identified by that framework" (§2.2, p. 8).
  • The control set implements an all-hazards approach and covers at least the NIS2 Article 21 domains (risk analysis policies, incident handling and reporting, business continuity and crisis management, supply chain, secure acquisition/development/maintenance including vulnerability handling, effectiveness assessment, cyber hygiene and training, cryptography, HR security/access control/asset management, MFA and secure communications) (§3.1, p. 10).
  • CyberFundamentals is derived from sources including the NIST Cybersecurity Framework, ISO/IEC 27001 and 27002, IEC 62443 and the CIS Critical Security Controls, and organises outcomes around six functions: Govern, Identify, Protect, Detect, Respond and Recover; NL-P-02 uses this structure (§3.2, p. 10-11).
  • NL-specific adaptations "shall not be represented as official CCB interpretations or as an official CCB certification scheme"; applicable law and the formally adopted NL documents prevail over CyFun in case of inconsistency (§3.3, p. 11).
  • Services offered by any assessment body "do not replace nor fulfill any accredited third-party assessment as described by the CyFun® Framework"; no assessment body can claim that its services fully meet the requirements of the CyFun® Framework, and the services cannot be considered for use in conformity assessments resulting in a presumption of conformity with the NIS2 Directive and its Belgian transposition (§3.3, p. 11).
  • Where national transposition or sector-specific rules are more specific or stricter, those prevail (§2.1, p. 8).
  • Controls are worded as "shall" statements, in all but one case followed by an "Implementation guidance" heading (see Notes); e.g. GV.OC-01.1 is followed by guidance stating its goal and that "the following should be considered" (§4.1.1, p. 12).
  • Key measures for 'Basic' include: patches and security updates installed (ID.AM-08.2); MFA required for remote network access (PR.AA-03.2); "No-one shall have administrative privileges for routine day-to-day tasks" (PR.AA-05.4); backups stored on a different system (PR.DS-11.1); logs maintained and monitored (PR.PS-04.1); firewalls and network segmentation (PR.IR-01.1, PR.IR-01.2); anti-malware (DE.CM-01.2) (§10.1, p. 169-170).
  • Additional key measures for 'Important' include a vulnerability management plan including Coordinated Vulnerability Disclosure (ID.RA-08.1) and sharing incidents with external stakeholders "including reporting significant incidents to authorities as required by law" (RS.CO-02.2) (§10.2, p. 171-172).
  • Additional key measures for 'Essential' include contractual requirements for a verifiable supplier flaw-resolution process and for reviewing suppliers' information/cybersecurity programs (GV.SC-05.2, GV.SC-05.3), mapping of external data flows (ID.AM-03-3), preventing unauthorised removal of maintenance equipment, inspecting maintenance tools and portable storage devices, and verifying security controls after maintenance (ID.AM-08.7, ID.AM-08.9, ID.AM-08.10), and control and protection of portable storage devices containing system data in transit and in storage (PR.DS-02.1) (§10.3, p. 173).
  • Management-aspect controls for 'Essential' include appointment of "a senior-level executive information security officer" (GV.RR-02.2) and specialised assessments such as vulnerability scanning and insider threat assessment on critical systems (ID.IM-03.9) (§10.5, p. 176).
  • Redundancy shall be implemented to meet availability requirements defined by the organisation, legislation and/or regulations (GV.OC-04.3) (§4.1.4, p. 15).

Requirements in this document​

All 218 entries are listed one by one, with their text and PDF page, on the NL-P-02 requirements page. You can also search them together with all other requirements.

  • Structure: Function (Resilience-area) → Category with code [XX.YY] → outcome heading (e.g. "4.1.1 GV.OC-01 The organisational mission is understood ...") → numbered controls (e.g. "GV.OC-01.1") (TOC, p. 4; §4.1, p. 12).
  • Function prefixes: GV = GOVERN (Resilience-area1), ID = IDENTIFY (Resilience-area2), PR = PROTECT (Resilience-area3), DE = DETECT (Resilience-area4), RS = RESPOND (Resilience-area5), RC = RECOVER (Resilience-area6) (TOC, p. 4-5).
  • Categories and control counts (counted in the PDF, 218 controls in total):
    • GV (40): GV.OC ORGANISATIONAL CONTEXT 9 (p.12); GV.RM RISK MANAGEMENT STRATEGY 6 (p.18); GV.RR ROLES, RESPONSIBILITIES, AND AUTHORITIES 7 (p.23); GV.PO POLICY 2 (p.28); GV.OV OVERSIGHT 2 (p.30); GV.SC CYBERSECURITY SUPPLY CHAIN RISK MANAGEMENT 14 (p.32) (§4, p. 12-42).
    • ID (55): ID.AM ASSET MANAGEMENT 28 (p.43); ID.RA RISK ASSESSMENT 15 (p.61); ID.IM IMPROVEMENT 12 (p.71) (§5, p. 43-78).
    • PR (79): PR.AA IDENTITY MANAGEMENT, AUTHENTICATION, AND ACCESS CONTROL 26 (p.79); PR.AT AWARENESS AND TRAINING 7 (p.101); PR.DS DATA SECURITY 15 (p.106); PR.PS PLATFORM SECURITY 18 (p.117); PR.IR TECHNOLOGY INFRASTRUCTURE RESILIENCE 13 (p.127) (§6, p. 79-137).
    • DE (22): DE.CM CONTINUOUS MONITORING 14 (p.138); DE.AE ADVERSE EVENT ANALYSIS 8 (p.148) (§7, p. 138-152).
    • RS (14): RS.MA INCIDENT MANAGEMENT 6 (p.153); RS.AN INCIDENT ANALYSIS 4 (p.157); RS.CO INCIDENT RESPONSE REPORTING AND COMMUNICATION 2 (p.159); RS.MI INCIDENT MITIGATION 2 (p.161) (§8, p. 153-162).
    • RC (8): RC.RP INCIDENT RECOVERY PLAN EXECUTION 4 (p.163); RC.CO INCIDENT RECOVERY COMMUNICATION 4 (p.166) (§9, p. 163-168).
  • The annexes repeat selected controls from the body by assurance level: Annex A 'Basic' key measures 13 controls; Annex B additional 'Important' key measures 9; Annex C additional 'Essential' key measures 7; Annex D 'Important' management-aspect controls 9; Annex E 'Essential' management-aspect controls 6 (§10.1-§10.5, p. 169-176). Annex B is stated to be in addition to 'Basic', and Annex C in addition to 'Basic' and 'Important' (§10.2, p. 171; §10.3, p. 173).
  • The body does not label individual controls with an assurance level; level membership is given only through the annex lists (apart from two headings in the ID.RA guidance: "Distinction from ID.RA-01.5 (CyFun® Important)" and "Distinction from ID.RA-01.4 (CyFun® Essential)") (§5.2, p. 63-64).
  • NL-SYS-01 and the applicable provider scheme (NL-P-W for Wallet Providers, NL-P-P for PID Providers): read together (§1.1, p. 6). Per §2.3 it shall be applied in conjunction with NL-SYS-01, NL-SYS-02 and the other applicable NL-SYS system documents, and NL-P-P/W (§2.3, p. 8-9).
  • NL-P-01: NL-P-02 complements its common organisational and security requirements (§1.1, p. 6; §2.3, p. 9). NL-P-03 (§2.3, p. 9). NL-P-W04* and NL-P-P04*: NL-P-02 complements the role-specific lifecycle, fraud-management and operational requirements (§1.1, p. 6).
  • Standards: ISO/IEC 17065, 17067, 27001, 27002, 27005; ETSI EN 319 401 V3.2.1 as complementary baseline; CyberFundamentals Framework (Essential level) (§2.2, p. 8). Informative: EUDI Wallet Architecture and Reference Framework; ENISA guidance on NIS2 risk-management measures, incident handling, CVD, supply chain and skills (§2.4, p. 9).
  • EU legal acts: Regulation (EU) No 910/2014 as amended by Regulation (EU) 2024/1183; Directive (EU) 2022/2555 (NIS2) Articles 20, 21, 23; CIR (EU) 2024/2690 where in scope or adopted nationally (§2.1, p. 8).
  • NL-P-W and NL-P-P refer to this document as "Essential Entity Requirements" / "Essential Entity Cyber Resilience Requirements" (NL-P-W §4.4, p. 8; NL-P-W §6.1 Table 1, p. 10; NL-P-P §4.4, p. 9; NL-P-P §6.1 Table 1, p. 11), whereas its own cover title is "Resilience Requirements for Wallet and PID Providers" (title page, p. 1).

Notes on this draft​

  • Page footers read "NL-P-01 / RC1.0" throughout instead of NL-P-02 (p. 2-176).
  • Cover date "31/10/206"; status "Working Document" on the cover vs "Release Candidate" in the history; document type "in support of N-P-P/W" (cover, p. 2; history, p. 3).
  • Copyright text contains a word split across a paragraph break: "... their only authentic source. T" / "his NL-P-02 adoption ..." (§3.3, p. 11).
  • Six control identifiers are written with a hyphen instead of a dot: GV.RR-03-1, GV.RR-03-2 (p.25), ID.AM-03-2 (p.48), ID.AM-03-3 (p.49), PR.PS-06-4 (p.126), DE.CM-03-1 (p.141); other text refers to them with dots (e.g. "DE.CM-03.1", "ID.AM-03.2") (§4.3, p. 25; §5.1, p. 48-49; §6.4, p. 126; §6.5, p. 133; §7.1, p. 141-142). ID.AM-03-3 is also written with a hyphen in Annex C (§10.3, p. 173).
  • Annex D heading "10.4.2 GV.RM-02 Risk management objectives are established and agreed to by organisational stakeholders" repeats the GV.RM-01 outcome text; in the body GV.RM-02 is "Risk appetite and risk tolerance statements are ..." (§10.4.2, p. 174; §4.2.2, p. 18).
  • 217 of the 218 controls are followed by an "Implementation guidance" heading (counted): GV.PO-01.2 has no such heading (§4.4.1, p. 28), and the heading for DE.AE-06.1 is in lower case ("implementation guidance") (§7.2.4, p. 151).

Sources​