All articles

Blog

DORA training, NIS2, PCI DSS: records don't prove effectiveness

DORA training, NIS2, PCI DSS, ISO 27001: what the regulations require of developers, what the auditor checks, and the evidence still missing.

  • By Azziz ERRIME
  • 11 min read
Empty parliamentary hearing room with no flag or emblem, a closed binder in front of the witness chair

TL;DR

  • DORA training, like NIS2 and PCI DSS training: the rules require you to train developers and document it, but rarely to prove that their practices have changed.
  • PCI DSS requires training every 12 months, and the assessor checks it by examining records and interviewing staff.
  • I’d prepare for the audit in two columns: what was done, and what changed in code reviews.

On 3 October 2017, Equifax’s former CEO told the US Congress that the security alert had gone to the right teams, and that the protocol had been followed. The breach affected around 147 million people. DORA, NIS2 and PCI DSS training obligations replay that scene on their own scale: they ask you to show that the arrangements exist far more than that they work.

On that 3 October in Washington, Richard Smith appeared before the House of Representatives’ Energy and Commerce Committee. Equifax had been warned in March but only discovered the intrusion in July. Before the committee, he walked through the chain as it was designed: the day after the CERT alert, the security team notified a large group of technical staff. They were to find the vulnerability and apply the patch, then run a verification scan a few days later.

The chain broke at one link, according to the hearing transcript. Smith put it like this: “The human error was the individual who is responsible for communicating in the organization to apply the patch did not.” He then summed it up in two parts: “Both human deployment of the patch and the scanning deployment did not work”, and “The protocol was followed”.

The FTC reported in 2019 that the internal policy required patching within 48 hours. The settlement provides for at least $575 million. The protocol had been followed, and it included its own check. That check saw nothing either.

Following a protocol doesn’t prove a control works

The scene shows the gap between two kinds of evidence that are easily confused. The first shows that an action took place: an alert sent, a scanner scheduled, a procedure signed. The second shows that the action changed something: the patch is in place, the server no longer responds to the attack. The first slots neatly into an audit file. The second, much less so.

Attackers don’t read your procedures. They look for the server that missed the patch, the form nobody filtered, the pull request reviewed in a hurry. In practice, they test the application in production, and what they find there measures how well your controls really work, training included.

Developer training sits squarely in that gap. A record says a developer completed a module on SQL injection in March. It doesn’t say whether, in September, they spotted the injection slipped into a colleague’s code. Do the rules on DORA, NIS2 or PCI DSS training settle for the first kind of evidence?

DORA training, NIS2 and PCI DSS: mostly checked against records

The table draws on the texts themselves, read in the Official Journal of the EU, and on the PCI DSS 4.0.1 standard. It sums up what they require of teams that write code.

Text What it requires What you show at audit Effectiveness required?
DORA, art. 13, § 6 Awareness programmes and training as “compulsory modules”, for all employees and senior management, and ICT third-party providers where relevant The programme and its delivery No
DORA, art. 5, § 4 Regular training for the management body, proportionate to ICT risk Training completion tracking No
RTS DORA 2024/1774, art. 16 Source code reviews with static and dynamic testing; third-party and open-source code analysed, where feasible, before production The reviews, the action plan and its follow-up Indirectly, through the results
PCI DSS 4.0.1, 6.2.2 Bespoke and custom software developers trained at least once every 12 months Training records and interviews (6.2.2.b) No
PCI DSS 4.0.1, 6.2.3 and 6.2.3.1 Code reviewed before production; manual review by someone other than the author Review evidence (6.2.3.b) Indirectly
NIS2, art. 20, § 2 Member States require management bodies to be trained; staff training encouraged Depends on national law No
NIS2, art. 21, § 2, e to g Security in development; assessment of the effectiveness of measures; cybersecurity training Depends on national law Yes, for the measures as a whole
ISO/IEC 27001:2022, 7.2 Staff competence, and evaluation of the effectiveness of the actions taken Documented information Yes
AI Act, art. 4, amended in 2026 Measures to support AI literacy, with no guaranteed level The measures taken No

DORA, the EU regulation on digital operational resilience in the financial sector, says neither how to train nor how often. Its Article 13 requires programmes and training “applicable to all employees and to senior management staff”, with “a level of complexity commensurate to the remit of their functions”. DORA training is an obligation to run modules, with no outcome to measure.

PCI DSS, the payment card standard, goes into more detail. PCI DSS requirement 6.2.2 sets the frequency: at least once every 12 months. It also sets the content: software security relevant to the job function and languages, secure design and secure coding techniques. Its testing procedure spells out what the assessor looks at: “Examine training records and interview personnel”.

So both texts describe training that has been delivered. What happens between the record and the code?

Blank ink stamp on a stack of DORA training attendance sheets, next to a switched-off screen

The stamp certifies attendance. The screen hasn’t shown anything yet.

No text requires the record to be linked to code reviews

Even the objective PCI DSS sets for its training requirement is about knowledge. Under the customised approach, the standard aims for developers who “remain knowledgeable about secure development practices”. A developer can stay knowledgeable and still let a vulnerability through in review, because that day they were reviewing the business logic.

Article 16 of DORA Delegated Regulation 2024/1774 does look at the code. It requires “the performance of source code reviews covering both static and dynamic testing”. Entities must then identify vulnerabilities, adopt an action plan and monitor its implementation. These reviews produce exactly the data the training record lacks, yet nothing in the text asks for the two to be compared.

You could conclude that the auditor settles for the record, and that doing more would be pointless. Two texts in the table say otherwise.

Two texts already require effectiveness to be evaluated

ISO/IEC 27001, in its 2022 edition, deals with competence in clause 7.2. According to reliable restatements of this paid-for standard, it requires organisations to take the actions needed to acquire competence, then evaluate their effectiveness. It also requires documented information to be retained as evidence. Completing a course is an action. Whether it worked is a separate question, and the standard asks it explicitly.

The NIS2 directive does the same, across all security measures. Its Article 21 lists, under point (e), security in the acquisition, development and maintenance of systems. Point (g) covers “basic cyber hygiene practices and cybersecurity training”. In between, point (f) requires “policies and procedures to assess the effectiveness of cybersecurity risk-management measures”. I read point (f) as also covering point (g), training. Neither text binds everyone yet. ISO 27001 applies to those seeking certification, and NIS2 is still waiting for its French law.

The NIST SP 800-50 guide, in Revision 1 published on 12 September 2024, binds no one. Even so, it offers “suggested metrics and evaluation methods” for improving a training programme.

In France, NIS2 compliance still hinges on the national text. The transposition deadline expired on 17 October 2024, according to InCyber. The NIS2 transposition bill comes before the National Assembly from 7 October 2026, according to Kohen Avocats.

Evidence that DORA training works is already in your code reviews

My conclusion is that the raw material for this evidence already exists in firms subject to DORA or PCI DSS. It lies unused in the code reviews those texts require. PCI DSS requires review evidence before every release to production, and the DORA RTS requires source code reviews with an action plan. What remains is to set them against the training record.

Here is what I’d put in the audit file, next to the record:

  • the DORA or PCI DSS training record in the form the assessor expects, with the modules each developer completed;
  • findings from code reviews and source code testing over the same period, sorted by type of vulnerability;
  • the two matched up: the vulnerabilities the training covered, and those that still get through review;
  • the resulting action plan and its follow-up, as Article 16 of the DORA RTS requires;
  • the same measurement repeated after each training cycle, to see whether the curve moves.

This comparison feeds the evaluation that clause 7.2 of ISO 27001 and point (f) of NIS2 Article 21 call for. Above all, it gives the executive committee something other than a completion rate. It’s also what I’m measuring at the moment: what developers spot, or let through, when they review code written by AI. I discussed it in an earlier article on code review.

Two-pan balance, rolled certificates on one side, a machined mechanical part on the other

On one side, certificates. On the other, a part that has changed.

After an incident, the second column is the one people read

Before the committee, Richard Smith described a protocol that existed, and an alert sent out the next day. The protocol even included a check on the outcome, the scanner, and that check failed too.

Well-run DORA, NIS2 or PCI DSS training often looks like that protocol. The record is complete, the modules are up to date, the assessor leaves satisfied. I’d still prepare for the audit in two columns: what was done, and what changed in reviews. After an incident, the second is the one you’ll be asked for.

One doubt remains. I don’t know whether regulators will go as far as requiring this evidence explicitly, or whether the French NIS2 law will spell it out. To my mind, the two texts that already ask for it are reason enough to start.

What are the DORA training requirements?

The DORA regulation’s training obligations come down to two articles. DORA training falls first under Article 13(6) of the regulation: ICT security awareness programmes and digital operational resilience training. These are built into staff training as “compulsory modules”, for all employees and senior management. Article 5 adds regular training for the management body. The text sets neither frequency nor duration.

What does PCI DSS requirement 6.2.2 say?

PCI DSS 4.0.1 requires developers of bespoke and custom software to be trained “at least once every 12 months”. The training covers software security relevant to their job function and languages, including secure design and secure coding techniques. To verify it, the assessor examines training records and interviews staff, under testing procedure 6.2.2.b.

When does NIS2 come into force in France?

The NIS2 directive was due to be transposed by 17 October 2024. In France, the transposition bill comes before the National Assembly from 7 October 2026, according to Kohen Avocats. National obligations, training included, will depend on the text adopted. The directive requires each Member State to impose this training on management bodies. In France, the obligation is therefore waiting on the law.

What does Article 4 of the AI Act say?

In its 2024 version, Article 4 of the AI Act applied to providers and deployers of AI systems. They had to ensure, “to their best extent, a sufficient level of AI literacy” among their staff. Since the Omnibus regulation entered into force on 27 July 2026, it asks them to support that literacy, without guaranteeing a level, according to Law & Technology.

Sources