IT Security Testing – How to Choose the Right Method and What PCI DSS, DORA, and NIS2 Require

Updated: 4 July 2026

What is IT security testing? IT security testing is the set of structured activities that verify whether an organisation’s systems, networks, and applications are resilient against real-world attacks. Methods differ in approach, depth, and the questions they answer: a vulnerability scan asks “what is vulnerable?”, a penetration test asks “what can an attacker do with that vulnerability?”, and TLPT asks “do your detection and response processes hold up under a simulated APT attack?”

According to Verizon DBIR 2024, 68% of breaches involved a human or technical element that regular security testing could have surfaced.

IT security testing methods – at a glance:

1. A vulnerability scan is automated and identifies known weaknesses – a penetration test is manual and confirms their real-world exploitability in your specific environment
2. PCI DSS v4.0.1 requires vulnerability scans quarterly (Requirement 11.3) and penetration tests annually (Requirement 11.4) – these are separate requirements that answer different risk questions
3. DORA Art. 26 requires TLPT for significant financial institutions every 3 years – the most expensive and complex form of security testing in EU regulation
4. NIS2 Art. 21 mandates regular security testing of networks and information systems as part of risk management for essential and important entities
5. The right test method depends on four factors: regulatory obligations, threat model, architecture (cloud/on-premises), and budget
6. Patronusec delivers penetration tests, TLPT support, and vulnerability scanning with OSCP, CREST, and OSWE-certified testers – reports prepared with QSA knowledge are directly accepted by PCI DSS assessors

---

---

How does a vulnerability scan differ from a penetration test – and when does each apply?

This is the most important distinction for any security manager or CISO procuring testing services. These are fundamentally different tools serving different purposes.

A vulnerability scan is an automated process that compares a system’s configuration against databases of known vulnerabilities (CVE, NVD). The scanner identifies missing patches, weak configurations, open ports, and expired certificates. It does not attempt exploitation – it reports “there is a gap here.” Conducted quarterly or more frequently, it is fast and relatively inexpensive.

A penetration test is a manual attempt by an experienced tester to actively exploit vulnerabilities. The objective is to demonstrate real-world impact – for example, taking over an administrator account or extracting data from a database. More expensive and conducted less frequently (at minimum annually for PCI DSS), but it answers the question that actually matters to the board: “can an attacker cause us real damage?”

Feature	Vulnerability scan	Penetration test
Method	Automated	Manual
Depth	Identification	Exploitation
Question answered	What is vulnerable?	What can an attacker do with it?
Frequency	Quarterly or more often	Annually or after significant changes
Indicative cost	£1,500 to £8,000	£5,000 to £65,000
Lead time	1 to 3 days	2 to 6 weeks
Required by PCI DSS	Yes (Requirement 11.3)	Yes (Requirement 11.4)

Patronusec Insight: The most common mistake when procuring testing services is commissioning a vulnerability scan and reporting it to the board as a “penetration test.” These two documents look visually similar, but they answer fundamentally different questions. A QSA during a PCI DSS assessment will immediately distinguish a scan report from a penetration test report – and will reject the former as an attempt to satisfy Requirement 11.4. Our penetration tests deliver a report with proof-of-concept exploitation, a documented attack path, and an assessment of business impact – not a CVE list sorted by CVSS score.

What types of penetration test exist – and when should each be used?

Penetration tests differ in the level of prior knowledge available to the tester – the so-called “box model.”

Black box: the tester has no prior knowledge of the target system (simulating an external attacker). The most expensive per unit of value for the client – significant time is spent on reconnaissance, leaving less time for deep exploitation.

White box: the tester has full documentation, source code, and network diagrams. The most efficient in terms of depth – it uncovers vulnerabilities in business logic and code that a black box engagement would not reach within a limited timeframe.

Grey box: a compromise – the tester has partial information (for example, a user account and general architecture overview), simulating an internal attacker or one who has already completed initial reconnaissance. Recommended for most PCI DSS engagements.

Penetration test categories by scope:

Type	What it covers	Typically required by
Infrastructure penetration test	Networks, servers, network devices, VPN	PCI DSS Req. 11.4.2, NIS2
Web application penetration test	HTTP/HTTPS, APIs, business logic, OWASP Top 10	PCI DSS Req. 11.4.2, DORA
Internal network penetration test	Active Directory, lateral movement, privilege escalation	PCI DSS Req. 11.4.3 (segmentation test)
Social engineering	Phishing, vishing, pretexting	NIS2, security awareness
TLPT (Threat-Led Penetration Testing)	Full APT simulation on live production systems	DORA Art. 26

---

Unsure which test type meets your regulator’s or client’s requirements?

Patronusec conducts a free 30-minute scoping call during which we determine the test scope appropriate to your environment, regulations, and budget. We provide written confirmation of the methodology acceptable to PCI DSS QSAs, ISO 27001 auditors, and DORA.

Discuss test scope with an expert

---

What is TLPT and when is it mandatory under DORA?

TLPT (Threat-Led Penetration Testing) is a simulation of a realistic APT attack on a financial institution’s live production systems. It differs from a standard penetration test in that:

• It is planned in strict secrecy (most of the organisation’s staff do not know a test is underway)
• It simulates specific APT groups and TTPs (Tactics, Techniques, Procedures) characteristic of the financial sector
• It tests not only technical controls but also detection, response, and communications processes
• It is coordinated with the relevant supervisory authority (EBA, ESMA, EIOPA, or national equivalent)

TLPT under DORA – what Art. 26 requires:

DORA Art. 26 mandates TLPT for significant financial institutions at a frequency of at least once every 3 years. Scope: critical systems and services as identified in the institution’s ICT risk management framework. The DORA TLPT framework is based on TIBER-EU (Threat Intelligence-Based Ethical Red Teaming), developed by the ECB.

TLPT versus a standard penetration test:

Aspect	Standard penetration test	TLPT
Scope	Defined in advance	Based on threat intelligence specific to the institution
Environment	May use test or staging systems	Live production systems
Duration	1 to 4 weeks	3 to 6 months (preparation plus execution)
Coordination	Internal IT teams	Supervisory authority, board
Cost	£5,000 to £65,000	£80,000 to £300,000+
Required by	PCI DSS, ISO 27001, NIS2	DORA Art. 26 (significant institutions)

TLPT is delivered by accredited red team providers and is the most demanding security test prescribed by EU financial regulation.

Patronusec Insight: Organisations subject to DORA frequently confuse TLPT with advanced penetration testing. The critical difference: TLPT tests the entire detect-and-respond cycle, not just the technical controls. A TLPT engagement that runs for 3 months without detection by the SOC – despite active malicious behaviour on production systems – is a finding that reveals a gap in the detection programme, not only in technical security. This distinction matters enormously for the board report and for regulatory reporting. We advise clients on TLPT readiness as part of our DORA compliance service.

When does SAST or DAST testing apply – and what do PCI DSS and DORA require for application code?

SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing) are testing methods specific to application code and APIs.

SAST (Static Analysis):
Analysis of source code or compiled code without running the application. Identifies vulnerabilities in the code itself – SQL injection, hard-coded credentials, cryptographic weaknesses, insecure functions. Required in a secure SDLC (PCI DSS Requirement 6.2.4). Can be automated in CI/CD pipeline.

DAST (Dynamic Analysis):
Testing the running application through its interfaces (HTTP, API, browser). Simulates attacker behaviour against the live application. Identifies vulnerabilities that only appear at runtime – authentication flaws, session management issues, business logic errors. Includes tools such as OWASP ZAP, Burp Suite, and manual application penetration testing.

What PCI DSS v4.0.1 requires for application testing:

• Requirement 6.2.4: Bespoke and custom software must be reviewed for common vulnerabilities before deployment – this covers both SAST and code review
• Requirement 6.3.3: All software components (including libraries and frameworks) must be protected against known vulnerabilities – continuous SAST/SCA in CI/CD
• Requirement 11.4.2: Annual penetration test must cover the application layer (not only the network layer) – DAST-based application testing with manual verification

What DORA requires for application testing:

DORA Art. 9 requires financial entities to identify and classify their critical ICT assets and test them proportionately to their risk classification. For payment applications and banking systems, this translates to application-layer testing at minimum annually, and after significant changes.

---

Planning an annual penetration test or application security review to satisfy PCI DSS or DORA requirements?

Patronusec delivers application penetration tests (OSCP, OSWE certified) and source code reviews. Reports are prepared specifically for QSA acceptance – with documented methodology satisfying PCI DSS Requirement 11.4.1.

Book a security testing scoping call

---

How do you choose the right security testing method for your organisation?

The decision depends on four factors:

Factor 1: Regulatory obligations

• PCI DSS: quarterly ASV scans (external) plus authenticated internal scans (11.3) plus annual penetration test with documented methodology (11.4)
• ISO 27001: Annex A Control 8.8 requires vulnerability management; penetration testing is strongly implied for technical environments
• NIS2: regular security testing of networks and information systems – method not prescribed but must be proportionate to risk
• DORA: TLPT every 3 years for significant institutions; annual threat-led testing for others

Factor 2: Threat model
External attacker focus: network perimeter penetration test plus ASV external scan. Insider threat or post-compromise: internal network test plus Active Directory review. Application fraud: web application penetration test plus API testing. Supply chain: CI/CD pipeline security review.

Factor 3: Architecture
Cloud-native environments require cloud-specific expertise (IAM policy analysis, Security Group review, container image scanning). Legacy environments require different tooling. Mixed hybrid environments require scope definition before testing begins.

Factor 4: Budget and frequency
A minimum annual budget: external ASV scans (4 per year) plus one internal penetration test plus one web application test. An optimal annual budget adds: quarterly authenticated internal scans plus a segmentation test plus a social engineering simulation.

FAQ – IT security testing

---

IT security testing – free consultation

Patronusec delivers penetration tests, TLPT support, and vulnerability scanning programmes for fintech, e-commerce, and financial services organisations – with OSCP, OSWE, and CREST-certified testers and QSA-accepted reports.

In a free 30-minute consultation we will help you:

• Determine which testing methods your regulatory obligations (PCI DSS, DORA, NIS2, ISO 27001) require
• Define a test scope matched to your architecture (cloud-native, hybrid, containerised)
• Understand the methodology documentation required by PCI DSS Requirement 11.4.1
• Receive a fixed-price quotation with a guaranteed report delivery date

Free consultation | Penetration testing | Vulnerability scans ASV | PCI DSS certification | DORA compliance