Law 48/2023:
your cybersecurity obligations in Moldova
Moldova’s first binding national cybersecurity framework, explained for companies: who falls under it, what must be done, and how it is evidenced.
For a long time, cybersecurity was, for companies in Moldova, a requirement arriving from customers or foreign partners. Law no. 48/2023 changes that: it introduces a binding national framework, built on the European NIS2 model, with designated entities, minimum measures and mandatory incident reporting. This guide explains what that means in practice for an organisation wondering whether it is concerned.
What it is, in short
Law no. 48/2023 on cybersecurity sets the legal and institutional framework for the field in the Republic of Moldova. It is aligned with the European NIS2 Directive — the same logic of essential and important entities, the same categories of risk-management measures, the same staged incident reporting model. For companies already working with EU partners, that is good news: the effort does not double.
Who it applies to
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 infrastructure, health, drinking water and wastewater, digital infrastructure, public administration, postal services, waste management, food production and distribution, manufacturing, digital service providers and research.
As in NIS2, classification depends on sector and organisation size, with the difference between essential and important entities showing up mostly in supervision intensity: the former are supervised proactively, the latter mainly in reaction to incidents or complaints.
What obligations it brings
- Risk analysis and information system security policies.
- Incident handling: detection, response, staged reporting to the competent authority.
- Business continuity: backups, disaster recovery, crisis management.
- Supply chain security, including requirements passed to direct suppliers.
- Security in acquisition, development and maintenance of systems, with vulnerability management.
- Policies to assess the effectiveness of measures — that is, testing, not just documenting.
- Cyber hygiene and staff training.
- Cryptography, access control, multi-factor authentication and secure communications.
Staged incident reporting
The model inherited from NIS2 splits reporting into three moments: a very fast early warning, a notification with an initial assessment within the first days, and a final report after the incident closes. Exact deadlines and forms are set by secondary legislation, but the structure is constant — and the practical consequence is that your internal procedure must be able to produce a useful message in hours, not weeks.
Where security testing fits
Two obligations on the list cannot be closed with documents: assessing the effectiveness of measures, and vulnerability management. The first requires independent verification that the defence holds; the second requires knowing which vulnerabilities you have before someone else finds them. A penetration test covers both and produces, on top, exactly the evidence format an inspection looks for: scope, methodology, findings, remediation, re-test.
| Obligation | What is not enough | What testing produces |
|---|---|---|
| Assessing effectiveness of measures | A signed policy and a control list | A practical check of the defence, with a measurable result |
| Vulnerability management | A scanner run once, with no remediation tracking | Findings prioritised by real risk, plus proof they were closed |
| Supply chain security | A questionnaire filled in by the supplier | An independent report on the supplier’s integration with your systems |
| Business continuity | A written, untested plan | Attack scenarios showing where the plan breaks |
Frequently asked questions
What is Moldova’s Law 48/2023?
It is the Republic of Moldova’s cybersecurity law, setting the legal and institutional framework for the field: which entities are covered, which minimum risk-management measures must be implemented, how incidents are reported, and how supervision is exercised. It is built on the European NIS2 Directive model, which means one compliance programme largely covers both frameworks.
How do I know whether my company is in scope?
Check two things: the sector you operate in and the size of your organisation. The covered sectors follow the European structure — energy, transport, banking, health, water, digital infrastructure, public administration and others. If you are not a designated entity, check the third route: if you supply an entity that is, the requirements reach you by contract, as part of its supply-chain obligations.
Does the law explicitly require penetration testing?
Like NIS2, the law requires policies to assess the effectiveness of risk-management measures and to manage vulnerabilities, without prescribing a particular method. In practice those two obligations cannot be demonstrated with documents: an independent technical check is needed. A penetration test is the most direct form of evidence and produces the format a supervisory authority looks for: scope, methodology, findings, remediation, re-test.
How does it relate to NIS2 and the GDPR?
Law 48/2023 is the national alignment to the NIS2 model, so the requirements overlap almost entirely: the same categories of measures, the same entity logic, the same incident reporting model. The GDPR is a different framework, concerning personal data protection, but it intersects at technical measures: Article 32 requires regular testing of their effectiveness. A single testing campaign can produce evidence for all three.
Where do I start if I have done nothing so far?
From inventory and scope. First establish which systems support the service you provide and who has access to them; then technically check what is exposed to the internet. An external penetration test at the start of the programme gives the real priority list and avoids the most common mistake: months of policy writing while an admin interface stays public. Documentation is easier to build on top of a clear technical picture than the other way round.
Related guides
- What a pentest costs — what drives the price, how effort is estimated, and what makes two quotes comparable.
- DORA & TLPT — digital operational resilience in finance and threat-led penetration testing.
- ISO 27001 & SOC 2 — which controls require technical testing and what evidence the auditor accepts.
- OWASP Top 10 — the ten web risk categories, explained with examples and what gets tested in each.
- PCI DSS 4.0 — requirements 11.3 and 11.4, segmentation testing, and what it means for payment processors.
- Pentest vs vulnerability scanning — what each one finds, what it misses, and what auditors accept as evidence.
- How to prepare for a pentest — scope, access, rules of engagement and everything settled before day one.
This material is informational and does not constitute legal advice. The law and its secondary legislation may change; the concrete classification of an organisation is determined case by case, with a specialist.
Not sure whether the law concerns you?
Book a free consultation: we establish the scope together and you get a testing plan for the obligations that actually apply to you.