NIS2 Readiness Assessment: Compliance Checklist Guide

NIS2 readiness assessment guide for the EU cybersecurity directive

By October 2024, EU Member States had to transpose NIS2 into national law. After that, regulators got sharper tools, and companies got tighter clocks. The incident reporting timeline is now 24 hours for an early warning, 72 hours for a detailed notification, and a final report within 30 days.

That timeline forces real operational discipline, not slide decks. It also turns “security maturity” into something you can measure in the middle of a crisis. This guide walks through how to run a NIS2 readiness assessment as a Series A or early Series B CTO, and how to turn the results into work your teams can actually ship.

What is the NIS2 Directive and who does it apply to?

NIS2 is the EU’s updated network and information security directive. It expands the original 2016 NIS scope and sets baseline security and reporting duties for more sectors. It covers both essential entities and important entities, with enforcement and fines tied to the category.

Most CTOs I talk to in 10 to 100 engineer companies run into NIS2 in one of three ways:

You operate in a covered sector in the EU.
You sell into covered entities, so customers push NIS2 clauses into contracts.
You’re part of the digital supply chain, like cloud, SaaS, MSP, or identity.

Size matters, but it’s not the only filter. Many summaries use a practical threshold: 50+ employees or €10 million turnover or balance sheet for “medium” entities, and higher thresholds for “large” entities. Wire’s 2025 overview uses those size bands and ties them to NIS2 scoping discussions in practice. It also calls out the governance and reporting pressure that lands on executives, not just security teams. See Wire’s NIS2 compliance guide.

The directive also pushes Member States to formalize who is in scope. By 17 April 2025, Member States must establish lists of essential and important entities and update them at least every two years. That matters for startups because “we’re not listed” isn’t a plan. It’s a guess that can expire. See the timeline notes at nis-2-directive.com and Puppet’s summary of key dates at Puppet’s NIS2 timeline.

A working CTO definition

NIS2 readiness means the company can show three things on demand:

Risk control: security measures exist, run, and get checked.
Crisis execution: the team can meet the 24 to 72 to 30 reporting clock.
Supplier control: third parties get assessed, contracted, and monitored.

That definition is useful because it maps to evidence, not intent.

NIS2 directive compliance checklist: what “good” looks like in a 10 to 100 engineer company

Search results for “NIS2 directive compliance checklist” often read like a big enterprise program. That falls apart for Series A and B teams. You need something that fits a small security function, a fast product cycle, and a board that wants plain language about risk.

Here’s a checklist that works as a readiness baseline. It’s written as outcomes you can prove:

Governance: a named owner, a board level risk cadence, and written policies.
Asset inventory: systems, data stores, and critical dependencies are listed.
Access control: MFA on admin paths, least privilege, and joiner mover leaver.
Logging: central logs for auth, cloud control plane, and production changes.
Detection: alerting that catches account takeover and ransomware patterns.
Backups: tested restores for crown jewel systems, with RPO and RTO targets.
Vulnerability management: patch SLAs, scanning, and a tracked exception path.
Incident response: an on call rota, runbooks, and a reporting workflow.
Supplier security: tiered vendor list, contract clauses, and ongoing checks.
Training: role based training for engineers and managers, not only phishing.

A lot of guides stop at the checklist. The gap is evidence. Regulators and customers will ask “show me,” not “tell me.” So each line item needs an artifact you can hand over without scrambling.

A simple evidence set for a 50 person engineering org looks like this:

A one page security policy and a board deck slide that shows ownership.
A CMDB lite spreadsheet or cloud inventory export, updated monthly.
Screenshots or config exports for MFA and privileged access.
A log routing diagram and retention settings.
A backup restore test ticket with timestamps and results.
A vulnerability report with patch closure rates.
An incident drill report and a postmortem template.
A vendor register with risk tier and last review date.

For incident reporting, the “24–72–30” clock is the forcing function. ISMS.online describes the timeline and ties it to operational steps and ISO 27001 control references. See ISMS.online on the NIS2 reporting timeline. Sygnia’s readiness guide also calls out the same 24 hour and 72 hour deadlines, plus a final report within 30 days. See Sygnia’s NIS2 readiness guide.

NIS2 readiness assessment: a practical way to run it in two weeks

A NIS2 readiness assessment fails when it turns into compliance theater. It works when it’s a short, time boxed discovery sprint that produces a ranked backlog.

Use this model.

The RACE model for NIS2 readiness

Rough scope: decide if you are in scope, adjacent, or supply chain.
Assess: map current controls to NIS2 outcomes and collect evidence.
Close gaps: ship the top fixes that reduce incident and audit risk.
Exercise: run drills and prove the reporting workflow under pressure.

RACE is link worthy because it fits a startup cadence. It also gives you a repeatable quarterly loop.

Rough scope: decide what you are, before you build a program

Start with a one hour session with legal, security, and product. You’re not trying to produce a perfect legal opinion. You’re trying to get to a working scope that drives engineering work.

Capture:

EU presence: entities, customers, and where services are delivered.
Sector mapping: do you fall into digital infrastructure, digital services, or a covered vertical.
Size: headcount, turnover, and balance sheet thresholds.
Customer pressure: which deals include NIS2 clauses.

Greenberg Traurig’s 2025 note is useful here because it highlights uneven Member State implementation and gives examples like Italy incorporating NIS2 into national law while other countries lag. That variation changes timelines and enforcement posture. See Greenberg Traurig on NIS2 obligations and Member State status.

Assess: collect evidence, not opinions

Run the assessment as a mix of interviews and system checks. If you only do interviews, you’ll get confidence instead of proof.

Interview set:

CTO or VP Eng: architecture, change control, and incident ownership.
Head of Security or security lead: detection, response, and vendor risk.
SRE lead: backups, monitoring, and on call.
Procurement or finance: vendor list, contract terms, renewal dates.

System checks:

Cloud IAM: MFA, break glass accounts, and role sprawl.
CI and CD: who can deploy, and what gets logged.
Endpoint and identity: device posture, SSO coverage, admin paths.
Backups: restore tests, not backup jobs.

The assessment output should be a table that ties gaps to risk and effort:

Gap	Likely NIS2 pain	Evidence missing	Fix effort	Owner
No tested restores	Ransomware turns into outage	Restore test tickets	2 to 5 days	SRE
No incident reporting workflow	Miss 24h deadline	CSIRT contact list, templates	3 to 7 days	Security
Vendor list incomplete	Supply chain questions fail	Vendor register	1 to 3 days	Ops
Weak privileged access	Account takeover risk	MFA proof, role review	3 to 10 days	Platform

This is also a good place to use our internal tools. Use Command Center for tracking risks, incidents, and remediation work so the assessment doesn’t die in a doc. Use ArchiMate Modeler for a simple system and dependency map so vendor and data flow questions have a clear answer.

Close gaps: pick the work that reduces reporting and outage risk

For early stage teams, the best first fixes are boring and high impact:

Centralize auth logs and cloud control plane logs.
Put MFA on every admin path, including CI secrets.
Add immutable backups for the top three data stores.
Write an incident reporting runbook with named roles.

Puppet’s NIS2 overview is blunt about what changes for covered orgs after October 2024. It points to new rules for preventing and reporting incidents and expects more spend and training, including leadership training. See Puppet on NIS2 compliance requirements and impact.

Exercise: drill the 24–72–30 clock

Most teams can write a policy in a day. Far fewer can produce a regulator grade report in 24 hours while production is on fire.

Run a two hour tabletop exercise with a real scenario:

A compromised Okta admin account.
A ransomware event on a production database.
A supply chain incident, like a compromised CI runner image.

During the drill, force these outputs:

A draft early warning message within 60 minutes.
A list of affected systems and customer impact within 3 hours.
A plan for evidence capture and chain of custody.

Glocert’s playbook explains the three stage reporting process and flags the overlap with GDPR. One incident can trigger both NIS2 and GDPR reporting, and teams need parallel workflows that stay consistent. See Glocert on NIS2 Article 23 reporting playbook.

EU cybersecurity directive requirements that hit CTOs hardest

The search query “EU cybersecurity directive requirements” often returns legal summaries. CTOs need the operational pressure points.

Incident reporting is a systems problem, not a legal problem

The 24 hour early warning requirement means you need fast detection and fast triage. It also means you need a pre built contact path to the national CSIRT or single point of contact.

If the company runs a single on call engineer at night, the reporting clock will break. That’s not a compliance issue. It’s a staffing and process issue.

A practical staffing rule for 10 to 100 engineers:

One primary incident commander per week.
One security duty officer per week, even if part time.
A backup for both roles.

This is where our incident postmortem guide and template pays off. Postmortems create the evidence trail that regulators and customers expect after the 30 day report.

Management liability changes the board conversation

NIS2 pushes accountability up the chain. Wire’s guide calls out executive accountability and the risk of penalties for management, including possible bans from management roles in some interpretations and enforcement paths. See Wire on accountability and governance under NIS2.

That changes how CTOs should talk to the CEO and board:

Stop framing security as “engineering hygiene.”
Start framing it as “operational risk with personal exposure.”

A board wants three numbers:

Mean time to detect and mean time to contain.
Patch closure rate for critical vulnerabilities.
Restore test success rate for crown jewel systems.

Use our Engineering Metrics Dashboard for DORA style delivery metrics alongside security metrics. Delivery speed without recovery capacity is a trap.

Supply chain security is where startups get surprised

NIS2 pushes supply chain assessment and ongoing monitoring. That’s hard for startups because the vendor list is long and messy.

A workable vendor tiering model:

Tier 1: identity, cloud, CI, monitoring, customer data processors.
Tier 2: billing, support tools, analytics, internal SaaS.
Tier 3: low risk tools with no sensitive data.

Tier 1 vendors need:

Contract clauses for incident notification.
A security review, even if lightweight.
A named internal owner.

If procurement isn’t a function yet, the CTO owns this until it becomes a role.

NIS2 for technology companies: what changes for SaaS, cloud, and platforms

“NIS2 for technology companies” is a common query because many teams don’t see themselves as critical infrastructure. But digital services sit in the blast radius.

SaaS companies: customer contracts become the enforcement channel

Even if a company isn’t directly listed as an essential entity, enterprise customers will push NIS2 aligned requirements into MSAs and DPAs.

Expect asks like:

24 hour notification for security incidents.
Proof of MFA and privileged access controls.
Evidence of backup restore tests.
Vendor risk management for subprocessors.

This is where build vs buy decisions show up. A startup can build a basic vendor register and incident workflow. It should buy mature tooling for logging, EDR, and identity.

Use our Build vs Buy Matrix for security and compliance tooling decisions so the team doesn’t burn a quarter building a GRC spreadsheet app.

Cloud and platform providers: shared responsibility needs written boundaries

Cloud doesn’t remove NIS2 duties. It changes where controls live.

A simple rule:

If the cloud provider secures the service, the company still secures the configuration.

So the readiness assessment must check:

IAM sprawl and unused roles.
Public storage buckets and key management.
Logging coverage for control plane events.

Critical infrastructure adjacency: the “supplier to essential entities” trap

A 40 person company that sells scheduling software to hospitals can get pulled into NIS2 expectations fast. The hospital will ask for evidence, and the sales team will promise it.

The CTO needs a standard answer pack:

Security overview and architecture diagram.
Incident response summary with reporting timelines.
Vendor list for subprocessors.
Backup and recovery summary.

That pack also reduces sales cycle time.

Enterprise implications for Series A and early Series B CTOs

Deal friction becomes a security execution problem. NIS2 clauses show up in procurement. Without evidence, deals stall for 30 to 90 days.
Shadow compliance work will eat engineering capacity. Teams will patch ad hoc for each customer. A single readiness baseline saves weeks per quarter.
Incident response becomes a board level deliverable. The 24 hour clock forces staffing, runbooks, and drills. It also forces clarity on who can speak to regulators.
Supplier risk becomes your problem. A breach at a Tier 1 vendor becomes your reporting event. That requires contract terms and monitoring, not trust.

CTO recommendations: turn readiness into a shipped program

Immediate actions

Name an owner: assign a security program owner and a backup. Put it in writing.
Build the incident clock: create templates and a contact list for the 24–72–30 workflow. Test it in a tabletop.
Prove restores: run restore tests for the top three systems and store the tickets.
Centralize logs: route identity, cloud control plane, and deploy logs to one place.

Policy framework

Risk register: track top risks, owners, and due dates in Command Center.
Vendor tiering: classify vendors into Tier 1 to 3 and review Tier 1 quarterly.
Change control: define who can deploy and how rollbacks work.

Architecture principles

Least privilege: remove standing admin access and use time bound elevation.
Recoverability by design: treat restore tests as a release gate for data stores.
Evidence by default: log security events and keep retention settings documented.

Bigger picture: NIS2 is a forcing function for operational trust

NIS2 isn’t only about fines. It’s about trust in cross border supply chains. It also sits next to other EU rules, and companies will face overlapping asks. The confusion is real, and it shows up in customer questionnaires and board risk reviews. The NIS2 directive site even calls out questions teams ask about how NIS2 relates to other acts and regulations. See nis-2-directive.com on NIS2 and related EU cyber rules.

Security spend is also trending up. The same site cites a figure that information security represents 9 percent of EU IT investments, up 1.9 percentage points from 2022. That’s a budget signal. Buyers will keep asking for proof.

The question is simple: if a regulator asked for your 24 hour early warning draft today, could your team produce it before tomorrow morning?

Use the tool: NIS2 Readiness

NIS2 Readiness Assessment Guide: A CTO Companion for the EU Cybersecurity Directive