If you run a Cyprus Investment Firm, a bank, an insurer, or any other regulated financial business on the island, you are very likely staring at three overlapping cybersecurity obligations right now: DORA, NIS2, and CySEC’s own ICT risk circulars. Each one has its own legal basis, its own regulator, and its own idea of what “tested” actually means. None of them is satisfied by an annual vulnerability scan, and confusing the three, or assuming one covers the others, is the single most common compliance gap we see when we scope a penetration test for a Cyprus financial firm.
This guide walks through what each framework actually requires, who is in scope, how often testing has to happen, and what a penetration test that satisfies DORA, NIS2, and CySEC actually looks like in practice.
What is penetration testing, and why does a regulator care?
Penetration testing is a controlled, authorised attempt to break into your systems the way a real attacker would, not a scan that checks your software versions against a list of known bugs. A tester manually chains weaknesses together, exactly the way a criminal actor would, to show what data or access a real intrusion could actually reach. That distinction matters to regulators specifically because a vulnerability scan tells you what might be wrong; a penetration test tells you what an attacker could actually do about it, and that is the standard DORA, NIS2, and CySEC are all built around.
DORA: what the Digital Operational Resilience Act actually requires
The Digital Operational Resilience Act (DORA) has applied across the EU, Cyprus included, since 17 January 2025. It covers banks, investment firms, payment institutions, e-money institutions, insurers, crypto-asset service providers, and a long list of other financial entities. DORA’s testing requirement sits in Article 24 and Article 26, and it splits into two tiers that get confused constantly:
- Basic ICT testing (Article 24) applies to every in-scope financial entity, every year. This covers vulnerability assessments, scenario-based testing, and, for most firms, penetration testing of critical ICT systems and applications.
- Threat-Led Penetration Testing, or TLPT (Article 26) is a much heavier, advanced requirement that only applies to entities the regulator identifies as significant to the financial system’s stability, typically larger banks and systemically important firms. TLPT has to follow the TIBER-EU framework and happen at least every three years, using real threat intelligence to simulate a specific, realistic adversary against live production systems.
The Regulatory Technical Standards (RTS) under DORA spell out exactly how this testing has to be scoped, documented, and reported, down to how test scenarios are selected and how findings get remediated and re-verified. For most Cyprus CIFs and payment firms, Article 24 basic testing is the relevant bar, not full TLPT, but “basic” does not mean superficial: DORA expects manual, evidence-backed penetration testing, not an automated scan with a summary attached.
How often does DORA require penetration testing?
At minimum, annually, for the basic testing programme under Article 24. Entities in scope for TLPT under Article 26 need a full threat-led test at least every three years, on top of, not instead of, their annual basic testing.
NIS2 in Cyprus: a much wider net than most businesses expect
NIS2 was transposed into Cyprus law as Law 60(I)/2025, with the Digital Security Authority acting as the national supervising body. Where the old NIS Directive only really touched a handful of critical infrastructure operators, NIS2 pulls in a much broader set of “essential” and “important” entities under its Annex I and Annex II sector lists, banking and financial market infrastructure among them, but also energy, health, digital infrastructure, and several other sectors that had never been directly regulated for cybersecurity before.
Article 21 of NIS2 sets out the actual risk management obligations: policies for risk analysis, incident handling, business continuity, supply chain security, and, explicitly, security testing of the measures put in place. Unlike DORA, NIS2 does not name “penetration testing” with a fixed schedule in the text itself, it talks about testing and evaluating the effectiveness of risk management measures on a regular basis, which in practice means an independent test mapped to your Article 21 obligations, repeated often enough to stay current as your systems change.
For a lot of Cyprus businesses, NIS2 is the first time a cybersecurity law has applied to them directly, rather than through a client’s due diligence questionnaire. If you have never had a genuine penetration test and you fall under NIS2 in Cyprus, that gap has gone from a business risk to a legal one.
CySEC ICT risk: Circulars C571 and C609
Before DORA existed, CySEC had already set out ICT risk management expectations for Cyprus Investment Firms through Circulars C571 and C609, aligned with EBA guidelines on ICT and security risk management. These circulars introduced capital-based thresholds that determine how deep a CIF’s ICT risk framework has to go, with the original compliance deadline set for 31 December 2023 and an internal audit report due by 30 June 2024.
DORA has not replaced this framework, it sits on top of it. In practice, the overlap between CySEC’s ICT risk expectations and DORA’s Article 24 testing requirement is large enough that a well-scoped penetration test can generate evidence that satisfies both at once, instead of running two separate engagements against the same systems a few months apart.
Where ISO 27001 fits in
Many Cyprus financial firms are also pursuing or maintaining ISO 27001 certification alongside their regulatory obligations, and this is the point where a common misunderstanding creeps in. ISO 27001’s Annex A.8.29 does require security testing during development and acceptance, but the standard itself does not name “penetration testing” as a mandatory line item, and certification auditors will accept a range of evidence for that control. In practice, though, a genuine penetration test remains the clearest way to demonstrate Annex A.8.29 is a real, operating control rather than a paper one, and it is exactly the kind of evidence CySEC and DORA supervisors are already used to reviewing. If your firm holds or is pursuing ISO 27001 on top of DORA and CySEC obligations, one properly scoped test can support all three at once.
What a penetration test that actually satisfies all three looks like
The mistake we see most often is a firm running a cheap, automated scan to “tick the box,” then discovering during an audit or after an incident that the report does not hold up as evidence. A test that genuinely satisfies DORA, NIS2, and CySEC at once needs to:
- Cover live production systems supporting critical or important functions, not a staging environment that only resembles them.
- Be performed manually by testers who chain findings together the way a real attacker would, not just list CVEs from a scanner.
- Map every finding back to the specific regulatory control it relates to (DORA Article 24, NIS2 Article 21, or the relevant CySEC circular), so the report reads as compliance evidence, not just a technical list.
- Include a retest after remediation, since an unclosed critical finding is exactly what a regulator, or an attacker, will find first.
- Come with a rules-of-engagement document and a plan that protects business continuity, since DORA testing in particular has to run against real production systems.
Our penetration testing service is built around exactly this kind of scoped, evidence-producing engagement. Where the exposure sits specifically in a customer portal, trading platform, or client area, which is usually where a CIF’s real client-facing risk lives, our web application penetration testing work drills directly into that layer, and for the wider public-facing infrastructure and network perimeter, our website penetration testing services cover what NIS2 and CySEC expect to see tested and documented.
Frequently asked questions
Does DORA require penetration testing every year?
Yes, for basic ICT testing under Article 24, which applies to essentially every in-scope financial entity. Only firms identified as significant to financial stability face the heavier Threat-Led Penetration Testing (TLPT) requirement under Article 26, which runs at least every three years, in addition to, not instead of, the annual basic testing.
Does NIS2 require penetration testing specifically?
NIS2’s Article 21 requires regular testing and evaluation of your risk management measures, without naming “penetration testing” as a fixed, scheduled requirement the way DORA does. In practice, an independent penetration test mapped to your Article 21 obligations is the evidence Cyprus’s Digital Security Authority expects to see.
Does ISO 27001 require penetration testing?
Not by that exact name. Annex A.8.29 requires security testing during development and acceptance, and auditors accept a range of evidence for it, but a real penetration test is the clearest, most defensible way to demonstrate the control actually works.
What is DORA threat-led penetration testing (TLPT)?
TLPT is the advanced testing track under DORA Article 26, following the TIBER-EU framework. It uses real threat intelligence to simulate a specific, realistic adversary against live production systems and only applies to entities identified by regulators as significant to financial system stability, at a minimum frequency of once every three years.
Can one penetration test cover DORA, NIS2, and CySEC at the same time?
Yes, if it is scoped correctly from the start. Because these frameworks overlap heavily in what they expect (manual, evidence-backed testing of production-relevant systems), a single engagement mapped explicitly to each framework’s specific articles and circulars can generate compliance evidence for all three, rather than running separate projects against the same infrastructure.
The practical takeaway
DORA, NIS2, and CySEC’s ICT risk circulars were written by different bodies on different timelines, but a Cyprus financial firm sitting under all three does not need three separate testing projects to prove it. What it needs is one engagement, scoped broadly enough and documented precisely enough, to generate evidence each regulator actually recognises. If you are not sure where your current setup stands against DORA, NIS2, or CySEC’s ICT risk circulars, that is the conversation worth having before an auditor, or an attacker, asks the question for you.