the whole job

DORA: the whole job, in order

This plan serves two readers. The first is the financial entity, which carries the whole regulation: governance, an ICT risk framework, a register of ICT contracts, incident reporting, resilience testing and third-party risk. The second is a software or IT supplier to such an entity, who receives DORA as contract terms. Steps meant only for the supplier start with the words supplier side only; every other step is for the financial entity.

last checked 2 November 2026

how to read this plan

Each step has an owner, a kind of work and two outputs. The kinds of work are different jobs: choices that someone with authority signs, systems and settings that someone builds, and checks that someone keeps running. The order follows dependencies, so a step needs the ones before it. If you are a supplier, read the phases as your customer's view of you, and do the supplier side only steps, mainly in the contract phase. Several duties scale with size and risk, and small or simplified entities have lighter versions, so confirm your own category with your supervisor. Under each step a small note names the legal basis, or says practice where no text sets it.

  • decide and documentchoices, policies and records that someone with authority signs
  • build and configuresystems, settings and procedures that make the choice real
  • prove and operatechecks, logs and records that show it keeps working
01

put management in charge

Settle which role you play under DORA, who answers for ICT risk and how much risk the company accepts.

  1. settle whether DORA covers you and in which role

    Check whether you are one of the listed types of financial entity, or an ICT provider to one. Note whether you are a microenterprise or on the list that gets a simplified framework, because several duties change with that. A supplier writes down which customers are financial entities.

    • owner legal or DPO
    • decide and document
    what it produces
    a one-page scope note with the date and the reasoning
    the proof it leaves
    the scope note, approved by management

    the work page

    basis DORA Art. 2(1), 4(1), 16(1)

  2. name who answers for ICT risk

    The management body defines, approves and oversees the ICT risk framework and carries ultimate responsibility for it. Outside microenterprises, also name a role or a senior manager to oversee the arrangements with ICT providers.

    • owner board
    • decide and document
    what it produces
    a board decision naming the accountable body and the person who oversees ICT providers
    the proof it leaves
    the minutes of that decision

    the work page

    basis DORA Art. 5(2), 5(3)

  3. train management and fund the work

    Members of the management body keep their knowledge of ICT risk up to date, including through specific training on a regular basis. Set a budget for digital operational resilience, including training and skills, and review it from time to time.

    • owner board
    • build and configure
    what it produces
    a management training session and a budget line
    the proof it leaves
    the attendance record and the approved budget

    the work pagethe control: awareness-training

    basis DORA Art. 5(4), 5(2)

  4. set the risk tolerance for ICT risk

    State in plain words how much ICT risk the company accepts, and approve the resilience strategy that follows from it. The framework in the next phase uses this as its yardstick.

    • owner board
    • decide and document
    what it produces
    a short statement of risk tolerance and a resilience strategy
    the proof it leaves
    the statement and the strategy, approved by the management body

    the work page

    basis DORA Art. 5(2)

you are done with this phase when you can show a board decision naming who answers, a training record for management and a stated risk tolerance.
02

build the ICT risk framework

Document the framework and the things it protects, then put the basic controls in place.

  1. give ICT risk a control function

    Outside microenterprises, assign the job of managing and overseeing ICT risk to a control function, and keep it free of conflicts of interest. Decide who sits in it and who it reports to.

    • owner board
    • decide and document
    what it produces
    a named control function with its reporting line
    the proof it leaves
    the decision and the role description

    basis DORA Art. 6(4)

  2. write the ICT risk management framework

    Write down the strategies, policies, procedures, protocols and tools that protect your information and ICT assets, from software and servers to premises and data centres. Write it as a description of what the company really does.

    • owner head of IT
    • decide and document
    what it produces
    a documented ICT risk framework and a risk register with owners
    the proof it leaves
    the framework and the register, approved by management

    the work pagethe control: risk-register

    basis DORA Art. 6(1), 6(2)

  3. map functions, assets and dependencies

    Identify and document the business functions that run on ICT, the assets behind them and their dependencies, including remote sites. Map the critical ones in detail, with their configuration and links. Review the classification at least yearly.

    • owner head of IT
    • build and configure
    what it produces
    an inventory of functions and assets with a map of the critical ones
    the proof it leaves
    dated exports and the map

    the work pagethe control: asset-inventory

    basis DORA Art. 8(1), 8(4)

  4. limit access and require strong sign-in

    Limit physical and logical access to what approved functions need. Write the policy for strong authentication and enforce it on the systems it names.

    • owner head of IT
    • build and configure
    what it produces
    an access policy and a coverage report for strong authentication
    the proof it leaves
    the report and the exception list with owners and dates

    the work pagethe control: mfa

    basis DORA Art. 9(4)

  5. write the continuity policy and the backup rules

    Put in place an ICT business continuity policy, approved by management. Document the backup policy with its scope and minimum frequency, and the procedures to restore from it.

    • owner head of IT
    • build and configure
    what it produces
    a continuity policy, a backup policy and restoration procedures
    the proof it leaves
    the documents and the records of restores

    the work pagethe control: backup-recovery

    basis DORA Art. 11(1), 12(1)

  6. make training compulsory for everyone

    Make ICT security awareness and resilience training compulsory modules in staff training, for all employees and senior management, at a level that fits each role. Where appropriate, include your ICT providers in the schemes.

    • owner HR
    • build and configure
    what it produces
    a yearly training programme and an attendance record
    the proof it leaves
    the record and the material with its version

    the work pagethe control: awareness-training

    basis DORA Art. 13(6)

you are done with this phase when you can show a written framework, a current map of functions and assets, and each control working.
03

list every ICT contract

Know which ICT services you buy, which of them support a critical or important function and what your policy says about them.

  1. list every contract for ICT services

    Keep a register of information on all contracts for ICT services from third-party providers, and keep it up to date. Start from what you can export: procurement, finance and the admin lists.

    • owner procurement
    • build and configure
    what it produces
    a register of all ICT contracts with provider, service and owner
    the proof it leaves
    dated exports and the register

    the work pagethe control: supplier-management

    basis DORA Art. 28(3)

  2. mark the contracts that support a critical or important function

    Document the contracts so that those covering services behind critical or important functions are told apart from the rest. The test is yours to apply, and your supervisor can question it. Tell the authority in good time about a planned contract of this kind, and when a function becomes critical or important.

    • owner legal or DPO
    • decide and document
    what it produces
    a register with the critical or important marker and the reasoning
    the proof it leaves
    the register and the notes behind each mark

    the work page

    basis DORA Art. 28(3)

  3. adopt a strategy and a policy for ICT third-party risk

    Outside microenterprises and the entities with a simplified framework, adopt a strategy for ICT third-party risk with a policy on services that support critical or important functions, and review it regularly. The management body approves the policy and reviews the risks in those contracts.

    • owner board
    • decide and document
    what it produces
    a strategy and a policy, with a review date
    the proof it leaves
    the documents, approved by the management body

    the work page

    basis DORA Art. 28(2), 5(2)

  4. get the register ready for your supervisor

    Prepare to report at least yearly the number of new arrangements, the categories of providers, the types of contract and the services and functions provided. Be able to hand over the full register, or parts of it, on request.

    • owner legal or DPO
    • prove and operate
    what it produces
    a yearly report from the register and a procedure for supervisor requests
    the proof it leaves
    the report and the log of requests answered

    the work page

    basis DORA Art. 28(3)

  5. supplier side only: prepare the facts your customers need for their register

    Keep one standard sheet with the legal entity, the services you provide, where they run and where data is stored, and which subcontractors take part. Your financial customers must record this, and a ready sheet saves a round of questions.

    • owner legal or DPO
    • build and configure
    what it produces
    a standard provider fact sheet
    the proof it leaves
    the sheet with the date of the last check

    basis working practice. No legal text sets this.

you are done with this phase when you can hand your supervisor a register of all ICT contracts that separates the critical ones.
04

classify and report incidents

Decide who handles an incident, how it is classified and how the supervisor hears about it on time.

  1. set up incident management and roles

    Define a process to detect, manage and notify ICT incidents. Assign the roles for each type of incident, set the plans for communicating with staff, clients and the media, and write the response procedures that get services running again.

    • owner head of IT
    • decide and document
    what it produces
    an incident procedure with named roles, escalation and communication plans
    the proof it leaves
    the procedure and the contact sheet, reviewed yearly

    the work pagethe control: incident-management

    basis DORA Art. 17(1), 17(3)

  2. record every incident and find the root cause

    Record all ICT incidents and significant cyber threats, put early warning indicators in place and follow each incident up until the root cause is identified, documented and addressed.

    • owner head of IT
    • build and configure
    what it produces
    an incident log with root causes and early warning indicators
    the proof it leaves
    the log and the follow-up records

    the work pagethe control: logging-monitoring

    basis DORA Art. 17(2), 17(3)

  3. classify incidents against the criteria

    Classify incidents and set their impact using the criteria in the regulation: clients and transactions affected, duration, geographic spread, data losses, criticality of the services and economic impact. Write the thresholds for major incidents into the procedure.

    • owner head of IT
    • decide and document
    what it produces
    a classification table with the thresholds for a major incident
    the proof it leaves
    the table and a record of classified incidents

    the work page

    basis DORA Art. 18(1)

  4. prepare the initial, intermediate and final reports

    Major incidents go to your competent authority in three stages: an initial notification within 4 hours of classifying the incident as major and at the latest 24 hours after becoming aware of it, an intermediate report within 72 hours and a final report within one month. Prepare the templates, decide who may send them and agree a fallback for when the template cannot be used.

    • owner legal or DPO
    • build and configure
    what it produces
    three report templates, a rule for who sends them and a fallback channel
    the proof it leaves
    the templates and a dry run

    the work page

    basis DORA Art. 19(1); RTS 2025/301 Art. 5(1)

  5. decide who tells management and clients

    Major incidents are reported to senior management, and the management body is told the impact, the response and the controls to add. Where a major incident touches clients' financial interests, they are informed without undue delay once you are aware of it.

    • owner legal or DPO
    • decide and document
    what it produces
    an escalation rule and a client notice template
    the proof it leaves
    the rule and the template, tested in the dry run

    the work page

    basis DORA Art. 17(3), 19(3)

  6. supplier side only: agree how you alert customers and help in their incident

    Your financial customers need your help to meet their clocks. Agree the assistance you give when an incident relates to your service, at no extra cost or at a cost fixed in advance, and the notice you give of any development that could affect your service.

    • owner legal or DPO
    • build and configure
    what it produces
    a customer incident procedure with a contact route and notice terms
    the proof it leaves
    the procedure, as sent to customers

    the work pagethe control: incident-management

    basis DORA Art. 30(2), 30(3)

you are done with this phase when you can show an incident process with named roles, classification criteria and tested report templates.
05

test resilience

Run a testing programme in proportion to your size and risk, and fix what it finds.

  1. set up the resilience testing programme

    Outside microenterprises, establish, maintain and review a testing programme as part of the ICT risk framework, using a risk-based approach. It checks your readiness for incidents and finds weaknesses and gaps.

    • owner head of IT
    • decide and document
    what it produces
    a testing programme with scope, rhythm and owners
    the proof it leaves
    the programme, approved by management

    the work pagethe control: vulnerability-management

    basis DORA Art. 24(1), 24(2)

  2. run the tests the programme calls for

    Choose appropriate tests from the regulation's list, such as vulnerability scans, network security assessments, source code reviews where feasible, scenario-based tests and penetration testing. Microenterprises combine a risk-based approach with a plan for what to test first.

    • owner head of IT
    • build and configure
    what it produces
    a test plan and the results of each test
    the proof it leaves
    test reports, dated

    the work pagethe control: vulnerability-management

    basis DORA Art. 25(1), 25(3)

  3. fix the findings and test again

    Put corrective measures in place promptly. Write down who fixes each finding and by when, retest the important ones and record what you accepted.

    • owner head of IT
    • prove and operate
    what it produces
    an action list with owners and dates
    the proof it leaves
    the list and the retest results

    the work page

    basis DORA Art. 24(1)

  4. find out whether advanced testing applies to you

    Entities identified by the authorities, other than microenterprises and those with a simplified framework, carry out advanced threat-led testing at least every 3 years. Ask your supervisor early whether you are on that list.

    • owner legal or DPO
    • decide and document
    what it produces
    a note of the supervisor's answer and the date
    the proof it leaves
    the note and any correspondence

    the work page

    basis DORA Art. 26(1)

you are done with this phase when you can show a programme, test results and the corrective actions that followed.
06

get the contracts right

Check providers before you sign, write the required terms into the contract and plan how to leave.

  1. assess a provider before you sign

    Before a new contract, check whether it supports a critical or important function, identify the risks, including concentration risk and conflicts of interest, and do due diligence on the provider. Contract only with providers that meet appropriate information security standards.

    • owner procurement
    • build and configure
    what it produces
    a pre-contract assessment for each new provider
    the proof it leaves
    the assessments and the answers received

    the work pagethe control: supplier-management

    basis DORA Art. 28(4), 28(5)

  2. write the mandatory terms into every ICT contract

    Set the contract out in writing, with service levels, and include at least these: the services and subcontracting conditions, locations and advance notice of changes, data protection, data access and return on insolvency or exit, service levels, help in an incident, cooperation with authorities, termination rights and participation in training.

    • owner legal or DPO
    • build and configure
    what it produces
    a standard clause set and a contract checklist
    the proof it leaves
    the checklist, completed for each contract

    the work pagethe control: supplier-management

    basis DORA Art. 30(1), 30(2)

  3. add the extra terms for critical or important functions

    For contracts behind critical or important functions, add full service levels with measurable targets, notice and reporting duties, the provider's continuity plans and security measures, participation in your advanced tests, audit and access rights and exit strategies with a transition period.

    • owner legal or DPO
    • build and configure
    what it produces
    an addendum for critical or important functions
    the proof it leaves
    the addendum, signed with each such provider

    the work page

    basis DORA Art. 30(3)

  4. plan audits of your providers

    Use a risk-based approach to decide in advance how often to audit each provider and which areas to cover. Where the service is technically complex, check that the auditors have the skills to do it.

    • owner head of IT
    • decide and document
    what it produces
    an audit plan by provider
    the proof it leaves
    the plan and the audit reports

    the work pagethe control: supplier-management

    basis DORA Art. 28(6)

  5. plan how to leave a provider

    For services behind critical or important functions, write exit strategies that cover failure, falling quality and termination, with alternative solutions and transition plans. Make sure the contract can be ended in the cases the regulation lists.

    • owner head of IT
    • build and configure
    what it produces
    an exit plan for each critical provider
    the proof it leaves
    the plans, with the dates they were tested and reviewed

    the work pagethe control: backup-recovery

    basis DORA Art. 28(7), 28(8)

  6. supplier side only: compare your standard terms with the mandatory list

    Read your standard contract against the minimum terms: services and subcontracting, locations and notice of change, data protection, data return, service levels, assistance, cooperation with authorities, termination rights and training. Mark what is missing and decide what you can offer.

    • owner legal or DPO
    • decide and document
    what it produces
    a gap list between your standard terms and the mandatory list
    the proof it leaves
    the list and the decisions taken

    the work page

    basis DORA Art. 30(2)

  7. supplier side only: decide your position on audit, testing and exit terms

    A financial customer with a critical or important function must be able to ask for audit and access rights, your cooperation in its advanced tests, notice duties and an exit period. Decide what you will agree and how, including alternative assurance if other clients' rights are affected.

    • owner legal or DPO
    • decide and document
    what it produces
    a position paper and a standard addendum for critical or important functions
    the proof it leaves
    the paper, approved by management

    the work page

    basis DORA Art. 30(3)

  8. supplier side only: set conditions for your own subcontractors

    Your contract has to say whether subcontracting is allowed and on what conditions. Decide this, list the subcontractors that touch the service and where they work, and agree matching terms with them.

    • owner procurement
    • build and configure
    what it produces
    a subcontractor list and a standard flow-down clause
    the proof it leaves
    the list and the signed clauses

    the work pagethe control: supplier-management

    basis DORA Art. 30(2)

you are done with this phase when you can show each ICT contract with its required terms, an audit plan and an exit plan for the critical ones. A supplier can show its standard terms against the same list.
07

show it keeps working

Keep the proof together, review the framework on a rhythm and report to management.

  1. keep the framework, register and incident records together

    Collect the output of every step above in one place, organised by chapter of the regulation. You must be able to give your supervisor complete and current information on ICT risk and the framework on request.

    • owner head of IT
    • prove and operate
    what it produces
    an evidence folder organised by chapter
    the proof it leaves
    the folder, with each item dated

    basis DORA Art. 6(3), 28(3)

  2. review classification and risk scenarios at least yearly

    Review the classification of functions and assets and their documentation at least yearly, and the risk scenarios that affect you. Update the register of ICT contracts when contracts change.

    • owner head of IT
    • prove and operate
    what it produces
    a yearly review record and an updated register
    the proof it leaves
    the record, dated and signed

    the work pagethe control: risk-register

    basis DORA Art. 8(1), 8(2)

  3. test restores and exit plans

    Restore from backups on a schedule and test the exit plans for critical providers. Review both periodically and record what failed and who fixed it.

    • owner head of IT
    • prove and operate
    what it produces
    restore and exit test reports with actions
    the proof it leaves
    the reports and the closed action list

    the work pagethe control: backup-recovery

    basis DORA Art. 12(1), 28(8)

  4. report to management and close the gaps

    Set up the channels that keep the management body informed on ICT provider arrangements, planned changes, and major incidents with their response and corrective measures. Once a year, show management the state of each part and the open gaps, and record what they decided.

    • owner board
    • prove and operate
    what it produces
    a yearly report to the management body
    the proof it leaves
    the report and the minutes

    the work page

    basis DORA Art. 5(2), 17(3)

  5. supplier side only: keep an assurance pack for customers

    Keep the material your financial customers will ask for in one place: your signed terms against the mandatory list, summaries of your tests, audit reports you can share and your incident contact route. Refresh it on a stated rhythm.

    • owner head of IT
    • prove and operate
    what it produces
    a customer assurance pack
    the proof it leaves
    the pack, with the date of each document

    basis working practice. No legal text sets this.

you are done with this phase when you can hand a supervisor, or a customer, one folder that shows each part working.

who carries what

The same steps, grouped by the person who has to act.

legal or DPO

board

head of IT

HR

procurement

controls you will need

Each control has its own page: what it is, what to look for, where it goes wrong and the proof it leaves.

    check it yourself

    your next step

    Open your list of ICT contracts and mark which ones support a critical or important function.

    open the supplier work