The vulnerability scan vs penetration test question decides whether your compliance file survives review. A scan is an automated list of known weaknesses. A penetration test is a manual attempt by a qualified tester to exploit them, and regulators treat the two as separate evidence. A scanner PDF labeled 'pentest' will fail a PCI DSS assessment and draw hard questions from DORA supervisors and ISO 27001 auditors.
The short answer
- A vulnerability scan finds known issues automatically; a penetration test proves what an attacker can actually do with them. They are not interchangeable.
- PCI DSS 4.0.1 requires both: quarterly internal and ASV external scans (Requirement 11.3) plus internal and external pentests every 12 months and after significant change (Requirement 11.4).
- DORA requires yearly testing of systems supporting critical or important functions. TLPT applies at least every three years, and only to entities their authority designates.
- NIS2 and ISO 27001 set no fixed frequency but expect risk-based test evidence. An ASV scan report satisfies one PCI requirement (11.3.2) and is never evidence of a penetration test.
Key takeaways
- A vulnerability scan lists known weaknesses; a penetration test proves exploitability. Regulators treat them as separate evidence.
- PCI DSS 4.0.1 puts scans in Requirement 11.3 and pentests in 11.4; both are mandatory, and an ASV attestation covers only 11.3.2.
- DORA requires yearly testing of systems supporting critical or important functions; TLPT every three years applies only to designated entities.
- NIS2 and ISO/IEC 27001:2022 set no pentest frequency but expect risk-based test evidence.
- Cyprus EMIs answer to the Central Bank of Cyprus on DORA; CIFs and CASPs answer to CySEC; NIS2 entities answer to the Digital Security Authority.
Vulnerability scan vs penetration test: is a scan enough for compliance?
Rarely, for a regulated Cyprus firm. A scanner such as Nessus, Qualys or OpenVAS matches services against a database of known flaws: a missing patch, a weak TLS configuration, a default credential. It cannot tell you whether an attacker could chain three medium findings into access to client funds.
A penetration test is a manual, time-boxed attack by a qualified person. The tester exploits what the scanner flagged and looks for what scanners miss: access-control flaws that let one customer reach another’s data, business-logic flaws in a withdrawal flow, weak session handling, insecure APIs.
The pattern we see most often: an IT team exports a scan PDF and files it as the annual pentest. The PDF has no tester name, no scope statement and no exploitation evidence. You want to discover that gap internally, not from a QSA or supervisor.
The test types answer different questions. A scan asks what is known to be weak. A pentest asks what can be broken. A red team asks whether you would notice.
| Activity | Method | Answers | Typical duration | Typical frequency |
|---|---|---|---|---|
| Vulnerability scan | Automated, signature-based | Which known CVEs and misconfigurations exist? | Minutes to hours | Monthly or quarterly |
| Vulnerability assessment | Scan plus human validation and prioritization, no exploitation | Which findings are real and which matter first? | 1 to 3 days | Quarterly |
| Penetration test | Manual exploitation within an agreed scope | What can an attacker reach, and how? | 3 to 20 tester-days | Annually and after significant change |
| Red team / assumed breach | Objective-driven, stealthy; tests people, process and detection | Would the SOC detect and stop a real intrusion? | Weeks | Every 1 to 2 years for mature firms |
| TLPT (DORA) | Intelligence-led red team on live production, under the RTS and TIBER-EU, overseen by the authority | Can a realistic threat actor compromise critical functions? | Months | At least every 3 years, designated entities only |
An assumed breach assessment sits between a pentest and a red team: the tester starts from a compromised laptop or account and measures the blast radius. It tests internal segmentation without the cost of a full phishing-to-domain-admin campaign. A framework-by-framework comparison follows further down.
What does PCI DSS 4.0.1 require, and does an ASV scan count as a pentest?
PCI DSS requires scans and pentests under separate requirements, and an ASV scan never counts as a pentest. Version 4.0.1 is the active standard (v4.0 was retired at the end of 2024), and its future-dated requirements became mandatory on March 31, 2025.
Watch the numbering if you reuse old templates. In v3.2.1, scans were Requirement 11.2 and pentests 11.3. In v4.0.1, scans are 11.3 and pentests are 11.4.
- 11.3.1: internal scans at least every three months, with high-risk and critical findings resolved and rescanned. 11.3.1.2 makes those scans authenticated.
- 11.3.2: external scans by an ASV every three months, with a passing result. 11.3.2.1 adds scans after significant change.
- 11.4.1: a documented methodology covering the CDE perimeter and critical systems, network and application layers, with results retained for at least 12 months.
- 11.4.2 and 11.4.3: internal and external penetration tests at least every 12 months and after any significant change.
- 11.4.4: exploitable findings corrected and retested.
- 11.4.5: segmentation controls tested at least every 12 months and after changes. 11.4.6 tightens this to every six months for service providers.
An Approved Scanning Vendor (ASV) is a company listed by the PCI Security Standards Council to scan your internet-facing IP addresses. Its attestation satisfies 11.3.2 and nothing else. ASV scans exploit nothing, never touch the internal network, never log in to your application and never test segmentation.
A QSA reviewing your Report on Compliance will mark 11.4.2 and 11.4.3 as not in place if the only evidence is an ASV attestation. Outside card payments, a clean ASV scan tells a reviewer only that your perimeter had no known, remotely detectable vulnerabilities this quarter. It says nothing about whether one customer can read another’s statements.
For EMIs, payment processors and iGaming operators taking card deposits, our PCI DSS penetration testing is mapped requirement-by-requirement to 11.4 so your QSA can verify each sub-requirement.
How often does DORA require a penetration test, and is TLPT mandatory?
DORA, in force since January 17, 2025, requires yearly testing of every ICT system and application that supports a critical or important function (Article 24(6)). TLPT applies at least every three years, but only to entities their competent authority designates.
Article 25 lists what counts as a test: vulnerability assessments and scans, open-source analyses, network security assessments, source code reviews where feasible, scenario-based tests, end-to-end testing and penetration testing. DORA does not say ‘pentest every system every year’. In practice, supervisors expect manual pentests on client portals, trading platforms and payment APIs, because a scan cannot test their authorization logic.
Smaller entities under the simplified ICT risk framework in Article 16 (for example small and non-interconnected investment firms) must still test, but proportionate to their risk.
TLPT follows Article 26 and Commission Delegated Regulation (EU) 2025/1190, which is aligned with TIBER-EU. It targets systemically relevant firms: large banks, CCPs and CSDs, major trading venues, large insurers, and payment institutions and EMIs above €150 billion in payment transactions in each of the two previous years. Most Cyprus CIFs and EMIs will not be designated.
On independence, Article 24(4) requires tests by independent parties, internal or external. For TLPT, internal testers are allowed only under conditions, external testers must run at least one test in every three, and significant credit institutions must use external testers only. If you are notified, our DORA threat-led penetration testing (TLPT) page explains the threat intelligence and red team phases.
Do NIS2 and ISO 27001 require penetration testing, and how often?
Neither names a pentest frequency. NIS2 Article 21 never uses the words ‘penetration test’. It requires vulnerability handling (21(2)(e)) and procedures to assess the effectiveness of your cybersecurity measures (21(2)(f)). Testing is how you prove 21(2)(f).
Two details make testing harder to avoid. Commission Implementing Regulation (EU) 2024/2690 adds explicit security testing duties for cloud providers, data centers, managed service and managed security providers, DNS and trust service providers, and online marketplaces. Under Article 32, supervisors can order security audits and security scans of essential entities. In Cyprus, that power sits with the Digital Security Authority.
Fines reach €10 million or 2% of global turnover for essential entities and €7 million or 1.4% for important ones. DORA takes precedence over NIS2 for financial entities, so a CIF or EMI follows DORA’s testing rules. Shipping companies, energy firms and Cyprus MSPs answer under NIS2.
ISO/IEC 27001:2022 likewise sets no frequency. Auditors expect a schedule that follows your risk assessment, which for most firms means an annual external and application pentest plus tests after major change. The relevant controls are A.8.8 (technical vulnerabilities), A.8.29 (security testing in development and acceptance) and A.5.35 (independent review).
Regular scanning evidences A.8.8; pentests are the usual evidence for A.8.29 and show that A.8.8 works beyond detection. The transition from the 2013 version ended on October 31, 2025. If your Statement of Applicability says pentesting is annual, the auditor will ask for this year’s report.
What does CySEC expect, and who supervises an EMI? (Not CySEC)
Who to answer to in Cyprus: CySEC for CIFs, CASPs under MiCA, AIFMs and UCITS management companies. The Central Bank of Cyprus for EMIs and payment institutions. The Digital Security Authority, with CSIRT-CY, for NIS2 entities. The Commissioner for Personal Data Protection for GDPR.
CySEC expects regulated firms to meet DORA’s testing requirements: yearly, documented tests of systems supporting critical or important functions, with findings tracked to closure. EMIs face the same DORA expectations, but their evidence goes to the Central Bank of Cyprus.
What reviewers look for in practice:
- A testing program tied to your register of critical or important functions, not a one-off report.
- External manual pentests of MT4/MT5 or proprietary trading front ends, client portals, mobile apps and payment APIs.
- Evidence that results feed the yearly review of the ICT risk management framework under DORA Article 6(5).
- Retest results showing high and critical findings closed.
GDPR Article 32(1)(d) adds a separate duty: a process for regularly testing, assessing and evaluating the effectiveness of the technical and organizational measures that secure processing. For a fuller plan, see our guide on what Cyprus financial firms need to test in 2026.
Which framework asks for what, and can your own IT team test?
PCI DSS is prescriptive, DORA is semi-prescriptive, and NIS2, ISO 27001 and GDPR are risk-based.
| Framework | Scans | Penetration test | Stated frequency | Who may test |
|---|---|---|---|---|
| PCI DSS 4.0.1 | Required: internal (11.3.1) and ASV external (11.3.2) | Required: internal, external, segmentation (11.4) | Scans quarterly; pentests every 12 months and after change | Qualified, organizationally independent internal staff or third party; ASV for external scans |
| DORA | Listed in Article 25 | Listed in Article 25; TLPT in Article 26 | Yearly for critical or important functions; TLPT at least every 3 years | Independent internal or external; TLPT tester rules in Articles 26 and 27 |
| NIS2 | Implied by vulnerability handling | Not named in Article 21 | None in the directive | Not specified |
| ISO/IEC 27001:2022 | Expected under A.8.8 | Expected by auditors, risk-based | None | Competent, independent of the system |
| GDPR Article 32 | Not named | Not named; ‘regularly testing’ required | Regularly | Not specified |
Internal teams can test if they are qualified and independent of what they test. PCI DSS accepts a qualified internal resource with organizational independence; the tester need not be a QSA or ASV. The person who configured the firewall cannot test it.
ISO 27001 auditors accept internal testing when competence and independence are documented. The practical cost is credibility: a report written by the team that runs the environment draws more questions in review.
What must the report contain, and how do you plan the work?
Report contents
Reports are usually rejected because one of these is missing:
- Scope: IP ranges, URLs, applications, user roles, exclusions and test dates.
- Methodology: a named standard such as the OWASP Web Security Testing Guide, PTES or NIST SP 800-115, matching your 11.4.1 methodology for PCI.
- Tester names, qualifications and a statement of independence.
- An executive summary mapped to business impact.
- Each finding with severity (CVSS or equivalent), affected asset, reproduction steps, evidence and remediation guidance.
- Segmentation results where required, and a retest section confirming which findings are closed.
Prioritizing scan findings
Rank by exploitability and exposure first, CVSS second. A CVSS 9.8 on an isolated test box matters less than a 7.5 on an internet-facing login page. Anything in the CISA Known Exploited Vulnerabilities catalog on an exposed asset goes first. EPSS scores separate likely-exploited flaws from theoretical ones.
Systems in the CDE or supporting a DORA critical or important function outrank back-office tools. Document any compensating controls, because auditors will ask. PCI DSS removes some discretion: high-risk and critical internal findings and all failing external findings must be resolved and rescanned.
Cost and timing
A scan is a recurring tool cost; a pentest is priced by tester-days and scope. Scanner licenses and ASV subscriptions typically run from a few hundred to a few thousand euros a year. Indicative pentest effort: 2 to 4 days for a small firm’s external perimeter, 5 to 10 days for a web application or API with several roles, 10 to 20 days for full PCI scope.
A red team takes several weeks; TLPT takes months, and the TLPT technical standards set a minimum active testing phase. Add time for scoping and a retest. Book the annual pentest at least two months before the audit or reporting deadline so remediation fits in.
FAQ
Is a vulnerability scan the same as a penetration test?
No. A scan automatically checks for known flaws. A penetration test is a manual attempt by a qualified tester to exploit weaknesses, including access-control and logic flaws that scanners cannot see.
Does PCI DSS 4.0.1 require a penetration test every year?
Yes. Requirements 11.4.2 and 11.4.3 require internal and external penetration tests at least every 12 months and after any significant change, separate from the quarterly scans in Requirement 11.3.
Is DORA TLPT mandatory for every financial entity?
No. TLPT is required at least every three years only for entities their competent authority designates, typically large banks, market infrastructures, large insurers and very large payment institutions or EMIs.
Does NIS2 require annual penetration testing?
The directive sets no frequency and does not name penetration testing. It requires you to assess the effectiveness of your security measures, and supervisors such as Cyprus's Digital Security Authority can order audits and scans of essential entities. Testing is the usual way to show compliance.
Can our internal IT team run the compliance pentest?
Yes, if the testers are qualified and independent of the systems they test. PCI DSS, DORA and ISO 27001 all accept independent internal testers, though DORA TLPT adds conditions and requires external testers for at least one test in every three.
If you need test evidence that will hold up in front of CySEC or the Central Bank of Cyprus, our CySEC ICT risk penetration testing is scoped to your register of critical functions and comes with a retest report.