NIS2 Readiness Self-Assessment
A 10-point self-check against the cybersecurity measures NIS2 expects — what each one means, what evidence demonstrates it, and where it sits on your plate versus your platform.
NIS2 turns security from good practice into a legal duty of care for organizations in scope. This is a fast way to see where you stand before that becomes someone else’s question — an auditor’s, a regulator’s, or a customer’s during procurement.
It is a readiness check, not legal advice. Use it to find your gaps; close them with whatever combination of process, people, and tooling fits.
Are you in scope?
Roughly, you are in scope if you are a medium or large organization (about 50+ staff, or more than €10M turnover) operating in one of the NIS2 Annex I or II sectors — energy, transport, banking, health, drinking and waste water, digital infrastructure, public administration, manufacturing of critical products, and others. If that’s you, the duty of care applies.
Where the deadline stands (June 2026):
- Netherlands: NIS2 is being transposed as the Cyberbeveiligingswet, expected to enter into force during 2026 once both chambers approve it. No fixed date yet.
- Belgium: Already in force since October 2024. First conformity self-assessment (CyberFundamentals or ISO 27001) was due 18 April 2026; full certification due 18 April 2027.
How to use this
For each of the ten areas below, rate yourself honestly:
- In place — implemented, and you can produce evidence today.
- Partial — some of it exists, but it’s incomplete or you couldn’t prove it on request.
- Not yet — not addressed.
The word that matters is evidence. NIS2 doesn’t ask whether you believe you’re secure. It asks whether you can demonstrate it.
The ten measures
NIS2 (Article 21) expects in-scope entities to have appropriate measures across ten areas. Here they are in plain language.
1. Risk analysis and security policies
Expected: A documented assessment of your risks and the security policies that follow from it. Evidence: A current risk assessment, dated, with owners and review cadence.
2. Incident handling
Expected: A defined way to detect, manage, and learn from security incidents. Evidence: An incident response process, run at least once, with logs and post-incident notes.
3. Business continuity and crisis management
Expected: Backups, disaster recovery, and a plan for keeping the lights on. Evidence: Tested backups (not just configured — tested), a recovery runbook, defined RTO/RPO.
4. Supply chain security
Expected: Security addressed in your relationships with direct suppliers and service providers. Evidence: Supplier security requirements in contracts; a view of which vendors touch your data.
5. Security in acquisition, development, and maintenance
Expected: Security built into how you buy, build, and run systems — including vulnerability handling. Evidence: A patching cadence, a vulnerability process, secure-configuration baselines.
6. Measuring effectiveness
Expected: Policies and procedures to check whether your measures actually work. Evidence: Regular reviews, audits, or assessments — and a record that you act on the findings.
7. Cyber hygiene and training
Expected: Basic practices and ongoing cybersecurity training for staff. Evidence: A training record, an acceptable-use policy, evidence people have read it.
8. Cryptography and encryption
Expected: Policies on the use of cryptography and, where appropriate, encryption. Evidence: Encryption at rest and in transit, documented; key management that isn’t a shared spreadsheet.
9. Access control and asset management
Expected: Human-resources security, access-control policies, and knowing what assets you have. Evidence: Least-privilege access, a joiner/mover/leaver process, an asset inventory that’s current.
10. Multi-factor authentication and secure communications
Expected: MFA or continuous authentication, and secured communications where appropriate. Evidence: MFA enforced on privileged and remote access; documented exceptions.
Reading your score
Count your answers.
- Mostly “in place”: You’re in good shape. The work now is keeping the evidence current — posture drifts, and a clean assessment from six months ago proves nothing today.
- A mix of “in place” and “partial”: Normal, and workable. Prioritize the partials you can’t currently prove, because “we do that, we just can’t show it” is the answer that fails an audit.
- Several “not yet”: Start with measures 3, 8, 9, and 10 — backups, encryption, access control, and MFA. They carry the most risk and are the most visible when someone goes looking.
What’s on your plate vs. your platform
Half of NIS2 is organizational and stays with you or your advisor: risk governance (1), incident process (2), supplier contracts (4), effectiveness reviews (6), and training (7). No tool does those for you.
The other half is technical, and it’s exactly what an automated assessment is good at: backup and recovery configuration (3), secure configuration and vulnerability posture (5), encryption and key management (8), access control and asset inventory (9), and MFA enforcement (10) — across Azure, Microsoft 365, and your identity layer.
That technical half is what PAA produces evidence for: it maps your real configuration to the NIS2 controls, attaches the evidence, exports an attestation you can hand to a regulator or board, and re-checks it on a schedule so the evidence doesn’t go stale. It won’t write your policies or run your training. It will mean you never again gather technical evidence by hand the week before a deadline.
Want the technical half handled? See how PAA produces NIS2 evidence, or start an assessment on a €99 day pass.
Need help implementing these practices?
Our team can help you apply these frameworks to your specific context.
