The DORA testing programme is a scoping problem before it is a testing problem

What Chapter IV actually requires

Articles 24 to 27 of DORA are short. Financial entities other than microenterprises maintain a sound and comprehensive digital operational resilience testing programme as part of the ICT risk-management framework (Art. 24(1)); it follows a risk-based approach and is proportionate to size, business and risk profile (24(2)); tests are performed by independent parties, internal or external (24(4)); every weakness, deficiency or gap is fully addressed under procedures that prioritise, classify and remediate it (24(5)); and all ICT systems and applications supporting critical or important functions are tested at least yearly (24(6)). Article 25 lists the kinds of test — from vulnerability scans and gap analyses to scenario-based tests and penetration testing. Articles 26 and 27 add threat-led penetration testing every three years for the entities the competent authority designates.

Read quickly, that is a testing obligation. Read carefully, three of the five paragraphs are about something else: which systems, in what order, and what happens to what you find.

Article 24 has one sentence about running tests and four about scoping them, ordering them and closing what they find. Plan the programme in that proportion.

Scope is a query on the inventory, not a list

“All ICT systems and applications supporting critical or important functions” is only answerable if two records exist: the list of critical or important functions, and the mapping from each function to the systems it depends on. Most testing programmes are scoped the other way round — someone lists the systems they know how to test, and the criticality column is filled in afterwards to justify the list.

The DORA-shaped way is: business functions (business solutions) carry the criticality classification; each depends on IT services; each IT service is composed of assets. The yearly test scope is then the set of assets and services reachable from any critical or important function — a query, not a spreadsheet — and it updates when the inventory does. A new service under a critical function is in scope the day it is linked, not the next time somebody rebuilds the list.

The same links answer the proportionality question. Risk-based means the entities and systems with the highest exposure are tested more thoroughly and more often; the risk register entries linked to those assets are where “highest exposure” comes from.

Independence and the third parties in the loop

Article 24(4) allows internal testers if conflicts of interest are avoided and the necessary independence is assured. That is a record too: who tested what, employed by whom, with what separation from the team that operates the system. For external testers it is a contract; for internal ones it is a documented independence statement per test.

Where the system under test is delivered by an ICT third-party provider — and for critical functions it usually is, in part — the provider’s cooperation is a contractual matter under Article 30 and, for TLPT, an explicit expectation under Article 26. Knowing which provider sits under which tested service is, again, the inventory question: provider → IT service → function.

Findings are the deliverable

Article 24(5) is the paragraph supervisors read most closely, because it is the one whose failure is visible in every audit: weaknesses found in testing that were never remediated. The requirement is not “fix everything” — it is that every finding is prioritised, classified, has a remediation procedure and an owner, and that closure is verified.

That means the finding is a record with a lifecycle, not a row in a test report. It carries the system it concerns, a severity, an owner, a due date, a status history and, at closure, the evidence that it was actually fixed. Findings from penetration tests, from the yearly scenario exercise, from an internal audit and from a post-incident review all belong in the same log, because the supervisor’s question — what is still open, how old is it, who owns it — is the same for all of them.

A programme in six records

Not a methodology; the set of things that should exist, in the order they usually get created.

1. The programme document. Approved, versioned, with the yearly cadence and the test types (Art. 25) per system class. A governance document with a review period.
2. The scope query. Critical or important functions marked on business solutions; the derived set of IT services and assets. Re-run before each cycle; keep the result as evidence of what was in scope when.
3. Risk anchors. Register entries linked to the in-scope systems, with a repeatable score, so “risk-based” points at something.
4. The tests. Per system: date, type, tester, independence statement or contract, report as an evidence item attached to the system or the control it exercised.
5. The findings log. One log; every finding with severity, owner, due date, status; closure verified with evidence.
6. The follow-through record. Post-cycle review: what was tested, what was found, what remains open, what changes in the framework — the input the management body needs under Article 5.

Where Secantra fits

The records above are the objects the compliance, CMDB and risk modules already share: business solutions with criticality, structural links to IT services and assets, third-party records linked to the services they deliver, risk register entries with assessments, controls with evidence items (up to 10 attachments each, recency-checked), findings with severity, owner and status linked to the asset, control or requirement they concern, treatment actions with due dates, governance documents with a versioned approval flow. The programme document and the test reports are documents; the scope, the anchors and the findings are records — and only records can be queried the next time the competent authority asks what was in scope last year.

Checklist

• Testing programme approved, versioned, with cadence and test types per system class
• Critical or important functions marked; the in-scope set of services and assets derived from the inventory, not maintained by hand
• Every system supporting a critical or important function tested at least yearly, with the report kept as dated evidence
• Tester independence documented per test (contract or internal statement)
• Third-party providers under tested services identified; TLPT participation planned where designated
• Every finding in one log with severity, owner, due date, status history and verified closure
• Post-cycle review recorded and fed back into the ICT risk-management framework