What DORA means for a bank or credit institution
DORA has applied since 17 January 2025, and as a regulation it is directly applicable in every member state without national transposion. For a bank, that means the ICT risk controls, incident process, testing programme and provider oversight are the bank's own obligations. The bank owns its controls and decides how they are run. An independent auditor or the competent authority judges whether they comply. A consultant or implementation partner can prepare systems and evidence, but cannot issue a finding of compliance.
Article 2(1)(a) lists credit institutions first among the 20 types of financial entity in scope, so a licensed bank cannot treat DORA as optional. What changes is who supervises it and which extra obligations apply. The bank should answer three questions in writing. First, is it classified as significant under the Single Supervisory Mechanism Regulation? If so, Article 46(a) makes the ECB the competent authority, and significant banks report major incidents to their national authority, which passes them to the ECB. Second, is it a G-SII or O-SII, or part of one? Article 2(2) then requires the TLPT authority to require threat-led penetration testing unless its assessment shows it is not justified. Third, does it belong to a group with entities in other categories? Group structure determines which entity carries which obligation.
Confirm the classification before planning the programme. The answers determine the supervisor, the reporting route, whether TLPT applies, and whether external testers are mandatory. The bank should record the basis for each answer, obtain confirmation from its supervisor where the status is uncertain, and check the classification each year as its balance sheet and status change. Each answer then feeds the TLPT and reporting sections of this page.
Which DORA obligations apply to which bank
A credit institution classified as significant under the Single Supervisory Mechanism Regulation falls under ECB competence for DORA purposes. Article 46(a) makes the ECB the competent authority for these institutions, but the day-to-day reporting channel runs through the bank's national competent authority. The bank files its incident reports there, and the national authority transmits them to the ECB without delay under Article 19(1). For testing, significant institutions may use only external testers when they run threat-led penetration tests, which is stricter than the rule for other banks.
- Supervisor: The ECB is the competent authority under Article 46(a), with the national authority as the reporting point.
- Incident reporting: Major ICT-related incidents are reported individually, not in aggregated form, under the rules for significant institutions.
- TLPT: Where the bank is in scope for threat-led testing, it must use external testers only.
- Weekend deadlines: Initial notifications and intermediate reports by credit institutions follow the stricter timing rule and do not move to noon on the next working day.
- Copies to NIS2 authorities: Member states may require copies of reports to NIS2 authorities or CSIRTs.
Confirm with your national competent authority how it wants the transmission handled and which reporting channel it has set up.
Credit institutions that are not classified as significant are supervised by their national competent authority under Article 46. There is no ECB layer for these banks. Their incident reports go directly to that national authority, and the aggregated reporting option in Article 7 is available for incidents caused by a shared ICT provider, provided the authority permits it. Testing obligations depend on whether the bank falls within the TLPT scope set by the authority, not on its significance classification.
- Supervisor: The national competent authority supervises DORA compliance directly.
- Incident reporting: Reports go to the national authority, and an aggregated report may be possible for a provider incident affecting several entities supervised by the same authority, if that authority agrees.
- TLPT: Inclusion depends on the authority's assessment under Article 2(2) and is not automatic for every bank.
- Internal testers: Where internal testers are used, the bank must contract external testers at least every three tests under Article 26(8).
- Deadlines: Weekend and holiday deadline rules follow the general approach in Delegated Regulation (EU) 2025/301.
Confirm your classification and TLPT status in writing with your national authority, and check whether it has published its own reporting procedures.
Global systemically important institutions (G-SIIs) and other systemically important institutions (O-SIIs) are named in Article 2(2) as entities whose TLPT authority should normally require threat-led testing, unless its assessment shows that testing is not justified. Being a G-SII or O-SII, or part of one, is therefore a strong signal of TLPT scope. Systemic status does not by itself change who supervises the bank, which still depends on whether it is significant under the SSM.
- TLPT presumption: The authority should require testing unless its assessment finds it unjustified.
- Group membership: Banks that are part of a G-SII or O-SII group are covered by the same presumption.
- Supervisor: The ECB or national authority applies, depending on SSM significance, so a G-SII or O-SII may fall under either route.
- External testers: Where the bank is also significant, it may use only external testers.
- Planning: TLPT scope should be fixed early because the test preparation and tester selection take time.
Ask your authority to confirm in writing whether it expects you to take part in threat-led testing and which testing framework it will apply.
Across all three bank situations, the same two questions drive the obligations: who supervises the bank and whether TLPT applies. Individual incident reporting is the default for banks that are significant, and the aggregated route in Article 7 is only available to other entities when the authority permits it. Before building a program, a bank should record its classification, its supervisor, its TLPT status and the reporting channel in one place, since these decide the rest of the compliance plan.
- Classification record: Document SSM significance, systemic status and the supervisor named for each.
- Reporting path: Map each incident type to its reporting route and deadline.
- Tester selection: Confirm whether internal testers are allowed and what external tester rules apply.
- Group scope: Check whether a parent or subsidiary changes the classification.
- Authority guidance: Track updates from the ESAs and the national authority, including the operational instructions for incident reporting.
Confirm each classification and TLPT decision with your supervisor and document the answer, because the auditor and supervisor will ask for it.
How weekend and holiday reporting deadlines work for banks
For most DORA incident reports, a deadline that falls on a weekend or bank holiday moves to noon on the next working day. Delegated Regulation (EU) 2025/301, Article 5(4) and (5), sets this rule. Credit institutions are carved out for the initial notification and intermediate reports, which keep their original timing. For a bank, that means the first notice and the interim update can fall due on a Saturday, Sunday or public holiday with no extension. Only the later final report benefits from the noon rule. The reader should map each deadline in the regulation to its report type before the first live incident, not during one.
This shapes incident-response staffing and on-call design. A bank's major incident process needs a named person who can classify the incident, decide whether it is major, and submit the initial notification outside office hours, including overnight on Friday and across long weekends. Ask who holds that authority on each day of the week, how the on-call rota escalates when the first contact is unreachable, and whether the incident team can draft the notification from a template and a pre-agreed data set. Test the path with a tabletop exercise that starts on a Sunday evening. Confirm with the bank's competent authority, and with the ECB for significant institutions, how submissions are accepted outside business hours.
The EBA's operational instructions for DORA incident reporting are the next read. They explain how the reporting templates and timing rules apply in practice, and they should be checked against the current version before the bank's runbooks are finalized, since the publication date and version of the guidance can change. Compare the instructions with the bank's own incident classification criteria, and record every assumption about working days, holidays in each member state where the bank operates, and the time zone used for deadlines. Those decisions belong in the incident management procedure and should be signed off by the management body.
What makes a bank's DORA project cost more or take longer
A bank's DORA cost is set less by the regulation than by the estate it has to document, test and report on. The drivers below interact: a large provider population feeds the register of information, legacy systems lengthen testing and remediation, and group structure multiplies every control across entities and jurisdictions. Each card names the decision that controls the driver.
Number of ICT third-party providers
Every ICT provider that supports a critical or important function must be identified, assessed and covered by contract terms under Chapter V. A bank with hundreds of SaaS, cloud and outsourced suppliers faces a larger due diligence and exit planning workload than one with a short list. Ask early which providers are actually in scope, and whether shared providers can be assessed once for several business lines. Confirm the criteria your own third-party policy applies before counting providers.
Critical functions and their mapping
The effort depends on how many business functions the bank has classified as critical or important, and how many ICT services each one depends on. Each mapping must be kept current, because a change in one provider can affect several functions. Control this by agreeing a single function inventory with business owners before any contract review starts, and by limiting re-classification to documented triggers.
Legacy core banking and integration
Older core banking platforms often lack logging, identity controls and recovery tooling that DORA's ICT risk management and testing expectations assume. Retrofitting these controls around a mainframe or batch-based core can take longer than any policy work. Ask the platform team to produce a gap view for the core and its interfaces first, then decide which gaps are fixed, isolated behind a compensating control or accepted with a dated plan.
Number of entities and jurisdictions
A banking group with several licensed entities across member states may need separate governance, registers and incident reporting routes, even where systems are shared. Each additional entity multiplies documentation and sign-off. Control this by mapping which entities rely on group-level ICT services and agreeing one group framework with entity-level annexes, subject to the competent authority for each entity.
State of the register of information
The register of information records contractual arrangements with ICT providers and must be complete and consistent before supervisors can use it. Where contract data sits in procurement systems, legal folders and spreadsheets, collecting and reconciling it is often the longest task. Start with a data owner for each field, a single source of record and a reconciliation against accounts payable so that the register does not diverge from actual spend.
Incident reporting maturity and external TLPT testers
Significant credit institutions report major incidents through their national authority, which passes them to the ECB, and must use only external testers for threat-led penetration testing. Weak incident classification and slow evidence collection extend every report, while external tester procurement can take months and draws on a limited supply of qualified firms. Ask the bank to rehearse classification against a sample incident, and to start tester selection well before a TLPT is due.
Who is paid for what in a DORA readiness project for a bank
This table shows who a bank typically pays for each part of DORA readiness, whether the cost is one-time or recurring, and what pushes it up. DORA sets no certificate, so no party issues a DORA certificate, and the implementation partner prepares systems and evidence while only an independent auditor or assessor issues any report. Use the table to frame quote requests, and ask every provider to state which costs sit inside their written scope.
| Cost component | Who is paid and for what | One-time or recurring, and what drives it up |
|---|---|---|
| Internal compliance and ICT staff | Bank employees who own the ICT risk framework, register of information, policies and board reporting. Internal time is an internal cost, not a payment to a third party. | Largely recurring once DORA applies. Costs rise with the number of ICT third-party arrangements, the size of the ICT estate and the number of in-scope legal entities. |
| Implementation partner for systems, evidence and documentation | A firm such as DeployOpen prepares and hardens systems, configures logging and backups, and assembles evidence packs under a written scope. It does not issue audit reports or certificates. | Mostly one-time for the readiness project, with optional recurring retainers for upgrades and evidence refresh. Costs rise with the number of self-hosted platforms, integrations and documentation gaps. |
| Security testing firm | A testing provider runs the penetration and security tests that DORA requires every entity to perform, separate from threat-led testing. | Recurring on a testing cycle. Costs rise with the number of applications, APIs, cloud accounts and the depth of retesting after remediation. |
| External TLPT testers where required | For banks that a competent authority requires to perform threat-led penetration testing, external testers are contracted. For significant credit institutions, Article 26(8) of DORA allows only external testers. | Recurring on the TLPT cycle set by the authority. Costs rise with the scope agreed with the authority, the number of live production systems in scope and the involvement of critical providers. |
| Legal review of ICT contracts | External counsel or in-house legal reviews contract clauses for ICT services, audit rights, subcontracting, exit and incident notification duties. | Mostly one-time per contract, then recurring at renewal. Costs rise with the number of contracts and the number of non-standard cloud or intra-group agreements. |
| Independent assessor or auditor where the bank commissions one | An independent assessor or auditor, if the bank chooses to commission one, issues any report on its own review. DORA sets no certification scheme, so this is a voluntary assurance choice, not a DORA certificate. | Periodic, when commissioned. Costs rise with the scope of the review, the evidence the bank has prepared in advance and the number of entities covered. Ask the assessor to confirm its scope and report type in writing. |
How a bank moves from gap analysis to a supervised DORA position
The sequence turns DORA's requirements into a documented, tested and board-approved position that the bank can show its competent authority, with the ECB involved where the bank is significant. Each phase produces a named artifact that the next phase depends on.
Confirm scope and map entities
The bank confirms whether it is a credit institution under Article 2(1), whether it is classified as significant under the Single Supervisory Mechanism Regulation, and which group entities, branches and ICT services fall inside the perimeter. Under Article 46, a significant bank's competent authority is the ECB, so this step decides who supervises the bank and who receives its incident reports. The output is a signed scope statement and an entity map that lists every in-scope legal entity, its supervisor and its ICT dependencies. Confirm the classification with the national competent authority rather than assuming it.
Run gap analysis against Chapters II to V
Assess current practice against the ICT risk management requirements in Chapter II, the incident rules in Chapter III, the testing rules in Chapter IV and the third-party rules in Chapter V, together with the delegated regulations that detail them. Teams from risk, security, operations and procurement each review their area and rate each requirement as met, partly met or not met, with the evidence that supports the rating. The output is a gap register with an owner, a remediation action and a board-visible priority for every open item.
Build the register of information
Compile the register of information covering every contractual arrangement on ICT services, including subcontracting chains and intra-group services. Each entry records the provider, the service, the functions it supports and whether those functions are critical or important. The data must be consistent with the contracts and the asset inventory, so the bank reconciles it against procurement records. The output is a validated register in the format the competent authority expects, with a named owner who keeps it current when contracts change.
Test the incident process and reporting
Walk the incident management process from detection through classification to reporting, using a tabletop exercise based on a realistic but invented scenario. Check whether the bank can classify an event as a major ICT-related incident, route the report to the national competent authority and meet the notification and report steps set out in the incident reporting technical standards. Confirm that the reporting path for a significant bank includes the immediate transmission to the ECB. The output is an exercise record with timings, gaps found, corrections made and a re-test result.
Assess TLPT readiness where scoped
Where Article 2(2) and the supervisor's assessment place the bank in scope for threat-led penetration testing, prepare for TLPT under Article 26 and the TLPT technical standards. This covers agreeing the authority's approach, identifying critical functions for testing, and confirming that testers are external, since significant banks may use only external testers. Banks outside the scope should still record the assessment and the authority's decision. The output is either a readiness plan with the test scope agreed with the authority or a documented decision that TLPT does not currently apply.
Remediate ICT provider contracts
Review each contract for an ICT service that supports a critical or important function against the contractual provisions in Article 30. Typical gaps include audit and access rights, service levels, incident cooperation, data location, subcontracting controls and exit provisions. Where the provider will not agree a change, record the risk and the exit plan the bank would use. The output is a contract remediation tracker showing each clause checked, each amendment agreed and each residual risk accepted by a named executive.
Obtain board approval and supervisory record
The management body approves the ICT risk management framework, the resilience strategy, the gap remediation plan and the residual risks, as required by Article 5. The bank then documents this approval and keeps the minutes, which supervisors review. Present the position to the competent authority through the normal supervisory dialogue, including the register and open remediation items. The output is signed board minutes, an approved framework version and a remediation plan the supervisor has seen. An independent auditor or consultant can prepare this evidence but does not approve it.
Who owns the bank's DORA controls and who prepares the evidence
The management body carries final responsibility for the bank's ICT risk management framework under DORA. It approves the digital operational resilience strategy, the ICT risk tolerance, the policies that implement the framework and the budget that pays for them. Board members are expected to understand enough about ICT risk to challenge management, and they must keep records showing that they did.
- Approval: Approves the ICT risk management framework, the resilience strategy and the ICT third-party policy, and records the decision.
- Oversight: Reviews reports on incidents, testing results and key ICT risks at a regular cadence set in the bank's governance documents.
- Accountability: Carries responsibility for the framework even where parts of it are delegated or outsourced.
- Training: Maintains an ICT risk training programme for members of the management body.
- Independence boundary: Cannot outsource accountability. Advisers may inform decisions but do not replace board judgment.
Check that the board minutes name the specific DORA decisions taken and the evidence the board reviewed for each.
The bank's compliance, risk, security and ICT operations teams own the day-to-day controls. They run the registers, operate the monitoring, manage incidents, maintain the policies and produce the evidence that an assessor or supervisor will ask for. Ownership sits inside the bank even when specialists do parts of the work.
- Control operation: Runs access reviews, change approvals, backups, monitoring and vulnerability management.
- Documentation: Maintains the policies, the asset inventory, the register of information and the incident records.
- Incident reporting: Staffs the process that meets the reporting deadlines in Article 19 and the related RTS.
- Internal review: Keeps an independent control function and internal audit that test the framework without owning it.
- Usually outsourced: Parts of security operations, penetration testing and tool administration, with the bank keeping the accountable owner.
Confirm that every control has a named internal owner and that the owner can produce current evidence without help from a vendor.
An implementation partner such as DeployOpen can plan, build, configure, harden, document and test systems inside the bank's own infrastructure, and it can prepare the evidence that those systems produce. It works to a written scope and delivers artifacts the bank reviews and adopts. It does not decide the bank's risk appetite, sign the bank's policies as the owner or issue any assurance report.
- Preparation: Builds self-hosted platforms, logging, backup and access configurations to the bank's documented requirements.
- Evidence packs: Prepares configuration records, test outputs and runbooks that the bank's owners review before adoption.
- Testing: Runs security testing and supports resilience testing, with findings handed to the bank for remediation and sign-off.
- Knowledge transfer: Trains the bank's staff so the controls keep working after the engagement closes.
- Independence boundary: The partner cannot review its own work as an assessor, and it cannot be the party that certifies or attests to the bank's compliance.
Ask for the written scope, the list of deliverables and a statement of which artifacts the bank must approve before they become evidence.
Independent parties test the bank's compliance from outside. For a significant credit institution, the ECB is the competent authority under Article 46, and national competent authorities supervise other credit institutions. Supervisors use their powers under Article 50 to inspect and require information. DORA sets no certification scheme, so no authority issues a DORA certificate. The only authority-issued attestation the Regulation provides for is the attestation that a threat-led penetration test met the requirements of Article 26(7).
- Supervision: The competent authority reviews the bank's governance, reports and testing outcomes, and can require remediation.
- Independent assessment: Where the bank commissions an external review, the assessor's report is the bank's own document, not a regulator's certificate.
- TLPT attestation: Issued after a threat-led test that meets the requirements, as the only authority attestation in the Regulation.
- Independence boundary: Assessors and supervisors cannot design the controls they test without losing their independence.
- Check: Confirm with your supervisor which reviews it expects and which external reports it will accept as supporting evidence.
What a bank needs in place before supervisors or testers arrive
Supervisors and testers start from the same few artifacts: an approved ICT risk framework, tested incident runbooks, a complete register of information, compliant ICT contracts and a documented testing programme. The evidence trail linking them is what they check first, so each item below includes how to verify it internally before an assessment begins.
ICT risk framework approved by the management body
The ICT risk management framework must be documented, reviewed at least annually and formally approved by the management body, which keeps responsibility for it. Check that the approval appears in board minutes with a version number, that the framework names owners for each function, and that it links to the current risk assessment and residual risk decisions. A framework that exists only as a policy document, without evidence of board challenge, is a common finding. Ask the board secretary to produce the last approval record.
Incident runbooks tested against deadlines
Major ICT-related incidents must be classified and reported to the competent authority within the deadlines set in the incident reporting technical standards. Significant credit institutions report to their national authority, which passes the report to the ECB. Check that runbooks name who classifies the incident, who drafts each report stage and who approves it, and that a tabletop exercise has walked through a weekend or bank holiday scenario. Confirm the current deadlines against the operational instructions before relying on them.
Complete register of information
The register of information records every contractual arrangement with ICT third-party providers, including subcontractors and the functions each one supports. Supervisors use it to map concentration risk and to select providers for oversight. Check that every ICT contract appears in the register, that each entry identifies whether the function is critical or important, and that the register is reconciled with procurement and the contract repository each quarter. Missing entries for cloud or open-source hosting arrangements are frequent gaps.
ICT contracts with required clauses
Contracts with ICT providers supporting critical or important functions must contain the clauses DORA requires, covering service levels, data location, audit and access rights, incident assistance, subcontracting conditions, and exit and termination provisions. Review a sample of contracts against a clause checklist and record gaps with remediation dates. For self-hosted open-source platforms run by an implementation partner, confirm which party holds the contractual obligations and which holds the audit rights.
Documented testing programme
The testing programme sets out the tests run on ICT tools and systems, their frequency, and how findings are ranked and remediated. Banks subject to threat-led penetration testing need a documented plan showing when the test is scheduled and how the testing authority is informed. Check that the programme lists tests by system criticality, that each test has an owner, and that remediation of high findings is tracked to closure. Ask the testing lead to show the last three completed cycles.
Evidence trails for every control
Supervisors test whether controls operate, not only whether they are written. Each control should point to an artifact with a date, an owner and a retention period, such as access review exports, backup restore logs, change approvals and incident post-mortems. Check that a sample control can be traced from policy to a dated record in under an hour, and that logs are retained in a system that the bank controls. Gaps usually appear where evidence sits in personal folders or chat threads.
How the CRD and BRRD changes reach bank governance and resolution
The DORA changes to bank prudential law reach governance through Article 4 of Directive (EU) 2022/2556, which amends the Capital Requirements Directive. Its outsourcing, governance, business continuity and supervisory review and evaluation process (SREP) provisions now extend to ICT third-party providers, to ICT continuity and recovery plans, and to risks revealed by digital operational resilience testing. In practice, this means the management body cannot treat a cloud or software vendor as an operational detail. The board must be able to show that it understands how ICT dependencies affect the bank's business continuity and outsourcing decisions, and supervisors can examine those dependencies within the SREP. Banks should map their ICT outsourcing arrangements against the governance and continuity records that the board already approves, and confirm which of those records supervisors will expect to see.
Article 5 of Directive (EU) 2022/2556 adds digital operational resilience to bank resolution planning under the Bank Recovery and Resolution Directive (BRRD). For resolution authorities, this brings the enforceability of ICT contracts into view, along with information on ICT incidents and on the results of resilience testing. A resolution plan that assumes a critical service can be transferred or continued is only credible if the underlying ICT contracts can be enforced in that scenario. Treasury, legal and technology teams should therefore review whether their critical ICT contracts contain termination, transition and data access terms that would hold up under resolution, and whether incident and testing records are organized so they can be provided to the resolution authority quickly.
The CRD and BRRD provisions reach each bank through national law, so the exact form of transposition, the supervisory expectations attached to it and the documents requested may differ between member states. Banks should ask their national competent authority and, for significant institutions, the ECB's joint supervisory team how these changes will be assessed in the next SREP cycle and in resolution planning discussions. They should also confirm with their resolution authority which ICT information it expects in the resolution pack. Getting these answers early allows the bank to decide whether existing governance papers, continuity plans and contract templates need revision before supervisors ask for them.
Common questions banks ask about DORA costs, timing and assessors
Does a bank always need an external tester for threat-led penetration testing?
Not always, but for a significant credit institution the answer is effectively yes. Under Article 26(8) of DORA, entities that use internal testers must contract external testers at least every three tests, and credit institutions classified as significant may use only external testers. A bank that is a G-SII or O-SII, or that is part of one, may also be required to test under the threat-led regime, subject to the authority's assessment of whether testing is justified. Banks outside those groups should confirm with their competent authority whether TLPT applies at all. Where external testers are required, budget for their fees, the scope workshops and the remediation work that follows, not only the test itself.
What actually drives the cost of DORA compliance for a bank?
The main drivers are the size and complexity of the ICT estate, the number of critical or important functions that depend on third-party providers, and how much evidence already exists. Costs fall into internal staff time, external advisory or readiness support, tooling, testing and audit or assessment fees. Some costs are one-time, such as the first register of information, gap analysis and policy drafting. Others recur, including annual testing, incident reporting exercises, contract reviews and provider monitoring. Ask any provider for a written scope that lists deliverables, assumptions about your systems and which items are excluded, because that scope is what makes quotes comparable.
Can an in-house team prepare for DORA readiness without outside help?
Yes, many banks do much of the readiness work internally, especially where security, risk and procurement teams already run mature processes. The work is mostly documentation, mapping existing controls to DORA requirements, updating contracts and building the register of information. The harder parts are usually the gaps: incident classification and reporting workflows that meet short deadlines, testing programmes that cover ICT third parties, and evidence collection across legacy platforms. An in-house team should be honest about whether it has capacity for those gaps while running day-to-day operations. External support is most useful for an independent gap assessment, for specialist testing and for systems work that needs engineers outside the usual team.
How long does DORA readiness take and what does it need from staff?
Duration depends on the starting point, not on a fixed calendar. A bank with a documented ICT risk framework, a current asset inventory and tested incident procedures will move much faster than one that has to build those from scratch. Plan for involvement from risk, information security, IT operations, procurement, legal and business continuity, because DORA touches all of them. Ask for a milestone plan with named owners, dependencies on system changes and the points where management body approval is needed. Be wary of plans that promise completion without showing what each phase produces.
Can a consultant or implementation partner certify that a bank complies with DORA?
No. DORA sets no certification scheme, and no consultant, implementation partner or auditor can certify a bank as DORA compliant in a way that replaces supervision. The bank owns its controls and remains accountable to its competent authority. An implementation partner prepares systems, controls and evidence, while independent auditors or the supervisor assess them. DeployOpen, for example, prepares systems and evidence for compliance assessments but does not issue audit reports, attestations or certifications. The only authority-issued attestation the Regulation provides for concerns a threat-led penetration test meeting the requirements under Article 26(7).
How does the ECB's role differ from the national competent authority for a bank?
For credit institutions classified as significant under the Single Supervisory Mechanism Regulation, the ECB is the competent authority under Article 46(a) of DORA. Less significant banks are supervised by their national competent authority. Incident reporting follows a similar split: a significant bank reports to its national authority, which immediately transmits the report to the ECB. Confirm with your supervisor which classification applies to your group, which contacts handle reporting and whether member state rules require copies to NIS2 authorities or CSIRTs.
Which reporting deadlines move when they fall on a weekend or bank holiday?
Under Delegated Regulation (EU) 2025/301, deadlines that fall on a weekend or bank holiday move to noon on the next working day. The exception applies to initial notifications and intermediate reports from credit institutions, central counterparties, trading venue operators and NIS2 essential or important entities, which do not get that relief. Banks should therefore build weekend and holiday rotas into incident response and confirm the exact timing rules against the regulation and the current EBA operational instructions before relying on them.
How to choose a partner for a bank's DORA readiness
A bank choosing help with DORA readiness should test a prospective partner on four things: whether it understands how credit institutions are supervised and what the technical standards require, whether it will commit its scope in writing, whether it stays independent of any later assessment, and whether the bank keeps the evidence at handover. The cards below set out those checks and the questions to ask before signing.
Supervision and technical standards experience
Ask whether the partner has worked with credit institutions and knows which authority supervises each one. A significant bank reports major incidents to its national competent authority, which passes them to the ECB, so the partner should explain that routing before it designs any reporting workflow. Ask which Commission delegated regulations the partner has mapped to the bank's systems, including the ICT risk management standard and the incident reporting rules. Request a description of that work, not a list of logos.
Work within a written scope
Agree the scope, deliverables and timeline in writing before any work starts. The document should name the entities, systems, ICT services and standards covered, and state what the partner will not do. A bank should be able to tell from the scope which controls the bank owns and which evidence the partner prepares. Fixed-scope agreements make cost changes traceable when the bank adds systems or entities during the project.
Independence from later assessments
The partner that designs or implements controls should not also be the independent assessor the bank later relies on for its own review. Ask whether the partner will take on work that could later be reviewed by the bank's internal audit or an external reviewer, and how it separates those roles. Where the bank plans threat-led penetration testing, check that the testing firm is not the same firm that prepared the systems under test, since the testing rules require external testers for significant credit institutions.
Consultants cannot issue DORA attestations
No consultant or implementation partner can issue a DORA report, attestation or certificate. DORA sets no certification scheme, and the only authority-issued attestation it provides for is the one confirming that a threat-led penetration test met the requirements. The partner prepares systems, controls and evidence, the bank owns its controls, and the competent authority decides on compliance. Ask any prospective partner to confirm this in its proposal, and be wary of anyone who offers a certificate.
Evidence handover and ownership
Specify in the contract which evidence the bank receives at handover: configuration records, runbooks, test reports, the register of information entries, and the policy documents the management body approves. Confirm that the bank holds the source configurations, access credentials and documentation for self-hosted platforms, so it can run them without the partner. Ask how the evidence will be kept current after handover and who is responsible for each update.
Questions to ask before signing
Ask who on the team will do the work, how the partner handles incident reporting timelines if a live incident occurs during the project, and which parts it will subcontract. Ask for the exit terms, the conditions for ending the engagement, and how the bank's data and systems are handled during and after the work. Compare written answers across at least two candidates before choosing one.
How DeployOpen prepares a bank's systems and evidence for DORA
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the bank's own infrastructure, so the systems and evidence behind DORA controls are in place for the bank's own review. The bank owns its controls and its regulatory relationship, and an independent auditor or assessor is the party that tests and reports on them.
How we scope
- Agree in writing which ICT systems, services and business functions fall inside the DORA engagement before work starts.
- Map the bank's in-scope platforms against the ICT risk management, incident and testing areas the bank has chosen to address.
- Identify which controls the bank owns, which DeployOpen will prepare, and which an independent assessor will test.
- Set deliverables, dependencies and acceptance criteria in a fixed-scope document with a quote derived from that scope.
How we build
- Deploy and configure self-hosted open-source platforms in the bank's own cloud accounts, data centers or air-gapped networks.
- Integrate logging, access control and monitoring so that events needed for incident classification and reporting are captured.
- Harden systems, document configurations and keep backup and recovery settings consistent with the bank's continuity plans.
- Run security and resilience testing on the built environment and track remediation of findings to closure.
How we hand over
- Deliver configuration baselines, architecture records, runbooks and the evidence set that maps to each in-scope control.
- Provide the bank's staff with documented procedures so the bank can operate, review and update the platforms after handover.
- Document the testing performed, the findings and the remediation status in a form the bank can give to its auditor.
- Confirm with the bank's compliance and risk owners which records they will keep and where they will be stored.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the initial engagement.
- Update evidence and documentation when platforms change, so records stay aligned with the systems in production.
- Support the bank's responses to supervisory questions by supplying the technical records it requests, while the bank leads the regulatory dialogue.
- Ask your auditor or competent authority which evidence formats and review cycles they expect before finalizing the handover.
