This page asks who remains accountable as a public digital service changes, who checks that it is still safe, and who can isolate or stop it in time.
Security of public digital services · Romania · verified through 20 July 2026
Who can stop a public system before the attacker does?
Romania has rules for fragments of a service. We did not identify a general mechanism that follows the whole service, reassesses its risk after major changes and requires proof that it can be restored.
What you will find here
- Incidents
Which patterns recur and what still cannot be claimed.
- Institutions and law
Who can do what today, and where those powers stop.
- Solutions
What can begin immediately and what requires new law or capacity.
The answer, in brief
The state has rules and institutions for parts of a service, but we found no general rule requiring someone to reconsider the whole service after every major change and decide again, with evidence, whether it can remain online. The page shows what repeats across incidents, who can intervene today and what can change without inventing an entirely new digital state.
Four terms that organise the analysis
Hover, focus or tap a term for its definition.
01 · The case that made the question urgent
ANCPI shows why the question can no longer be postponed
The ANCPI attack makes the underlying problem visible: a public service can have different administrators for the application, infrastructure, identity, backups and contracts, while the public still cannot easily see who owns the whole path. This page does not claim to provide the official technical report on the incident; it separates public information, images attributed to the attacker and what remains unknown.
Open the ANCPI caseWhat is confirmed, what the images indicate and what remains unknown
ANCPI confirmed the system-wide outage. In its 20 July update, the institution said that its technical and legal databases were not affected and that application migration to the Government Cloud had begun under STS coordination, with completion estimated for 22 July. Applications and data are then to be checked and a report produced; only after that will a timetable for phased service restoration be announced. These are institutional statements, not independently verified technical findings. Screenshots attributed to the attacker support, if authentic, access that appears to cross identity, applications, monitoring, virtualisation and recovery. They do not publicly demonstrate exfiltration of the complete cadastral database.
- 01
Authentication
The service that decides who gets in.
- 02
Identity
User directories and privileges.
- 03
Code and operations
GitLab, configuration and monitoring.
- 04
Virtualisation
The console used to manage the server estate.
- 05
Recovery
Backups and the ability to return to a clean state.
What is publicly documented
ANCPI says that its technical and legal databases were not affected and that it had several backup locations. Application migration to the Government Cloud, coordinated by STS, is estimated to finish on 22 July. This is not the restart date: checks and a report are to follow, and services will return in phases on a date that has not yet been announced.
What the screenshots support, if authentic
If authentic, the screenshots indicate access to identity, virtualisation, monitoring, code, configurations and backups, plus visibility into an estate of about 1,071 virtual machines and 107 physical hosts.
What is not publicly demonstrated
ANCPI has not yet published a complete public technical account. The initial vector, persistence, the scope of access and exfiltration, the final amount of copied data, the actual state of each backup, the findings of the announced report and the date on which each application can safely return.
ANCPI is the starting point, not the final verdict of the page. The useful question here is why a path could cross so many layers before a barrier stopped it.
Eight questions from incident to reform
02 · Repetition
ANCPI was not the first case
Four incidents show four ways the same control can fail: a shared platform can multiply disruption, the data-loss tally can remain contradictory even after the incident is confirmed, recovery may have to span an entire IT estate, and compromise of one layer can open the way to many others.
The Hipocrate platform and 26 hospitals
Backmydata ransomware, from the Phobos family, encrypted servers running a shared platform. DNSC's final count reached 26 hospitals and about one week of disruption.
A shared platform can turn one breach into simultaneous disruption across dozens of hospitals.
Chamber of Deputies
The attack and the exfiltration of some documents were publicly confirmed. The official figures subsequently communicated do not agree: the digitalisation minister initially referred to about 250 GB, while a later statement attributed to DNSC referred to 316 files totalling about 300 MB.
Two incompatible official public figures show why incidents need longitudinal updates, while the STS clarification separates the institution providing support from the institution owning the system.
Timisoara City Hall, Tax Directorate and Local Police
Online services were affected and DNSC later reported about 112 systems. Critical data and part of the non-critical data were recovered.
Partial recovery after about 112 systems were affected shows that restoration is an operational control, not an inventory tick-box.
Romanian Waters and 10 basin administrations
About 1,000 IT and communications systems at the Romanian Waters Administration were compromised, including GIS, databases, servers and workstations. Operational technology remained unaffected.
The reported scale shows how quickly an incident can outgrow one server and become a problem of inventory, segmentation and recovery.
Institutions and attackers change. The same elementary controls return: updates, privileged accounts, system separation, restorable backups and a person accountable for risk.
Explore all 25 documented cases03 · The institutional mechanism
Everyone owns a layer. Who owns the service as a whole?
The institution remains responsible even when the application, infrastructure, maintenance and security are divided among teams and suppliers. In public documents, the person accountable for the service’s risk across its full lifecycle and the point at which that risk must be accepted again are not always visible.
The institution
- Can do
- owns the service and remains accountable for operations, data and resources
- Limit
- generic leadership accountability does not automatically name an owner for every service
The contractor
- Can do
- develops or maintains the application and may receive privileged access
- Limit
- it can execute controls but should not accept public risk on the state’s behalf
The infrastructure operator
- Can do
- runs servers, networks or cloud within its remit
- Limit
- secure infrastructure does not repair application code, identity or business processes
Technical-Economic Committee for the Information Society and Authority for the Digitalisation of Romania
- Can do
- review certain investments, architecture and shared standards
- Limit
- the gate is tied to projects and documentation; the service continues after implementation
DNSC
- Can do
- regulates, inspects and imposes measures, deadlines and evidence of remediation
- Limit
- supervision is not the same as daily ownership of the service
STS and SRI
- Can do
- have precise technical roles inside the Private Government Cloud
- Limit
- they do not universally administer every public application
Romanian National Supervisory Authority for Personal Data Processing
- Can do
- acts on personal-data breaches and GDPR duties
- Limit
- it is not an architecture, patch-management or continuity regulator
Responsibilities are distributed among several actors. The public framework does not always make visible the person explicitly accountable for the risk of the whole service, from launch to retirement.
Open the complete ‘who can do what?’ map04 · The law as it exists
The law requires many controls. We did not identify a general requirement for a fresh operating decision after every major change.
Duties covering assets, suppliers, access, incidents and continuity are extensive, and DNSC can inspect and require remediation. Public evidence does not show how consistently they are applied in every institution. The gap identified here is a uniform link between material change, renewed assessment and formal, time-limited acceptance of the remaining risk.
Exists and can be used now
Can the state require central institutions to manage cyber risk?
Yes. The NIS2 framework requires controls over assets, access, suppliers, incidents and recovery, while leadership approves measures and resources.
Exists and can be used now
Can DNSC inspect and follow remediation?
Yes. It can demand evidence, impose measures and deadlines, while Order 3/2025 requires owners, a plan, supporting documents and monitoring until remediation is verified.
Exists, but implementation or capacity is not sufficiently visible
Is there a national inventory of public digital infrastructure?
Law no. 119/2026 was published on 3 July 2026 and enters into force on 3 January 2027. Implementing rules are due within 60 days of entry into force, while inter-institutional cooperation mechanisms must be established by joint order within 90 days. Institutions then have six months to register their resources. Unless the timetable or text changes, the first general registration deadline falls on 3 July 2027. Implementation is gradual, and PNIDP’s value will depend on the quality of the rules, verification of the data and automated updating.
Limited or ambiguous
Is public administration’s security officer independent from IT?
The safeguards on managerial authority, direct reporting and independence from IT that apply to other entities do not apply in the same form to public administration.
Limited or ambiguous
Can an authority immediately and unambiguously isolate any dangerous public service?
We did not identify a general, explicit and uniform power allowing one external authority to take any dangerous public service offline immediately. Inspection powers, preventive measures and remediation orders exist; a service owner can stop or degrade its own system; and narrower operational powers exist within shared infrastructure. External legal review should confirm the precise limits of emergency intervention.
Missing as a cross-government mechanism
Must every critical service be reauthorised after a material change?
We did not identify a universal regime that links material change, reassessment, temporary acceptance of risk and a renewed operating decision for every service.
Some instruments exist and can be used now. Others are ambiguous or not yet operational. The central gap remains a new decision about the real service after major change, rather than only the approval of the project once purchased.
Check the legal stack and article-to-claim matrix05 · The incomplete control
An approval describes the project reviewed. The live service keeps changing.
Patches, integrations, suppliers, privileges, exceptions and unsupported technology can gradually transform the service. Without a mandatory, uniform and verifiable reassessment trigger, the original file comes to describe a system that no longer exists.
What “operating decision” means here: a proposed mechanism through which an identifiable person decides, for a limited period and on the basis of evidence, whether the service may remain in production. It is not the name of a general legal regime currently in force across Romania.
Start the scenario and watch the initial assessment lose its explanatory power.
The service enters production with its architecture and controls assessed.
When the service has changed and the assessment is out of date, a new decision is required
- 01reassess the service
- 02accept the risk temporarily and set a deadline
- 03isolate the vulnerable component
- 04pause or withdraw permission to operate
- 05migrate or retire the service
The inventory says what exists. The proposed operating-decision mechanism would say whether the real service can still remain online under acceptable conditions.
06 · Other governments
Three concrete ways other governments connect the pieces
France, the United States and Estonia use different mechanisms. Their common feature is a formal point at which someone decides, signs and must provide evidence. No model eliminates incidents: the difference is that risk has an owner, directives can carry deadlines and permission to operate can expire.
France
Risk is accepted formally and for a limited period
Security homologation requires an identifiable authority to decide whether residual risk permits operation. Major changes and expiry reopen the decision.
Romania needs the mechanism’s outcome: a named person accepting the remaining risk for a limited period.
United States
Directives turn a general duty into a verifiable deadline
CISA can require covered civilian agencies to discover assets, remediate exploited vulnerabilities or protect management interfaces by concrete dates.
‘Manage vulnerabilities’ becomes ‘fix this exposure by date X and provide evidence’.
Estonia
A register can be a procedure, not only an inventory
RIHA links systems, owners and changes, while E-ITS provides usable controls and proportional audit for organisations performing public functions.
Small institutions are not left to invent minimum control alone; they receive a standard and reusable services.
Romania does not need to copy another country's organisational chart. It can adopt three outcomes: named and time-limited risk acceptance, measurable technical orders and a common standard checked periodically.
Compare all five models and their limits07 · Seven rules
Seven rules so the next incident is not treated as a surprise
The reform can be stated without a giant new organisational chart. Each rule produces a verifiable object, an owner and a moment of decision.
- 01
Know every critical service.
The inventory must be reconciled with DNS, cloud, identity, scanners and contracts, not completed once in a form.
- 02
Name an owner for the whole service.
Someone must connect operations, data, continuity, contract and risk without transferring them entirely to a supplier.
- 03
Authorise before production and reauthorise after material change.
The decision needs a deadline, conditions, exceptions and a clear trigger for reassessment.
- 04
Turn urgent remediation into a deadline and evidence.
DNSC can use existing powers more uniformly, while the law can clarify temporary isolation in grave and imminent risk.
- 05
Control every supplier’s privileged access.
Named identities, time-bound access, logging, approval and removal at contract end.
- 06
Prove recovery through tested restoration.
The existence of a backup is not enough if the attacker shares its identities or full restoration has not been attempted.
- 07
Publish post-incident lessons that can be reused.
Without exposing sensitive detail, the state can say which control failed, what changed and how remediation was verified.
Reform can start with verified inventory, named accountability, the proposed time-limited decision mechanism, controlled privileged access and demonstrated recovery.
08 · Action plan
What can begin in the first 100 days — and what must be built afterwards
The first measures do not require a new institutional architecture. Emergency asset discovery, privileged-access control, checks for exploited vulnerabilities and restoration testing can begin immediately. Recurring authorisation, CTE reform and shared capacity for local government take longer.
Status of the programme: this is an editorially proposed programme built from the identified gaps and the practices reviewed. It is not an official programme, does not include a full budget assessment and would require operational validation by the responsible institutions.
How the first 100 services should be selected: by combining impact with exposure: national importance, data sensitivity, dependencies, absence of a workable manual alternative, consequences of outage, internet-facing interfaces, actively exploited vulnerabilities, unsupported technology and demonstrated recovery capability, not contract value. The method and aggregate progress can be public without publishing an exploitable list of systems.
Intervention does not always mean shutting down the whole service. It may mean isolating an administrative interface, removing supplier access, moving into a degraded mode, disabling a vulnerable function or temporarily withdrawing the operating decision until remediation.
Can start now under existing law
Inventory every internet-exposed management interface and exploited vulnerability
- Owner
- Romania's National Cyber Security Directorate. It appears as an owner for supervision, inspection, remediation measures and technical cyber-security coordination.The institutions that own and operate the services. They remain accountable for implementation, data, continuity, contracts and residual risk.
- Instrument
- thematic supervision and existing measures
- Completion evidence
- inventory reconciled between institutional declarations and technical discovery; an owner for every asset; remediation deadline; retesting that confirms closure of the exposure; aggregate reporting without exploitable details
- Deadline
- 30 days
Name owners for service, system, data, continuity and contract
- Owner
- Institutional leadership can name service owners, allocate resources and formally assign managerial accountability.
- Instrument
- management decision
- Completion evidence
- signed matrix tested in an exercise
- Deadline
- 30–60 days
Test full restoration for the first critical services
- Owner
- The institutions that own and operate the services. They remain accountable for implementation, data, continuity, contracts and residual risk.The teams or suppliers that run the infrastructure. They carry out restoration and provide technical evidence alongside the institution that owns the service.
- Instrument
- continuity plans and management control
- Completion evidence
- full restoration in an isolated environment, measured RTO/RPO, verified data integrity, recorded problems and successful retesting
- Deadline
- 100 days
Requires coordination, rules or a government decision
Build a temporary service passport for the first 100 critical services
- Owner
- Romania's Authority for Digitalisation. It appears for common standards, digital architecture, shared platforms and coordination of public IT investment.Romania's National Cyber Security Directorate. It appears as an owner for supervision, inspection, remediation measures and technical cyber-security coordination.The institutions that own and operate the services. They remain accountable for implementation, data, continuity, contracts and residual risk.
- Instrument
- joint protocol and funding conditions
- Completion evidence
- 100 records with owners, suppliers, risks, tests and a reassessment date
- Deadline
- 100 days
Publish standard clauses for supplier privileged access
- Owner
- Romania's National Agency for Public Procurement. It appears because it can standardise procurement documents and clauses used across public contracts.Romania's Authority for Digitalisation. It appears for common standards, digital architecture, shared platforms and coordination of public IT investment.Romania's National Cyber Security Directorate. It appears as an owner for supervision, inspection, remediation measures and technical cyber-security coordination.
- Instrument
- model documents and guidance
- Completion evidence
- named identities, logs, audit, notification and access closure
- Deadline
- 100 days
Requires legislation
Add a criticality threshold to CTE’s financial threshold
- Owner
- The Romanian Government. It can coordinate ministries, amend government decisions and assign mandates, capacity and budget.Romania's Authority for Digitalisation. It appears for common standards, digital architecture, shared platforms and coordination of public IT investment.
- Instrument
- amend Government Decision 941/2013
- Completion evidence
- critical services enter assurance regardless of cost
- Deadline
- 6–12 months
Clarify reauthorisation and temporary isolation in grave and imminent risk
- Owner
- The Romanian Government. It can coordinate ministries, amend government decisions and assign mandates, capacity and budget.The Romanian Parliament. It is required when a measure needs primary legislation rather than administrative rules or decisions.Romania's National Cyber Security Directorate. It appears as an owner for supervision, inspection, remediation measures and technical cyber-security coordination.
- Instrument
- amend the NIS2 framework with procedural safeguards
- Completion evidence
- triggers, deadlines, reasons, continuity and review route
- Deadline
- 6–12 months
Requires capacity and budget, not another law
Create shared services for administrations with little technical capacity
- Owner
- The Romanian Government. It can coordinate ministries, amend government decisions and assign mandates, capacity and budget.Romania's Authority for Digitalisation. It appears for common standards, digital architecture, shared platforms and coordination of public IT investment.Romania's National Cyber Security Directorate. It appears as an owner for supervision, inspection, remediation measures and technical cyber-security coordination.Authorities and organisations with responsibilities in a public-service domain. They contribute sector knowledge and can extend shared capacity to smaller institutions.
- Instrument
- budget, staffing frameworks and shared platforms
- Completion evidence
- scanning, PAM, logging and backup offered as shared services
- Deadline
- 12–24 months
The next incident cannot be eliminated. But it need not find a system that nobody has examined as a whole for years.
Evidence and sources
The evidence behind the analysis
This page brings together the documents and data supporting the analysis: 25 selected cases and campaigns, institutional powers, legislation, the Government Cloud, international comparisons, methodology and the complete source library.