0%
0 of 56 answered
Governance & Risk Framework
0/5
Risk Analysis & Security Policies
0/5
Incident Handling — Internal Capability
0/4
Incident Reporting Obligations
0/9
Business Continuity & Crisis Management
0/5
Supply Chain Security
0/5
Secure Acquisition & Development
0/3
Vulnerability Management
0/3
Cryptography
0/3
HR Security & Training
0/3
Access Control
0/4
Asset Management
0/2
MFA & Secured Communications
0/4
Registration & Regulatory Engagement
0/1

🇪🇺 NIS2 Directive Compliance Assessment

Auto-saved to your browser
Sector & size: Not set
Governance & Risk Framework 0/5 ▼
Does your management body formally approve and oversee the cybersecurity risk-management measures in place?
NIS2 Article 20(1). Management bodies (boards of directors, executive management) must approve, oversee, and be trained on the cybersecurity risk-management measures the organisation takes, and can be held individually liable for infringements of Article 21.
Do members of your management body undergo dedicated cybersecurity training to understand and assess cyber risk?
NIS2 Article 20(2). This is a distinct, board-level training obligation separate from the general staff security-awareness training required under Article 21(2)(g) — management must gain sufficient knowledge to identify risks and evaluate cybersecurity risk-management practices.
Do you have a documented, systematic risk-management framework covering all your network and information systems?
NIS2 Article 21(1). The framework must systematically identify, analyse, evaluate, and treat cybersecurity risks across the full scope of your network and information systems.
Is your risk-management framework proportionate to your size and risk exposure, and reviewed and updated on a defined cycle?
NIS2 Article 21(1)/21(3). The proportionality principle lets smaller, lower-risk entities apply lighter-weight measures while higher-risk/critical entities apply more, provided the framework is kept current through regular review.
Do you have a defined process for remediating identified compliance gaps and control weaknesses without undue delay?
NIS2 Article 21(4). Once a gap is identified, the Directive requires corrective action to move from identification to remediation quickly and demonstrably — not sit unaddressed.
Risk Analysis & Security Policies 0/5 ▼
Do you conduct a documented risk analysis process to identify and assess cybersecurity risks to your network and information systems?
NIS2 Article 21(2)(a). The risk analysis must specifically address the security of network and information systems, not just general business risk.
Are risk assessments conducted at a defined, regular cadence rather than ad hoc?
NIS2 Article 21(2)(a). A one-off risk assessment does not satisfy an ongoing risk-management obligation — the cadence itself is what turns a point-in-time exercise into a living process.
Are risk treatment decisions documented and tracked to closure, e.g. in a risk register or treatment plan?
NIS2 Article 21(2)(a). Identifying a risk without a tracked, owned treatment decision leaves the risk analysis process incomplete in practice, even if a report exists.
Do you have a comprehensive information system security policy, approved by management, covering the scope of the Article 21(2) measures?
NIS2 Article 21(2)(a). The Directive requires security policies covering all of the risk-management measures in Article 21(2), not a narrow acceptable-use-only policy.
Are your security policies reviewed and updated on a defined cycle?
NIS2 Article 21(2)(a). A policy that exists but is never revisited will drift out of step with the organisation's actual risk profile and control environment.
Incident Handling — Internal Capability 0/4 ▼
Do you have logging and monitoring in place capable of detecting cybersecurity incidents promptly?
NIS2 Article 21(2)(b). Incident handling starts with the ability to detect that an incident is occurring — without this, none of the reporting-timeline obligations in Article 23 can be met.
Do you have a documented incident classification and triage process, including severity levels and escalation criteria?
NIS2 Article 21(2)(b). This is the internal mechanism for deciding how serious an incident is and who needs to be told — distinct from the legal significance test in Article 23(3), which determines whether an incident must be reported externally.
Do you have documented incident response procedures with defined roles and responsibilities?
NIS2 Article 21(2)(b). A response plan with named owners for each step is what turns incident handling into a repeatable process rather than an ad hoc scramble.
Do you have documented containment and eradication procedures for cybersecurity incidents?
NIS2 Article 21(2)(b). The technical response capability — actually stopping and removing the threat — is distinct from detecting it, classifying it, or reporting it.
Incident Reporting Obligations 0/9 ▼
Do you have criteria and a process for determining when an incident meets the threshold for mandatory NIS2 reporting?
NIS2 Article 23(1) and 23(3). An incident is significant if it causes or could cause severe operational disruption or financial loss to your organisation, or considerable damage to others. "Capable of causing" is the key test — you cannot wait to see whether the damage actually materialises before treating it as significant.
Do you have the technical means and channels in place to submit incident notifications in the format your competent authority or CSIRT requires?
NIS2 Article 23(11). Meeting the reporting deadlines is only half the requirement — you also need portal access, secure communication channels, and the ability to produce structured notifications in whatever format the European Commission's implementing acts specify.
Can you submit an initial early-warning notification to your CSIRT or competent authority within 24 hours of becoming aware of a significant incident?
NIS2 Article 23(4)(a). The 24-hour clock starts when your organisation recognises that an incident meeting the significance threshold has occurred or is in progress — not when the incident technically began. This first report only needs to cover the basic facts.
Can you submit a fuller incident notification within 72 hours, including an initial severity/impact assessment and any indicators of compromise identified?
NIS2 Article 23(4)(b). This second report should give the CSIRT a clearer picture — the types of systems and data affected, estimated impact, and any indicators of compromise found so far.
Can you produce an intermediate status report to your CSIRT or competent authority on request during a live incident?
NIS2 Article 23(4)(c). Unlike the fixed-deadline reports, this one is demand-driven — the CSIRT can ask for updates at any time, typically for complex, long-running, or cross-border incidents.
Can you produce a comprehensive final incident report within one month of your 72-hour notification?
NIS2 Article 23(4)(d). The final report must cover a detailed timeline, a thorough severity and impact assessment, the root cause or threat type, and a full account of mitigation measures taken.
Do you have a process to notify affected customers or service recipients when an incident or threat could affect them?
NIS2 Article 23(2). Notifying regulators is only half the picture — when a significant incident or cyber threat could affect your customers, you need to tell them too, quickly enough that they can take protective action.
Does your incident-reporting process assess and flag whether an incident could have cross-border impact on services or entities in other EU Member States?
NIS2 Article 23(8). Cyber incidents do not stop at national borders — while CSIRTs handle the actual cross-border coordination, your organisation is the one that needs to flag the cross-border dimension in its notifications.
Do you have a policy on voluntary reporting of incidents, cyber threats, and near-misses that fall below the mandatory reporting threshold?
NIS2 Article 23(9). The Directive actively encourages voluntary reporting to strengthen the overall EU threat-intelligence picture, and gives voluntary reporters access to CSIRT support and guidance even for sub-threshold incidents.
Business Continuity & Crisis Management 0/5 ▼
Have you conducted a business impact analysis for your critical systems and services?
NIS2 Article 21(2)(c). A business impact analysis is the precursor to a genuine continuity plan — it establishes which systems and services matter most and what the impact of losing them would be.
Do you have documented business continuity plans for your critical systems?
NIS2 Article 21(2)(c). Must maintain business continuity to ensure the availability of network and information systems.
Are your business continuity plans tested on a defined, regular basis?
NIS2 Article 21(2)(c). A plan that exists on paper but has never been exercised is unlikely to work when it is actually needed.
Do you have documented backup and disaster recovery procedures, with regular recovery testing?
NIS2 Article 21(2)(c). Backup management and disaster recovery procedures are explicitly named as part of the business continuity obligation.
Do you have a crisis management plan for cybersecurity incidents, with a defined crisis team and communication procedures?
NIS2 Article 21(2)(c). Crisis management is the organisational and communications dimension of continuity — who is in charge, and how stakeholders are kept informed, during a major incident.
Supply Chain Security 0/5 ▼
Do you have defined security requirements for suppliers and third parties with access to your systems or data?
NIS2 Article 21(2)(d). Must address information security in supplier relationships — baseline is a vendor security questionnaire plus contractual security clauses.
Do you classify suppliers by risk or criticality to prioritise oversight of the ones that matter most?
NIS2 Article 21(2)(d). Not every supplier carries the same risk — a risk-based classification lets you focus assessment and monitoring effort where it matters.
Do you conduct formal third-party risk assessments before or during onboarding of critical suppliers?
NIS2 Article 21(2)(d). Must assess cybersecurity risks posed by critical suppliers — this is the pre-contract due-diligence step.
Do you monitor supplier security posture on an ongoing basis, not just at the point of initial assessment?
NIS2 Article 21(2)(d). Enhanced practice per the Directive's intent is continuous or periodic re-assessment rather than a one-time check that goes stale.
Do you assess fourth-party or concentration risk — i.e. risk from your suppliers' own subprocessors, or from over-reliance on a single critical vendor?
NIS2 Article 21(2)(d). Supply-chain attacks increasingly propagate through subprocessors your organisation has no direct relationship with, and concentration on a single critical vendor creates a single point of failure across your supply chain.
Secure Acquisition & Development 0/3 ▼
Are security requirements defined and applied when acquiring or procuring new systems or services?
NIS2 Article 21(2)(e). Must consider security in the acquisition of network and information systems — baseline is security requirements written into procurement specifications.
Do you follow a secure development lifecycle — secure coding standards, security testing, code review — for custom or in-house development?
NIS2 Article 21(2)(e). The development half of "acquisition, development and maintenance" — applies wherever your organisation builds rather than buys.
Is security considered in ongoing system maintenance and change management, not just at the point of acquisition or initial build?
NIS2 Article 21(2)(e). The Directive explicitly extends this measure to maintenance, not only acquisition and development — security review of changes to systems already in production.
Vulnerability Management 0/3 ▼
Do you have a coordinated vulnerability disclosure policy or process?
NIS2 Article 21(2)(e). "Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure." A disclosure process is how you receive and act on vulnerabilities reported by researchers or third parties.
Do you conduct regular vulnerability identification and scanning across your network and systems?
NIS2 Article 21(2)(e). Vulnerability handling starts with knowing what vulnerabilities exist in your environment.
Do you have a risk-based patching process with defined remediation timelines?
NIS2 Article 21(2)(e). Enhanced practice per the Directive's intent is SLA-driven, risk-prioritised patching rather than an undefined "patch when convenient" approach.
Cryptography 0/3 ▼
Do you have a documented cryptography and encryption policy?
NIS2 Article 21(2)(h). Must have policies and procedures for cryptography, including encryption, where appropriate.
Is encryption actually applied to sensitive data at rest and in transit on your critical systems?
NIS2 Article 21(2)(h). A policy is not the same as implementation — this checks whether encryption is genuinely applied on the systems that need it, not just documented as an intention.
Do you have documented key management procedures?
NIS2 Article 21(2)(h). Encryption is only as strong as the key management behind it — how keys are generated, stored, rotated, and revoked.
HR Security & Training 0/3 ▼
Do you conduct background checks or vetting for staff in privileged or sensitive roles?
NIS2 Article 21(2)(i). Human resources security, access control policies and asset management — the personnel-security half covers screening appropriate to the role before someone starts.
Do all staff receive regular cybersecurity awareness training?
NIS2 Article 21(2)(g). Basic cyber hygiene practices and cybersecurity training — the Directive requires this be provided to personnel generally, on a periodic basis, not as a one-off induction item.
Do staff in privileged or high-risk roles receive role-specific security training beyond general awareness?
NIS2 Article 21(2)(g)/(i). General awareness training does not cover what an administrator, developer, or finance-team member specifically needs to know about the risks tied to their own role.
Access Control 0/4 ▼
Do you have a documented access control policy?
NIS2 Article 21(2)(i). Human resources security, access control policies and asset management — the access-control half of this bundled measure.
Is there a defined process for provisioning and revoking access when staff join, change roles, or leave?
NIS2 Article 21(2)(i). Every joiner, mover, or leaver event is a moment where access rights can go wrong if the process isn't defined and followed.
Is privileged or administrative access separated from standard user access and specifically controlled?
NIS2 Article 21(2)(i). Administrative accounts carry materially higher risk than standard user accounts and warrant dedicated controls — separate accounts, least privilege, closer monitoring.
Are user access rights reviewed periodically to confirm they remain appropriate?
NIS2 Article 21(2)(i). Enhanced practice per the Directive's intent is continuous or periodic access certification, catching access that should have been revoked but wasn't.
Asset Management 0/2 ▼
Do you maintain an inventory of your IT assets, covering both hardware and software?
NIS2 Article 21(2)(i). Human resources security, access control policies and asset management — the asset-management half of this bundled measure. You cannot secure what you don't know you have.
Are assets classified by criticality or sensitivity, with an owner assigned to each?
NIS2 Article 21(2)(i). An inventory without classification and ownership tells you what exists but not what matters most or who is accountable for it.
MFA & Secured Communications 0/4 ▼
Is multi-factor or continuous authentication enforced for internal staff accessing critical systems?
NIS2 Article 21(2)(j). Stolen credentials remain the single most common way attackers gain initial access — NIS2 calls out MFA by name rather than leaving it buried inside general access control.
Is multi-factor or strong authentication extended to external ICT service providers and third parties with access to your systems?
NIS2 Article 21(2)(j). The Directive names "external ICT service management" as its own target for this measure, separate from internal staff — vendor and contractor access is a commonly overlooked gap.
Do you use secured (encrypted) channels for voice, video, and text communications where appropriate?
NIS2 Article 21(2)(j). Beyond authentication, this measure also requires secured communication channels — increasingly relevant with remote working and cross-border operations as standard.
Do you have a secured, out-of-band emergency communication system for use during an incident, in case your primary communication systems are compromised?
NIS2 Article 21(2)(j). "Secured emergency communication systems" is named explicitly in the Directive text — if your primary systems are the ones under attack, you need a way to coordinate response that doesn't depend on them.
Registration & Regulatory Engagement 0/1 ▼
Has your organisation registered with the relevant national competent authority as required under NIS2?
NIS2 Article 27(1). If your organisation falls within scope, you must register with your national competent authority, providing organisational basics (name, address, sector classification), cybersecurity contact details, and relevant technical information such as IP ranges.