PCI DSS takes a genuinely different approach to leadership accountability than NIS2, DORA or the UK CAF.
PCI DSS doesn't name the board or executive team in a training clause anywhere in the standard. What it does require is executive-level accountability for compliance (and only for service providers), plus training for the personnel who actually handle incidents and cardholder data.
Boards sit outside the standard's direct language entirely. Here's exactly where the line falls, and why that gap matters more than it looks.
If you've read our pieces on NIS2 Article 20, DORA Article 5(4), or the UK Cyber Assessment Framework's Principle A1, you'll know each of those frameworks eventually lands on the same conclusion: yes, board-level cybersecurity competence is required, whether stated directly or built into an outcome the board can't otherwise reach.
PCI DSS breaks that pattern. It's worth spelling out exactly how, because the difference has real implications for how organisations that handle cardholder data structure their governance.
The closest PCI DSS v4.0.1 comes to a board-adjacent clause is Requirement 12.4.1, and it's narrower than it first sounds:
"Additional requirement for service providers only: Senior management should establish a PCI DSS compliance program outlining their responsibilities for protecting cardholder data."
Two limits matter immediately. First, this requirement applies only to service providers — an entity that itself stores, processes or transmits cardholder data on behalf of another organisation. A merchant that is not also a service provider is not in scope for 12.4.1 at all.
Second, this is an accountability clause, not a training clause. It requires senior management, which PCI DSS guidance describes as potentially including "senior management, C-level positions, the board of directors, or equivalent positions" depending on organisational structure, to hold overall accountability for maintaining PCI DSS compliance and to define the bylaws of the compliance programme.
Nowhere does it require those individuals to undertake training, refresh their knowledge periodically, or demonstrate competence the way NIS2's Article 20(2) or DORA's Article 5(4) do for their respective management bodies.
The training obligation PCI DSS does contain sits under Requirement 12.10, and it's aimed at a different population entirely:
12.10.4 requires personnel responsible for responding to security incidents to be appropriately and periodically trained.
12.10.4.1 requires that training frequency be set by a targeted risk analysis performed under Requirement 12.3.1, rather than a fixed calendar interval.
This is genuine, specific, testable training language. But it's scoped to incident responders, not governance. A board member with no operational incident response role is not the "personnel" 12.10.4 is written about. The training obligation runs in the opposite direction from NIS2 and DORA: those frameworks start at the top (the management body) and extend downward as encouraged or required practice for staff; PCI DSS starts with operational personnel and never explicitly reaches the board at all.
This isn't an oversight. It reflects what kind of standard PCI DSS is. NIS2 and DORA are statutory instruments enforced by government regulators, built around governance obligations because a legislature was defining accountability across an entire sector. PCI DSS is an industry-mandated contractual standard, created and maintained by the PCI Security Standards Council on behalf of the payment card brands, and enforced through acquirer and payment brand contracts rather than government statute.
Its 12 requirements are built almost entirely around technical and operational controls over the cardholder data environment, network security, access control, encryption, monitoring, and yes, incident response, with governance addressed only insofar as it's needed to keep those controls actively managed, not as an independent objective in its own right.
That's why Requirement 12.4.1 exists at all. The PCI Security Standards Council recognised that a compliance program with no executive-level ownership tends to decay. But it stops well short of building out an equivalent to NIS2's Article 20 or DORA's Article 5, which treat board understanding of risk as a first-order governance requirement independent of any single control.
The absence of a PCI DSS clause naming the board doesn't mean board-level cyber literacy is irrelevant to PCI compliance. It means the standard leaves that connection implicit rather than mandatory.
A few reasons the gap is worth closing voluntarily:
This is exactly the gap our Cybersecurity Training for Executives and the Board Cyber Crisis Programme are designed to close voluntarily. These training programmes help in building the literacy and tested decision-making PCI DSS doesn't mandate, but that a board carrying real financial and reputational exposure from a cardholder data breach benefits from regardless.
Because PCI DSS pushes its training and accountability requirements down toward operational personnel rather than up toward the board, the practical compliance workload concentrates in a different place: building and maintaining the incident response documentation that Requirement 12.10 actually demands across its seven sub-requirements. That's a substantially larger and more technical body of evidence than a governance training record. The PCI DSS Incident Response Document Library organises the full set into 67 documents across 13 categories, each mapped to the specific PCI DSS v4.0.1 requirement number it evidences, including the training register and targeted risk analysis that satisfy 12.10.4 and 12.10.4.1 directly.
Keeping 67 documents current across owners, review dates and requirement mappings needs more than a folder structure. The accompanying master register tracks that detail in one Excel-ready sheet, so the actual compliance obligation PCI DSS imposes — accurate, current, requirement-mapped documentation maintained by named owners — has a working control document behind it rather than a static reference built once and left to decay.
1. Does PCI DSS require board members to complete cybersecurity training?
No. PCI DSS v4.0.1 contains no clause requiring board members to undertake training, unlike NIS2's Article 20(2) or DORA's Article 5(4). The standard's closest governance provision, Requirement 12.4.1, requires accountability rather than training, and applies only to service providers.
2. What does PCI DSS Requirement 12.4.1 actually require?
It requires senior management at service providers to establish a PCI DSS compliance program outlining their responsibilities for protecting cardholder data, giving executive-level visibility and accountability to the compliance program. It does not require training, refresher cycles, or demonstrated competence.
3. Does Requirement 12.4.1 apply to every organisation subject to PCI DSS?
No. It is explicitly scoped as an "additional requirement for service providers only." A merchant that accepts card payments but does not otherwise store, process or transmit cardholder data on behalf of other organisations is not in scope for this requirement.
4. Who does PCI DSS's training requirement under 12.10.4 actually cover?
Requirement 12.10.4 requires personnel responsible for responding to security incidents to be appropriately and periodically trained. This is an operational population, such as incident responders and security team members, not a governance body like the board.
5. How is PCI DSS incident response training frequency determined?
Requirement 12.10.4.1 requires that training frequency be set by a targeted risk analysis performed under Requirement 12.3.1, rather than a fixed calendar interval applied uniformly across all organisations.
6. Why does PCI DSS not include a board training requirement like NIS2, DORA or the UK CAF?
PCI DSS is an industry-mandated contractual standard maintained by the PCI Security Standards Council and enforced through payment brand and acquirer contracts, focused primarily on technical and operational controls over the cardholder data environment. NIS2, DORA and the UK CAF are statutory or government-backed frameworks built around governance and management-body accountability as an independent objective, which is why they extend training obligations to boards in ways PCI DSS does not.
7. Should boards still receive cybersecurity training even though PCI DSS doesn't require it?
Many organisations choose to provide it voluntarily, given that a cardholder data breach carries financial and reputational consequences, such as payment brand fines and loss of card processing ability, that ultimately land on board-level oversight of enterprise risk, regardless of what PCI DSS itself formally requires.
8. How does PCI DSS's governance requirement differ from NIS2's Article 20 or DORA's Article 5?
NIS2 Article 20 and DORA Article 5 both explicitly name management body members and require them to undertake training to gain sufficient knowledge and skills. PCI DSS's Requirement 12.4.1 only requires senior management at service providers to hold accountability for a compliance program, with no corresponding training clause, making PCI DSS's governance obligation narrower in scope and lighter in substance than either regulatory framework.