NIS2 readiness: scope, management duties, and evidence

NIS2 readiness begins with a documented applicability decision. Sector, service, size, establishment, and special inclusion rules can all matter. A customer's questionnaire is useful context, but it does not determine your legal status. Neither does a security certificate establish that every relevant entity, service, and reporting obligation has been addressed.

For a CEO, readiness means being able to explain what management has approved, why the measures are appropriate, who will implement them, and how their effectiveness will be assessed. It also means ensuring that the organization can report a significant incident while information is incomplete and normal operations are disrupted.

The practical task is to connect legal scope, service risks, delivery priorities, and reviewed evidence. That connection gives leadership a basis for decisions about investment, operational disruption, suppliers, and unresolved exposure.

Establish which entities and services are covered

The NIS2 Directive establishes an EU cybersecurity baseline across specified activities. Articles 2 and 3, together with the annexes, determine its scope and classification structure. National implementing legislation supplies the applicable local obligations and procedures.

Assess each relevant legal entity rather than treating the group name as the regulatory boundary. A subsidiary's activities, ownership relationships, and establishment locations can change the answer. Management should require a recorded conclusion, supporting facts, and an owner for unresolved questions.

Match activities to the listed entity types

Annex I includes sectors such as energy, transport, health, water, financial services, digital infrastructure, ICT service management, public administration, and space. Annex II extends coverage to areas including postal services, waste management, chemicals, food, specified manufacturing activities, digital providers, and research.

The sector heading is only the starting point. Read the entity types and activities within the relevant entry. Manufacturing is not a universal inclusion category, and selling software does not automatically make a business a cloud provider or managed service provider.

Describe what the entity actually delivers: the service, its recipients, how it operates, and whether it administers customer systems. Commercial registration codes and website descriptions can support that analysis, but they should not replace it.

For example, selling a licensed application and operating a customer's information systems are different activities. A business described as a consultancy may nevertheless provide ongoing administration that requires assessment against the managed-service definitions. Resolve such questions before designing the compliance boundary.

Calculate size using the applicable rules

Article 2 uses the EU enterprise-size definition. As an initial screening shorthand, the general inclusion threshold is 50 employees or more, or both turnover and balance sheet total exceeding EUR 10 million. Broadly, exceeding the medium-sized ceilings involves at least 250 employees, or turnover above EUR 50 million together with a balance sheet total above EUR 43 million.

These figures do not replace the full calculation. Relevant accounting periods, staff-count methodology, and partner or linked enterprises can affect the result. A locally small subsidiary may cross a threshold once the appropriate ownership relationships are considered.

Keep the calculation, underlying figures, and reasoning about group relationships. Avoid recording only “medium-sized” without explaining how that conclusion was reached. Turnover alone is not the complete financial alternative to headcount.

Where size is close to a boundary or ownership is complex, commission a specific legal assessment. The cost of resolving that uncertainty should be treated as part of establishing the operating requirements, not postponed until an authority or customer challenges the conclusion.

Examine special inclusion and classification rules

Some service categories can be included regardless of size. Article 2 addresses specified communications, trust, DNS, and top-level domain activities, certain public administration bodies, and entities identified as critical under the relevant EU framework. National identification can also bring entities into scope because of their societal importance or the consequences of disruption.

Article 3 then determines whether a covered entity is essential or important. Large Annex I entities form one significant essential-entity category, but the article contains additional service-specific and designation rules. A medium-sized Annex I business is not automatically essential; the annexes are not simply two lists of supervisory tiers.

Both classifications carry the core security risk-management and significant-incident reporting duties. Important status changes the supervisory model; it does not remove the need for effective measures.

Direct legal coverage and customer requirements should be recorded separately. A smaller supplier may be outside direct scope while facing substantial contractual security duties. Conversely, a customer questionnaire saying “NIS2 applies” is not an authoritative classification decision.

A defensible scope record should contain:

• The legal entity and its actual services.
• Relevant annex entries or special inclusion grounds.
• The size calculation and relevant ownership relationships.
• Essential or important classification, with reasons.
• Establishment locations and jurisdiction analysis.
• Applicable national rules, reviewer, approval date, and open questions.

Reassessment triggers should include acquisitions, new services, material size changes, and legislative developments. An exclusion decision can be sound when made and become outdated later.

Translate the EU baseline into national obligations

NIS2 is a directive implemented through national law. Member States had an EU transposition deadline of 17 October 2024, with implementing measures intended to apply from 18 October 2024. Those dates do not tell an individual company its current national registration deadline or the procedure it must use.

Create an obligation register for each relevant entity and country. Identify the applicable legislation, authority, registration process, reporting channel, sector-specific provisions, and responsible internal owner. Distinguish a statutory requirement from authority guidance or an internal implementation recommendation.

Determine jurisdiction before choosing a reporting channel

Article 26 generally connects jurisdiction to establishment, but certain services follow different rules. Public electronic communications providers are regulated where they provide the relevant services. Specified digital providers use a main-establishment approach, including cloud, data centre, content delivery, managed service, managed security, and certain online-platform and domain-related businesses.

For that main-establishment assessment, examine where cybersecurity risk-management decisions are predominantly taken in the Union. If that location cannot be determined or those decisions are not taken in the Union, assess where cybersecurity operations are carried out in the Union; if that also cannot be determined, use the Union establishment with the most employees. A holding company's registered address may therefore be insufficient.

Certain providers offering services in the Union without an EU establishment must appoint an EU representative. A foreign headquarters is not an automatic exemption, but European customers do not automatically bring every non-EU business into scope either. Service type and other applicability conditions still matter.

Record registration and entity-information duties separately from the security program. Keep submission receipts, current contact details, and responsibility for updates. If registration is overdue, confirm the authority's current process and act promptly. Completion of the registration does not prove implementation of the security measures.

Keep KRITIS and sector-specific obligations distinct

For German operations, check KRITIS requirements alongside applicable NIS2 implementation rules. The two regimes overlap but are not identical. NIS2 coverage does not automatically designate every facility as a critical installation, and an established KRITIS program does not automatically discharge every NIS2 obligation.

Maintain separate records for entity classification, critical installations, and additional duties. Consult the BSI's NIS2 information for the current national process rather than relying on old deadline announcements.

Article 4 also addresses equivalent sector-specific EU requirements. For covered financial entities, DORA can govern relevant areas. Determine which duties apply to the particular entity and service instead of maintaining duplicate reporting paths by default.

Build a management-owned plan

Article 20 places approval and implementation oversight with the management bodies of essential and important entities. It also provides for liability concerning infringements of Article 21; the legal consequences depend on national law and the entity's legal form.

Delivery can be delegated to security, IT, operations, procurement, and other teams. Delegation should preserve visible management oversight. The CEO's role is not to configure systems, but to ensure that significant service risks receive informed decisions, resources, and follow-through.

Approve decisions, not just documents

An approval pack should connect the risk assessment to an executable plan. Include the covered services, principal disruption scenarios, proposed measures, alternatives, delivery dependencies, staffing requirements, milestones, and expected evidence.

For each obligation, record the implementation, owner, evidence, gap, and next decision. This makes it possible to distinguish an approved intention from a completed capability. It also exposes measures that have no accountable owner or depend on resources that were never allocated.

Management minutes should explain the decision and its basis. For example, approving a recovery investment should record which service interruption it addresses, the expected recovery outcome, and the operational constraints. A signature on a policy does not explain whether management considered the implementation problem behind it.

Budget discussions should include internal capacity and business interruption, not only software expenditure. A network change may require a production outage; a supplier review may need legal negotiation; a restoration test may need an isolated environment and operations staff.

Risk acceptance deserves particular care. It can document a treatment decision within a risk-management process, but it cannot waive a legal requirement. Where an exception could conflict with an obligation, obtain legal interpretation, identify interim protection, and keep the unresolved issue visible.

Separate delivery progress from control effectiveness

A project can finish deploying a measure without achieving the intended protection. Management reporting should answer both whether approved work is complete and whether it works across the relevant service boundary.

Set a review cadence proportionate to the program. Quarterly management reviews may be practical for a stable operation, with more frequent reviews during implementation. This is a recommendation, not a universal frequency prescribed by Article 20.

Define escalation between meetings. A failed recovery test, compromised privileged account, or newly identified critical dependency should not wait for the next scheduled presentation.

Make executive training relevant to decisions

Article 20 requires management-body members to undertake training sufficient to help them identify risks, evaluate risk-management practices, and understand service consequences. It does not set one universal course length or renewal interval.

Training should cover incident significance, recovery trade-offs, supplier concentration, evidence limitations, and decisions under uncertainty. Include a scenario requiring executives to authorize a report, restrict operations, or fund urgent treatment.

Retain dates, participants, content, and follow-up actions. Employee training is also addressed within Article 21, but staff awareness sessions do not substitute for management's own training. Leadership should be able to challenge assurance claims without needing to become technical specialists.

Turn Article 21 into service-level measures

Article 21 requires proportionate technical, operational, and organizational protection. Its proportionality assessment considers exposure, organizational size, implementation cost, and incident likelihood and severity, including wider societal and economic effects.

The required approach encompasses hazards beyond malicious cyber activity. Power failure, flooding, physical intrusion, unavailable personnel, and disrupted telecommunications may all threaten the same service.

The following implementation examples are practical recommendations. They explain the ten subject areas without prescribing an identical technical design for every entity. Certain digital services also face more detailed EU implementing requirements; check applicability before relying on a high-level checklist alone.

Risk analysis and system-security policies

Begin with the service: what must continue, who depends on it, and what disruption would mean. Map the supporting systems, facilities, people, and external providers before assigning risk ratings.

Use impact criteria that distinguish financial loss from safety, service-recipient harm, and wider disruption. Record scenarios, existing protection, proposed treatments, residual exposure, and reassessment triggers. A generic list of cyber threats is less useful than an explanation of how a specific dependency can interrupt the service.

The deliverable is a risk assessment that supports decisions, with policies describing how those decisions become operating requirements.

Incident handling

Define detection, triage, escalation, containment, investigation, recovery coordination, and closure. Appoint a coordinator and alternates, and give responders usable procedures for likely incidents.

Operational severity and statutory significance are related but distinct. An urgent technical incident may require containment before legal reportability is resolved. The process must support both activities without allowing one to block the other.

Keep incident timelines, decisions, relevant evidence, and corrective actions. Review whether agreed improvements were completed; a lessons-learned document with no follow-through provides weak assurance.

Continuity, backup, recovery, and crisis management

Use business impact analysis to identify essential activities and acceptable disruption. Agree recovery time objectives and recovery point objectives with service owners. The former concerns restoration time; the latter concerns tolerable data loss.

Backup completion records are useful, but they do not establish that a service can be recovered. Test restoration, supporting identities, keys, interfaces, and usable data. Check whether recovered systems can support the actual business workflow.

Crisis arrangements should address operational decisions and communication as well as technical recovery. Record test outcomes, missed objectives, actions, and management decisions about the remaining exposure.

Supplier relationships

Identify direct suppliers whose failure or compromise could materially affect the service. Consider administrative access, sensitive information, software dependencies, and availability.

Assess the security relevance of the actual relationship, including supplier-specific vulnerabilities and product or development practices. Connect findings to access controls, contractual arrangements, contingencies, and review triggers.

A supplier certificate can support the assessment. It does not automatically cover your purchased service, its configuration, or your integration responsibilities.

Acquisition, development, maintenance, and vulnerabilities

Set security acceptance criteria for purchases and new systems. Define responsibilities for secure development, configuration, changes, maintenance, updates, and incoming vulnerability reports.

Track significant vulnerabilities through assessment, treatment, exception handling, and verification. Remediation priorities should reflect exploitation potential and service consequences, not just a numerical severity rating.

Operational technology may require vendor validation and planned outages before patching. Document interim safeguards and the treatment schedule. “Cannot patch” is a constraint to manage, not a complete risk decision.

Effectiveness assessment

For important measures, define the question the test must answer. An access review checks authorization; a restoration exercise checks recovery; an incident simulation checks coordination and decision-making.

Record the tested scope, expected result, method, reviewer, findings, and response to failure. Use independent assurance where it adds value or applicable rules require it.

Article 21 calls for effectiveness assessment, but does not impose one penetration-testing frequency on every covered organization. Testing should match the assurance need and any relevant detailed requirements.

Cyber hygiene and staff training

Give staff practical instructions for reporting suspicious activity, protecting credentials, handling information, and working securely. Add role-specific content for developers, administrators, procurement personnel, and responders.

Training attendance shows participation, not necessarily the ability to act. Exercises and observed performance can reveal unclear instructions or weak escalation paths.

Use the findings to improve procedures. If employees report suspicious messages correctly but the receiving team responds slowly, repeating the same awareness course will not address the underlying problem.

Cryptography

Define which information and workflows need cryptographic protection, including relevant data in transit and at rest. Identify ownership of keys and certificates, renewal, revocation, access, and recovery.

Evidence should include configuration decisions and key-management arrangements, not only an assertion that encryption exists. Protection can fail if encrypted backups depend on unavailable keys or if key access is not appropriately restricted.

Maintain justified exceptions and review them when systems or risks change. Avoid treating a broad claim such as “everything is encrypted” as sufficient assurance.

People, access, and assets

Connect hiring, role changes, and departures to access decisions. Identify business owners, administrators, external accounts, service identities, and relevant assets.

Review privileged access and remove permissions that are no longer justified. Include shared or non-human accounts in the assessment rather than limiting it to employee user lists.

Evidence can include approved requests, sampled offboarding records, completed access reviews, and resolved exceptions. An asset inventory should explain ownership and service dependency, not merely count devices.

Authentication and secure communications

Article 21 addresses stronger authentication and protected communications, including emergency arrangements, with an appropriateness qualifier.

As a practical priority, examine privileged and remote access to critical services. Identify legacy limitations and evaluate protective alternatives rather than assuming every system supports the same mechanism.

Also test crisis communication when ordinary email, collaboration tools, or identity services are unavailable. An emergency procedure that depends entirely on the failed platform may be unusable precisely when it is needed.

Make critical-supplier decisions explicit

Supply-chain security often becomes a management issue because procurement cannot eliminate every dependency through a questionnaire. Start with the failure consequence: can this supplier interrupt delivery, introduce unauthorized changes, expose information, or prevent recovery?

For critical direct suppliers, record the supported service, access provided, assessment owner, assurance reviewed, outstanding findings, and treatment decisions. Check the scope and period of assurance documents. A report covering another service or an earlier operating model may not answer the current question.

Contract negotiation should address the risks of the relationship. Practical subjects include security responsibilities, incident communication, investigation cooperation, vulnerability handling, access restrictions, evidence availability, continuity, and exit support. These are recommended negotiation topics, not identical statutory clauses for every contract.

Supplier notification arrangements should support your reporting timetable. Confirm operational contacts and alternates; an account manager's ordinary business-hours inbox may be inadequate for a serious incident.

Article 21 specifically addresses direct relationships. Upstream dependencies can still matter where they create concentration risk or undermine recovery. Investigate deeper when it changes the decision, rather than attempting an unlimited inventory of every supplier's suppliers.

If assurance remains insufficient, management may restrict access, add monitoring, negotiate improvements, introduce alternatives, redesign the dependency, or replace the provider. Record the rationale and interim measures. Outsourcing service delivery does not remove responsibility for the entity's own risk-management program.

Rehearse significant-incident reporting

Article 23 establishes reporting for significant incidents. An incident is significant if it causes or is capable of causing severe operational disruption of services or financial loss for the entity, or considerable material or non-material damage to other natural or legal persons. Confirm applicable national and sector-specific significance rules before designing the decision process.

The clock concerns awareness of a significant incident, not completion of forensic analysis. Record when relevant information became available, the significance assessment, and who made the decision. Do not manufacture a later awareness time by delaying internal escalation.

Trust service providers have a specific 24-hour notification provision for significant incidents affecting their trust services. Both essential and important entities have staged reporting duties; important classification does not remove the early warning.

Design authority and access for out-of-hours use

Name the assessment lead, authorized submitter, alternate, legal contact, and management escalation route. Agree how provisional information will be approved. Management needs visibility without becoming an unavoidable bottleneck for every submission.

Prepare templates separating confirmed facts, preliminary assessments, unknowns, and planned updates. Avoid unsupported attribution or recovery promises. Early reporting should be accurate about uncertainty rather than artificially complete.

Test reporting-channel access, credentials, contact information, and fallback arrangements. If the submitter depends on a compromised corporate identity service, the process needs an alternative.

Exercise an evening or weekend scenario. Measure the time to recognize potential significance, convene the necessary people, prepare the warning, authorize it, and reach the channel. Keep this activity connected to containment and recovery, while assigning enough people to prevent reporting from consuming the entire response team.

Article 23 also addresses communication to service recipients where appropriate. Contracts and other laws may create additional notifications. A personal-data breach requires its own GDPR assessment; a NIS2 submission does not automatically satisfy it. Coordinate the facts while retaining separate decisions and deadlines.

Maintain evidence that explains what operates

Policies, certifications, supplier agreements, and registration receipts can support readiness. The evidence must still show what operates within the applicable scope.

Distinguish design, implementation, and operation. An access policy describes intended behavior. Configuration evidence shows deployment. A completed access review showing removed permissions and resolved exceptions demonstrates operation. These records answer different questions and should not be treated as interchangeable.

For each evidence item, retain its source, scope, date or period, owner, reviewer, conclusion, and limitations. A successful restoration test for one application does not prove recovery of the entire environment. A screenshot may show one configuration at one moment, not sustained operation.

Protect sensitive evidence. Incident logs, architecture diagrams, and access exports can expose operational or personal information. Set appropriate access, retention, and external-sharing arrangements.

Evidence gaps should become work items. “No recent test,” “unclear supplier scope,” and “owner has not reviewed the export” are distinct problems requiring different actions. A document count does not reveal them.

Reuse established ISMS and KRITIS work

An ISO 27001 ISMS can supply risk assessment, treatment, policy, audit, management-review, and operating records. Compare its certified boundary with the entities and services covered by national NIS2 rules.

Corporate IT certification may exclude production systems, a managed service, or an acquired business. Reuse relevant controls and evidence, then address classification, registration, legal reporting, and management training explicitly. Our NIS2 and ISO 27001 guide explains how existing ISMS work can support this process.

NIS2 does not establish a general EU compliance certificate. Certification supports assurance within its own scope; it does not settle every legal duty. Apply the same relevance checks to existing KRITIS evidence instead of assuming previous acceptance covers the current obligations.

Worked example: remote maintenance and production recovery

Consider an illustrative German manufacturer with 180 employees producing equipment within a listed Annex II manufacturing activity. Assume a reviewed calculation establishes medium-sized status, national analysis confirms important-entity classification, and a separate assessment identifies no KRITIS critical-installation designation. These assumptions are specific to the example, not a rule for every manufacturer of that size.

The first implementation focus is production scheduling at one plant. Dependencies include an ERP application, industrial controllers, identity services, backups, and a maintenance supplier with remote access. The legal scope assessment still covers the entity's relevant obligations beyond this initial service.

The review finds three connected weaknesses. Supplier technicians share a privileged account. Backup jobs complete, but no recent restoration test includes the scheduling application's identity dependency. The incident procedure names a report owner without an alternate authorized to submit.

Management requests options rather than approving three isolated policy updates. Operations proposes named, time-bounded supplier access through a controlled remote-access path. IT proposes a service restoration exercise against business-approved objectives. Security and legal propose alternate reporting authority and an out-of-hours rehearsal.

For planning purposes only, assume six weeks and a scheduled maintenance window. Management approves staff capacity, the outage arrangements, and interim supplier-access restrictions. The decision record explains service consequences, why the treatments were selected, and what evidence will establish completion.

The access work produces configuration records, supplier acknowledgement, and a review confirming removal of the shared account. The restoration exercise recovers data but misses the agreed service recovery time because authentication cannot be restored promptly. That finding remains open: successful backup jobs do not override the failed service outcome.

Management then decides whether to improve the identity recovery arrangement, change the architecture, or adopt a different operational contingency. Any revised recovery objective needs a business rationale and must remain consistent with applicable obligations.

The reporting rehearsal finds that the alternate submitter cannot access the reporting channel independently. The team corrects the access dependency and retests it. Readiness improves through verified changes and reviewed decisions, rather than through a declaration that the revised procedures are complete.

Understand supervision and consequences accurately

Articles 32 and 33 distinguish supervisory approaches. Essential entities can face proactive inspection and audit powers. Important entities face ex post supervision when information indicates possible non-compliance. Neither should interpret the absence of an incident or authority inquiry as evidence of readiness.

For infringements of Articles 21 or 23, Article 34 requires national maximum penalties to reach at least the following levels: for essential entities, the higher of EUR 10 million and 2% of the relevant undertaking's worldwide annual turnover; for important entities, the higher of EUR 7 million and 1.4%. These are floors for national penalty ceilings, not standard fine amounts or universal fixed caps.

Authorities also have corrective powers. Article 32 provides conditional mechanisms for essential entities involving relevant certification or authorization and temporary restrictions on specified managerial functions after the prescribed enforcement steps. These are not automatic consequences of every incident, and the provision excludes public administration entities.

Management liability and insurance treatment require jurisdiction-specific advice. Leadership should focus on truthful records, timely treatment, and informed oversight rather than treating potential penalties as a substitute for implementing required measures.

Set the next management decision

Start delivery with the highest-impact service and its dependencies, while keeping the legal assessment complete for every relevant entity. Prioritize statutory urgency, service consequences, and tasks that unlock later work. A focused implementation boundary helps establish the workflow; it does not reduce the entity's legal obligations to that pilot.

The next management review should approve or resolve the scope decision, confirm registration and reporting arrangements, fund priority treatments, assign accountable owners, and schedule recovery and reporting exercises. It should also establish when management will review operating evidence and what findings require earlier escalation.

In Secani, teams can model the selected service, supporting systems, and external-provider dependencies, then connect requirements, controls, owners, and reviewed evidence. Missing proof and unresolved conclusions can become tasks. Human reviewers should approve mappings and evidence conclusions, retaining source links, comments, approvals, and timestamps so the reasoning remains inspectable.

Bring one service map, one obligation register, and the most consequential gaps to that meeting. Leave with funded actions, usable reporting authority, and a date to examine results—not merely a commitment to produce more documentation.