DORA Compliance Engine
To improve the efficiency and effectiveness of your staff's time & effort (and reduce your external support cost) our consultants use various methods, tools and accelerators in delivering our DORA compliance services.
​
At the core of our DORA-COMP service is our DORA Compliance Engine which contains the text of DORA Regulation up to and including Article 58. Articles 59 to 63 are amendments to prior regulations and Article 64 is the data of 'entry into force and application' (January 17 2025).
We have provided metadata against each component of DORA such as Article and paragraph number, the type of requirement (single or multiple control objective, principle of operation, definition, financial entity obligation etc). Against each DORA component, that is a financial entity obligation within the 5 pillars, we have identified the most likely ITIL processes (v3 and V4) and ISO 27002 sections and control objectives.
This metadata enables the user of the DORA Compliance Engine to view DORA compliance components via three lenses (using keyword searches): 1. Filter DORA text, 2. Filter ITIL text and 3. Filter ISO27002 text. Being able to fast filter DORA information is very helpful as there is some degree of duplication of ICT aspects within the Regulation.
The compliance scores are on a 0 to 5 basis where, a score of 0 is 'not started' on this compliance component to a score of 5 where it is it is 'fully embedded, operational and documented'. Compliance scores are also entered into the DORA Compliance Engine with automatic RAG status allocated at the Article component level and at the overall Article level.
Service Mapping
Our consultants work with you using our, four layer, Service Architecture and service mapping method to connect Functions to Applications / Services to Towers, and so to Third-Party Provider contractual agreements associated with the Towers.
The illustration shows how a user in a Function is connected to Towers (e.g., End User Compute and Network) to enable their laptop (or other device) to connect to their digital business applications and supporting services.
​
The (Technology) Towers also underpin the digital business services above by providing infrastructure (e.g., hosting (compute), storage, network) and support services (e.g., applications maintenance, operations management and service management (e.g., Incident, Major Incident, Risk and Problem Management) services)).
​
Third-party providers are often used to provide Tower services alongside internal ICT teams, known as "ICT intra-group service providers", in the DORA ITS document.
The illustration also shows third-party provider contractual agreements 'pinned' to Towers which contract numbers shown (e.g., contract 265 and statement of work 254). This enables the mapping of Functions to contracts which is required in the register of information and can be used to identify potential ICT risks in the supply chain.
​
We note that some organisations have Applications Dependency software which can do automated service mapping. We will use this data if it is available.
Register of information
The register of information (ROI) is set out as an obligation of financial entities in Article 28 paragraph 3 "As part of their ICT risk management framework, financial entities shall maintain and update at entity level, and at sub-consolidated and consolidated levels, a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers."
A 48 page guidance paper on the register of information was issued in January 2024, titled: Final Report - On Draft Implementing Technical Standards (ITS) on the standard templates for the purposes of the register of information.
This guidance is known as 'ITS' and it explains how to complete the 15 different Excel spreadsheets that underpin the register of information. Input to the register of information is all licenced activities, all business functions and all third-party provider contractual agreements. In addition, business functions and third-party provider contractual agreements are connected to enable risk assessment to be made by financial entities.
​
DORACompliant.com has created an ROI engine (based on 30 years experience in service mapping, ICT benchmarking and outsourcing ICT services) to simplify data collection and migration of relevant data to the ITS spreadsheets.
DORA Audit Report
Your DORA Audit Report has two parts:
​
Part 1 is the Report on the ICT Risk Management Framework Review using the report format and content as set out in Article 27 of the January 2024 Draft Regulatory Technical Standards (RTS)
Part 2 of the DORA Audit Report contains the financial entity compliance levels against each of the DORA components as set out in the relevant Articles within the 5 pillars of DORA. Supporting evidence is provided in terms of listed documents and sections (where appropriate) to substantiate the reported DORA compliance levels.
The register of information accompanies the submitted DORA Audit Report.
The Plan to prepare your DORA Audit Report
​
The following illustration shows the DORA-Comp Project Plan. Initially, we would agree the project scope and commercial terms, and both organisations would sign a Non-Disclosure Agreement. Following the Mobilisation stage, the DORA-COMP Project Plan comprises two workstreams culminating in the DORA Audit Report and supporting materials.
The left-hand side workstream creates the register of information via discovery, service mapping, risk analysis and creation of the DORA specified Excel repositories. The right-hand side workstream creates DORA report through discovery, fact finding interviews, compliance level recording (scoring and RAG status), creation of the Action Plan to improve DORA compliance and compilation of the DORA Audit Report.
