NIS2 readiness starts with the critical service—not a compliance spreadsheet.
A credible NIS2 program connects obligations to the services that must continue, the scenarios that can stop them, and evidence that safeguards work. This guide turns the framework into an executable technical and management plan.
Decisions that matter
- Confirm applicability against consolidated law and the entity’s actual activities.
- Organize risk around essential services—not only IT assets.
- Give every safeguard an owner, evidence, frequency and effectiveness criterion.
- Management needs a coherent view it can approve, challenge and track.
- Rehearse incident and recovery paths before a real reporting window begins.
1. Start from the current framework, not an old summary
NIS2 is a legal obligation, while readiness is a risk and resilience program.
Romania transposed NIS2 through Government Emergency Ordinance 155/2024. It was approved with amendments by Law 124/2025 and subsequently amended, including through Law 123/2026. Before deciding whether an entity is in scope, check the consolidated text, sector, size, services and any special criteria.
Document the reasoning, legal entities, services and sources used. Obtain authorized legal advice for interpretation. A technical assessment supports readiness but does not replace legal counsel or certify compliance.
- Legal entities and activities inventoried
- Sector and subsector checked
- Size criteria and exceptions reviewed
- Consolidated law and applicable orders monitored
- Owner for regulatory change assigned
2. Build a map of services that must withstand disruption
A server inventory does not explain impact. Begin with the service delivered to a citizen, customer or internal operation, then trace dependencies through identity, network, data, applications, suppliers, people and recovery mechanisms.
Assign a business owner, critical periods, outage tolerance, data types and compromise consequences to every service. This becomes the connection between risk assessment, continuity, incident response and investment.
- Services and business owners
- Technical and supplier dependencies
- Privileged accounts and trust relationships
- RTO/RPO and degradation tolerance
- Outage, fraud and data-loss scenarios
3. Connect measures to risk, ownership and evidence
Article 21 of NIS2 requires appropriate and proportionate technical, operational and organizational measures using an all-hazards approach. Areas include risk analysis, incident handling, continuity and crisis, supply chain, secure development and maintenance, effectiveness assessment, hygiene and training, cryptography, people security, access and asset management.
An approved policy is not proof that a measure works. Define the owner, implementation, observable evidence, review frequency and remediation threshold for each outcome. Evidence may include test results, configuration extracts, logs, exercise records, metrics and closed remediation tickets.
- Control tied to a risk and service
- Explicit owner and delegate
- Technical or operational evidence
- Review frequency and acceptance criterion
- Approved exception, deadline and residual risk
4. Rehearse management and incident reporting together
NIS2 raises accountability to management bodies. Leadership needs a view preserving the line from service to scenario, exposure, safeguard, owner and decision. An aggregate score without evidence can conceal the risk requiring acceptance or funding.
Incident reporting uses staged, short time windows. Test who qualifies an incident, authorizes notification, controls information and updates the situation while technical response continues. Include management, legal, communications, operations and critical suppliers in a tabletop exercise.
- Classification and escalation criteria
- Decision and notification roles
- Alternative channels after identity compromise
- Chronological decision log
- Exercise with management and suppliers
5. A realistic first 90 days
In days 1–30, clarify scope, critical services, responsibility and dangerous assumptions. In days 31–60, validate identity, external exposure, backup, logging, privileged access and suppliers. In days 61–90, test response and recovery, approve the backlog and establish measurement cadence.
Do not expect to close every finding in 90 days. The goal is a verifiable baseline: dominant risks are understood, decisions have owners, critical safeguards have evidence and the organization can show how deviations are found and corrected.
- 1–30: scope, services, owners, scenarios
- 31–60: technical validation and evidence
- 61–75: tabletop and recovery test
- 76–90: approved roadmap and metrics
- Monthly: progress, exceptions and residual risk to management
NIS2 readiness questions
Is a compliance audit enough?
No. An audit is a point-in-time view. The organization still needs recurring processes, effectiveness evidence, exception management, response and recovery capability.
Can a platform solve NIS2?
No. Technology can support controls, but accountability, architecture, people, suppliers, process and exercises must work together.
Where do we begin without a complete inventory?
Start with one or two critical services and trace their dependencies. Expand the model and treat inventory gaps as explicit findings.
Does HeyValue provide legal advice?
No. HeyValue can assess governance, process and technical measures, while legal applicability and interpretation require authorized specialists.
Official sources and legal context
Sources were checked on the update date. Always use the consolidated legal text and competent-authority instructions for obligations.
- Romanian Legislative Portal, Ministry of Justice Government Emergency Ordinance 155/2024 — current text displayed by the Legislative Portal
- Romanian Legislative Portal, Ministry of Justice Law 124/2025 approving and amending GEO 155/2024
- Romanian Legislative Portal, Ministry of Justice Law 123/2026 amending GEO 155/2024
- EUR-Lex Directive (EU) 2022/2555 — NIS2
- ENISA NIS2 Technical Implementation Guidance
Turn NIS2 readiness into an executable technical program.
We map critical services, validate controls and build a backlog management and technical teams can own together.