On the afternoon of 8 September 2026, around 17:00, the website of Romania's National Cyber Security Directorate stopped responding properly. In an interview with Radio România Actualități the next morning, DNSC director general Dan Câmpean put numbers to it: attackers sent roughly 2.8 million access requests, of which about 50,000 cleared every technical filter DNSC had in place and overloaded the site. The outage lasted under 30 minutes.
The technical response was blunt and effective. DNSC isolated all internet traffic to the site and, for a temporary period, allowed access only from Romania — because a large share of the attacking requests came from the Netherlands, the United States, Indonesia and Singapore.
There is an obvious irony in the institution that defends Romania from cyberattacks having to defend its own website, and the Romanian press enjoyed it. The useful reading is different. A DDoS against a public-facing site is not a breach: no data was compromised and nothing was accessed. What it is, under NIS 2, is a security incident affecting availability — and availability is the obligation most Romanian entities have thought about least.
Availability is a security requirement, not an infrastructure topic
Article 21 of OUG nr. 155/2024, which transposes NIS 2 into Romanian law, lists business continuity and crisis management among the risk-management measures an essential or important entity must take. In most organisations that paragraph is read by the infrastructure team as uptime, and by the security team as somebody else's problem.
The DNSC incident is a clean illustration of why that split fails. There was no vulnerability to patch. There was no credential to rotate. The entire outcome was decided by two things agreed in advance: what filtering capability was already in front of the site, and how quickly a human could authorise a drastic traffic decision.
Câmpean's own framing in the interview is the one worth quoting internally: any organisation, any website, any platform can be affected by a cyber incident at some point, and what matters very much is the capability of that organisation's technical teams to restore the infrastructure quickly.
Note also what the numbers say about partial success. Filters stopped roughly 98% of the traffic. The remaining 2% was enough to take the site down. Anti-DDoS protection that is working is not the same as anti-DDoS protection that is sufficient, and the only way to know the difference is to have measured your own capacity rather than the vendor's.
Contract the protection before the incident, not during it
The practical lesson is procurement, not engineering. Anti-DDoS capability bought mid-incident arrives late, costs more and requires DNS or routing changes under pressure, with whoever holds the registrar credentials unreachable.
Before you need it, four things should already be settled:
- Where the mitigation sits. Upstream provider, CDN, scrubbing service, or your own edge. Each has a different activation path and a different person who can trigger it.
- What triggers it. An automatic threshold, or a phone call? If it is a phone call, whose, and what is the out-of-hours number?
- What capacity you have actually bought. Many contracts cover volumetric attacks but not application-layer floods against a specific endpoint, which is what a few tens of thousands of well-formed HTTP requests look like.
- Whether the protection covers the services behind the website. Public sites are the visible target. The portal customers log into, the API partners call and the mail gateway are usually worth more and are often outside the contract.
Geo-filtering is a business decision with customers attached
DNSC's response — allow Romania only, temporarily — was proportionate for a national authority whose audience is overwhelmingly domestic. Copying it without thinking is how an entity turns a 30-minute outage into a week of complaints.
Before it is needed, someone outside IT has to answer: which countries do our legitimate users connect from, including staff travelling, partners, suppliers and Romanian diaspora customers? What breaks if we cut everything else — payments, webhooks, monitoring, third-party integrations? Who is authorised to accept that trade-off at 17:00 on a Tuesday, and how do we tell affected customers?
Geo-filtering is a good tool. It is also a deliberate decision to make your service unavailable to a defined set of real people, and that decision belongs to the business, agreed in advance, not improvised by whoever is on shift.
When an availability incident has to be reported
Entities often assume reporting duties attach only to data compromise. They do not. Article 15 of OUG nr. 155/2024 sets the sequence for a significant incident, and significance is assessed on operational disruption as well as on data:
- An early warning within 24 hours of becoming aware of the significant incident.
- An incident notification within 72 hours, with an initial assessment including severity, impact and, where available, indicators of compromise.
- An intermediate report only where the national CSIRT requests one.
- A final report within 30 days — or a progress report where the incident is still running.
Two points save a lot of internal argument. First, Article 15(3) provides that reporting does not in itself expose the entity to increased liability, so "we do not yet know the full impact" is a legitimate 24-hour answer. Second, under Article 15(9) the national CSIRT has to respond within 24 hours and provide mitigation guidance on request — which makes the early warning useful to you, not only to the regulator.
A sub-30-minute outage of a public website will frequently not meet the significance threshold. The reason to work the question out now is that nobody can assess a threshold in the middle of an incident while the site is down. We set out the first-hour sequence in more detail in the first hour of a DNSC incident report.
Testing a continuity plan means degrading something
A continuity plan that has never been exercised is a document, and under Article 21 the obligation is to have measures that work, with testing and auditing of their effectiveness among the listed items.
Exercising availability does not require taking production down. A useful sequence:
- Load-test the actual path, not a synthetic endpoint. Find where your own site breaks and at what request rate — so the next time you see a number like 50,000 requests, you know whether that is survivable.
- Run the activation call. Phone the anti-DDoS provider's emergency line during business hours and see who answers and what they ask for. Many teams discover at this point that the contract contact left the company.
- Rehearse the geo-filter in a maintenance window, with the business decision-maker on the call, and write down what broke.
- Time the human path. From alert to someone authorised to act, out of hours. That number, not the mitigation technology, is usually what sets your outage length.
A tabletop exercise improves steps 2 to 4 more than any tool does. The parts that need technical verification — whether your edge survives what you think it survives — are what an infrastructure penetration test and a broader vulnerability assessment are for, and the governance and evidence side sits with audit, risk and compliance work.
The trend behind the incident
In the same interview Câmpean gave the figure that matters more than the attack itself: in the first half of 2026, DNSC identified and reported more incidents than in the whole of the previous year.
He also described the motivation honestly. DDoS attacks of this type are frequent, the large majority fail, and their purpose is reputational — signalling that an institution's infrastructure is vulnerable, in order to undermine public and partner confidence. Most are ideologically motivated, often announced in advance on forums, dark-web channels or social media. That last detail is actionable: announced campaigns are a threat-intelligence input, and knowing a wave is coming is worth more than any single control.
Sources: Radio România Actualități — interview with Dan Câmpean, 9 September 2026 · Economedia, 8 September 2026
DNSC described the event as the possibility of a DDoS attack based on available technical data and has not published a forensic attribution; the traffic volumes and source countries come from the director general's public statements and have not been independently verified.
This article is general information, not legal or regulatory advice.