STAT / DIGITAL

Current chapter: Where did the path fail?

Menu

Security of public digital services · Romania · verified through 20 July 2026

Who can stop a public system before the attacker does?

Purpose of this page

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.

Thesis

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.

The application, data, infrastructure, identities, suppliers and procedures that together deliver a public function. The person or function required to see the service as a whole and remain accountable for the residual risk. A term proposed here for a formal, time-limited decision that the service may remain in production under stated conditions. Controlled reduction of exposure: removing access, separating an interface, entering degraded mode or temporarily disabling a function.

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.

  1. 01

    Authentication

    The service that decides who gets in.

  2. 02

    Identity

    User directories and privileges.

  3. 03

    Code and operations

    GitLab, configuration and monitoring.

  4. 04

    Virtualisation

    The console used to manage the server estate.

  5. 05

    Recovery

    Backups and the ability to return to a clean state.

01

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.

02

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.

03

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.

Open the separate assessment of the public evidence on ANCPI

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.

Incident

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.

What this adds to the argument

A shared platform can turn one breach into simultaneous disruption across dozens of hospitals.

Publicly confirmed incidentPrimary and secondary sources
Incident

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.

What this adds to the argument

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.

Publicly confirmed incidentSecondary reporting attributing confirmation to the institutionConflicting public figures
Incident

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.

What this adds to the argument

Partial recovery after about 112 systems were affected shows that restoration is an operational control, not an inventory tick-box.

Publicly confirmed incidentPrimary and secondary sources
Incident

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.

What this adds to the argument

The reported scale shows how quickly an incident can outgrow one server and become a problem of inventory, segmentation and recovery.

Publicly confirmed incidentPrimary source available

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 cases

03 · 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.

01

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
02

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
03

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
04

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
05

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
06

STS and SRI

Can do
have precise technical roles inside the Private Government Cloud
Limit
they do not universally administer every public application
07

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?’ map

04 · 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.

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 matrix

05 · 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.

When the service has changed and the assessment is out of date, a new decision is required

  1. 01reassess the service
  2. 02accept the risk temporarily and set a deadline
  3. 03isolate the vulnerable component
  4. 04pause or withdraw permission to operate
  5. 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.

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 limits

07 · 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.

  1. 01

    Know every critical service.

    The inventory must be reconciled with DNS, cloud, identity, scanners and contracts, not completed once in a form.

  2. 02

    Name an owner for the whole service.

    Someone must connect operations, data, continuity, contract and risk without transferring them entirely to a supplier.

  3. 03

    Authorise before production and reauthorise after material change.

    The decision needs a deadline, conditions, exceptions and a clear trigger for reassessment.

  4. 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.

  5. 05

    Control every supplier’s privileged access.

    Named identities, time-bound access, logging, approval and removal at contract end.

  6. 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.

  7. 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.