DORA, NIS2 and PCI DSS: what each one actually requires for API security testing

The three obligations side by side

Read the table, then read the section for whichever instrument applies to you. The wording quoted is from the consolidated text on EUR-Lex in each case, except for PCI DSS, whose requirement text sits behind the council’s licence acceptance and is therefore summarized rather than quoted.

DORA: yearly, independent, and defined by function rather than by technology

The Digital Operational Resilience Act has applied since 17 January 2025. Article 24(1) requires financial entities other than microenterprises to “establish, maintain and review a sound and comprehensive digital operational resilience testing programme as an integral part of the ICT risk-management framework”. Article 24(4) adds that entities “shall ensure that tests are undertaken by independent parties, whether internal or external”, and Article 24(6) sets the frequency: appropriate tests, at least yearly, on all ICT systems and applications supporting critical or important functions.

Article 25(1) is where penetration testing appears by name, in a list of what the programme must be able to execute.

the execution of appropriate tests, such as vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testingRegulation (EU) 2022/2554, Article 25(1)

The word API does not appear. It does not need to. The obligation attaches to “ICT systems and applications supporting critical or important functions”, and a payment initiation API, a customer data API or a partner integration that a critical function depends on is one of those applications. The mapping exercise you owe your regulator is therefore short: list the critical and important functions, list the ICT assets supporting each, and show that the testing programme reaches them.

Threat-led penetration testing is a separate obligation

Article 26(1) requires entities identified by their competent authority to “carry out at least every 3 years advanced testing by means of TLPT”, and Article 26(2) states that each threat-led penetration test “shall cover several or all critical or important functions of a financial entity, and shall be performed on live production systems supporting such functions”. TLPT is intelligence-led red teaming against production, not an application test, and it does not replace the Article 24(6) yearly testing. An API pentest satisfies part of the yearly obligation; it does not satisfy Article 26.

What the DORA auditor asks for

• The testing programme document, and where API testing sits inside it.
• The register of critical and important functions, with the ICT assets mapped to each.
• For each test: the date, the scope, the identity and independence of the tester, and the findings.
• The remediation record, showing what was fixed and when, and the retest that confirmed it.

NIS2: derive your own cadence, then document it

Directive (EU) 2022/2555 works differently. Article 21(1) requires essential and important entities to take “appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems”. Article 21(2) then lists what those measures must include at least, and two items reach application testing directly.

(e) security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure; (f) policies and procedures to assess the effectiveness of cybersecurity risk-management measuresDirective (EU) 2022/2555, Article 21(2)

There is no frequency in the directive because proportionality is the governing principle: the cadence follows from your own risk assessment. That sounds permissive until you read the implementing regulation.

Commission Implementing Regulation (EU) 2024/2690

For DNS providers, TLD registries, cloud and data-centre providers, CDNs, managed service and managed security service providers, online marketplaces, search engines, social networks and trust service providers, CIR 2024/2690 makes the requirement concrete. Annex point 6.5 requires relevant entities to establish, implement and apply a policy and procedures for security testing, and then to:

• establish, based on the risk assessment, “the need, scope, frequency and type of security tests”;
• carry out security tests “according to a documented test methodology, covering the components identified as relevant for secure operation in a risk analysis”;
• document “the type, scope, time and results of the tests, including assessment of criticality and mitigating actions for each finding”;
• apply mitigating actions in the case of critical findings;
• review and, where appropriate, update the security testing policy at planned intervals.

Recital 15 confirms what counts: security tests “may include automated or manual tests, penetration tests, vulnerability scanning, static and dynamic application security tests, configuration tests or security audits”. A manual API penetration test is squarely inside that list.

Note the shape of the obligation. NIS2 does not tell you to test annually; it tells you to decide, in writing, how often you test and why, and then to keep the records. A supervisor finding no documented rationale is a finding, even if you tested last month.

PCI DSS v4.0.1: it says web applications, and it reaches your API

PCI DSS never uses the word API in the requirement text that can be verified without accepting the council’s licence. It reaches APIs through scope: anything that stores, processes or transmits cardholder data, or that could affect the security of the cardholder data environment, is in scope, and the application-layer testing requirement then applies to it.

Three requirements matter, and the numbering below is the standard’s own. Because the primary document sits behind a licence acceptance, these are summaries rather than quotations; read the requirement text yourself from the PCI SSC document library before you rely on it in an audit response.

Requirement 6.2.4

Software engineering techniques must be defined to prevent or mitigate common software attacks in custom software, and the requirement enumerates the classes: injection attacks, attacks on data and data structures, attacks on cryptography usage, attacks on business logic, attacks on access control mechanisms, and attacks via any high-risk vulnerability identified in the vulnerability identification process. Two of those classes, business logic and access control, are exactly the OWASP API1, API5 and API6 territory that automated tooling does not reach.

Requirement 6.4.2

For public-facing web applications, an automated technical solution must be deployed that continually detects and prevents web-based attacks, sitting in front of the application, running and up to date, generating audit logs and either blocking or alerting. This became mandatory on 31 March 2025, replacing the previous 6.4.1 option of periodic vulnerability assessment. It is a control requirement rather than a testing requirement, but it changes what a tester should verify: whether the protection is actually in the request path for the API, and whether it can be bypassed.

Requirement 11.4

Requirement 11.4.1 asks for a documented penetration testing methodology that includes industry-accepted approaches, covers the entire cardholder data environment perimeter and critical systems, tests from inside and outside the network, validates segmentation controls, includes application-layer testing to identify at minimum the vulnerabilities listed in 6.2.4, includes network-layer testing, reviews the threats and vulnerabilities of the last 12 months, defines a remediation approach, and retains results and remediation activities for 12 months. Requirements 11.4.2 and 11.4.3 set the cadence for internal and external testing: at least once every 12 months and after any significant infrastructure or application upgrade or change, performed by a qualified internal resource or a qualified external third party with organizational independence.

The practical reading: if your API is in or adjacent to the cardholder data environment, the application-layer testing in your 11.4.1 methodology has to reach it, and the methodology document has to say so. A methodology that describes web application testing and is silent about the API is the finding.

ISO 27001 and SOC 2: expected, not mandated

Neither ISO/IEC 27001 nor SOC 2 requires a penetration test. Both require that technical vulnerabilities are identified and managed, and auditors routinely accept a current penetration test report with a remediation record as the strongest available evidence of that. In practice, for a company selling software to enterprises, the customer questionnaire is the harder requirement: it will ask for an annual third-party test and increasingly for the API to be named in the scope.

The useful consequence is that one well-scoped engagement answers several questions at once, provided the report maps its findings to a recognized frame. A report mapped to the OWASP API Security Top 10 and to OWASP ASVS requirements can be quoted into an ISO statement of applicability, a SOC 2 description and a customer security questionnaire without rewriting anything. The report guide sets out what that mapping needs to look like.

Writing the obligation into your own policy

Whichever regime applies, the artefact a supervisor asks for first is a policy that says what you test, how often and why. Six lines are usually enough, and they should be specific enough to be falsifiable.

• Scope. Which APIs are in scope, identified by name and by the function they support, and how new APIs enter the list.
• Trigger. The calendar cadence, plus the change events that trigger an out-of-cycle test: a new authentication scheme, a new tenant model, a new public-facing version.
• Method. The named methodology, and the frame findings are mapped to. Naming tools is not naming a method.
• Independence. Who may run the test, and what independence means in your structure. DORA requires it explicitly; PCI DSS requires organizational independence for the tester.
• Records. What is retained, where and for how long. PCI DSS sets 12 months as a floor for results and remediation activities.
• Closure. The remediation window by severity, and the requirement for a retest statement before a finding is considered closed.

What none of them require

It is worth being precise about the limits, because vendors are not always. None of these instruments requires a specific certification for the testing firm; PCI DSS requires a qualified resource with organizational independence, not a named scheme. None requires a particular tool. None sets a minimum number of tester-days. And none of them, DORA included, requires threat-led red teaming for the general population of entities: Article 26 applies to entities identified for TLPT by their competent authority, not to everyone in scope of the regulation.

What all of them require is the same three things: that you decided what to test and wrote the reason down, that a competent and independent party did the testing, and that you can show what happened to the findings afterwards. A good report supplies the second and third. Only you can supply the first.