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.

Back to the analysis

Selective timeline

What we know about an incident changes over time

The first statement, technical confirmation, investigation and later consequences do not arrive at once. The dossier preserves the timeline and the contradictions, not only the first figure published.

How the timeline was assembled

Cases and campaigns selected for the patterns they illustrate; this is not an exhaustive register of incidents in Romania.

Included

Romanian public entity, state-owned company or supplier with documented public-sector impact
at least one verifiable public source
enough information to separate documented facts from unknowns
explanatory value for a recurring pattern

Excluded

rumours and uncorroborated claims
exposed vulnerabilities without evidence of an incident
duplicates and reports lacking verifiable information
classified systems without sufficient public information

Search institution or serviceRecordSectorTypePeriod25 records shown

Cases were selected for explanatory value and verifiable public sourcing. The number is not the total of Romanian incidents. DDoS can block access without compromising data; defacement may affect only a public interface.

19 September 2014IncidentStatusPublicly confirmed incidentSource shownSecondary reporting attributing confirmation to the institutionLatest public status

Romanian Police public interface

What is publicly documented: An unauthorised message appeared on the website. Police said only the public interface, separate from operational databases, was affected.
Still unknown: The vector and extent of administrative access.
What changed or followed: Police said the operational databases were separated from the public interface and were not affected.

Secondary sourceRomanian Police: September 2014 public-interface incident, contemporaneous report

13 September 2016IncidentStatusCredibly reportedSource shownSecondary reportingLatest public status

Sector 1 City Hall

What is publicly documented: The information system was blocked, digital citizen services became unavailable and the city hall referred the case to DIICOT.
Still unknown: The vector, data access, exact duration and recovery outcome.
What changed or followed: Citizens were redirected to physical counters; no public technical postmortem was identified.

Secondary sourceSector 1 City Hall: IT-system outage, contemporaneous report

12 May 2017CampaignStatusPublicly confirmed incidentSource shownPrimary source availableLatest public status

APT28 attempt against a government institution

What is publicly documented: SRI announced it had stopped a spear-phishing attempt probably linked to APT28. The attack caused no damage.
Still unknown: The targeted institution and operational objective were not disclosed.
What changed or followed: SRI published details of the attempt and said it was countered without damage.

Primary sourceRomanian Intelligence Service: the APT28 attempt of 12 May 2017

June 2019IncidentStatusPublicly confirmed incidentSource shownSecondary reporting attributing confirmation to the institutionLatest public status

Four hospitals hit by ransomware

What is publicly documented: CERT-RO and partners investigated incidents at four hospitals. Later analysis pointed to the Maoloa and Phobos families.
Still unknown: The full service, data and recovery impact for each facility.
What changed or followed: Recommendations covered antivirus, RDP, updates and offline backups.

Secondary sourceCERT-RO: investigation of ransomware incidents at four hospitals

3 July 2021IncidentStatusCredibly reportedSource shownSecondary reportingLatest public status

Oradea City Hall

What is publicly documented: Ransomware encrypted part of the data and blocked the document management system. City Hall said the data would be fully recovered from backup.
Still unknown: The vector, actual restoration time, exfiltration and prior backup testing.
What changed or followed: Some counter services were suspended until restoration.

Secondary sourceOradea City Hall: document-system outage, contemporaneous report

22 July 2021IncidentStatusPublicly confirmed incidentSource shownPrimary source availableLatest public status

Witting Hospital

What is publicly documented: PHOBOS encrypted servers and attackers demanded a ransom. The hospital continued with offline registers and did not pay.
Still unknown: Recovery duration, data loss and verification of remediation.
What changed or followed: SRI published urgent technical recommendations to contain and prevent similar incidents.

Primary sourceRomanian Intelligence Service: PHOBOS ransomware at Witting Hospital

10 September 2021IncidentStatusPublicly confirmed incidentSource shownPrimary source availableLatest public status

A faculty platform at Politehnica Bucharest

What is publicly documented: User lists and, for some students, national identification numbers were extracted. The university said its central database was not accessed.
Still unknown: The number of people, the vector and how long the vulnerability existed.
What changed or followed: The issue was remediated the same day and the authorities were notified.

Primary sourceUniversity Politehnica of Bucharest: statement on the September 2021 incident

29 April 2022CampaignStatusPublicly confirmed incidentSource shownPrimary source availableLatest public status

Killnet-claimed DDoS wave

What is publicly documented: Websites belonging to authorities and financial institutions were unavailable for several hours.
Still unknown: The precise cost and duration for each service.
What changed or followed: SRI said the affected sites were outside the TITEICA protection system.

Primary sourceRomanian Intelligence Service: the DDoS attacks of 29 April 2022

8 May 2023IncidentStatusPublicly confirmed incidentSource shownSecondary reporting attributing confirmation to the institutionLatest public status

Education Ministry website

What is publicly documented: An unauthorised message replaced the public page. The ministry took the site offline for assessment, isolation and remediation and said the platform held no confidential data.
Still unknown: The vector, administrative access and the security audit findings.
What changed or followed: The website infrastructure was hardened before restoration.

Secondary sourceRomanian Education Ministry: May 2023 public-page incident

2024IncidentStatusIncluded in an official reportSource shownSecondary reporting attributing confirmation to the institutionLatest public status

National disability management system

What is publicly documented: DNSC's annual report included the compromise of the National Disability Management System infrastructure.
Still unknown: The exact date, impact on beneficiaries, data, duration and recovery.
What changed or followed: Public information remains limited to the annual summary.

Secondary sourceDNSC 2024 report, public summary

30 January 2024IncidentStatusPublicly confirmed incidentSource shownSecondary reporting attributing confirmation to the institutionLatest public statusConflicting public figures

Chamber of Deputies

What is publicly documented: 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.
Still unknown: We did not identify a public technical report reconciling the two figures, describing the full extracted dataset or explaining whether they measure different things. The initial vector, the number of affected people and the outcome of the criminal investigation also remain insufficiently documented in public.
What changed or followed: The Chamber of Deputies later announced restrictions on access to certain services and platforms. We did not identify a consolidated public technical postmortem.

Secondary sourceChamber of Deputies: initial estimate of approximately 250 GB Secondary sourceDNSC, as reported by AGERPRES: 316 files totalling approximately 300 MB Secondary sourceChamber of Deputies: subsequent restrictions on access to services and platforms Secondary sourceSTS: the attacked system was neither administered nor secured by STS

11 February 2024IncidentStatusPublicly confirmed incidentSource shownPrimary and secondary sourcesLatest public status

The Hipocrate platform and 26 hospitals

What is publicly documented: 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.
Still unknown: Exfiltration, the initially failed control, final data loss and cost.
What changed or followed: Malware analysis, YARA rules and distributed recommendations; recovery is not consolidated in one public report.

Primary sourceRomanian Health Ministry: the Hipocrate ransomware incident Secondary sourceDNSC: final count of 26 hospitals in the Hipocrate incident

23 August 2024IncidentStatusPublicly confirmed incidentSource shownPrimary and secondary sourcesLatest public status

Timisoara City Hall, Tax Directorate and Local Police

What is publicly documented: Online services were affected and DNSC later reported about 112 systems. Critical data and part of the non-critical data were recovered.
Still unknown: The vector, accessed data and full recovery time.
What changed or followed: Public services returned gradually; no public technical postmortem identified.

Primary sourceTimișoara City Hall: statement of 26 August 2024 Secondary sourceDNSC 2024 report, public summary

26 October 2024IncidentStatusPublicly confirmed incidentSource shownPrimary and secondary sourcesLatest public status

Sector 5 City Hall

What is publicly documented: Domain controllers, workstations and the Local Police telephone exchange were affected. Attackers demanded 5 million dollars.
Still unknown: Exfiltration, backups, system count and final recovery.
What changed or followed: New measures were promised, without a unified public record of implementation.

Primary sourceSector 5 City Hall: statement on the ransomware incident Secondary sourceDNSC 2024 report, public summary

9 December 2024IncidentStatusPublicly confirmed incidentSource shownPrimary and secondary sourcesLatest public status

Electrica Group

What is publicly documented: Power distribution and supply continued and critical systems were declared unaffected. DNSC reported more than 800 servers and 4,000 workstations affected in corporate IT.
Still unknown: The vector, exfiltration, cost and complete recovery outcome.
What changed or followed: The company reported restoration and continuity measures. A sector response centre for energy was later provided for in government documents; the sources do not establish the Electrica incident as the sole cause.

Primary sourceElectrica: Bucharest Stock Exchange report of 9 December 2024 Secondary sourceDNSC 2024 report, public summary

February 2025Supplier eventStatusPartially confirmedSource shownPrimary source availableLatest public status

Orange incident and data linked to public clients

What is publicly documented: Orange confirmed that a ticket-resolution application was attacked and that categories of data belonging to some YOXO customers were extracted. DNSC said its preliminary analysis also identified legal persons, including public institutions, municipalities, schools and hospitals. Orange network services were not reported affected.
Still unknown: The list of institutions, the exact data associated with each and any direct compromise of those customers’ systems have not been published.
What changed or followed: Orange announced additional security measures; DNSC continued its analysis. No complete public postmortem was identified.

Primary sourceDNSC: statement on the Orange Romania incident of 23 February 2025 Primary sourceOrange Romania — confirmation of an incident in a ticketing application

5 October 2025IncidentStatusPublicly confirmed incidentSource shownSecondary reporting attributing confirmation to the institutionLatest public status

Iași County Council Facebook page

What is publicly documented: An administrator account was taken over without authorisation and the institution lost control of an official communication channel.
Still unknown: The compromise method, whether MFA was enabled and the exact access period.
What changed or followed: The institution worked with Meta on recovery and moved communication to alternative channels.

Secondary sourceIași County Council: Facebook-page compromise, reported by Radio România

15 October 2025IncidentStatusCredibly reportedSource shownSecondary reportingLatest public status

Orăștie City Hall

What is publicly documented: Files on two servers and one computer were encrypted across accounting, taxes, human resources and other functions; attackers demanded about EUR 26,000.
Still unknown: Exfiltration, backup quality, duration and the final recovery result.
What changed or followed: The local administration reported the case; no final public technical account was identified.

Secondary sourceOrăștie City Hall: October 2025 ransomware incident, local reporting

20 December 2025IncidentStatusPublicly confirmed incidentSource shownPrimary source availableLatest public status

Romanian Waters and 10 basin administrations

What is publicly documented: About 1,000 IT and communications systems at the Romanian Waters Administration were compromised, including GIS, databases, servers and workstations. Operational technology remained unaffected.
Still unknown: The vector, exfiltration, cost and point of full recovery.
What changed or followed: Operational systems were not reported affected. Public sources do not identify which control limited the impact.

Primary sourceRomanian Waters Administration: statement of 21 December 2025

3 February 2026IncidentStatusPublicly confirmed incidentSource shownPrimary source availableLatest public status

CONPET

What is publicly documented: The attack affected business IT infrastructure and the company website. SCADA and operational telecommunications remained unaffected and oil transport continued.
Still unknown: The vector, accessed data, the scope of affected systems and full recovery.
What changed or followed: CONPET worked with the authorities and filed a criminal complaint with DIICOT.

Primary sourceCONPET: Bucharest Stock Exchange report on the February 2026 attack

13 March 2026IncidentStatusPublicly confirmed incidentSource shownPrimary source availableLatest public status

eViza and eConsulat

What is publicly documented: The Foreign Ministry reported a DDoS attack against eViza and eConsulat on 13–14 March. The platforms slowed down and were briefly unavailable, then returned to normal operation. The ministry said no sensitive information was accessed.
Still unknown: The actor and malicious traffic volume were not published.
What changed or followed: Protective equipment and ministry specialists reduced the impact. No intrusion was reported.

Primary sourceRomanian Ministry of Foreign Affairs — DDoS attack on eViza and eConsulat

8 April 2026CampaignStatusPublicly confirmed incidentSource shownPrimary source availableLatest public status

Operation Masquerade

What is publicly documented: SRI joined the disruption of a router infrastructure used by APT28. Romanian entities, including government, military and critical sectors, were compromised in the global campaign.
Still unknown: The Romanian victims, access duration and losses.
What changed or followed: The attack infrastructure was disrupted; recommendations covered unsupported routers and firewall rules.

Primary sourceRomanian Intelligence Service: Operation Masquerade

14 July 2026IncidentStatusUnder investigationSource shownPrimary source availableOngoing

ANCPI and e-Terra

What is publicly documented: ANCPI confirmed the largest technical disruption in its history. 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. Checks and a report were to follow; no date for phased service restoration had yet been announced.
Still unknown: The vector, persistence, access scope, exfiltration, the final amount of copied data, backup integrity and isolation, the proportion restored and the final recovery time.
What changed or followed: ANCPI estimates completion of application migration on 22 July. This is not the service-restart date: applications and data are to be checked, and the resulting report will inform a timetable for phased restart. ANCPI’s statement that the technical and legal databases were not affected does not replace an independent public technical report.

Primary sourceANCPI — statement of 15 July 2026 Primary sourceANCPI — outage, restoration and investigation updates checked on 19–20 July 2026 Primary sourceANCPI — 20 July 2026 update on application migration and verification

16 July 2026IncidentStatusUnder investigationSource shownPrimary source availableOngoing

MIPE — Private Beneficiaries Procurement

What is publicly documented: MIPE announced that the application used for procurement by private beneficiaries of cohesion projects had been targeted in a cyber incident and was inaccessible. Competent authorities were notified and teams were analysing and restoring the service.
Still unknown: The vector, duration, affected data, any exfiltration and the recovery mechanism had not been published by the verification date.
What changed or followed: By 20 July 2026, we had found no public update later than the statement of 16 July. The latest public position found said the incident was under analysis and the application was being restored.

Primary sourceRomanian Ministry of Investments and European Projects — incident affecting the Private Beneficiaries Procurement application

20 July 2026IncidentStatusUnder investigationSource shownPrimary and secondary sourcesOngoing

Brașov Fiscal Directorate

What is publicly documented: Brașov City Hall says that the server hosting the Fiscal Directorate website was targeted by Trojan malware. The server was temporarily disconnected to limit the effects, making the website unavailable.
Still unknown: The initial vector, technical confirmation of the malware type, access beyond the web server, any access to data and the restart date.
What changed or followed: The institution says it is identifying the causes and carrying out remediation. Server isolation is documented as a containment measure; the investigation outcome and full recovery are not yet public.

Primary sourceBrașov City Hall — cyber incident affecting the Fiscal Directorate website Secondary sourceDigi Economic — Brașov Fiscal Directorate website temporarily disconnected

The power map

“Who is responsible?” has a different answer for each operation

Choose an action. The institutions remain, but the primary role, control and limit change.

Choose an action to see how responsibility is distributed

Who can see what exists?

Institution

Inventories its assets and risks; remains accountable for accuracy.

DNSC

Can demand relevant asset lists and evidence during supervision.

ADR / PNIDP

Will operate the national inventory after entry into force and population.

Current limit

The PNIDP law enters into force on 3 January 2027; the national inventory is not yet operational. Automated links to technical sources remain decisive.

Emergency Ordinance no. 155/2024, consolidated to 6 July 2026 Law no. 119/2026 on PNIDP

All operations without interaction

Who can see what exists?

Institution: Inventories its assets and risks; remains accountable for accuracy.

DNSC: Can demand relevant asset lists and evidence during supervision.

ADR / PNIDP: Will operate the national inventory after entry into force and population.

Current limit: The PNIDP law enters into force on 3 January 2027; the national inventory is not yet operational. Automated links to technical sources remain decisive.

Emergency Ordinance no. 155/2024, consolidated to 6 July 2026 Law no. 119/2026 on PNIDP

Who approves architecture?

Institution: Defines the need and documentation.

CTE: Issues binding opinions for covered investments and requires renewed review when documentation changes.

ADR: Sets standards in assigned areas and coordinates shared platforms.

Current limit: A financial threshold can miss small but critical services. CTE reporting ends with implementation.

Government Decision 941/2013 and the CTE framework ADR, Technical-Economic Committee for the Information Society

Who allows production use?

Institution: Retains accountability for the service and makes the operational decision to launch or keep it running. That accountability is not, in every case, equivalent to a formal, time-limited and publicly traceable acceptance of risk.

SRI: For SaaS services in the Private Government Cloud, participates in assessment, tests security and approves production launch from a cybersecurity perspective.

STS: Within the Private Government Cloud, can block IaaS/PaaS resources that endanger the platform.

Current limit: The gate exists in the cloud but not as a uniform regime for every critical public service.

Government Decision no. 112/2023 on Private Government Cloud governance

Who compels remediation?

DNSC: Supervises, imposes plans, owners and deadlines, then verifies remediation evidence.

Sector authority: Can supervise and sanction within its sector and coordinates with DNSC.

Entity leadership: Approves measures, allocates resources and is accountable for breaches.

Current limit: There is no public dashboard of active plans, missed deadlines, retesting and case closure.

Emergency Ordinance no. 155/2024, consolidated to 6 July 2026 DNSC Order no. 3/2025 and supervision rules

Who can isolate danger?

Institution: Can stop its own service and remains responsible for continuity.

SRI / STS: Have technical isolation powers inside the private government cloud perimeter.

DNSC: Can order preventive measures and the cessation of non-compliant conduct.

Current limit: The institution can stop its own service, and DNSC can impose measures and the cessation of non-compliant conduct. The reform proposal is an explicit, rapid cross-government procedure for temporary isolation in cases of severe risk, with continuity safeguards and legal review.

Emergency Ordinance no. 155/2024, consolidated to 6 July 2026 Government Decision no. 112/2023 on Private Government Cloud governance

Who follows the data breach?

Institution / DPO: Assesses risk, notifies and informs people when required.

ANSPDCP: Investigates GDPR compliance and can impose a warning, remediation plan, follow-up control and fine.

DNSC: Handles the cyber security and significant incident dimension.

Current limit: The two supervisory tracks are not publicly consolidated into one incident and remediation record.

Law 190/2018, the regime applicable to public authorities Emergency Ordinance no. 155/2024, consolidated to 6 July 2026

Selected legal framework

Law covers many stages. A persistent service identity must connect them.

The analysis mainly concerns civilian national cyberspace and public administration. Defence, public order, national security and classified information may have separate regimes.

Audit scope

A partial model already visible

The government cloud separates migration, assessment and audit

Government Cloud procurement documents separate three functions that should not be confused: a supplier moves the application, an evaluator looks for vulnerabilities, and an auditor independently checks whether the stages and controls existed.

The application is adapted and moved

The procedure treats preparation, adaptation and transfer to the Private Government Cloud as a separate function. A contract shows that services were ordered, but does not by itself prove that an application was accepted or entered production.

Procedure: CN1077543 / CAN1155065
What it covers: preparation, adaptation and transfer of applications

Public procurement catalogue · SICAP.ai — CN1077543, application migration services for the Private Government Cloud

Vulnerabilities are tested and retested

A separate procedure requires security assessments before, during and after migration. It covers finding vulnerabilities, recommending remediation and retesting after fixes.

Procedure: CN1083774
What it covers: vulnerability assessment, remediation and retesting

Public procurement catalogue · SICAP.pro — CN1083774, security assessment of migrated applications

An independent actor checks the delivery chain

Technical audit is an independent function that checks migration, operation and the presence of security assessments. It does not repeat penetration testing and vulnerability assessment: those belong to the security evaluator.

Procedure: CN1088688 / CAN1168520
What it covers: independent checks of migration and controls

Public procurement catalogue · SICAP.ai — CN1088688, technical and financial audit for MAS IC

Together, the three procedures describe a control chain: one team moves the application, another tests its security, and a third independently checks whether migration and assessment were performed. None of these stages can replace another.

International models

Other states connect the pieces in different ways

France, the United States, the United Kingdom, Estonia and Germany use different mechanisms. The comparison asks who defines architecture, who checks security, how operation is authorised and who can demand measurable action.

Country	Digital architecture	Cyber authority	Inventory	Authorisation	Directives	Stopping and accountability	Limit / trade-off
France	DINUM	ANSSI	Government registers and doctrine	Homologation: a named authority accepts risk for a fixed period	Doctrine and mandatory requirements in defined perimeters	The decision depends on the homologation authority and competent operators	The process can be resource-intensive and does not remove the need for monitoring between homologations. DINUM, France’s interministerial digital directorate ANSSI, security accreditation (homologation de sécurité)
United States	Federal CIO / OMB	CISA	Automated discovery and federal visibility in covered civilian agencies	NIST RMF: an authorising official decides whether risk is acceptable; continuous monitoring informs the decision	Binding Operational Directives and Emergency Directives with concrete deadlines	CISA and agencies act within the civilian federal framework; national-security systems have separate regimes	The federal model does not apply uniformly across every level of government and does not mean universal continuous authorisation. CISA BOD 23-01 — asset visibility and vulnerability detection CISA BOD 23-02 — internet-exposed management interfaces NIST Risk Management Framework: Authorize step
United Kingdom	Government Digital Service	NCSC / Government Security Group	Initiative pipeline and continuous monitoring of exposed assets for thousands of public bodies	From April 2026, organisations conduct most assurance and approvals; GDS supports complex and risky initiatives	Shared standards, GovAssure and the Digital Assurance Playbook; former spend controls were removed	Accounting Officers and service owners retain accountability; the centre tracks major risks	Devolution assumes uneven maturity and sufficiently strong internal assurance teams. Government Digital Service: the UK government’s digital centre Digital Assurance Playbook, effective from 1 April 2026 UK Vulnerability Monitoring Service GovAssure UK Government Cyber Security Standard
Estonia	Government CIO function	RIA	RIHA links systems, owners and changes	RIHA procedures and E-ITS audit	E-ITS provides concrete controls and proportional audit	RIA and owners act within the Estonian legal framework	Scale and administrative architecture differ from Romania; transfer requires shared services for small institutions. Estonia, RIHA Estonia, E-ITS
Germany	Federal CIO / federal ministries	BSI	Federal tools and registers in a system fragmented between federal and state levels	IT-Grundschutz and security audits for federal administration	BSI sets standards and supports audits within its remit	Powers vary by level and legal regime	Federalism produces the same fragmentation problem the model is designed to manage. BSI: IT security audits for Germany’s federal administration

Reform proposal

A service passport, two technical keys and one risk owner

An architecture function coordinates the portfolio and standards. DNSC verifies independently. Institutional leadership formally accepts risk for a limited period. These roles check one another.

RO / SERVICE

Service passport

01service, system, data, continuity and contract owners
02criticality, RTO, RPO and degraded mode
03assets, versions, support, domains, certificates and APIs
04suppliers, subcontractors and privileged access
05assessments, audits, remediation and retesting
06backup, last restoration and clean recovery environment
07accepted risks, exceptions and expiry date
08history of changes, incidents and authorisations

Architecture key

A strengthened ADR or equivalent Government CTO function: standards, PNIDP, shared platforms, portfolio, spend controls and removal of unsupported technology.

Safety key

Independent DNSC: supervision, audit, directives, deadlines, scanning, remediation verification, managed suppliers and urgent isolation under defined conditions.

Proposed risk-acceptance mechanism

Under the model proposed in this analysis, institutional leadership signs a time-limited decision on continued operation. An incident, expiry or material change reopens the assessment.

Centralisation can create a single point of failure

Standards and estate visibility can be shared without one institution operating every application. Separating architecture from supervision reduces self-certification.

Stopping a service can harm essential delivery

The proposed procedure should prefer minimum isolation, degraded mode and short duration, with explicit continuity ownership.

Transparency can expose infrastructure

The public needs indicators and decisions, not IP addresses, live vulnerabilities or exploitable architecture. Passport access must be tiered.

Small municipalities cannot implement every control alone

Shared scanning, privileged identity, backup and response services reduce burden and standardise evidence.

A new register can become a static form

PNIDP’s value will come from automated reconciliation with DNS, cloud, identity, code, vulnerabilities and contracts, plus owners accountable for discrepancies.

The main cost is human capability

PAM, EDR and scanning can be bought. The state also needs people who can define architecture, challenge suppliers, read evidence and accept risk.

Critical services with a named owner

Definition: A service for which service, system, data, continuity and contract ownership is approved.
Numerator / denominator: critical services with every role completed / all critical services in the reporting universe
Owner: institutions / ADR
Frequency: quarterly
Target: 100% after inventory
Caveat: individual names may remain non-public; the percentage can be published in aggregate

Automatically discovered and reconciled assets

Definition: Technically observed assets that have an inventory record and owner.
Numerator / denominator: reconciled assets / automatically discovered assets
Owner: ADR + institutions
Frequency: monthly
Target: ≥95%
Caveat: granular publication can create risk; publish distributions and trends

Internet-exposed management interfaces

Definition: Management consoles directly reachable from the internet without an approved intermediary control.
Numerator / denominator: open non-compliant interfaces / identified management interfaces
Owner: DNSC + institutions
Frequency: continuous / quarterly report
Target: 0 non-compliant after deadline
Caveat: temporary exceptions must be documented and expire

Privileged accounts with phishing-resistant MFA and PAM

Definition: Named administrative accounts protected and managed through privileged-access controls.
Numerator / denominator: compliant accounts / all active privileged accounts
Owner: institutions
Frequency: monthly
Target: ≥95%, then 100% for critical systems
Caveat: break-glass accounts need separate procedures and audit

Exploited vulnerabilities remaining after deadline

Definition: Known-exploited vulnerabilities not remediated or compensated by the required deadline.
Numerator / denominator: overdue vulnerabilities / all identified exploited vulnerabilities
Owner: DNSC + institutions
Frequency: weekly / monthly report
Target: 0 overdue without a valid exception
Caveat: technical details are not published per system

Successful restoration tests

Definition: Services for which a backup restoration was executed and validated in the reporting period.
Numerator / denominator: services with a successful test / services requiring backup and recovery
Owner: institutions
Frequency: semi-annually or by criticality
Target: 100% according to cadence
Caveat: the existence of a backup does not prove restorability

Proposal: services with a valid operating decision

Definition: A proposed indicator for critical services whose assessment and formal risk acceptance have not expired or been invalidated by material change.
Numerator / denominator: services with a valid decision / critical services subject to the regime
Owner: institutions + assurance authority
Frequency: continuous / quarterly report
Target: 100%
Caveat: proposed indicator; the uniform regime does not yet exist

Public post-incident reports

Definition: Major incidents with a public summary after the investigation stabilises.
Numerator / denominator: incidents with a public report / eligible major incidents
Owner: institutions + DNSC
Frequency: annual
Target: 100%, with reasoned exceptions
Caveat: the report must protect operational and personal data

Method and sources

How the evidence is handled

Each entry shows what is publicly documented, what remains unknown and which sources support the statement. Incidents, campaigns and supplier events are counted separately.

Publicly documentedAn institution, authority, court record or identifiable report supports the claim.Ongoing investigationFacts may change; unknowns remain visible beside the claim.InferenceAn analytical conclusion is separated from documented facts.ProposalA recommended solution, not an existing power or institution.

What the evidence can and cannot show

The timeline is selective. It brings together cases with public sources that reveal a mechanism; it does not claim to count every incident in Romania.
Some reports and technical evidence are confidential. Their absence from public view does not prove that institutions lack internal controls or information.
Procurement figures describe procedures and contracts. They do not by themselves prove that an application was accepted, tested and placed in production.
The Court of Accounts audit concerns a legal-consultancy procurement and the administrative controls around it. It does not assess DNSC’s technical incident-response capacity.

Author and editor

Marius Comper

Corrections and contact

statdigital [at] mariuscomper [dot] uk

Verified through

2026-07-20

Published data licence

CC BY 4.0

No trackers; filter preferences remain only in the URL.

Data and documentation

Timeline data in JSON Timeline data in CSV Responsibilities: JSON Sources: JSON v1 Data documentation Data-file structure Corrections policy

Glossary

CTE: Technical-Economic Committee for the Information Society
PNIDP: National Public Digital Infrastructure Platform
MAS IC: the project for migrating applications and information systems to cloud
IaaS: infrastructure as a service
PaaS: platform as a service
SaaS: software as a service
PAM: privileged access management
MFA: multi-factor authentication
SOC: security operations centre
SIEM: platform for correlating logs and alerts
SBOM: software bill of materials
RTO: recovery time objective
RPO: recovery point objective
ATO: formal authority-to-operate decision
BOD: binding operational directive issued by CISA
RIHA: Estonian information-system administration system
E-ITS: Estonian information security standard

Sources

62 sources

Search sourcesSource type

Primary source

Government Decision 941/2013 and the CTE framework

Portal Legislativ · 2013-11-27

The evidence behind the analysis

What we know about an incident changes over time

How the timeline was assembled

Included

Excluded

Timeline filters

Romanian Police public interface

Sector 1 City Hall

APT28 attempt against a government institution

Four hospitals hit by ransomware

Oradea City Hall

Witting Hospital

A faculty platform at Politehnica Bucharest

Killnet-claimed DDoS wave

Education Ministry website

National disability management system

Chamber of Deputies

The Hipocrate platform and 26 hospitals

Timisoara City Hall, Tax Directorate and Local Police

Sector 5 City Hall

Electrica Group

Orange incident and data linked to public clients

Iași County Council Facebook page

Orăștie City Hall

Romanian Waters and 10 basin administrations

CONPET

eViza and eConsulat

Operation Masquerade

ANCPI and e-Terra

MIPE — Private Beneficiaries Procurement

Brașov Fiscal Directorate

“Who is responsible?” has a different answer for each operation

Who can see what exists?

Institution

DNSC

ADR / PNIDP

Who can see what exists?

Who approves architecture?

Who allows production use?

Who compels remediation?

Who can isolate danger?

Who follows the data breach?

Law covers many stages. A persistent service identity must connect them.

Audit scope

Finding

Response and deadline

NIS2 in civilian public administration

What it does

What remains to connect

DNSC supervision and remediation

What it does

What remains to connect

Incident reporting

What it does

What remains to connect

PNIDP: the legislated inventory

What it does

What remains to connect

CTE and IT investments

What it does

What remains to connect

Private Government Cloud

What it does

What remains to connect

Interoperability and shared platforms

What it does

What remains to connect

Personal data and remediation

What it does

What remains to connect

Internal control and procurement

What it does

What remains to connect

Responsible vulnerability reporting

What it does

What remains to connect

The government cloud separates migration, assessment and audit

The application is adapted and moved

Vulnerabilities are tested and retested

An independent actor checks the delivery chain