On 16 October 2026, Depozitarul Central — Romania's central securities depository — published a short statement confirming it had been the target of a cyber attack on its "Servicii Online pentru Investitori" application.
The statement is worth reading in the original, because the wording is careful: the institution says it was the target of an attack "care a vizat aplicația Servicii Online pentru Investitori, incident care a fost identificat în ziua producerii", that is, identified on the day it occurred.
What makes this case instructive is not the technical detail — almost none has been published. It is that a single incident at a single financial entity starts three regulatory clocks simultaneously, each with its own authority, its own deadline and its own definition of what counts as late.
What is confirmed, and by whom
The public press release says financial holdings were untouched: "nu au fost accesate, modificate și/sau alterate deținerile de instrumente financiare sau informații privind tranzacțiile decontate." Settlement and registry functions ran normally.
The list of personal data categories does not appear in that press release. It comes from a separate notification sent directly to users of the application, quoted by several Romanian outlets: names, address, CNP, ID card series and number, email address, phone number and IBAN were viewed, and were not modified or altered. The same notification states that application passwords were not accessed.
Two points of precision that most coverage has blurred. First, Depozitarul Central's word is "vizualizate" — viewed. It has not said the data were copied or exfiltrated, and it has not published a number of affected people. Second, the claim that holdings were unaffected is the institution's own assertion; no authority has corroborated it publicly.
The Bucharest Stock Exchange confirmed separately on the same day that its own systems were unaffected and trading continued normally.
The attack vector has not been disclosed. Neither has the attacker, the attack type, or whether the data left the building. One outlet, citing the user notification it says it saw, dates the attack itself to 8 October — a single source, absent from every primary document, and worth treating as unconfirmed.
Three clocks, one incident
Here is where a Romanian financial entity needs to be clear-headed, because the three regimes are not alternatives.
DORA, to ASF. A central securities depository is a financial entity under Article 2(1)(g) of Regulation (EU) 2022/2554, and under Article 46(e) the competent authority is the one designated under the CSDR — in Romania, the Autoritatea de Supraveghere Financiară. Depozitarul Central was authorised by ASF under CSDR in 2019.
The reporting deadlines for a major ICT-related incident are in Commission Delegated Regulation (EU) 2025/301, Article 5, and they are tighter than most people remember:
- Initial notification — as early as possible, and in any case within four hours of classifying the incident as major, and no later than 24 hours from becoming aware of it
- Intermediate report — at the latest 72 hours after the initial notification, and submitted even if nothing about the status or handling has changed, with an updated intermediate report without undue delay once regular activities are recovered
- Final report — no later than one month after the intermediate report, or after the latest updated intermediate report
The four-hour figure is the one that catches people. It does not run from the incident; it runs from the moment you classify it as major. Which means the classification decision itself is on the critical path, and if nobody is empowered to make it at two in the morning, the clock runs anyway.
GDPR, to ANSPDCP. Article 33 requires notification to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals. Article 34 requires communication to the data subjects themselves only where the breach is likely to result in a high risk to their rights and freedoms.
A set that combines full name, address, CNP, ID document series and number and IBAN is close to a complete identity package for Romanian purposes. Depozitarul Central did write directly to its users, which is consistent with an Article 34 communication.
NIS 2, to DNSC. Where the entity is also in scope nationally, OUG nr. 155/2024 brings its own 24-hour early warning and 72-hour notification. According to the user notification, the institution informed DNSC and ANSPDCP, and filed a criminal complaint with DIICOT.
Three authorities, three forms, three definitions of "aware". The practical answer is not to pick one — it is to have a single internal trigger that fans out to all of them, with the classification decision made once and recorded once.
What has not been established
It is worth being explicit, because the gap between what is known and what is being asserted online is wide.
No public statement from ASF, DNSC or ANSPDCP has appeared. Whether a DORA major-incident notification was made, and on what timeline, is not public. Whether the GDPR 72-hour deadline was met cannot be assessed without the incident date, which rests on one outlet's report. The number of data subjects is unknown. Whether the data were exfiltrated rather than merely viewed is unknown.
None of that is a criticism of the institution. Early disclosure is almost always incomplete, and an organisation that publishes before it knows everything is behaving better than one that waits. But it does mean a reader should resist the confident reconstructions circulating about how this happened.
The question this raises for everyone else
Strip out the specifics and what remains is a customer-facing web application, built for self-service, holding enrolment data for retail users, operated by an entity whose core systems are elsewhere and are heavily controlled.
That shape is extremely common. The core platform — settlement, registry, the ledger — gets the attention, the segregation, the change control and the annual testing. The self-service portal that was built so people could stop phoning is treated as a convenience layer. It usually sits on a different stack, often with a different supplier, and it holds exactly the data an identity fraudster wants.
Under DORA Article 24 and 25, digital operational resilience testing is not a once-a-year formality, and it is explicitly meant to cover ICT systems and applications supporting critical or important functions. The question to ask internally is whether the scope of your last test actually included the customer-facing application, or whether it stopped at the core.
What a test of this scenario would cover
A penetration test scoped at a self-service portal of this kind looks at a specific set of things, and most of them are authorisation rather than injection:
- Whether one authenticated user can reach another user's enrolment record by changing an identifier — the single most common serious finding in applications of this type
- Whether the enrolment and account-recovery flows can be abused to view data before authentication is complete
- Whether administrative or support interfaces are reachable from the internet, and what they expose
- Whether session handling, rate limiting and enumeration protections hold on the login and recovery paths
- Whether the data returned by each API endpoint is the minimum the screen needs, or whether the client is filtering a fuller response
- What the application logs, where those logs go, and whether a forensic reconstruction would be possible afterwards
That last one decides whether you can answer the regulator's questions at all. An institution that cannot reconstruct which records were accessed has to assume the worst, and notify on that basis.
If your organisation is in scope of DORA, an audit and compliance review establishes where the obligations land and what evidence is expected. The application itself is the subject of a web security assessment or an API penetration test, depending on how the self-service layer is built — and for most institutions, it is built as an API with a thin client in front of it.
Sources: Depozitarul Central press release, 16 October 2026 · Bucharest Stock Exchange statement · Commission Delegated Regulation (EU) 2025/301 · Regulation (EU) 2022/2554 (DORA) · Economica.net, quoting the user notification
The data categories come from a notification sent to application users and quoted by Romanian press, not from Depozitarul Central's public press release. The claim that financial holdings were unaffected is the institution's own and has not been independently corroborated. The 8 October incident date is reported by a single outlet and does not appear in any primary document. No statement from ASF, DNSC or ANSPDCP had been published at the time of writing.
This article is general information, not legal or regulatory advice.