EvidenceSheet

Art.9 Protection and prevention

Financial entities keep the security and operation of ICT systems and tools under continuous monitoring and control and limit ICT risk with security policies, procedures, protocols and tooling designed to keep ICT systems (above all those supporting critical or important functions) resilient and available, and protect data at rest, in use and in transit. The chosen solutions must be appropriate under Article 4 and cover secure data transfer, data loss and corruption, unauthorised access and data management risk. Within the ICT risk management framework they keep an information security policy (covering customer data where applicable), a risk-based network and infrastructure management structure that can cut or segment connections at once, least-privilege access controls, strong authentication and cryptographic key protection, a risk-based ICT change management process approved by management, and documented patch and update policies. Entities listed in Article 16(1) are outside this Article and follow the simplified framework of Article 16 instead.

Source: DORA (Regulation (EU) 2022/2554), Art.9. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open DORA (Regulation (EU) 2022/2554) in the compliance library.

Applies to the financial entities listed in Article 2. Many duties are lighter or absent for microenterprises and for the entities in Article 16(1); each statement says where. Article 19 carries the reporting clocks of Delegated Regulation (EU) 2025/301, Article 5.

5
artefacts
1
held by a system
1
at each review
hard
to go live
Policy repository / GRC workspace
where the evidence lives
teal = a system already holds it · olive = produced at each review. To go live: easy when half or more of the artefacts are already held by a system, moderate from a quarter to a half, hard below a quarter.

These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.

system holds itEvidence a system already holds

  • ICT change records showing each change was assessed, tested, approved and verified · Document repository

periodic reviewEvidence produced at each review

  • Network architecture and segmentation records showing connections can be severed or isolated quickly · Cloud console / configuration management

governing documentDocuments that govern the control

  • Information security policy, including its scope for customer data where the entity holds such data · Policy repository / GRC workspace
  • Access rights reviews, authentication standards and cryptographic key management procedures · Policy repository / GRC workspace
  • Patch and update policy with patch compliance reports · Policy repository / GRC workspace

First move

Mostly documents and reviews. Pull the 1 system-held artefact from your Document repository on a schedule; put the documents under version control with an owner and review date, and log each review as a dated record with a named reviewer.

Common gaps auditors find

Do this for your whole sheet

Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.

Build my evidence sheet

Art.8 Identification · Art.10 Detection