DORA has been enforceable across the EU since January 2025, and year one was, honestly, a paperwork exercise for most Cyprus financial firms: risk registers built, vendor contracts rewritten, incident procedures documented. None of that was wasted effort, but it also didn’t answer the question regulators are starting to ask in year two, which is considerably harder to fake: if an attacker is inside your network right now, does your SOC actually know it, and can you scope and report that intrusion inside DORA’s own deadlines?
Why year two is a different test than year one
Year one of DORA rewarded documentation. A firm could point to a risk framework, a vendor questionnaire, a tested-on-paper incident response plan, and satisfy most of what a first supervisory review was looking for. Year two shifts the question from “do you have a framework” to “does the framework work when something actually happens.” That shift shows up directly in how Articles 9 and 10 read: Article 9 requires continuous monitoring and management of the ICT ecosystem’s security, and Article 10 requires swift detection of anomalous activity, including degraded network performance, with defined thresholds for what counts as an incident worth escalating. Neither article is satisfied by a policy document sitting in a compliance folder.
The deadline that exposes the gap
Article 19 sets DORA’s incident reporting clock: initial notification to the competent authority no later than four hours after an incident is classified as major, and no later than 24 hours after the entity becomes aware of it in the first place. Read that sequence carefully and the real problem becomes obvious. The four-hour clock starts at classification, but classification itself depends on detection, and detection depends on visibility your SOC either has or doesn’t. A firm can have a beautifully written four-hour reporting procedure and still blow the deadline by days, simply because nobody noticed the intrusion until a client complained or a ransom note appeared. The paperwork was never the bottleneck. Seeing the incident in the first place is.
Where the visibility actually breaks down
The gaps tend to cluster in predictable places: legacy infrastructure that predates modern monitoring, specialized appliances that only expose limited telemetry, unmanaged or BYOD devices with no endpoint agent on them at all, and communication paths between systems that nobody thought to instrument because they seemed internal and boring. None of these are exotic. They’re the ordinary accumulated debt of running IT for more than a few years, and DORA doesn’t grade on a curve for that.
Consider a fairly mundane scenario: a payment routing application that normally talks to a credit assessment service starts showing a lot more traffic to unfamiliar internal hosts, outside business hours. The application’s own logs won’t flag this, because from the application’s point of view nothing looks wrong, it’s just making connections. The only place this anomaly is visible at all is at the network layer, in the pattern of who’s talking to whom, when, and how much. If that layer isn’t instrumented or nobody’s watching it, the first four hours of the Article 19 clock can pass without a single alert firing.
The other side of the same problem is alert fatigue rather than blindness: plenty of SOCs do have EDR agents, identity system logs, and network sensors generating data, and still miss the intrusion because the genuine signal is buried under routine noise. Individual alerts rarely tell the full story on their own. What actually scopes an incident fast enough to hit a four-hour window is correlation: connecting an identity warning to a network flow to an endpoint event and building the timeline in minutes instead of days.
Third-party access makes this worse, not better
Articles 28 through 30 push DORA’s ICT risk obligations onto vendors and contractual relationships, and this is exactly where a lot of Cyprus firms have the least direct visibility. A vendor’s credentials can stay perfectly valid, pass every access review, and still represent an active compromise, because the credential being valid was never the control that mattered. What matters is whether that access is being used the way it’s documented to be used: the same data paths, the same volume, the same timing. A legitimate vendor account suddenly pulling data at 3am, or touching systems it’s never touched before, is a pattern only visible if someone is actually watching for behavioral drift rather than just checking that the login succeeded.
Our take
Monitoring tooling gets sold as the answer to all of this, and better telemetry genuinely helps. But telemetry alone doesn’t tell you whether your SOC would catch a real intrusion, it just tells you data exists somewhere in a dashboard. The only way to actually know whether your Article 9 and Article 10 controls hold up under a real, current attack pattern, not a tabletop scenario written eighteen months ago, is to run one. That’s the honest gap between year one and year two of DORA: year one asked you to build the detection capability, year two is where a supervisor, or an actual attacker, tests whether you built something that works.
We wrote about the broader DORA, NIS2, and CySEC testing landscape for Cyprus firms in an earlier piece, and the point stands here even more directly: a penetration test that only checks for vulnerabilities misses the actual question DORA’s year two supervision is asking. The question isn’t “can someone get in.” It’s “once someone is in, does anyone notice, how fast, and with enough detail to file a real Article 19 report instead of a guess.”
What to actually test before a supervisor asks
- Run a DORA threat-led penetration test scoped specifically to measure detection and response time against your SOC, not just to find exploitable vulnerabilities. The finding that matters most in year two is how long it took your team to notice, not just whether the door was unlocked.
- If your CySEC ICT risk documentation and DORA testing haven’t been consolidated into one evidence trail, a combined CySEC ICT risk assessment avoids running two separate, overlapping engagements against the same infrastructure.
- Commission red team operations built around a realistic, current attack chain, including the kind of low-and-slow lateral movement that alert-fatigued SOCs miss, rather than a noisy scan that trips every alarm and tells you nothing about real detection capability.
- Run an assumed breach assessment that starts from “attacker already has a foothold” and measures how fast your team scopes it. This maps almost directly onto what Article 19’s four-hour clock actually demands of you.
- Treat vendor and third-party access paths as part of the same test, not a separate compliance checkbox, since Articles 28 through 30 hold you accountable for exactly the blind spot most firms have the least visibility into.