DORA 2026 Roadmap for ICT Risk, Suppliers and TLPT

The DORA 2026 search panic is not really about regulation, it is about evidence

It is 08:15 on a Monday and the CISO of a mid-sized payments institution has three browser tabs open: “DORA RTS/ITS checklist,” “DORA ICT third-party register template,” and “TLPT requirements financial entities.”

The compliance manager has already asked whether the board pack should include the latest incident classification workflow. Procurement wants to onboard a new cloud analytics platform. The COO wants assurance that the core banking SaaS provider has no hidden subcontractor exposure outside the EU. Internal audit is asking for a testing calendar. Legal is asking whether GDPR breach notification timelines have been aligned with DORA incident reporting.

Nobody is asking a theoretical question. They are asking, “Can we prove this by Friday?”

That is the real DORA 2026 problem. Most financial entities understand the headline obligations: ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management and stronger oversight of critical ICT providers. The hard part is converting Regulatory Technical Standards, Implementing Technical Standards and article-level obligations into controlled, repeatable, auditable practice.

The Digital Operational Resilience Act requires financial entities to maintain robust ICT risk management capabilities, policies for managing and reporting ICT-related incidents, testing of ICT systems, controls and processes, and structured oversight of ICT third-party providers. It also expects proportionality. A smaller investment firm and a large banking group do not need identical evidence models, but both must prove that their approach is suitable for their size, risk profile, complexity and critical functions.

DORA projects usually fail for one of three reasons. First, the organization treats DORA as a legal mapping exercise rather than an operating model. Second, supplier risk is documented as a vendor list rather than as dependency, substitutability and concentration risk. Third, testing is treated as an annual penetration test rather than a resilience program that includes vulnerability scanning, scenario testing, incident exercises and, where applicable, threat-led penetration testing, commonly searched as TLPT.

A better approach is to build one evidence system that connects policies, registers, owners, risks, incidents, suppliers, testing, recovery and management review. That is where Clarysec’s Zenith Blueprint, ready-to-use policies and Zenith Controls help financial entities turn DORA from a deadline into an operating rhythm.

Start with the DORA operating model, not the RTS/ITS spreadsheet

Many teams begin with a spreadsheet listing DORA articles and RTS/ITS requirements. That is useful, but it is not sufficient. A spreadsheet can tell you what must exist. It does not assign owners, define review frequency, preserve evidence, or prove that a control actually works.

In the Zenith Blueprint: An Auditor’s 30-Step Roadmap, Clarysec addresses this in the Risk Management phase, Step 14, Risk Treatment Policies and Regulatory Cross-References:

“DORA: For financial sector firms, DORA requires an ICT risk management framework very much aligned with what we’ve done: identify risks, put controls (and policies) in place, and test them. DORA also stresses on incident response and reporting, and oversight of third-party ICT service providers.”

The practical message is simple: do not build “DORA compliance” as a parallel bureaucracy. Build a risk-based ICT governance layer that maps DORA requirements to policies, registers, control owners, testing records, supplier evidence and management review.

A practical DORA operating model should have five evidence pillars:

For regulated financial entities, this structure turns RTS/ITS implementation into an audit-ready evidence system. For entities under simplified ICT risk management, the same model can be scaled into fewer documents and simpler registers. The core disciplines remain the same: identify, protect, detect, respond, recover, test and govern suppliers.

ICT risk management: the register is the control room

DORA’s ICT risk management expectations require financial entities to identify, classify and manage ICT risks across systems, data, processes, critical or important functions and third-party dependencies.

The common failure is not the absence of a risk register. It is that the register is disconnected from suppliers, assets, incidents and tests. DORA does not reward a beautiful spreadsheet if it cannot explain why a high-risk supplier has no exit plan, or why a critical customer payment platform has not been tested.

Clarysec’s SME Risk Management Policy gives smaller financial entities a concise evidence baseline:

“Each risk entry must include: description, likelihood, impact, score, owner, and treatment plan.”
From section “Governance Requirements”, policy clause 5.1.2.

For larger financial entities, Clarysec’s Enterprise Risk Management Policy requires a more formal process:

“A formal risk management process shall be maintained in accordance with ISO/IEC 27005 and ISO 31000, covering risk identification, analysis, evaluation, treatment, monitoring, and communication.”
From section “Governance Requirements”, policy clause 5.1.

This distinction matters. DORA is proportionate, but proportionality does not mean informal. A small payment firm may use a streamlined register, while a banking group may use integrated GRC tooling. In both cases, the auditor will still ask: What are your ICT risks? Who owns them? What is the treatment plan? What evidence shows progress? How do suppliers and critical functions affect the score?

A strong DORA ICT risk register should include these fields:

A practical exercise is to take one critical ICT service, such as a cloud-hosted transaction monitoring platform, and create a risk entry in 20 minutes. Describe the failure or compromise scenario, score likelihood and impact, assign an owner, identify related suppliers, define a treatment plan and link the entry to evidence such as supplier due diligence, SLA, incident clauses, BIA, DR test results, monitoring dashboards and access reviews.

That single entry becomes the thread connecting DORA ICT risk management, third-party oversight, incident detection, continuity and testing. This is how a risk register becomes a control room, not a filing cabinet.

RTS/ITS readiness: map obligations to policies, not promises

The practical search term “DORA RTS/ITS checklist” usually means “What documents will supervisors expect?” Financial entities should avoid promising compliance through generic statements. They need a mapping that ties each obligation to a policy, control, owner and evidence item.

Clarysec’s SME Legal and Regulatory Compliance Policy establishes a simple governance anchor:

“The GM must maintain a simple, structured Compliance Register listing:”
From section “Governance Requirements”, policy clause 5.1.1.

For DORA 2026, your compliance register should include:

• DORA obligation or RTS/ITS requirement area.
• Applicability, including proportionality rationale.
• Policy or procedure reference.
• Control owner.
• Evidence location.
• Review frequency.
• Open gaps and remediation deadline.
• Board or management reporting status.

This aligns with the Zenith Blueprint Step 14 approach: map regulatory requirements to ISMS controls and policies so nothing falls through the cracks. Instead of asking “Are we DORA compliant?”, leadership can ask “Which DORA evidence items are overdue, which critical suppliers lack exit plans, and which testing activities have not yet produced remediation evidence?”

Third-party ICT risk: concentration, substitutability and subcontractors

DORA has changed the supplier conversation in financial services. It is no longer enough to ask whether a provider has a security certification, insurance or a data processing agreement. Financial entities must evaluate whether a provider creates concentration risk, whether the provider can realistically be replaced, whether multiple critical services depend on one supplier or related suppliers, and whether subcontracting introduces additional legal or resilience exposure.

This is the issue that keeps many CISOs awake. A firm may rely on one major cloud service provider for transaction processing, data analytics, customer portals and internal collaboration. If that provider suffers a prolonged outage, a regulatory dispute, or a subcontractor failure, the question is not just “Do we have a contract?” The question is “Can we continue critical services, communicate with customers, and prove we understood the dependency before it failed?”

Clarysec’s SME Third-Party and Supplier Security Policy sets the foundation:

“A Supplier Register must be maintained and updated by the administrative or procurement contact. It must include:”
From section “Governance Requirements”, policy clause 5.4.

For enterprise programs, Clarysec’s Supplier Dependency Risk Management Policy goes deeper into DORA-specific dependency and substitutability:

“Supplier Dependency Register: The VMO shall maintain an up-to-date register of all critical suppliers, including details such as services/products provided; whether the supplier is sole-source; available alternate suppliers or substitutability; current contract terms; and an assessment of the impact if the supplier were to fail or be compromised. The register shall clearly identify high-dependency suppliers (e.g., those for which no rapid alternative exists).”
From section “Implementation Requirements”, policy clause 6.1.

This is the supplier evidence DORA projects often miss. A supplier register says who the vendor is. A dependency register says what happens when the vendor fails.

The Zenith Blueprint, Controls in Action phase, Step 23, Organizational controls, provides a practical workflow for supplier oversight. It recommends compiling a full supplier list, classifying suppliers based on access to systems, data or operational control, verifying that security expectations are embedded in contracts, managing subcontractor and downstream risk, defining change and monitoring procedures, and creating a cloud service evaluation process.

In Zenith Controls: The Cross-Compliance Guide, ISO/IEC 27002:2022 control 5.21, Managing information security in the ICT supply chain, is mapped as a preventive control supporting confidentiality, integrity and availability. It is associated with supplier relationship security and the Identify cybersecurity concept. It connects to secure engineering, secure coding, access control, security testing, evidence collection, secure development lifecycle and outsourced development.

That is exactly the DORA third-party oversight reality. Supplier risk is not only procurement. It touches architecture, development, incident response, access control, business continuity and legal.

From a cross-compliance perspective, Zenith Controls maps ICT supply chain security to GDPR Articles 28 and 32 because processors and sub-processors must be selected and supervised with appropriate technical and organizational measures. It supports NIS2 supply chain security expectations, including Article 21 cybersecurity risk-management measures and Article 22 coordinated supply chain risk assessments. It maps strongly to DORA Articles 28, 29 and 30, where ICT third-party risk, concentration risk, sub-outsourcing and contractual provisions are central.

Supporting standards strengthen the evidence. ISO/IEC 27036-3:2021 supports ICT procurement and supplier selection security. ISO/IEC 20243:2018 supports trusted technology product integrity and supply chain security. ISO/IEC 27001:2022 connects this into risk treatment and Annex A supplier controls.

Incident reporting: build the escalation chain before the incident

DORA incident reporting is not only about submitting a notification. It is about detecting, classifying, escalating, communicating and learning from ICT-related incidents. Financial entities must maintain processes for ICT incident management and reporting, with defined roles, classification criteria, notification routes and post-incident analysis.

Clarysec’s SME Incident Response Policy connects incident response timelines to legal requirements:

“Response timelines, including data recovery and notification obligations, must be documented and aligned with legal requirements, such as the GDPR 72-hour personal data breach notification requirement.”
From section “Governance Requirements”, policy clause 5.3.2.

For enterprise environments, Clarysec’s Incident Response Policy adds the regulated-data escalation lens:

“If an incident results in confirmed or likely exposure of personal data or other regulated data, Legal and the DPO must assess the applicability of:”
From section “Policy Implementation Requirements”, policy clause 6.4.1.

The quote ends at the trigger point, which is exactly where many incident processes fail. If the trigger is unclear, teams debate notification duties while the clock is already running.

The Zenith Blueprint, Controls in Action phase, Step 16, People Controls II, emphasizes personnel-driven incident reporting. Employees, contractors and stakeholders need to know how to recognize and report potential security incidents using simple channels such as a dedicated mailbox, portal or hotline. The Blueprint links this to GDPR Article 33, NIS2 Article 23 and DORA Article 17 because regulatory reporting starts with internal awareness and escalation.

In Zenith Controls, ISO/IEC 27002:2022 control 5.24, Information security incident management planning and preparation, is mapped as a corrective control supporting confidentiality, integrity and availability, aligned with Respond and Recover. It ties directly to event assessment, learning from incidents, logging and monitoring, security during disruption, information security continuity and contact with authorities. The guide maps this to DORA Articles 17 to 23 for ICT-related incident management, classification, reporting and voluntary cyber threat notification, GDPR Articles 33 and 34 for breach notification, and NIS2 Article 23 incident notification.

A DORA-ready incident process should include:

• Clear incident intake channels.
• Event triage and classification criteria.
• Major ICT-related incident escalation workflow.
• Legal, DPO and regulatory notification decision points.
• Supplier incident notification triggers.
• Evidence preservation requirements.
• Executive and board communication rules.
• Post-incident review and lessons learned.
• Linkage to risk register updates and control remediation.

Supporting standards add structure. ISO/IEC 27035-1:2023 provides planning and preparation principles for incident management. ISO/IEC 27035-2:2023 details incident handling steps. ISO/IEC 22320:2018 supports command, control and structured crisis communication. This matters when an ICT outage becomes a customer-impacting crisis and the entity must show that decisions were timely, coordinated and evidence-based.

Digital operational resilience testing and TLPT: do not let the test become the incident

Testing is one of the most searched DORA 2026 topics because it is both technical and governance-heavy. Financial entities need to test ICT systems, controls and processes. For designated entities, advanced testing such as TLPT becomes a central requirement under DORA Article 26.

The audit question is not only “Did you test?” It is “Was the test risk-based, authorized, safe, independent where required, remediated and linked to resilience objectives?”

Clarysec’s Enterprise Security Testing and Red-Teaming Policy defines the minimum testing program clearly:

“Types of Tests: The security testing programme shall include, at a minimum: (a) vulnerability scanning, consisting of automated weekly or monthly scans of networks and applications to identify known vulnerabilities; (b) penetration testing, consisting of manual in-depth testing of specific systems or applications by skilled testers to identify complex weaknesses; and (c) red-teaming exercises, consisting of scenario-based simulations of real attacks, including social engineering and other tactics, to test the organisation’s detection and response capabilities as a whole.”
From section “Implementation Requirements”, policy clause 6.1.

This is the bridge between routine testing and TLPT maturity. Vulnerability scanning finds known weaknesses. Penetration testing validates exploitability. Red-teaming tests detection and response as a system. TLPT, where applicable, should sit inside a governed testing program with scope control, safety rules, production risk management, evidence capture and remediation tracking.

The Zenith Blueprint, Controls in Action phase, Step 21, addresses protection of information systems during audit and testing. It warns that audits, penetration tests, forensic reviews and operational evaluations can introduce risk because they may involve elevated access, intrusive tools or temporary system behavior changes. The Blueprint maps this concern to GDPR Article 32, DORA digital operational resilience testing expectations, NIS2 continuity concerns and COBIT 2019 practices for safe execution of audits and assessments.

In Zenith Controls, ISO/IEC 27002:2022 control 5.35, Independent review of information security, is mapped as preventive and corrective, supporting confidentiality, integrity and availability. It ties to compliance with policies, management responsibilities, learning from incidents, protection of records, information deletion, logging and monitoring. For DORA, the relevant testing obligations are primarily Articles 24 to 27, including Article 26 for TLPT. This also supports GDPR Article 32(1)(d), which requires regular testing and evaluation of technical and organisational measures, and NIS2 Article 21, which requires cybersecurity risk-management measures.

A DORA TLPT readiness pack should include:

The key DORA lesson is that testing evidence must not stop at the report. Auditors will ask whether findings were risk-rated, assigned, remediated and retested. They may also check whether testing covered critical or important functions, not just internet-facing assets.

Business continuity and disaster recovery: resilience must be operational

DORA is a digital operational resilience regulation. Recovery matters as much as prevention. A documented ICT risk framework will not help if a payment platform outage reveals that recovery time objectives were never tested, supplier contact trees are outdated, and the crisis team cannot agree who communicates with customers.

Clarysec’s SME Business Continuity Policy and Disaster Recovery Policy sets a clear baseline:

“The organization must test both its BCP and DR capabilities at least annually. Tests must include:”
From section “Policy Implementation Requirements”, policy clause 6.4.1.

The Enterprise Business Continuity Policy and Disaster Recovery Policy begins with business impact:

“Business Impact Analysis (BIA) shall be performed at least annually for all critical business units and reviewed upon significant changes to systems, processes, or dependencies. BIA outputs shall define:”
From section “Governance Requirements”, policy clause 5.2.

For DORA, the BIA should be connected to ICT assets, suppliers, incident response and testing. If the BIA identifies “customer payments” as a critical function, the supplier dependency register should identify the processors, cloud services and network providers supporting it. The risk register should include failure scenarios. The testing plan should include resilience validation. The incident response plan should include escalation and communication. The DR test should produce evidence, not just a meeting note.

This traceability is what turns DORA compliance into an operational resilience system.

Cross-compliance: one evidence set, many audit questions

Financial entities rarely face DORA alone. They often have GDPR obligations, NIS2 exposure, contractual security commitments, ISO/IEC 27001:2022 objectives, internal audit requirements, customer due diligence, SOC expectations and board risk reporting. The answer is not to create separate evidence silos. The answer is to build a cross-compliance evidence model.

Zenith Controls is Clarysec’s cross-compliance compass. It does not invent new obligations. It maps official standards and frameworks so organizations can understand how one control area supports several compliance outcomes.

This matters for budget and governance. A CISO can explain to the board that improving incident classification supports DORA reporting, GDPR breach notification, NIS2 incident handling and internal resilience. A procurement leader can justify supplier dependency mapping because it supports DORA concentration risk, GDPR processor due diligence and NIS2 supply chain security. A testing lead can show that red-team exercises and independent reviews support DORA testing, GDPR control evaluation and wider assurance.

Audit lens: how assessors will test your DORA evidence

DORA readiness becomes real when someone asks for evidence. Different auditors and assessors will approach the same topic from different angles.

An ISO/IEC 27001:2022-oriented auditor will start with ISMS logic: scope, risk assessment, risk treatment, Annex A control applicability, internal audit, management review and evidence that controls are implemented. For ICT supply chain security, they will look at policies, supplier classification, contractual clauses, due diligence and ongoing monitoring. For incident management, they will inspect the plan, roles, escalation routes, tools and records. For testing, they will expect planned intervals, independence where appropriate, remediation and management review input.

An ISO/IEC 19011:2018 audit lens focuses on audit execution. In Zenith Controls, the audit methodology for ICT supply chain security notes that auditors examine procurement policies, RFP templates and supplier management processes to verify that ICT-specific security requirements are embedded from acquisition through disposal. For incident management, auditors examine the incident response plan for completeness and alignment with best practices. For independent review, auditors look for evidence that independent audits or reviews have been conducted.

An ISO/IEC 27007:2020 lens is more ISMS-audit specific. Zenith Controls notes that auditors may interview procurement officers, IT security staff and vendor managers to assess understanding and execution of ICT supply chain controls. For incident preparation, they confirm that an Incident Response Team exists and is operational. For independent review, they verify that the internal audit program covers the full ISMS scope and is properly resourced.

A NIST SP 800-115-informed testing assessor will focus on vulnerability assessment and penetration testing methodology. They may examine whether test scope, rules of engagement, findings, severity ratings, remediation and retesting are documented. For DORA TLPT, that means the assessor will not be satisfied with a red-team slide deck. They will want proof of governance, safety, technical depth and closure.

A COBIT 2019 or ISACA-style auditor will ask whether governance objectives are met: who owns the process, how performance is measured, how exceptions are approved, and how management receives assurance.

The practical DORA 2026 readiness checklist

Use this checklist as a working baseline for converting DORA searches into action.

Governance and RTS/ITS mapping

• Maintain a DORA compliance register with obligation area, applicability, owner, evidence, review frequency and gap status.
• Map DORA requirements to policies, registers, controls and management reporting.
• Define proportionality rationale for simplified or scaled ICT risk management where applicable.
• Assign executive accountability for ICT risk, incident reporting, third-party oversight and testing.
• Include DORA status in management review and board risk reporting.

ICT risk management

• Maintain an ICT risk register with description, likelihood, impact, score, owner and treatment plan.
• Link risks to critical or important functions.
• Link risks to ICT assets, suppliers and processes.
• Review risks after major incidents, supplier changes, technology changes or test findings.
• Track treatment actions to closure or formal risk acceptance.

Third-party ICT oversight

• Maintain a supplier register and supplier dependency register.
• Identify suppliers supporting critical or important functions.
• Assess sole-source suppliers and substitutability.
• Review subcontractors and sub-outsourcing arrangements.
• Embed security, access, incident reporting, audit and exit clauses in contracts.
• Monitor critical suppliers at least annually or after material changes.
• Maintain exit and contingency plans for high-dependency providers.

Incident management and reporting

• Maintain incident response procedures with clear roles and escalation routes.
• Define ICT incident classification criteria.
• Align DORA reporting triggers with GDPR, NIS2 and contractual notification obligations.
• Train employees and contractors on incident reporting channels.
• Maintain incident logs, decision records and evidence.
• Conduct post-incident reviews and update risks and controls.

Testing, red-teaming and TLPT

• Maintain a risk-based testing calendar.
• Perform vulnerability scanning and penetration testing at defined intervals.
• Use scenario-based red-team exercises to test detection and response.
• For TLPT readiness, define scope, rules of engagement, safety controls and supplier coordination.
• Protect production systems during testing.
• Track findings, remediation, retesting and lessons learned.
• Report testing outcomes to management.

Continuity and recovery

• Perform annual BIA for critical business units and update after significant changes.
• Define recovery objectives for critical functions and supporting ICT services.
• Test BCP and DR capabilities at least annually.
• Include supplier outage and cyber incident scenarios.
• Preserve test evidence, gaps, remediation actions and retest results.
• Align continuity plans with incident response and crisis communications.

How Clarysec helps financial entities move from search results to audit-ready evidence

DORA 2026 readiness is not achieved by downloading a checklist and hoping the organization can fill the gaps later. It requires a structured operating model that connects risk, suppliers, incidents, testing, continuity and audit evidence.

Clarysec’s approach combines three layers.

First, the Zenith Blueprint provides the implementation roadmap. Step 14 helps organizations cross-reference regulatory requirements to risk treatment and policies. Step 16 strengthens personnel-driven incident reporting. Step 21 ensures audits and tests do not endanger production systems. Step 23 turns supplier oversight into a practical workflow covering classification, contracts, subcontractors, monitoring and cloud evaluation.

Second, Clarysec policies provide ready-to-operationalize governance. The Risk Management Policy, Legal and Regulatory Compliance Policy, Third-Party and Supplier Security Policy, Supplier Dependency Risk Management Policy, Incident Response Policy, Security Testing and Red-Teaming Policy, and Business Continuity Policy and Disaster Recovery Policy give teams concrete clauses, ownership models and evidence expectations.

Third, Zenith Controls provides the cross-compliance map. It shows how ICT supply chain security, incident management planning and independent review connect to DORA, GDPR, NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022, ISO/IEC 27035, ISO/IEC 27036, ISO/IEC 22320, ISO/IEC 20243, COBIT 2019 and NIST testing practices.

The result is a DORA compliance program that is defensible in an audit and useful during a real incident, supplier failure or resilience test.

Next step: build your DORA evidence pack before the next audit request

If your team is still searching for “DORA RTS/ITS checklist,” “DORA ICT risk management template,” “DORA third-party oversight,” or “DORA TLPT requirements,” the next step is to turn those searches into controlled evidence.

Start with four actions this week:

1. Create or update your DORA compliance register using the Clarysec policy model.
2. Select one critical function and trace it through the risk register, supplier dependency register, incident workflow, BIA and testing plan.
3. Review your top five ICT suppliers for substitutability, subcontractors, incident clauses and exit options.
4. Build a testing evidence pack with scope, authorization, results, remediation and retesting.

Clarysec can help you implement this using the Zenith Blueprint, policy templates and Zenith Controls so your DORA 2026 program is practical, proportionate and audit-ready.