NIS2 readiness checklist: seven fields on the way to verifiability

What this checklist is for

NIS2 does not call for isolated measures but for verifiable risk management across the entire IT estate. This checklist translates the obligations into seven checkable fields. It does not replace legal advice, but it does provide a solid self-assessment — and shows where the gaps lie between ambition and operational reality.

The list is available below as a PDF (German). Requesting it is data-minimising and cookieless: one email address for delivery, nothing else. No third-party tracking, no marketing pixels.

The seven fields at a glance

1. Governance and responsibilities

• Senior management has formally assumed the NIS2 obligations and has been trained.
• Roles for information security are assigned and backed with time and budget.
• Risk management is documented and reviewed regularly.
• Security policies are written down and known to staff.

2. Asset inventory

• Complete, up-to-date inventory of all endpoints, servers and network components.
• Owner and protection requirement are documented for each asset.
• Shadow IT is actively detected, not merely maintained by hand.
• The inventory is updated automatically, not via spreadsheet.

3. Patch and vulnerability management

• Defined process for applying updates, with deadlines according to criticality.
• Vulnerabilities are detected, prioritised and tracked.
• Evidence of which patch was applied when to which asset.
• Handling of systems that cannot be patched is governed (compensation, isolation).

4. Backup and recovery

• Backups run automatically and are monitored for success.
• Restoration is tested regularly, not merely assumed.
• Offline or immutable copies protect against ransomware.
• Recovery time and recovery point objectives (RTO/RPO) are defined.

5. Reporting channels and incident response

• The procedure for NIS2 reporting obligations is documented (initial notification, follow-up report).
• Responsible persons and escalation paths are designated and reachable.
• Incidents are detected, classified and logged.
• The reporting process has been rehearsed at least once.

6. Supply chain

• Critical service providers and their security level are known.
• Contractual security requirements have been agreed.
• Dependence on non-European providers has been assessed (including CLOUD Act exposure).
• Service provider access is traceable and limited.

7. Awareness and training

• Staff are trained regularly on phishing and secure behaviour.
• Training is documented and verifiable.
• Management and key roles receive in-depth training.
• A reporting culture for suspicious events is established.

From ticking boxes to keeping evidence

Ticking off a list is the first step. Beyond that, NIS2 requires you to be able to demonstrate effectiveness. This is exactly where an RMM comes in: asset inventory, patch status, backup status and incidents arise in day-to-day operations anyway and can be documented in an audit-ready form.

OneLog is set up as a sovereign RMM designed for NIS2 requirements — EU-operated in the STACKIT Sovereign Cloud, with no US cloud exposure, and with an AI agent layer that handles defined incidents autonomously. The checklist names the requirements; OneLog makes their fulfilment visible.