ICT Risk Management Framework Document Template

Purpose and status

DORA is one regulation with five pillars: ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, the management of ICT third-party risk, and information sharing. Every financial entity meets the same five pillars, and the depth of each depends on what the entity is. A microenterprise, a small investment firm, an exempted payment institution and a large bank each owe a different part of each pillar, and the Regulation says which. So the first question is what you are, the second is which duties that makes yours, and only then is it worth asking how ready you are. Being ready is a count of duties in place and duties still open. It is never one score.

This document is the ICT risk management framework of [[Organisation Name]]. ICT is information and communication technology. DORA, Regulation (EU) 2022/2554, asks every financial entity in scope for a documented framework of this kind. The full framework is set out in Articles 5 to 15 (Chapter II). A small group of entities follows the simplified framework of Article 16 instead. This template covers both, and the statements for each are labelled.

The template holds 61 numbered statements, FW-01 to FW-61, in twelve sections. Each section lists the duties it answers, by the IDs RQ-01 to RQ-52 that the pack uses, so that every one of the 52 duties the pack tracks has a place. It then gives the statements [[Organisation Name]] adopts, and the tables that support them.

Legal note. This document helps you see what DORA asks of an entity like yours and what you can show. It is not legal advice, and following it is not a statement that you comply with DORA or any standard. Whether DORA binds you, and which of its duties apply to you, depends on what you are, how you are authorised and how your Member State and your supervisor apply it: confirm it with counsel or your competent authority.

Scope and proportionality

This section says what the entity is and how hard DORA bears on each part of it. Complete it first, because every later section depends on the answer. The number of duties that apply changes a good deal with the answer, as the illustrations show.

Duties in this section: RQ-01 (Article 2(1), (3), (4)); RQ-02 (Article 4).

For illustration, the scope assessment's own test cases give 44 of 52 duties for a large bank that a TLPT authority has identified, 41 of 52 for the same bank when it is not identified, 34 of 52 for an investment firm that is a microenterprise, and 25 of 52 for a small and non-interconnected investment firm. These are not your answer.

The two frameworks are: Full ICT risk management framework (DORA Articles 5 to 15); and Simplified ICT risk management framework (DORA Article 16). An entity that DORA does not cover, or that is a supplier to a financial entity, does not write this framework (DR-22).

FW-01 This framework applies to [[Organisation Name]], identified by [[legal entity identifier]], which is [[entity type, with the point of DORA Article 2(1)]]. The scope assessment, approved by the management body on [[YYYY-MM-DD]], places the entity under [[the full framework (Articles 5 to 15) / the simplified framework (Article 16)]]. The assessment is reviewed at least every [[12]] months, and when a size figure, a licence or the Member State's use of Article 2(4) changes.

FW-02 The entity [[is / is not]] a microenterprise. The figures behind that answer are: persons employed [[number]], annual turnover [[amount in euros]], annual balance sheet total [[amount in euros]], as at [[YYYY-MM-DD]], from [[source]]. Where the competent authority gives a different view, the authority's view stands.

FW-03 The entity applies this framework in proportion to its size, its overall risk profile, and the nature, scale and complexity of its services, activities and operations. Each place where a measure is lighter or heavier than the standard approach is entered in the proportionality log below, with the reason.

Proportionality log

Governance, control and audit

DORA gives the management body the decisions and the responsibility. This section names who does what, what the management body approves, and what reaches it. It also keeps ICT risk management, control and internal audit apart. That asks for three separate responsibilities. It does not ask for three separate teams.

Duties in this section: RQ-04 (Article 5(1), (2)); RQ-05 (Article 5(2)(i)); RQ-06 (Article 5(4)); RQ-26 (Delegated Regulation 2024/1774 Article 28); RQ-45 (Article 5(3)); RQ-08 (Article 6(4), (6), (7)).

Roles

FW-04 The management body defines, approves and oversees this framework and is responsible for putting it into effect. It bears ultimate responsibility for the entity's ICT risk. It sets the policies that keep data available, authentic, intact and confidential, and the roles and responsibilities for all ICT-related functions. Applies to: Full framework.

FW-05 The management body approves, and the minutes name and date, each of: this framework; the digital operational resilience strategy with the risk tolerance; the ICT business continuity policy and the response and recovery plans; the ICT audit plans; the policy on ICT third-party arrangements; and the budget, including awareness programmes and training. The approval record at the end of this document holds the dates. Applies to: Full framework.

FW-06 The management body bears overall responsibility for the simplified framework. It sets the roles and responsibilities for ICT tasks and the information security objectives. It approves, oversees and periodically reviews the classification of information assets, the main risks, the business impact analysis, the continuity plans and the response and recovery measures. It allocates and reviews the budget at least once a year, and sets its own reporting arrangements. Applies to: Simplified framework.

FW-07 Each role in the table above has a named holder and a named deputy. One person may hold several roles, except that the people who manage ICT risk, control it and audit it are kept separate.

FW-08 The management body receives the reports in the reporting calendar below. They keep it informed of ICT third-party arrangements, of planned material changes to providers and their effect on critical or important functions, and of major ICT-related incidents with the response, recovery and corrective measures. Applies to: Full framework.

FW-09 Each member of the management body completes ICT risk training at least every [[12]] months, and each new member within [[3]] months of appointment, so that every member can understand and assess ICT risk. DORA asks for training "on a regular basis", so these intervals are the entity's own. [[Role]] keeps the training record. Applies to: Full framework.

FW-10 [[Role, or the member of senior management designated]] monitors the arrangements with ICT third-party service providers and the related risk exposure and documentation, and reports to the management body through the reporting calendar. Applies to: Full framework, other than microenterprises.

FW-11 [[Control function]] oversees ICT risk management. It has enough independence from the people who manage ICT risk to avoid conflicts of interest. ICT risk management, control and internal audit are separate functions. Applies to: Full framework, other than microenterprises.

FW-12 [[Internal audit function, or external auditors]] audits this framework regularly, on a plan the management body approves, with the skills in ICT risk and the independence the work needs. A formal follow-up process verifies and remedies critical audit findings in time. Applies to: Full framework, other than microenterprises.

FW-13 Article 6(4) does not ask a microenterprise for a separate control function. The management body records here who oversees ICT risk, who is independent of that person, and why this arrangement is proportionate: [[record]]. Applies to: Microenterprises.

Reporting calendar

What the management body receives, from whom and how often:

Digital operational resilience strategy

The strategy says where the entity wants its ICT risk to stand and how it will know. It sits inside this framework. It may be a separate document, and it is approved by the management body.

Duties in this section: RQ-10 (Article 6(8)).

The elements the strategy covers:

FW-14 The digital operational resilience strategy is part of this framework. It is held in [[document title and ID]], approved by the management body on [[YYYY-MM-DD]], and covers the elements in the table below. Applies to: Full framework.

FW-15 The management body sets the risk tolerance level for ICT risk, which is [[level, stated in the entity's own terms]], and analyses the impact tolerance for ICT disruptions, which is [[longest disruption and greatest loss accepted, for each critical or important function]]. Only [[role]] may accept a residual risk above the tolerance level. Each acceptance is entered in the inventory of accepted residual risks with its justification, and the inventory is reviewed at least every [[12]] months. Applies to: Full framework.

FW-16 The strategy sets information security objectives with indicators. The management body sees the measures DM-01 to DM-08 (readiness items at each level, blocking gaps, register findings, exit plans in place, systems tested in time, gaps open and overdue, members trained, evidence items ready) whenever it receives the reports in the reporting calendar. Every measure is a count with the gaps named. None is turned into a score, a share or a colour for the whole. Applies to: Full framework.

Functions, assets and dependencies

The entity cannot protect, test or recover what it has not listed. These inventories come before the rest of the work, and the register of ICT third-party arrangements is one of them.

Duties in this section: RQ-12 (Article 8(1), (2), (4) to (6)); RQ-13 (Article 8(3), (7)); RQ-23 (Article 16(1)(e)).

FW-17 The entity identifies, classifies and documents its ICT-supported business functions, the information assets and ICT assets that support them, and their dependencies, including the processes that depend on ICT third-party service providers, in [[inventories and their locations]]. [[Role]] keeps these inventories current and reviews them, with the classification and the risk scenarios, at least every [[12]] months. Applies to: Full framework.

FW-18 The entity identifies, classifies and documents its critical or important functions, the information assets and ICT assets that support them and their interdependencies. It identifies which of these functions ICT third-party service providers support, and its key dependencies on those providers. Applies to: Simplified framework.

FW-19 The owner of each function proposes whether it is critical or important. [[DORA programme lead]] records the reason. The management body approves the list. The list and the reasons are reviewed at least every [[12]] months.

FW-20 A function that has not been assessed is treated as critical or important until it is. The arrangements behind it are handled as arrangements that support a critical or important function. This is the entity's own working rule. DORA does not set it.

FW-21 The entity carries out a risk assessment on each major change to its network and information system infrastructure and to the processes that affect its ICT-supported functions, at least yearly on all legacy ICT systems, and before and after connecting technologies, applications or systems. Applies to: Full framework, other than microenterprises.

ICT risk assessment and the framework's documents

The framework sits inside the entity's overall risk management system. The risk assessment method is the entity's own. The Risk Assessment Methodology & Scoring Model and the Information Security Risk Register in the CISO Times Library are examples of a method and a register that help with the work.

Duties in this section: RQ-03 (Article 16(1)(a) to (d)); RQ-07 (Article 6(1) to (3)).

FW-22 This framework sits within the entity's overall risk management system, described in [[document title and ID]]. It contains the strategies, policies, procedures, ICT protocols and tools that protect all information assets and ICT assets, including physical premises and infrastructure. The entity gives complete and updated information on ICT risk and on this framework to the competent authority on request. Applies to: Full framework.

FW-23 ICT risk is assessed with the method in [[document title and ID]]. The method identifies vulnerabilities and threats, uses [[quantitative / qualitative]] indicators of impact and likelihood, and records the risk treatment measures chosen. Applies to: Full framework.

FW-24 Each policy and procedure this framework names has an owner, a version and a review date in [[the list of policies, and its location]]. The owner of each document approves it. Applies to: Full framework.

FW-25 The entity keeps this documented simplified framework, with an information security policy and security measures in [[document title and ID]]. It monitors the security and functioning of all its ICT systems, uses sound, resilient and updated systems, detects sources of ICT risk and anomalies promptly, and handles incidents swiftly. Applies to: Simplified framework.

Protection, detection and reliable systems

Protection keeps incidents from happening. Detection finds the ones that do. Reliable systems make both easier. The detail lives in the entity's own policies. This framework names them and says who owns them.

Duties in this section: RQ-11 (Article 7); RQ-14 (Article 9); RQ-15 (Article 10).

FW-26 The entity monitors and controls its ICT systems and uses security tools, policies and procedures that keep data available, authentic, intact and confidential. The policy areas are: [[information security policy; network and infrastructure management, including isolating affected assets; access limited to what is needed; strong authentication and key protection; controlled ICT change management; patch and update policy]]. Each has an owner and produces records, such as access reviews, change records and patch status, that show it operating. Applies to: Full framework.

FW-27 The entity detects anomalous activity promptly, including network performance issues and incidents, and identifies material single points of failure. [[Detection mechanisms, alert thresholds and escalation criteria, with the document ID]]. The mechanisms are tested at least every [[12]] months, and [[role]] keeps enough resources to monitor user activity and incidents. Applies to: Full framework.

FW-28 The entity uses and maintains updated ICT systems, protocols and tools that suit the size of its operations, are reliable, have enough capacity to process data accurately and handle peak volumes, and are resilient under stress. [[Role]] keeps capacity and performance records for the systems behind critical or important functions. Applies to: Full framework.

Continuity, backup and recovery

This framework sets the duty and points to the documents that do the work. It states none of the recovery objectives, recovery criteria or test rules of the packs it cites.

Duties in this section: RQ-16 (Article 11(1) to (5), (8)); RQ-17 (Article 11(6)); RQ-18 (Article 11(7)); RQ-19 (Article 12); RQ-24 (Article 16(1)(f), (g)).

Where the parts of continuity, backup and recovery are set:

FW-29 The entity has an ICT business continuity policy, [[document title and ID]], approved by the management body. Documented arrangements keep critical or important functions running, respond to and resolve incidents, activate containment, estimate impacts and manage communication. The entity has response and recovery plans and a business impact analysis, and keeps ready access to records of what happened before and during a disruption. Applies to: Full framework.

FW-30 The response and recovery plans are reviewed by independent internal audit. Applies to: Full framework, other than microenterprises.

FW-31 The backup policy and the restoration and recovery procedures are in [[document title and ID]]. They set the scope of the data that is backed up and the minimum frequency. Backup systems can be activated without jeopardising security, and a restoration on the entity's own systems uses systems physically and logically segregated from the source. Recovery time and recovery point objectives are set for each function, and recovery includes the checks that keep data integrity highest. The recovery objectives are those of P22 (RR-02, RR-04). The backup standard and the restore checks are those of P23 (BR-13). Applies to: Full framework.

FW-32 The entity keeps redundant ICT capacity with the resources, capabilities and functions to meet its business needs. A microenterprise assesses the need for redundant capacity on its risk profile and records the result: [[record]]. [[Role]] reviews the redundancy at least every [[12]] months. Applies to: Full framework.

FW-33 The entity tests the continuity plans and the response and recovery plans for the systems behind all functions at least every [[12]] months, and after substantive changes to the systems behind critical or important functions. It tests its crisis communication plans. The recovery test is the one P22 RR-14 sets. The restore test is the one P23 BR-13 sets. An exercise or a tabletop under P10 is never counted as a test of a system. Results are documented, and deficiencies are analysed, addressed and reported to the management body. Applies to: Full framework.

FW-34 The tests include scenarios of cyber-attacks and of switchovers to redundant capacity, backups and facilities. Applies to: Full framework, other than microenterprises.

FW-35 [[Crisis management function]] sets out clear procedures for internal and external crisis communication when the continuity or recovery plans are activated. Its mandate, members and procedures are in [[document title and ID]]. Applies to: Full framework, other than microenterprises.

FW-36 The entity ensures the continuity of its critical or important functions through business continuity plans and response and recovery measures that include at least backup and restoration. It tests them regularly: the backup and restore procedures at least every [[12]] months, and on every major change to the plan. Results are documented, and deficiencies are analysed, addressed and reported to the management body. Applies to: Simplified framework.

Incident management and reporting

This framework adds no rule to incident response or reporting. P09 (Security Incident Management Policy) owns incident response and every decision right, clock and recovery criterion. P18 (EU Incident Notification Timeline Matrix (NIS2, DORA, GDPR)) holds the DORA classification criteria and the reporting duties. What DORA asks of the framework is that the capability exists and has been tried. The checks below say what to expect.

Duties in this section: RQ-27 (Article 17); RQ-28 (Article 18); RQ-29 (Article 19(1), (3), (4)); RQ-30 (Article 19(2)); RQ-31 (Article 23).

What the entity can show for the incident pillar:

FW-37 The entity runs the incident management process in [[incident management policy and plan, document IDs]] (P09). Every ICT-related incident and significant cyber threat is logged, the root cause of each incident is identified, documented and addressed, and major incidents are escalated to senior management and the management body.

FW-38 Classification of incidents and reporting to the competent authority follow P18, which holds the classification criteria of Delegated Regulation (EU) 2024/1772 and the DORA reporting duties RD-10 to RD-13. P09 holds every decision right, clock and recovery criterion. This framework states no reporting clock. The entity stays responsible for a report that a third party submits for it.

FW-39 The classification and reporting process also covers operational or security payment-related incidents, and major ones. Applies to: For credit institution, payment institution, account information service provider, electronic money institution only.

FW-40 The entity [[will / will not]] notify the competent authority of significant cyber threats it considers relevant to the financial system, service users or clients. The decision rule is: [[rule]]. Each decision is recorded. Applies to: Every financial entity in scope; optional.

Digital operational resilience testing

Testing proves that the controls work. DORA fixes one frequency: the systems behind critical or important functions are tested at least yearly. For the rest, the entity chooses. The statements below say which intervals DORA fixes and which are the entity's own.

Duties in this section: RQ-32 (Article 24(1) to (5)); RQ-33 (Article 24(6)); RQ-34 (Article 25(1)); RQ-35 (Article 25(3)); RQ-36 (Article 25(2)); RQ-37 (Article 26(1) to (3), (8)); RQ-38 (Article 26(6), (7)); RQ-39 (Article 27); RQ-40 (Article 16(1)(g)).

FW-41 The entity keeps a digital operational resilience testing programme as part of this framework, in [[document title and ID]]. It is risk-based, sets its tests by priority, and uses independent parties. Applies to: Every entity other than microenterprises.

FW-42 Every ICT system and application that supports a critical or important function is tested by an independent party at least every [[12]] months. Each test is recorded with its date, type, tester, result and findings. Applies to: Every entity other than microenterprises.

FW-43 Every test finding is entered in [[the findings register]] with an owner, a priority and a due date. A person other than the one who fixed it confirms that the weakness is fully addressed. Applies to: Every entity other than microenterprises.

FW-44 The programme provides for appropriate tests from the list in Article 25(1): DT-01 to DT-12 of the testing programme in this pack. For each type the entity records why it chose the test or left it out.

FW-45 A microenterprise combines a risk-based approach with a strategic plan for testing. The plan balances the resources and time spent against the urgency, the type of risk, the criticality of assets and services, and the entity's ability to take calculated risks. The plan is: [[document title and ID]]. Applies to: Microenterprises.

FW-46 The entity keeps an ICT security testing plan that validates the effectiveness of its security measures and takes account of the threats and vulnerabilities it has identified. It monitors and evaluates the results and updates its measures without undue delay for the systems that support critical or important functions. Applies to: Simplified framework.

FW-47 Before any deployment or redeployment of applications, infrastructure components and ICT services that support critical or important functions, the entity performs a vulnerability assessment. Applies to: For central securities depository, central counterparty only.

FW-48 The entity plans threat-led penetration testing only after a TLPT authority has identified it. It then follows Delegated Regulation (EU) 2025/1190 and DORA Article 27 for its testers, keeps the identification and the validated scope on file, and tracks each finding of the remediation plan to closure. Applies to: Entities a TLPT authority has identified.

The Digital Operational Resilience Testing Programme holds the types of test (DT-01 to DT-16), the frequency rules (TR-1 to TR-6) and the due date of each test.

ICT third-party risk

This section sets the duties that sit inside the framework. The register of information has its own working copy (ICT Third-Party Arrangements Register — Working Copy). The entity stays responsible for what it contracts out.

Duties in this section: RQ-41 (Article 28(1)); RQ-42 (Article 28(3)); RQ-43 (Article 28(3), third to fifth subparagraphs); RQ-44 (Article 28(2)); RQ-46 (Article 28(4) to (6)); RQ-47 (Article 30(1), (2)); RQ-48 (Article 30(3)); RQ-49 (Article 28(7), (8)); RQ-50 (Article 29(2)); RQ-51 (Articles 31 and 28(3)).

FW-49 The entity manages ICT third-party risk as part of ICT risk, in proportion to the nature, scale, complexity and importance of its ICT dependencies. The entity stays fully responsible for its own compliance, whatever it contracts out.

FW-50 The management body approves the strategy on ICT third-party risk and the policy on ICT services that support critical or important functions, reviews the policy at least every [[12]] months, and regularly reviews the risks of those arrangements. The strategy and the policy are: [[document titles and IDs]]. Applies to: Full framework, other than microenterprises.

FW-51 [[Role]] keeps the register of information on all contractual arrangements for ICT services, in the templates of Implementing Regulation (EU) 2024/2956. Every arrangement is listed before any is judged, including arrangements within a group and for a small or free service. The entity reports on the register in the form and by the date the competent authority sets: [[authority's instruction]]. It tells the authority in good time of any planned arrangement for a critical or important function.

FW-52 Before contracting, the entity assesses whether the arrangement supports a critical or important function and all relevant risks including concentration risk, and carries out due diligence on the provider. It contracts only with providers that follow appropriate information security standards. It sets the frequency and areas of its audits on a risk basis, and checks each provider against the list of critical ICT third-party service providers that the European Supervisory Authorities publish.

FW-53 Every contract for ICT services is in writing and holds the terms of Article 30(1) and (2). A contract for a service that supports a critical or important function also holds the terms of Article 30(3). A contract signed before this framework is amended without waiting for its renewal.

FW-54 Each arrangement that supports a critical or important function has an exit plan, which is reviewed and tested at least every [[12]] months, and a subcontracting assessment. DORA says only that exit plans are tested and reviewed periodically, so this interval is the entity's own.

Arrangements that support a critical or important function

Each such arrangement needs the following. Entities already live do not wait for a renewal (DR-11).

Learning, awareness, crisis communication and information sharing

The entity learns from what happens to it and to others, and makes sure its people know what to do. DORA makes information sharing optional: the management body decides, and the decision is recorded.

Duties in this section: RQ-20 (Article 13(1) to (3), (5)); RQ-21 (Article 13(6)); RQ-22 (Article 14); RQ-25 (Article 16(1)(h), 16(2)); RQ-52 (Article 45).

FW-55 The entity gathers information on vulnerabilities and cyber threats, reviews major incidents after they disrupt core activities, and builds the lessons from tests, real incidents and supervisory reviews into its ICT risk assessment. Senior ICT staff report to the management body at least every [[12]] months on the findings, with recommendations. Applies to: Full framework.

FW-56 The entity feeds the conclusions of its tests and of its post-incident analysis into its ICT risk assessment. It develops awareness and resilience training for staff and management as its needs and risk profile require. Applies to: Simplified framework.

FW-57 ICT security awareness programmes and digital operational resilience training are compulsory modules in staff training, for all employees and senior management, at a level that suits their role, and include ICT third-party service providers where appropriate. [[Role]] keeps the attendance record and the list of people not yet trained. Applies to: Full framework.

FW-58 The entity has crisis communication plans that allow responsible disclosure of at least major ICT-related incidents or vulnerabilities to clients, counterparts and the public, with communication policies for staff and external stakeholders. [[Name and role]] is tasked with the public and media function. Applies to: Full framework.

FW-59 The management body has decided whether the entity takes part in a trusted community that exchanges cyber threat information. The decision is: [[takes part / does not take part]], recorded on [[YYYY-MM-DD]]. If the entity takes part, it tells the competent authority once its membership is validated, and when it ends. Applies to: Every financial entity in scope; optional.

Review and improvement of the framework

The framework is a living document. The management body approves each version, and the review report shows what changed and why.

Duties in this section: RQ-09 (Article 6(5)).

FW-60 The entity documents this framework and reviews it at least every [[12]] months, after a major ICT-related incident, and after supervisory instructions or conclusions from resilience testing or audit. A microenterprise reviews it periodically, at the interval [[interval]]. The framework is improved continuously on the lessons learned. Applies to: Full framework.

FW-61 [[Role]] writes a report on each review, in a searchable electronic format, with the contents in the table below. The management body approves the report. The entity gives the report to the competent authority on request.

The contents of the review report. The full framework follows Article 27(2) of Delegated Regulation (EU) 2024/1774, and the simplified framework Article 41(2):

Records and evidence

Records show the framework operating. The entity keeps the records behind each item for at least [[3]] years, unless a duty or the competent authority says longer, and can produce any item within [[5]] working days of a request (DR-19). DORA sets no general retention period, so these figures are the entity's own. The DORA Documentation & Evidence Checklist lists all 34 evidence items. The first 17, EV-01 to EV-17, belong to this framework. The core records are the scope and proportionality assessment, approved by the management body (EV-01), minutes of the management body's approvals and its reports (EV-02), the management body's training record (EV-03), the ICT risk management framework document (EV-04), the latest report on the review of the framework (EV-05) and the digital operational resilience strategy (EV-06). Each has an owner and a place where it is kept, set in that checklist.

Approval and review record

The management body approves this framework. This section holds the record. Each approval names what was approved, and the minutes carry the same words.

Approval of this framework

What the management body has approved

Reviews

One line for each review, the yearly one and any review after a trigger (FW-60):

Example: Lantern Pay Services

EXAMPLE, not part of the framework. The entity used in this pack is Lantern Pay Services (EXAMPLE), a small authorised payment institution in an EU Member State, with 64 staff. It is an authorised payment institution under Directive (EU) 2015/2366 that is not an exempted one, with a board of five: the chair, the managing director, the finance director and two non-executive directors. All names, figures and dates are made up. Replace this section with your own, or delete it before approval.

DORA applied from 17 Jan 2025. Lantern Pay's board approved its scope assessment on 21 Nov 2024: a payment institution, authorised and not exempted, so under the full framework, and with 64 staff not a microenterprise.

The board approved the ICT risk management framework and its yearly review report on 12 Mar 2026, and the ICT third-party strategy and policy on 10 Jun 2026. It submitted its register of information on 27 Mar 2026, in the format its authority set.

What the scope assessment decided

Full ICT risk management framework (DORA Articles 5 to 15). Lantern Pay is not a microenterprise. 41 of 52 duties apply. The other 11 are marked Not applicable, each with the reason the profile gives: RQ-03, RQ-23, RQ-24, RQ-25, RQ-26, RQ-40 (for entities under the simplified framework: the entity follows Articles 5 to 15); RQ-35 (for microenterprises only); RQ-36 (for central securities depository, central counterparty only); RQ-37, RQ-38, RQ-39 (a TLPT authority has not identified the entity).

Threat-led penetration testing: Not required unless a TLPT authority identifies the entity (Article 26(8)). Delegated Regulation 2025/1190 Article 2(2) names payment institutions that exceeded EUR 150 billion of total value of payment transactions in each of the 2 calendar years before the assessment; the authority may decide that the assessment does not justify TLPT.

The framework's readiness items on 30 September 2026

The DORA programme lead rated the 8 items that relate to this framework: Operating 5 of 8 and In place 3 of 8. The items below Operating, named:

The gaps raised on these items:

Approvals

The board approved the scope assessment on 21 Nov 2024 and reviewed it on 4 Mar 2026. It approved the framework and its review report on 12 Mar 2026, so the next review falls due by 12 Mar 2027. It approved the third-party strategy and policy on 10 Jun 2026.

Four of 5 board members have completed ICT risk training in the last 12 months. The member appointed on 15 Jul 2026 is booked for 8 Oct 2026, inside the 3 months FW-09 allows.

Adapting this template

If you supply ICT services to a financial entity

DORA lists ICT third-party service providers in Article 2(1), point (u), and defines financial entities as points (a) to (t) only. Its duties for the contract fall on the financial entity. A supplier is reached by DORA mainly through the terms its customers must ask for (the supplier flow-down list) and the information they must collect. A supplier designated as critical is also overseen by a Lead Overseer. A supplier does not write this framework or run the readiness assessment (DR-22). It checks its contracts against the list below, and keeps ready the information its customers must collect.

Framework references

These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Regulation (EU) 2022/2554 (DORA); Delegated Regulations (EU) 2024/1772, 2024/1773, 2024/1774, 2025/301, 2025/532 and 2025/1190; Implementing Regulations (EU) 2024/2956 and 2025/302; as published in the Official Journal and read on 8 October 2026.

ISO/IEC 27001 references name the clause or control this document relates to, by number and title only. They do not say that meeting one meets any DORA requirement.

This library does not say which ISO/IEC 27001 controls or NIST CSF outcomes meet a DORA requirement. It gives each article's own words, what an entity must be able to show, and the CISO Times documents that help with the work. Where the CISO Times Library holds a mapping between a DORA requirement and a control, it shows it there with how closely the two match and where they differ; confirm it against both texts before relying on it. A document listed here helps with the work a requirement describes. Using it does not by itself show that the requirement is met.

Who these texts bind

Regulation (EU) 2022/2554 binds the financial entities of its Article 2(1), points (a) to (t), except those Article 2(3) excludes and any that a Member State excludes under Article 2(4). Articles 5 to 15 do not apply to the entities of its Article 16(1), which follow Article 16 and Title III of Delegated Regulation (EU) 2024/1774. Several duties do not apply to microenterprises, and the Regulation says where. It reaches an ICT third-party service provider through the contract with a financial entity and, for a provider designated as critical, through the oversight framework of Chapter V, Section II.

Definitions