NIS2 compliance checklist: steps and evidence

What a NIS2 compliance checklist must cover before you hire anyone

NIS2 creates no certificate of compliance. A national competent authority decides whether your organization complies, by inspecting the evidence you can produce, through inspections, security audits, security scans and information requests. The checklist is the ordered set of steps that produces that evidence, so each step should end with a record a supervisor could read without you present. Before any consultant or platform vendor is involved, the organization should be able to say which entity it is, which sector it sits in and what proof exists for each step. Scope and classification come first, because the essential or important label sets the supervision regime and the fine ceiling that apply, and it is the entity, not the partner, that must hold that answer.

Four elements form the core of the checklist: scope and classification, management approval and training, the Article 21 risk-management measures, and incident reporting readiness. Management approval is a documented decision by the management body, and the training it requires under Article 20(2) must also be recorded. The measures are the ten minimum areas in Article 21(2), and the depth you document for each depends on your own exposure, size and the likelihood and severity of incidents, which the proportionality principle in Article 21(1) ties to your risk picture. Where the Implementing Regulation 2024/2690 allows a requirement to be qualified, any decision not to apply it must be written down with reasons. Confirm with your national authority which transposition law applies to you, since the Directive is implemented country by country.

Before you hire anyone, decide who inside the organization owns each step and what they must sign. A partner can prepare systems, controls and evidence, and an independent assessor can test them, but neither can declare you compliant or issue a certificate. Ask any proposed partner to show, in writing, which checklist items they will deliver and which remain with your staff, including approvals, risk acceptance and corrective action under Article 21(4). Those answers define the scope of any quote and tell you where your internal capacity must go. The EUR-Lex text of Directive (EU) 2022/2555 is the primary reference for confirming these obligations against your own entity.

The NIS2 compliance checklist, step by step

This sequence takes an organization from knowing whether NIS2 applies to it to a documented, approved and corrective-action-ready program that a competent authority can inspect.

Confirm scope and classify the entity
Start by checking whether the organization falls within an Annex I or Annex II sector and whether it is essential or important under Article 3. Confirm the size test, any sector-specific law that may displace NIS2, and the Member States where services are provided, because jurisdiction shapes which authority supervises you. Legal counsel or the national authority's guidance should confirm the classification, since the outcome drives supervision style and fine ceilings. The output is a signed scope memo that names the sector, subsector, classification and each Member State involved. Confirm the final classification against the NIS2 text on EUR-Lex before the memo is approved.
Register with the competent authority
Prepare the registration details Article 3(4) requires: name, address, up-to-date contact details including email addresses, IP ranges and telephone numbers, sector and subsector, and the Member States where services are provided. Confirm with each national authority how and when to submit, since registration mechanics are set nationally. Keep a copy of the submission and the authority's acknowledgment, and assign an owner to update these details when IP ranges, contacts or service locations change. The output is a registration record with dated proof of submission and a named owner for updates.
Obtain management body approval and training
The management body must approve the cybersecurity risk-management measures and oversee their implementation under Article 20(1). Table the planned measures, the risk assessment summary and the resources needed, and record the decision in board or management minutes. Members of the management body must also complete training under Article 20(2) that builds enough knowledge to assess risk and its effect on services. Record attendance, the provider and the topics covered. The output is signed approval minutes and training records for each management body member.
Run the all-hazards risk assessment
Identify systems, services, dependencies and threats, then assess likelihood and impact while weighing the proportionality factors in Article 21(1): risk exposure, entity size, incident likelihood and severity. The risk assessment is the input that justifies each measure, so the risk owner and the methodology should be written down before scoring starts. Document how each risk maps to the ten measures. The output is an approved risk register, an asset inventory and a treatment plan with named owners, reviewed at least annually under the implementing regulation's fixed cycles.
Implement the ten Article 21(2) measures
Assign each of the ten minimum measures in Article 21(2)(a) to (j) to an owner, then map it to the risks it treats and to the technical requirements in Implementing Regulation 2024/2690 that apply to your entity type. Where the regulation qualifies a requirement with 'where appropriate', 'where applicable' or 'to the extent feasible', record the decision to apply it or not, with reasoning. Collect evidence for each measure as it is put in place, such as configuration exports, policy documents, test results and access reviews. The output is a measure-by-measure control register linking each measure to its owner, risks, implementation status and evidence location.
Document proportionality decisions
Where the implementing regulation allows discretion and the entity decides not to apply a requirement, Article 2(2) requires the reasoning to be written down in a comprehensible manner. Record each decision with the requirement reference, the risk and size factors considered, the alternative controls used, and the approver. Review these decisions alongside the annual risk assessment, because a change in exposure can reverse a decision. The output is a decision log that an inspector can read without interviews, with approval dates and review dates for each entry.
Prepare incident reporting readiness
Build the process to identify significant incidents and meet the 24-hour early warning, 72-hour notification and one-month final report deadlines in Article 23(4). Define who detects, who decides significance, who submits to the authority and who informs service recipients. Test the process with a tabletop exercise and keep the timeline record. The output is an approved reporting procedure, contact lists, report templates and exercise records showing the clock was tracked. Confirm the reporting thresholds with the national authority and the relevant significant incident criteria in the implementing regulation.
Set supplier controls and corrective action
Assess the security aspects of your relationships with direct suppliers and service providers, as Article 21(2)(d) requires. Classify suppliers by criticality, include security clauses in contracts and record the assurance evidence you obtained. Then set up the corrective action process that Article 21(4) requires whenever a gap is found: log the finding, assign corrective measures that are necessary, appropriate and proportionate, and close them without undue delay. The output is a supplier register with assurance records and a corrective action log that shows gap, action, owner and closure date for each finding.

Why scope and classification come first

Classification decides how every later step is supervised, not whether the Article 21 and Article 23 duties apply. Essential and important entities carry the same risk-management measures and the same incident reporting obligations. What differs is the supervisory model: essential entities face ex ante supervision, meaning authorities can act before an failure is shown, while important entities face ex post supervision, reacting once there is evidence of non-compliance. The fine ceilings also differ between the two categories, so the label changes the financial exposure of a failed inspection. Get the classification wrong and the risk assessment, policies and evidence file may be built to the wrong level of scrutiny.

The starting test is sector and size. NIS2 lists 11 sectors of high criticality in Annex I and 7 other critical sectors in Annex II, and an entity must first match a listed sector and subsector before anything else is considered. Inside the sector test, the entity then establishes whether it is essential or important under Article 3. Confirm the exact subsector wording against the Annex text in the NIS2 Directive on EUR-Lex, and check with your national transposition law, since some Member States add or narrow entity types.

Once the classification is settled, the entity must give its competent authority a defined set of facts: its name, address and contact details including email addresses, IP ranges and telephone numbers, its Annex I or II sector and subsector, and the Member States where it provides services. Assemble this as a controlled record with an owner and a review date, because registration data goes stale when infrastructure changes. The size-cap rule and the size-independent entity categories determine whether an entity is in scope at all, and they are covered in detail on the scope and entity classification page, so settle that question there before recording the classification here.

Which evidence supports each of the ten measures

Each card names a group of Article 21 measures and the evidence a competent authority would ask to see, drawn from ENISA's evidence examples and the requirements of Implementing Regulation 2024/2690. Evidence carries weight only when it is dated, approved and consistent across the cards, and no single tool produces all of it.

Policies and risk analysis

Supervisors start with the approved information system security policy and the risk assessment behind it. Ask who approved each document, when management last reviewed it, and whether the risk assessment was reviewed within the annual cycle the implementing regulation sets. Keep a risk register that links each risk to the measure that treats it. Dated management approval is the item most often missing from an otherwise complete file.

Incident handling and reporting

Keep the incident response procedure, an incident log, and records showing how each incident was classified against the significant incident criteria. Article 23 sets a 24-hour early warning, a 72-hour notification and a final report within one month, so retain timestamps for each step. Add the quarterly assessment of recurring incidents, which shows whether the process learns. Timed reporting records show whether deadlines were met in practice, beyond what the written procedure says.

Business continuity and backup

Continuity plans, backup schedules and restore test records make up this group. Supervisors look for backups that exist, are protected from the systems they cover, and have been restored successfully. Ask for backup job logs, restore test reports with dates and results, and the recovery priorities agreed with business owners. Backup logs show that a job ran. Only restore test records show that data can be recovered.

Supplier security

A supplier register covering each direct supplier or service provider is the starting point. Article 21(2)(d) covers the security aspects of each direct relationship, so record what access each supplier holds and how often it is reviewed. Keep the security clauses in each contract, questionnaire answers from critical suppliers, and records of remediation actions you requested. A current access inventory lets you answer supplier questions quickly.

Secure development and vulnerability handling

This group covers security requirements in purchased and in-house systems, change records, and vulnerability scan results. Supervisors ask how known vulnerabilities are found, prioritized and closed. Keep penetration test reports with remediation tracking, and link change approvals to the test results that support them. Remediation tracking shows that a finding was closed, not only that it was reported.

Access control and MFA

Keep an access control policy, an inventory of privileged accounts, periodic access review records, and exports of MFA and encryption settings. Supervisors typically test whether privileged access is limited, reviewed and logged, and whether MFA covers remote and administrative access. Ask for review records and configuration exports dated to the same period. Privileged access reviews are where gaps usually appear first.

Who owns each checklist step

Article 20 places approval and oversight of the cybersecurity risk-management measures with the management body of an essential or important entity. Members must also follow training so they can identify cyber risks and judge whether the entity's practices are adequate. These duties cannot be delegated to a consultant, so the board or executive team must make the decisions and keep the records that show them.

Approval record: Minutes or written resolutions that approve the Article 21 measures and the policies behind them.
Ongoing oversight: Scheduled reviews of risk, incident and gap-closure status, with the decisions taken documented.
Training evidence: Attendance records, course content and dates for each management body member.
Residual risk acceptance: Named decisions on which residual risks the entity accepts and on whose authority.
Partner role: A consultant or vCISO may draft briefing papers and training material, but the body must review and adopt them.

Check that minutes name the measures approved, not only that a cybersecurity item appeared on the agenda.

Documenting proportionality and the measures you do not apply

Every measure you do not apply needs a written reason that someone can read and follow. Article 21(1) asks entities to size their measures to their risk exposure, their size, and the likelihood and severity of incidents. That proportionality is not a free pass. Where Implementing Regulation (EU) 2024/2690 qualifies a requirement with wording such as "where appropriate," "where applicable" or "to the extent feasible," and you decide not to apply it, Article 2(2) requires you to document your reasoning in a comprehensible manner. A checklist that simply ticks a box as "not applicable" will not meet that test, and supervisors will ask for the reasoning first.

A useful decision record names the requirement by its reference in the implementing regulation, states the qualifier that applies, and describes the entity's situation in concrete terms: which systems, services and assets are affected, what the risk assessment found for them, and what size or exposure facts drive the conclusion. It records the alternative controls in place or the compensating measures, the person who approved the decision (normally someone with accountability in the management body's oversight chain), the date, and a review date. Because the implementing regulation sets fixed review cycles for risk assessments and policies, the record should be revisited on the same cycle or sooner if the system changes. Confirm the exact review cycle for each requirement in the regulation text before you set your calendar.

Decision records matter because they show that proportionality was a reasoned choice rather than an omission. In practice, ask your team to check that every qualified requirement in scope has either an applied control with evidence or a signed decision record, and that no requirement is silently absent. Ask your implementation partner or auditor to test a sample of records against the underlying risk assessment. The records are your strongest answer when a competent authority questions a gap, and they are cheaper to write during the first pass than to reconstruct after an inspection.

What to check before a supervisor asks

Supervisors rarely ask whether a program exists. They ask whether the program runs on schedule and leaves records. The checks below test whether the fixed review cycles, drills, supplier records, management training and corrective actions are visible in your own files, and they are the first things a competent authority can request.

Fixed review cycles on time

Implementing Regulation (EU) 2024/2690 sets fixed cycles: at least annual management review of the information system security policy (Annex, point 1.1.2), at least annual review of risk assessments (point 2.1.4), and a quarterly assessment of recurring incidents (point 3.4.2(b)). Pull the last review date for each. Confirm that each review has a named approver, a signed or logged date, and a record of what changed. A missing date is treated as a missed cycle.

Reporting drill evidence

Reporting readiness means identifying significant incidents and meeting the 24-hour, 72-hour and one-month deadlines under Article 23(4). A plan that has never been run is hard to defend. Check for dated tabletop or live exercises, the participants, the timeline reached against each deadline, and the gaps the exercise produced. Confirm that each gap has an owner and a closure record.

Complete supplier register

Article 21(2)(d) requires supply chain security, including the security aspects of the relationship with each direct supplier or service provider. Compare your supplier register against accounts payable, cloud subscriptions, managed service contracts and open-source components you depend on in production. For each supplier, confirm the service provided, the data or systems it touches, the contract security clauses, and the date of the last security review. Gaps here are easy to find, so supervisors often check this early.

Management training records

Article 20(2) requires members of the management body to follow training that lets them identify cybersecurity risks and assess the entity's risk-management practices. Keep a roster of every board and executive member who holds approval authority, with the course title, provider, date completed and the topics covered. Confirm that approval of the Article 21 measures is minuted, so training and approval can be shown together. New members who join later need the same record.

Dated corrective action log

Article 21(4) requires an entity that finds it does not comply with the Article 21(2) measures to take all necessary, appropriate and proportionate corrective measures without undue delay. Keep a single log of every finding from audits, tests, incidents and self-assessments. For each entry, record the date found, the measure affected, the owner, the corrective action, the closure date and the evidence of closure. An open item with no dates is harder to defend than a documented finding that took time to close.

What the checklist costs and who gets paid

The checklist has no single price tag, because the cost is spread across several payees: your own staff, any consultant or vCISO you engage, tooling, technical remediation, and independent reviews or tests. Internal time is usually the largest and least visible item. Management approval, the Article 20 training, asset inventories, policy writing, and the recurring reviews that the implementing regulation sets on fixed cycles all land on named people in your organization. Tooling can be a licence, a hosting bill, or open-source software run on your own infrastructure, so the license line may be small while the labor to deploy and maintain it is not. Technical remediation, such as adding multi-factor authentication, centralizing logs, or tightening backups, depends on how far your current estate is from the measures. Independent reviews are a separate decision: NIS2 creates no certificate, so an external audit or security test is something you choose or something a competent authority may later require, not a step the directive itself prices.

Ask every provider for a written, scoped quote that separates one-time work from recurring work. One-time items typically include the initial scope and classification, the gap analysis, policy drafting, and first deployments. Recurring items include the annual review of the security policy and risk assessments, the quarterly review of recurring incidents, incident exercises, supplier reassessments, and any retainer for ongoing support or testing. For each line, ask who performs the work, what the deliverables are, which assumptions the estimate rests on (such as the number of sites, systems, and suppliers in scope), and what would change the price. Confirm whether the figure includes your staff time, which tools are licensed rather than self-hosted, and whether the scope covers one Member State or several.

DeployOpen does not publish prices. Quotes follow from a written scope agreed before work starts, and most engagements are fixed-scope, so the scope document is where you should compare offers. Use the same scope to compare consultants, managed providers, and in-house estimates on equal terms. If a figure for NIS2 cost is quoted to you, ask which source it comes from and what it includes. No fee, budget, or duration figure for this checklist was available to base this section on, so treat any number you are given as a starting point to verify against your own inventory.

Questions buyers ask about the NIS2 checklist

Does NIS2 give my organization a certificate of compliance?

No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines, as set out in Articles 32 to 34 of the directive. Any document that claims to certify NIS2 compliance on its own should be treated with suspicion. Your organization owns its controls and must be ready to show a supervisor the policies, records and evidence behind each measure. If a customer or contract asks for independent assurance, you will need to agree with that party which assessment or attestation they accept, because the directive does not define one. The checklist helps you prepare, but a completed checklist is not a certificate.

Can a small security team run a NIS2 program on its own?

Often yes for the internal work, but not for every part of it. The directive scales obligations by proportionality to risk exposure, entity size and incident likelihood and severity, so a small team can meet the ten Article 21(2) measures with a focused scope. The work that usually stays in-house is ownership of the risk assessment, the policies, decisions on proportionality, incident handling and supplier decisions. Work that is often bought in includes technical hardening, log pipeline setup, backup testing, penetration testing and gap analysis support. Ask whether your team has the hours to maintain evidence every quarter and at least annually, since several implementing regulation requirements set fixed review cycles. If the answer is no, a fixed-scope partner for setup plus a retainer for upkeep is a common split.

What does NIS2 require from management and the board?

Management must approve the cybersecurity risk-management measures and oversee their implementation, as Article 20(1) requires. Members of the management body must also follow training that gives them enough knowledge and skills to identify risks and assess cybersecurity practices and their impact on the entity's services, under Article 20(2). In practice this means a minuted approval of the measures, a named owner for each area, a standing agenda item for risk and incidents, and a training record for each board member. Management carries accountability for infringements, so approval should follow a real briefing on the risk assessment rather than a signature on a summary. Keep the approval and training records ready, because a supervisor will ask for them first.

How long does a NIS2 checklist take to complete?

The directive does not fix a duration, so the timeline depends on your scope, the number of entities and systems, how mature your current controls are, and how much of the work you assign to others. Organizations with an existing ISO 27001 or similar program usually start from a stronger position, while those starting from little documentation need more time for policies and asset inventories. Your first milestones are scope and classification, registration with the competent authority, management approval and training, and a gap analysis. Ask any provider to break the timeline into those phases with dependencies on your staff and on supplier responses, and to state what happens if a phase slips. A dated plan built from your written scope is more useful than any generic number.

Does completing a NIS2 checklist prove that we are compliant?

No. A checklist shows which steps you have considered and where the evidence lives, but it does not prove compliance on its own. Compliance depends on whether the measures are implemented, operating and supported by records that a supervisor can test. ENISA's technical implementation guidance is non-binding, so following its examples does not by itself establish compliance either. Use the checklist to track each measure against its evidence, note every documented proportionality decision, and set a review date for each item. Then have someone independent test whether the evidence matches what the systems actually do. Treat a green checklist that no one has verified as an open risk.

What should we ask a partner before signing a NIS2 engagement?

Start with the written scope: which entities, sites, systems and suppliers are covered, and which deliverables you will receive. Ask who owns each control and each piece of evidence after handover, and what the partner prepares versus what only an independent auditor or certification body can issue. Ask how changes to scope are priced and approved, how upkeep is handled, and what the retainer covers after the first delivery. Confirm which open-source platforms will be deployed, whether they run in your own cloud accounts, data centers or air-gapped networks, and who holds the administrative credentials. Finally, ask for references you can verify through your own channels, and request a sample of the evidence pack before committing.

Where checklists fail and how corrective action closes gaps

Most NIS2 checklists fail in the paperwork, not in the technology. The first common failure is a classification decision made without written reasoning. An entity may state that it is essential or important, but if the file does not show why, the sector and subsector under Annex I or II, the size test and the Member States where services are provided, a supervisor has nothing to test. Article 3(4) already requires the entity to give the competent authority its sector, subsector and contact details, so the classification memo should match what was registered. The second failure is management approval missing from the record. Article 20(1) expects the management body to approve the Article 21 measures and oversee them, so minutes, a signed approval or a dated resolution should exist for the measures in force. A security team's own sign-off does not replace it. Check that the approval names the version of the policy it covers.

The third failure is measures listed as done but without evidence behind them. A checklist line reading "multi-factor authentication: yes" is a claim, not proof. For each of the ten Article 21(2) measures, ask for the configuration export, an access review, a test result or a log sample that a third party could reproduce. The fourth failure is supplier controls that stop at the first contract. Article 21(2)(d) concerns the relationship with direct suppliers and service providers, so confirm that each direct supplier has a security clause, a named contact for incidents and a way to evidence its own controls. Gaps beyond that tier are a matter for the supplier, but the entity should know which of its suppliers depend on sub-suppliers. When a gap is found, Article 21(4) requires the entity to take all necessary, appropriate and proportionate corrective measures without undue delay. Record each gap in a register with its owner, the measure affected, the corrective action, the decision date and the verification method, then close it only when someone other than the owner has checked the evidence. Where a requirement is qualified by "where appropriate" or "to the extent feasible" and the entity decides not to apply it, Article 2(2) requires the reasoning to be written down in a comprehensible manner. Ask your partner or internal reviewer to confirm that every closed gap has a dated record, because a corrective action without a record is, for a supervisor, a gap that was never addressed.

How DeployOpen prepares NIS2 evidence

DeployOpen works on the NIS2 compliance checklist as an implementation partner. We prepare the systems, controls and evidence your organization needs to walk a supervisor through each checklist step, while your management body keeps ownership of the measures it approves. Only an independent auditor or competent authority can assess compliance.

How we scope

We agree the checklist steps in scope, such as classification, registration, measures and reporting readiness, in a written scope before work starts.
The written scope names which systems, sites and Member States are covered, so evidence gaps are traced to specific assets.
Engagements are fixed-scope, with deliverables and timelines confirmed in writing before any implementation begins.

How we build

We implement and harden the self-hosted open-source platforms that produce logging, access, backup and vulnerability evidence for the ten Article 21 measures.
We document proportionality decisions for each Implementing Regulation requirement, so reasoning for any measure not applied is recorded clearly.
We configure supplier records and incident reporting workflows so the 24-hour, 72-hour and one-month steps have named owners and tested paths.

How we hand over

You receive documented policies, the evidence register, configuration records and runbooks mapped to each checklist step.
We test the evidence trail with your team, including a walkthrough of how each artifact would be presented to a competent authority.
Management approval records, training records and corrective action logs are handed over in formats your compliance team can maintain.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, keeping the annual review cycles on schedule.
Retainers can cover recurring tasks such as quarterly recurring-incident assessments and annual risk assessment reviews, as agreed in writing.
Before engaging us, confirm with your legal counsel and national competent authority which obligations apply to your entity.

NIS2 compliance checklist