NIS2 Compliance Timeline: The 30/60/90/180-Day Roadmap to Audit-Readiness

Most organisations don’t fall behind on NIS2 because they misunderstand Article 21. They fall behind because they try to do all ten measures at once, discover in month four that nothing is actually finished, and hand an auditor a folder of half-built policies. A phased timeline fixes that — but only if the phases are built around checkpoints an auditor can actually verify, not arbitrary calendar blocks.

This roadmap breaks NIS2 implementation into four checkpoints — 30, 60, 90, and 180 days — each ending in a specific, testable deliverable rather than a vague “progress update.” Unlike a fixed SME-only plan, it scales: some organisations are genuinely done at day 90, and others need the full 180 days to reach audit-readiness. The article shows you which is which.

Who This Roadmap Is For

In plain terms: if your organisation falls under NIS2 as an essential or important entity, this roadmap gives you a project plan from “nothing built yet” to “audit-ready,” scaled to your size and complexity.

Your situation	Typical endpoint	Why
SME, single site, no OT/ICS, straightforward supplier list	Day 90	Ten measures fit in three governance-risk-technical passes; little to layer on top
Mid-market, multiple business units or a moderate supplier chain	Day 150-180	Supply chain classification and business continuity testing take longer to document properly
Large or essential entity, subsidiaries, OT/ICS, or cross-border operations	Day 180+ (ongoing)	Board governance, effectiveness assessment, and full audit trail require iteration, not a single pass

This is a companion to two other resources on this site, not a replacement for either. If you specifically run an SME under 250 employees and want a week-by-week task list, the 90-day NIS2 compliance plan for SMEs is more granular for that exact case — this article picks up where a fixed 90-day plan can’t, for organisations that need to keep building past day 90. And if what you actually need is the regulatory calendar — transposition dates, registration windows, when the CIR entered into force — that’s covered in the NIS2 regulatory timeline. This article is about your internal project plan, not the EU’s legislative one.

The 30/60/90/180-Day Framework at a Glance

Each checkpoint below answers one question. If you can’t answer it honestly with evidence — a signed document, a completed register, a tested plan — you’re not at that checkpoint yet, regardless of what the calendar says.

Day	Phase	Core question answered
30	Governance & Scope	Who owns this, and does it even apply to us?
60	Risk & Documentation	Where are our gaps, and are they written down?
90	Core Technical Controls	Are the ten Article 21(2) measures actually implemented?
180	Supply Chain, Continuity & Audit-Readiness	Could we hand an auditor evidence for every measure, today?

Days 1-30: Governance and Scope (Phase 1)

Effort level: Low-Medium. This phase is about decisions, not documents — most of it fits in a handful of meetings, but the decisions are load-bearing for everything that follows.

Under Article 20, the management body must approve the entity’s cybersecurity risk-management measures and oversee their implementation — and stays accountable for Article 21 compliance even after delegating day-to-day work to a NIS2 Officer or IT lead [1]. That approval has to happen in month one, not retrofitted in month five once policies already exist, because Article 20 also requires management-body members to complete cybersecurity training so their oversight is informed rather than nominal [1].

In parallel, confirm scope and register. Article 27 requires in-scope entities to submit their name, sector classification under Annex I or II, establishment address, contact details, service jurisdiction, and IP ranges to the competent authority, and to notify any change within three months [2].

Role	Owns
Board / management body	Formal approval of the risk-management programme; completes Art. 20 training
NIS2 Officer / Compliance Lead	Scope determination, competent-authority registration, project coordination
IT / Security Lead	Initial asset inventory, technical stakeholder input
HR	Early input on the training and awareness track (built out in Phase 3)

Deliverable by day 30: signed board approval, completed scope determination, competent-authority registration submitted, and a named project owner.

Days 31-60: Risk Assessment and Documentation (Phase 2)

Effort level: Medium. Article 21(2)(a) requires policies on risk analysis and information system security as the first of the ten mandatory measures [3]. You cannot write a credible risk-management policy before you know what you’re protecting, which is why this phase starts with a structured gap analysis — mapping current controls against all ten Article 21(2) letters and flagging what’s missing, partial, or undocumented. If you haven’t run one yet, the site’s 5-phase NIS2 gap analysis walks through exactly that process in more depth than this roadmap has room for.

By day 60 you should have: a documented risk assessment methodology, a populated risk register, and draft versions of the information security policy and incident-handling policy. These don’t need to be final — they need to exist in a form a reviewer could read and understand your reasoning, not a bullet-point placeholder.

Deliverable by day 60: risk register populated, gap analysis complete, draft core policies circulated for review.

Days 61-90: Core Technical Controls (Phase 3)

Effort level: Medium-High. This is where most of the remaining Article 21(2) measures get implemented in practice: incident handling (b), security in system acquisition and maintenance including vulnerability handling (e), cryptography and encryption policy (h), human resources security, access control, and asset management (i), and multi-factor authentication, continuous authentication, and secured voice, video, and text communications (j) [3].

Incident handling deserves particular care here, because Article 23 sets a strict clock: an early warning within 24 hours of becoming aware of a significant incident, a fuller incident notification within 72 hours, and a final report within one month of that notification [4]. An incident counts as significant if it causes severe operational disruption or financial loss, or if it’s capable of affecting other people through considerable material or non-material damage — either condition alone is enough [4]. The Article 23 incident notification guide and the significant-incident threshold breakdown go deeper on both points; the full Article 21 measure-by-measure guide is the reference for all ten letters if you need more than this roadmap’s summary.

If your organisation falls within the scope of CIR 2024/2690 — this applies specifically to DNS providers, cloud and data-centre providers, CDNs, managed service and managed security service providers, online marketplaces, search engines, social networking platforms, and trust service providers, not to NIS2 entities generally — the Annex adds detailed technical and methodological requirements across 13 thematic sections covering logging, access control, and cyber hygiene, among others [5]. ENISA’s technical implementation guidance, published in June 2025 after industry consultation, is the most current practical reference for applying both Article 21 and the CIR requirements [6]; the site’s own summary of that ENISA guidance and the logging and monitoring requirements breakdown translate the source documents into checklists.

This is also the checkpoint where the SME 90-day plan stops. For a straightforward SME with a short supplier list and no operational technology, day 90 with the ten measures implemented and an incident-handling procedure tested is often genuinely sufficient. Larger or more complex entities are not done yet — see the decision framework below.

Deliverable by day 90: all ten Article 21(2) measures implemented (not just documented), incident-handling procedure tested with a tabletop exercise, MFA deployed on remote and privileged access.

Days 91-180: Supply Chain, Continuity, and Full Audit-Readiness (Phase 4)

Effort level: High. Three things tend to take longer than teams expect, and they’re exactly what fills this phase: supply chain security (d), business continuity and crisis management (c), and building the evidence trail that lets you assess and demonstrate the effectiveness of everything above (f) [3].

Supply chain security under Article 21(2)(d) means classifying suppliers by criticality and documenting the vulnerabilities specific to each direct supplier — not a blanket vendor questionnaire. The supply chain security guide covers classification in more depth; this is realistically a multi-week exercise for any organisation with more than a handful of significant suppliers, because it involves contract review and supplier engagement, not just internal paperwork.

Business continuity and crisis management (c) is the other long pole: a business impact analysis, a tested continuity plan, and a disaster recovery plan take longer to build credibly than to draft — testing a continuity plan properly means running the test, not just writing that one occurred. By day 180, the goal is a complete, internally consistent evidence set: every Article 21(2) measure has a policy, an owner, and evidence it’s actually in use, and the board has reviewed a formal briefing on programme status and residual risk.

Deliverable by day 180: supply chain classification and contractual clauses in place, business continuity plan tested, effectiveness-assessment framework running, board briefing delivered, full audit pack assembled.

The Day-180 Audit Pack: What Evidence You Actually Need

An auditor doesn’t want to hear that you have a risk-management programme — they want to see it. By day 180, each Article 21(2) measure should have a named piece of evidence behind it, not just a policy title. The gaps below are the ones teams most often discover too late, when there’s no time left to close them.

Measure	Evidence an auditor will actually ask for
Risk analysis & policy (a)	Dated risk register with a methodology document, not just a policy PDF
Incident handling (b)	A tested procedure — minutes from a tabletop exercise, not just a flowchart
Business continuity (c)	A completed business impact analysis and evidence the continuity plan was actually run once
Supply chain (d)	Supplier classification register plus signed contractual security clauses, not a blanket questionnaire
Governance & training (Art. 20)	Board meeting minutes recording formal approval, and attendance records for management-body training

Teams that treat Phase 4 as “write the missing policies” instead of “produce the missing evidence” are the ones who pass day 180 on the calendar but fail the audit six months later.

Which Phase Can You Stop At? A Decision Framework

The honest answer to “how long will this take us” depends on three factors, not the calendar alone.

Factor	Pushes toward day 90	Pushes toward day 180
Entity size & structure	Single site, single legal entity	Multiple subsidiaries, cross-border operations
Supply chain complexity	Handful of well-known suppliers	Long or opaque supplier chain, critical dependencies
Operational environment	Standard IT only	OT/ICS, legacy systems, regulated sector overlap (e.g. DORA)

As a general guideline, if you score toward the left column on all three factors, day 90 with the ten measures implemented is a defensible stopping point pending your next annual review cycle. If even one factor pushes right, budget for the full 180 days — attempting to compress supply chain classification or continuity testing to hit day 90 tends to produce documentation that doesn’t survive scrutiny, which is a worse outcome than taking the extra weeks.

Effort and Cost by Phase

Costs vary widely by organisation, and the ranges below are practitioner estimates rather than a regulatory figure — treat them as a planning guideline, not a quote. As a general guideline, a gap analysis alone typically takes 8-12 weeks for a mid-sized organisation, and total remediation budgets in the range of €50,000-€200,000 are commonly cited depending on company size and infrastructure complexity, with smaller organisations toward the lower end and large or complex ones toward the upper end [7].

Phase	Effort	Typical driver of cost
1: Governance & Scope (Day 30)	Low-Medium	Internal time only — board and coordination hours
2: Risk & Documentation (Day 60)	Medium	Gap analysis, policy drafting — internal or light consultant support
3: Core Technical Controls (Day 90)	Medium-High	MFA rollout, access control tooling, incident-handling tooling
4: Supply Chain & Continuity (Day 180)	High	Supplier engagement, continuity testing, audit-pack assembly

Penalty and Enforcement Exposure If You Fall Behind

Competent authorities can order security audits, issue binding instructions, and — for essential entities — temporarily suspend certifications or seek to bar responsible managers from executive functions once earlier enforcement measures prove ineffective, independent of any fixed calendar date; these are supervisory powers the authority can exercise once an entity is in scope, not a once-a-year event [8]. Administrative fines run up to at least EUR 10 million or 2% of total worldwide annual turnover, whichever is higher, for essential entities, and up to at least EUR 7 million or 1.4% of turnover for important entities [9]. Because Article 20 makes the management body accountable for Article 21 compliance, a stalled timeline is a governance exposure, not only a technical one — which is exactly why Phase 1’s board sign-off matters as much as any later technical control.

What’s Changing: The 2026 Simplification Proposal

On 20 January 2026, the European Commission published a proposal — not yet adopted law — to amend the NIS2 Directive as part of a wider package to simplify EU cybersecurity rules, building on the Digital Omnibus package from November 2025 [10]. Among the changes under discussion is a new “small mid-cap” category, provisionally defined as entities with fewer than 750 employees and less than €150 million in annual turnover, which would generally be treated as “important” rather than “essential” entities, shifting them toward reactive rather than proactive supervision [11]. The Commission’s own proposal describes simplifying jurisdictional rules and expanding ENISA’s coordinating role for cross-border entities [10]. None of this is in force, and reporting suggests the Parliament may still push the employee threshold higher during negotiation — so build your Phase 1-4 timeline against the current rules, and treat this as a “watch this space” rather than something to plan around yet.

Frequently Asked Questions

Can we compress this timeline if we’re already partway through NIS2 work?
Yes — the checkpoints are about deliverables, not elapsed time. An organisation with an existing ISO 27001 programme, for instance, often has meaningful overlap with several Article 21(2) measures already in place, which can shorten Phases 2 and 3 considerably. The framework still holds: don’t call Phase 3 done until the ten measures are implemented, not just mapped.

What if we’re still not sure whether NIS2 even applies to us?
Resolve that in Phase 1, not later — it determines everything downstream, including whether you’re essential or important, and therefore which enforcement track applies.

Does finishing day 180 mean we’re “NIS2 compliant” permanently?
No. NIS2 compliance is a maintained state, not a one-time project. Day 180 is when your evidence trail is complete enough to withstand an audit; effectiveness assessment (Article 21(2)(f)) is meant to run on an ongoing basis after that.

Key Takeaways

A NIS2 timeline only works if each checkpoint ends in something an auditor could actually verify — a signed approval, a tested plan, a populated register — rather than a date on a calendar. Governance and scope belong in the first 30 days because everything else depends on them; core technical controls are realistically a 90-day undertaking; and supply chain, continuity, and full audit-readiness are where the honest cases stretch to 180 days. Use the decision framework above to set your own real endpoint before you start, rather than discovering it in month five.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. NIS 2 Directive, Article 20 — Governance and management-body responsibilities. nis-2-directive.com/Article_20
2. NIS 2 Directive, Article 27 — Registration requirements. nis-2-directive.com/Article_27
3. NIS 2 Directive, Article 21 — Cybersecurity risk-management measures. nis-2-directive.com/Article_21
4. NIS 2 Directive, Article 23 — Incident notification timeline and significance criteria. nis-2-directive.com/Article_23
5. Commission Implementing Regulation (EU) 2024/2690. EUR-Lex
6. ENISA Technical Implementation Guidance on cybersecurity risk-management measures, v1.0 (June 2025). enisa.europa.eu
7. NIS 2 Gap Analysis: Timeline and Cost Figures, Kiteworks. kiteworks.com
8. NIS 2 Directive, Article 32 — Supervision and enforcement for essential entities. nis-2-directive.com/Article_32
9. NIS 2 Directive, Article 34 — General conditions for imposing administrative fines. nis-2-directive.com/Article_34
10. European Commission, Proposal for a Directive on simplification measures and alignment with the Cybersecurity Act (January 2026). digital-strategy.ec.europa.eu
11. European Commission Proposes Targeted Amendments to NIS2, Global Policy Watch. globalpolicywatch.com