DORA Articles 7 and 8: you cannot protect what you have not written down¶
Article 5 gave the board the accountability, Article 6 gave you the framework and its RTS. Articles 7 and 8 are where the real work starts, because they demand something most organisations quietly do not have: a complete, current picture of what they actually run. Today: ICT systems and the identification exercise everything else depends on.
Article 7: four adjectives with teeth¶
Article 7 is short. ICT systems, protocols and tools must be appropriate to the magnitude of operations, "reliable", equipped with sufficient capacity for peaks, and "technologically resilient" enough to deal with "stressed market conditions or other adverse situations". One sentence, four testable properties.
The word doing the heavy lifting is "maintain updated". Running an unsupported database version is now not just bad practice; it is arguably a breach of the first article in the regulation about technology itself. Keep that thought, because Article 8 turns it into an inventory question.
Article 8: the identification exercise¶
Article 8(1) requires entities to "identify, classify and adequately document all ICT supported business functions, roles and responsibilities, the information assets and ICT assets supporting those functions, and their roles and dependencies in relation to ICT risk", reviewed at least yearly. Paragraph 4 goes further: identify all assets "including those on remote sites", map the ones considered critical, and map "the links and interdependencies" between them. Paragraph 5 extends the mapping to processes depending on ICT third-party providers. Paragraph 6 makes it operational: maintain inventories, update them periodically and on every major change.
In plain terms: a CMDB that is actually correct, an asset classification tied to business functions, and a dependency map that includes your vendors. Paragraph 2 adds continuous risk identification on top, explicitly including "the risk exposure to and from other financial entities". Your risk register is supposed to know that you can hurt others, not just be hurt.
Then paragraph 7, my favourite in the whole chapter: a specific yearly ICT risk assessment "on all legacy ICT systems", and in any case before and after connecting technologies. The regulation does not care that nobody knows how the old core system works anymore. That is precisely why it wants the assessment.
Where the RTS makes it concrete¶
RTS 2024/1774 turns Article 8 into two documents. Article 4 demands an ICT asset management policy, and it lists exactly what your asset records must contain: unique identifier, physical or logical location, classification, owner, supported business functions, recovery time and recovery point objectives, internet exposure, interdependencies, and, remarkably, "the end dates of the ICT third-party service provider's regular, extended, and custom support services". End-of-support dates are now regulatory data. Article 5 demands an asset management procedure with explicit criticality assessment criteria.
Two details worth knowing. First, the RTS cross-references DORA Article 8(1) and 8(7) by name, so an auditor can walk from your asset record straight back to the Level 1 obligation. Second, the official text of RTS Article 4(2)(b)(iii) cites "Regulation (EU) 2022/2254", a typo for 2554 that sits in the Official Journal to this day. Even the lawmakers' own documents fail quality checks. Comforting, in a way.
Why this article matters more than it looks¶
Nothing downstream works without Article 8. Incident classification asks how many critical functions are affected: you need the map. The register of information under Article 28(3) wants every ICT third-party arrangement linked to functions and assets: that is your Article 8(5) mapping, formalised into the ESAs' template set (ITS 2024/2956). TLPT scoping starts from critical functions: the map again. Do Article 8 badly and every later obligation inherits the gaps.
The artefact: minimum asset record¶
Straight from RTS 2024/1774 Article 4(2), this is the minimum column set for your inventory. If your CMDB cannot fill these today, that is your gap list.
| Field | Source |
|---|---|
| Unique identifier | RTS Art. 4(2)(b)(i) |
| Location, physical or logical | RTS Art. 4(2)(b)(ii) |
| Classification per DORA Art. 8(1) | RTS Art. 4(2)(b)(iii) |
| Asset owner | RTS Art. 4(2)(b)(iv) |
| Business functions or services supported | RTS Art. 4(2)(b)(v) |
| RTO and RPO | RTS Art. 4(2)(b)(vi) |
| Internet exposure, yes or no | RTS Art. 4(2)(b)(vii) |
| Links and interdependencies | RTS Art. 4(2)(b)(viii) |
| Vendor support end dates | RTS Art. 4(2)(b)(ix) |
| Legacy risk assessment data | RTS Art. 4(2)(c), DORA Art. 8(7) |
One more thing. BaFin has done a version of this exercise for the entire regulation: a structured overview of every documentation requirement in DORA and its RTS and ITS, published in December 2024 precisely because the requirements are scattered across so many legal texts. The one-page overview (PDF, English) and the accompanying guidance are the closest thing to an official master checklist of what documents DORA expects you to have. If you only download one supervisor-made tool this year, make it this one.
The official texts and the supervisory tooling around them, including the ESAs' register templates and reporting packages, are collected in the DORA branch of the resource library, which got a substantial update today.
Next in this series: Article 9, protection and prevention, where the RTS suddenly gets very specific about encryption, patching and logging.