PCI DSS, DORA and NIS2: three testing regimes, one payment firm

Three instruments, three kinds of force

The first thing to get straight is what each one actually is, because the word "requirement" is doing three different jobs.

What each regime is, and why it applies to you

	PCI DSS	DORA	NIS2
Instrument	A private industry standard published by the PCI Security Standards Council	Regulation (EU) 2022/2554, directly applicable	Directive (EU) 2022/2555, transposed into national law
Applies because	Your acquirer contract requires it	Article 2 names your entity type	You are an essential or important entity in a listed sector
Scope of testing	The cardholder data environment	ICT systems and applications supporting critical or important functions	Network and information systems used for your operations
Who enforces it	Card brands, through acquirers	Financial supervisors	National competent authorities
Named testing duty	Vulnerability scanning at least once every three months, plus penetration testing	A testing programme, at least yearly on critical functions, plus TLPT for identified entities	Policies and procedures to assess the effectiveness of risk-management measures

DORA: who is in, and what it asks for

DORA applies because of what you are, not what you signed. Article 2(1) lists the entities, and the payments sector is comprehensively covered: credit institutions; payment institutions, "including payment institutions exempted pursuant to Directive (EU) 2015/2366"; account information service providers; electronic money institutions, including those exempted under Directive 2009/110/EC; investment firms; crypto-asset service providers; central securities depositories; central counterparties; trading venues; and further categories through to insurance and pension undertakings. Article 2(2) calls points (a) to (t) collectively "financial entities". Point (u) brings in ICT third-party service providers.

The testing programme, Article 24

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". Three of its paragraphs matter to anyone buying a test.

• Article 24(4): "financial entities, other than microenterprises, shall ensure that tests are undertaken by independent parties, whether internal or external. Where tests are undertaken by an internal tester, financial entities shall dedicate sufficient resources and ensure that conflicts of interest are avoided throughout the design and execution phases of the test."
• Article 24(5): entities must "establish procedures and policies to prioritise, classify and remedy all issues revealed throughout the performance of the tests" and internal validation methodologies to confirm that every weakness is fully addressed.
• Article 24(6): entities must ensure "at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions."

That last line is the annual obligation people mean when they say DORA requires yearly testing. Note what it is scoped to: critical or important functions, not the whole estate, and not the cardholder data environment.

What counts as a test, Article 25

DORA does something PCI does not: it lists the techniques, in the text of the law.

The digital operational resilience testing programme referred to in Article 24 shall provide … for 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 testing.Regulation (EU) 2022/2554, Article 25(1)

It is a menu, not a checklist. The choice among them is risk-based under Article 24(3), which requires entities to follow "a risk-based approach … duly considering the evolving landscape of ICT risk, any specific risks to which the financial entity concerned is or might be exposed, the criticality of information assets and of services provided".

Threat-led penetration testing, Article 26

TLPT is a separate, heavier obligation and it does not apply to everyone. It applies to entities that competent authorities identify, using criteria in Article 26(8): the impact of the entity's services on the financial sector, financial stability concerns including systemic character, and the entity's ICT risk profile and maturity.

• Frequency: identified entities "shall carry out at least every 3 years advanced testing by means of TLPT", and the competent authority may require a higher or lower frequency based on risk profile.
• Scope: each 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". The precise scope is validated by the competent authority.
• Third parties: where ICT third-party providers are in scope, the entity must ensure their participation and "shall retain at all times full responsibility for ensuring compliance with this Regulation". Where their participation would harm other customers, a pooled test involving several financial entities is permitted.
• Testers: entities may use internal testers, but "shall contract external testers every three tests", and significant credit institutions under Article 6(4) of Regulation (EU) No 1024/2013 "shall only use external testers".
• Output: at the end, the entity and any external testers provide the designated authority with "a summary of the relevant findings, the remediation plans and the documentation demonstrating that the TLPT has been conducted in accordance with the requirements", and the authority issues an attestation enabling mutual recognition between competent authorities.

Article 26(11) requires the regulatory technical standards to be developed "in accordance with the TIBER-EU framework", which is why a DORA TLPT looks like a TIBER engagement rather than like a penetration test.

Who may test, Article 27

DORA writes tester requirements into law, which PCI does not do in any text this site could read. Testers must "be of the highest suitability and reputability"; "possess technical and organisational capabilities and demonstrate specific expertise in threat intelligence, penetration testing and red team testing"; be "certified by an accreditation body in a Member State or adhere to formal codes of conduct or ethical frameworks"; provide "an independent assurance, or an audit report, in relation to the sound management of risks associated with the carrying out of TLPT"; and be "duly and fully covered by relevant professional indemnity insurances, including against risks of misconduct and negligence."

Where internal testers are used, Article 27(2) adds that the competent authority must have approved it, verified the resourcing and conflict-of-interest controls, and that "the threat intelligence provider is external to the financial entity".

NIS2, and why it may not apply to you

NIS2 sets out ten minimum cybersecurity risk-management measures in Article 21(2), and exactly one of them is the testing hook: "policies and procedures to assess the effectiveness of cybersecurity risk-management measures". The Directive never uses the phrase penetration test. Anyone quoting you a NIS2 penetration-testing clause is quoting something that does not exist.

The other nine are worth knowing because they shape the supplier questionnaires you receive: risk analysis and information system security policies; incident handling; business continuity including backup management, disaster recovery and crisis management; supply chain security; security in acquisition, development and maintenance including vulnerability handling and disclosure; basic cyber hygiene and training; cryptography and encryption; human resources security, access control and asset management; and multi-factor or continuous authentication.

The carve-out

For a financial entity in DORA scope, the substantive NIS2 provisions switch off. The mechanism is Article 4(1) of NIS2:

Where sector-specific Union legal acts require essential or important entities to adopt cybersecurity risk-management measures or to notify significant incidents and where those requirements are at least equivalent in effect to the obligations laid down in this Directive, the relevant provisions of this Directive, including the provisions on supervision and enforcement laid down in Chapter VII, shall not apply to such entities.Directive (EU) 2022/2555, Article 4(1)

DORA asserts that it meets that test. Its recital 50 states that because the Regulation introduces requirements "more stringent in comparison to those laid down in the current Union financial services law", this "constitutes lex specialis with regard to Directive (EU) 2022/2555". Financial entities nonetheless remain inside the NIS2 ecosystem for cooperation purposes: DORA recital 54 says they "should remain part of the ecosystem of that Directive", including the Cooperation Group and the CSIRTs.

Can one test serve two regimes?

Partly, and only if it is planned that way from the scoping call. The obstacle is not effort, it is that the three regimes draw their boundaries around different things.

• PCI stops at the cardholder data environment and the systems connected to it. Anything outside that boundary is, by design, not what the test is about.
• DORA follows critical or important functions. A payment platform is almost certainly one; so may be a customer-facing app or a settlement process that touches no cardholder data at all.
• NIS2 covers network and information systems used for your operations or the provision of your services, which is broader still and less precisely bounded.

For a payment institution, the payment platform sits inside all three circles, and one well-scoped engagement can generate evidence for all three. What it cannot do is produce three reports. A PCI assessor is looking for scope traceable to the documented cardholder data environment and findings mapped to the control areas of the standard. A DORA supervisor, for TLPT, is looking for threat intelligence, a red-team narrative against live production, and an authority attestation under Article 26(7). Those are different documents even when they describe the same week of work.

The practical sequence that works: scope once, against a map that names which systems belong to which regime; test once, with the union of the objectives; then write the reports separately, each answering the questions its audience is required to ask. Nobody saves money by pretending a TLPT summary is a PCI test report.

Three questions worth asking before you buy

1. Which regimes actually apply to us? DORA is answered by reading Article 2 against your licence. NIS2 is answered by whether Article 4 carves you out. PCI is answered by your acquirer contract.
2. Has a competent authority identified us for TLPT? If not, Article 26 does not apply to you and buying a TIBER-style engagement is a choice, not an obligation. Article 24(6) still requires yearly testing of critical or important functions.
3. Where is the boundary of each? Write down, once, which systems are in the cardholder data environment, which support a critical or important function, and which are neither. Most of the argument about test scope is really an unresolved argument about that table.

For the PCI side of the boundary question, see segmentation testing. For what the PCI regime asks you to run and how often, see ASV scan or penetration test.