Moldova's Law 48/2023: What the NIS2-Style Cyber Rules Mean for Your Company
Moldova's first mandatory cybersecurity framework is now in force, modelled on the EU's NIS2. Here is who falls under it, what it actually demands, and why two of its obligations cannot be satisfied with paperwork.
For years, cybersecurity in Moldova was something a company did because a client asked, or because a foreign partner put it in a contract. Law No. 48/2023 changes the source of that pressure: it makes cybersecurity a national legal obligation, built on the same architecture as the EU's NIS2 Directive. If you supply a critical service, or sell into an organisation that does, this framework now reaches you — directly or through the supply chain clause in your next contract.
What Law 48/2023 actually is
Law No. 48/2023 on cybersecurity establishes the legal and institutional framework for the field in the Republic of Moldova. It defines which organisations count as regulated entities, what minimum risk-management measures they must implement, how incidents get reported, and how supervision is exercised. The design is deliberately European: the same essential/important entity distinction, the same categories of risk-management measures, and the same tiered incident-reporting model found in NIS2.
That alignment is the single most useful fact in the whole law for a Moldovan company. If you already maintain a compliance programme for the European market — whether driven by NIS2 itself, by a client's vendor questionnaire, or by a parent group's security baseline — you are largely covering the national requirements too. The reverse is equally true, and for exporters it is the more valuable direction: work done to satisfy Chisinau travels well to Brussels, Frankfurt and Bucharest.
Note: NIS2 alignment means a compliance programme built for the European market largely covers the national requirements as well. For exporters, that overlap is the cheapest path to both.
Who falls under the law
The law targets organisations providing services considered critical to the functioning of society and the economy. The sectors follow the European structure: energy, transport, banking and financial market infrastructures, health, drinking water and wastewater, digital infrastructure, public administration, postal services, waste management, food production and distribution, manufacturing, digital service providers, and research.
As under NIS2, whether you are in scope depends on two variables: your sector and the size of your organisation. The distinction between essential and important entities is reflected mainly in the intensity of supervision rather than in the core obligations. Essential entities are supervised proactively — the authority can come and look before anything goes wrong. Important entities are supervised more reactively, typically after an incident or a tip-off. Both must implement the same categories of measures and report incidents.
The third route into scope
Here is the part most companies miss. Even if you are not a designated entity yourself, the law's supply-chain obligations push requirements down through contracts to your IT providers, hosting companies, software developers and maintenance contractors. An essential entity is required to manage the security of its direct suppliers, and the practical way to do that is contractual: security clauses, evidence requests, audit rights, incident-notification duties. For a great many Moldovan companies — a SaaS vendor, a managed service provider, a small development shop — Law 48/2023 will arrive as a clause in a customer's contract long before it arrives as a letter from a regulator.
The obligations it imposes
The law sets out minimum risk-management measures that in-scope organisations must adopt. In substance they cover:
- Risk analysis policies and policies for the security of information systems.
- Incident handling: detection, response, and tiered reporting to the competent authority.
- Business continuity: backups, disaster recovery, and crisis management.
- Supply-chain security, including requirements imposed on direct suppliers.
- Security in the acquisition, development and maintenance of systems, with vulnerability management.
- Policies for assessing the effectiveness of the measures — that is, testing, not just documenting.
- Cyber hygiene and staff training.
- Cryptography, access control, multi-factor authentication and secure communications.
Read that list again and notice how much of it is about evidence rather than intention. A signed policy document proves you wrote something. It does not prove the control works. The law, like NIS2, is written by people who understand that difference.
Incident reporting happens in stages
The NIS2-derived model splits reporting into three moments: a very fast early warning, a notification with an initial assessment within the first days, and a final report once the incident is closed. The precise deadlines and the forms are set by subordinate normative acts, but the structure is fixed — and the practical consequence is blunt. Your internal procedure must be capable of producing a useful message in hours, not weeks.
That is a process-design problem, not a paperwork problem. Who decides whether an event is a reportable incident? Who has the authority to send the early warning at 2 a.m.? Where does the technical detail come from — your SIEM, your EDR, your hosting provider's logs? Organisations that discover the answers during an actual incident tend to miss the early warning window entirely.
Where security testing fits
Two obligations on that list cannot be closed with documents. The first is assessing the effectiveness of the measures — which requires independent verification that the defence actually holds. The second is vulnerability management — which requires knowing what vulnerabilities you have before someone else finds them. A penetration test covers both, and produces the evidence format a supervisory authority looks for: scope, methodology, findings, remediation, retest.
| Obligation | What is not enough | What testing produces |
|---|---|---|
| Assessing effectiveness | A signed policy and a control list | Practical verification, measurable result |
| Vulnerability management | A scanner run once, no follow-up | Findings prioritised by real risk, plus closure evidence |
| Supply-chain security | A questionnaire filled in by the vendor | Independent report on the vendor's integration with your systems |
| Business continuity | A written, untested plan | Attack scenarios showing where the plan breaks |
The fourth row deserves emphasis. Continuity plans fail in predictable places: the backup that was never restored, the recovery credentials stored on the system that went down, the failover that depends on a single DNS provider. None of that surfaces in a tabletop exercise run by the same team that wrote the plan. It surfaces when someone actually tries to break the recovery path.
Does the law require penetration testing by name?
No — and this is a common source of confusion. Like NIS2, Law 48/2023 requires policies for evaluating the effectiveness of risk-management measures and requires vulnerability management, but it does not mandate a specific method. In practice, though, those two obligations cannot be demonstrated with documents alone. Technical, independent verification is needed, and a penetration test is the most direct form of that evidence. It also happens to generate exactly the artefact a supervisory body asks for: perimeter, methodology, findings, remediation, retest.
Caution: A vulnerability scan is not a penetration test, and auditors increasingly know the difference. A scan enumerates what a tool can see; a test demonstrates what an attacker can actually achieve by chaining those findings together. If your evidence folder contains only scanner output, expect questions.
How it relates to NIS2 and GDPR
Law 48/2023 is Moldova's national alignment with the NIS2 model, so the requirements overlap almost completely: the same categories of measures, the same entity logic, the same tiered incident reporting. If you are already working toward NIS2 in another jurisdiction, you are not starting over.
GDPR is a different framework — it concerns the protection of personal data — but it intersects with Law 48/2023 at the technical measures. Article 32 of GDPR requires regular testing of the effectiveness of those measures. One well-scoped testing campaign can therefore produce evidence for all three: the national cybersecurity law, NIS2, and the GDPR's security-of-processing obligation. That is the efficient way to think about it. Not three programmes, but one programme with three reporting outputs.
Where to start if you have done nothing
Start with inventory and perimeter. First establish which systems support the service you provide and who has access to them. Then verify technically what is exposed to the internet. An external penetration test at the beginning of the programme gives you a real priority list and avoids the most common failure mode: months of writing policies while an administrative interface sits publicly reachable, unpatched, waiting.
Documentation is easier to build on top of a clear technical picture than the other way around. The teams that struggle with Law 48/2023 are rarely the ones with weak technology — they are the ones that wrote the policy first and only later discovered what their estate actually looked like.
The honest assessment is this: Law 48/2023 does not demand anything a well-run security programme would not already do. What it changes is that the demand is now external, dated, and evidenced. The organisations that treat it as a documentation exercise will pass an audit and fail an incident. The ones that treat it as a reason to test their defences — starting with what is exposed, and following the findings through to a retest — will end up with something more valuable than compliance: a defensible position they can actually demonstrate.