NIS2 checklist: the ten elements of the duty of care, and the evidence that goes with them
Published · Updated
The duty of care in the Cyberbeveiligingswet (Cbw), the Dutch NIS2 act, requires appropriate and proportionate measures to manage the risks to your network and information systems. Article 21, third paragraph lists ten elements those measures must at least cover, lettered a to j. The Cyberbeveiligingsbesluit works them out in articles 5 to 18.
Almost every organisation has a list of measures. What is usually missing is the evidence. That is why the decree keeps using the same formula: policy that is recorded in writing and demonstrably applied. This checklist sets out, per element, what the rules ask and what evidence goes with it.
First: one management system
Under article 6 of the Cyberbeveiligingsbesluit you operate a management system so that you can demonstrably meet the duty of care. You set roles, responsibilities and powers, and separate conflicting roles as far as possible. The board approves the measures (article 24).
The decree prescribes no standard and requires no certificate; its explanatory note names an information security management system such as the ISO 27000 series as an example. Only for essential entities in the government sector, water authorities excluded, does the sector regulation make ISO 27001 mandatory. If you already run such a system, hang the ten elements on it rather than next to it.
a. Risk analysis and security policy
Policy on risk analysis and information system security, worked out in articles 6 and 7 of the decree. It asks for a risk-management method with risk-acceptance criteria, an overview of the risks and the security requirements that follow from it. The evidence:
- An adopted, dated security policy and risk-management policy.
- The method and the criteria you use to decide which risk is acceptable.
- A current risk overview, with the security requirements you derived from it.
b. Incident handling
Worked out in article 8 of the decree: set roles and procedures for detecting, analysing, handling, documenting, reporting and learning from incidents, monitoring of relevant events, and logs kept for a predetermined period and protected against unauthorised change. How you report is explained in the notification duty in three stages. The evidence:
- An incident policy with procedures and names against the roles.
- The log retention period you set and how the logs are protected against change.
- An incident register, including what you learned from each incident.
c. Business continuity and crisis management
Worked out in article 9: a continuity policy, a business continuity plan, a recovery plan and a crisis-management plan, all tested periodically. Backups are made and their reliability is verified periodically. The evidence:
- The three plans, adopted and dated.
- Reports of backup restore tests.
- Reports of crisis-plan exercises, with the points for improvement.
d. Supply chain
Direct suppliers and service providers fall within your duty of care. For each supplier you weigh its specific vulnerabilities, the quality of its products and security practices and its secure development procedures (article 21, fourth paragraph). Article 10 of the decree asks for a policy on your dependencies and a periodic check that direct suppliers meet your security requirements. The evidence:
- An overview of suppliers and the dependencies that affect security.
- An assessment per direct supplier, and the date of the last check.
- The security requirements as included in contracts.
e. Acquisition, development and maintenance
Security in acquiring, developing and maintaining systems, including vulnerability handling and disclosure. Article 11 asks for security requirements when buying software, hardware and services, where applicable procedures for secure development, and maintenance procedures covering at least configuration management and change management. The evidence:
- Security requirements in procurement and tender documents.
- Recorded configurations and a change log.
- A procedure for handling and disclosing vulnerabilities.
f. Assessing effectiveness
Policies and procedures to assess whether the measures work. Article 18 asks for a periodic evaluation of their effectiveness and their effects in practice, recorded in writing, and adjustment where needed. Targeted warnings about vulnerabilities or threats are assessed and recorded too (article 17). Without this element, the other nine are asserted rather than demonstrated. The evidence:
- Dated evaluations or internal audits, with their findings.
- The actions that followed those findings.
- A record of warnings received and what you did with them.
g. Cyber hygiene and training
Article 12 asks that staff, as far as relevant to their role, are aware of the risks and apply basic cyber hygiene practices, and that anyone with a security role is trained regularly. Board members have separate requirements under article 24. The evidence:
- An awareness programme with participation per employee.
- An overview of who holds a security role, with the training they followed.
h. Cryptography
Article 13 asks for a policy and procedures on the use of cryptography that state at least when you use cryptography, which types of encryption you use and how, who is responsible for implementation and who for key management. The evidence:
- A cryptography policy that answers those four points.
- A record of key management: who, which keys, which periods.
i. Personnel, access and assets
Three articles work this out. Article 14 asks you to designate staff with security roles, review that designation periodically and set reliability requirements where appropriate. Article 15 asks for a policy on logical and physical access and a periodic review of identities, authentication means and authorisations. Article 16 asks for an asset classification, rules for acceptable use and a complete, current inventory. The evidence:
- An access policy and dated reviews of access rights.
- A complete, current asset inventory, with classification.
- The designation of security roles and the reliability requirements that go with them.
j. Authentication and secure communication
Where appropriate: multi-factor or continuous authentication, secured voice, video and text communication, and secured emergency communication within the organisation. Because the law says 'where appropriate', the substantiated choice is what counts here. Under article 9, the crisis plan also describes emergency communication where appropriate. The evidence:
- An overview of where multi-factor authentication applies, and the reason where it does not.
- The agreed secure communication means, including for emergencies.
Where to start
Start with element a. Under article 7 the security requirements follow from the risk overview, and articles 10 and 11 refer back to those requirements for suppliers and procurement. Without a risk overview, the other elements have nothing to stand on.
Then check per element not whether a measure exists, but whether you can demonstrate it: is the policy adopted and dated, is there a report of the last test or review? The largest gap between 'exists' and 'demonstrable' sets the order. Element f closes the loop: a periodic evaluation keeps the evidence current.
Read alsoDoes the Cyberbeveiligingswet apply to your organisation?
From checklist to evidence file
We set up the ten elements and keep the evidence current, on one management system for NIS2 and ISO 27001.
See how we set up the duty of care