DORA compliance checklist requirements became urgent for US financial firms when the European Supervisory Authorities designated 19 ICT service providers as critical third-party providers in November 2025, including AWS, Microsoft Azure, and Google Cloud, sending ripple effects well beyond Brussels.
In New York, Chicago, and San Francisco, risk managers at US banks, broker-dealers, and insurance groups found themselves fielding urgent calls from European counterparts asking for evidence of operational resilience controls that most US firms had never been asked to produce before. The Digital Operational Resilience Act was no longer a European problem.
DORA (Regulation EU 2022/2554), the regulation behind every DORA compliance checklist, establishes uniform requirements for ICT risk management, incident reporting, digital operational resilience testing, and third-party risk oversight across the entire EU financial sector. It became enforceable on January 17, 2025.
For US financial firms, the extraterritorial reach is unmistakable: any organization providing ICT services to EU-regulated financial entities, operating EU subsidiaries, or processing data for EU counterparts falls within scope.
According to Deloitte, only 50% of institutions expected full compliance by end of 2025, and 38% are targeting 2026, creating a live DORA compliance checklist gap that regulators are watching closely.
| What You Will Learn |
| DORA became enforceable on January 17, 2025, and applies to US financial firms with EU operations, clients, or ICT service agreements serving EU-regulated entities. |
| Only 50% of financial institutions expected full compliance by end of 2025; 38% are targeting 2026, making this a live compliance gap for US firms right now. |
| The five pillars of DORA (ICT risk management, incident reporting, resilience testing, third-party oversight, and information sharing) map closely to ISO 27001 and NIST CSF 2.0, giving US firms a head start if they already hold those certifications. |
| Penalties reach up to 2% of total annual worldwide turnover for entities and up to EUR 5 million for critical third-party ICT providers, with daily fines possible for up to six months. |
| The Register of Information (ROI) is the single most challenging compliance requirement, cited by 46% of institutions in Deloitte’s survey, and the next annual submission is due in Q1 2026. |
| Threat-Led Penetration Testing (TLPT) must be conducted at least every three years for significant financial entities, with the first cycle due by H2 2026. |
| This checklist provides a 90-day implementation roadmap, framework mapping to ISO 27001 and NIST CSF, and a complete gap analysis template to accelerate your compliance program. |
This guide delivers a practitioner-level DORA compliance checklist tailored for US financial firms. You will find a pillar-by-pillar breakdown, framework mapping to ISO 27001 and NIST CSF 2.0, a 90-day implementation roadmap, and the specific traps that catch organizations that treat DORA as a documentation exercise rather than an operational transformation.
What Is DORA and Why Does It Matter for US Financial Firms?
The Digital Operational Resilience Act is the EU’s first sector-specific regulation mandating end-to-end digital operational resilience for financial services.
Unlike voluntary frameworks, DORA carries binding legal force across 27 member states, plus EEA countries. It covers over 22,000 financial entities and their ICT service providers, including those headquartered outside the EU.
For US firms, the applicability test is straightforward: if your organization provides cloud infrastructure, data analytics, cybersecurity tools, payment processing, or any ICT service to an EU-regulated bank, insurer, investment firm, or fund manager, the DORA compliance checklist applies to you.
This is the same extraterritorial logic that drives GDPR compliance and it is already reshaping vendor contracts across the Atlantic.
DORA’s Five Pillars
The DORA compliance checklist is structured around five pillars that collectively define what digital operational resilience looks like in practice.
Each pillar carries specific requirements, and the enforcement framework treats gaps in any single pillar as a compliance breach. Understanding the pillar structure is essential for mapping your existing ERM framework to DORA requirements.
| Pillar | Core Requirement | US Firm Implication |
| 1. ICT Risk Management | Establish and maintain a comprehensive ICT risk management framework with governance, identification, protection, detection, response, and recovery capabilities | Map to existing NIST CSF 2.0 or ISO 27001 ISMS; identify gaps in ICT-specific governance and board reporting |
| 2. Incident Reporting | Classify, report, and notify competent authorities of major ICT-related incidents within prescribed timelines | Build or adapt incident response playbooks with EU reporting timelines (initial notification within 4 hours of classification) |
| 3. Resilience Testing | Conduct regular testing including TLPT at least every 3 years for significant entities | Extend existing penetration testing programs to include threat-led scenarios targeting critical financial services functions |
| 4. Third-Party Risk | Maintain a Register of Information on all ICT third-party arrangements; conduct due diligence and ongoing monitoring | Inventory all ICT vendor relationships; contractual amendments for subcontracting transparency and exit strategies |
| 5. Information Sharing | Participate in voluntary cyber threat intelligence sharing arrangements with other financial entities | Join FS-ISAC or equivalent information sharing communities; establish protocols for receiving and acting on threat intelligence |
Financial Sector Compliance Readiness by Pillar
Figure 1: Estimated compliance readiness across DORA’s five pillars. Resilience testing and third-party risk management show the largest gaps. Source: Industry survey data, 2025-2026.
DORA Scope: Which US Financial Firms Are Affected?
DORA’s scope is deliberately broad. It covers 21 categories of financial entities, from credit institutions and investment firms to crypto-asset service providers and crowdfunding platforms.
For US firms, the critical question is not whether you are an EU financial entity, but whether you are an ICT third-party service provider to one.
| Entity Type | DORA Applicability | Example US Scenario |
| US bank with EU subsidiary | Directly in scope for the EU subsidiary; parent must ensure group-wide ICT risk governance | JPMorgan Chase’s EU operations must comply; group ICT risk framework must cover DORA requirements |
| US cloud provider serving EU banks | Subject to Critical Third-Party Provider (CTPP) oversight if designated by ESAs | AWS, Azure, Google Cloud designated as CTPPs in November 2025; face direct ESA supervision |
| US fintech with EU clients | In scope as ICT third-party provider; must meet contractual DORA requirements | US payment processor serving EU neobanks must provide audit rights, exit plans, and resilience evidence |
| US insurer with EU reinsurance | EU reinsurance subsidiary directly in scope; group risk management implications | Must demonstrate ICT resilience across reinsurance chain including cross-border data flows |
| US asset manager with EU fund | EU-registered fund entity in scope; US manager must support ICT compliance | Must provide Register of Information data for ICT arrangements supporting EU fund operations |
The extraterritorial reach extends further through the CTPP designation framework. Once an ICT provider is designated as critical, it faces direct oversight by a Lead Overseer (one of the three European Supervisory Authorities), including the power to conduct inspections, issue recommendations, and levy penalties up to EUR 5 million. For US technology firms, this represents a fundamentally new regulatory relationship with
European authorities. Your existing third-party risk management program needs to work in both directions: you are both a consumer and a provider of ICT services under DORA.
The Complete DORA Compliance Checklist for US Financial Firms
This DORA compliance checklist translates DORA’s requirements into actionable steps for US-based organizations. Each item maps to a specific DORA article and identifies the evidence required to demonstrate compliance.
Treat this as a risk assessment tool: score each item as Compliant, Partially Compliant, or Non-Compliant to establish your baseline.
Pillar 1: ICT Risk Management Framework
| Checklist Item | DORA Reference | Evidence Required |
| Board-approved ICT risk management framework documented and reviewed annually | Art. 6(1) | Board minutes, framework document, review schedule |
| Dedicated ICT risk management function with clear mandate and reporting lines | Art. 6(4) | Organizational chart, role descriptions, RACI matrix |
| ICT asset inventory maintained and classified by criticality | Art. 8(1) | Asset register, classification methodology, update logs |
| Business impact analysis covering all ICT-supported critical functions | Art. 11(1) | BIA reports, RTO/RPO definitions, dependency maps |
| ICT risk appetite defined and linked to enterprise risk appetite statement | Art. 6(8) | Risk appetite statement, threshold definitions, escalation rules |
| Incident detection and monitoring capabilities deployed and tested | Art. 10 | SIEM configuration, alert rules, detection test results |
| Backup and recovery procedures documented and tested | Art. 12 | Backup policy, recovery test results, data integrity checks |
This section of the DORA compliance checklist requires that the ICT risk management framework be comprehensive enough to satisfy European regulators while integrating with your existing US regulatory obligations.
Organizations already certified to ISO 27001 or aligned to NIST CSF 2.0 will find that roughly 70-80% of Pillar 1 requirements are already addressed.
The gaps typically appear in DORA’s specific requirements around board-level ICT governance, mandatory annual framework reviews, and the granularity of business impact analysis for ICT-supported functions.
Pillar 2: ICT Incident Reporting
| Checklist Item | DORA Reference | Evidence Required |
| Incident classification methodology aligned to DORA criteria (clients affected, duration, geographic spread, data losses, criticality) | Art. 18 | Classification matrix, scoring methodology |
| Major incident notification process: initial report within 4 hours, intermediate within 72 hours, final within 1 month | Art. 19 | Incident response playbook, notification templates, escalation procedures |
| Incident register maintained with root cause analysis for all ICT incidents | Art. 17 | Incident log, RCA reports, trend analysis |
| Voluntary significant cyber threat notification process established | Art. 19(2) | Threat notification policy, reporting templates |
Pillar 3: Digital Operational Resilience Testing
| Checklist Item | DORA Reference | Evidence Required |
| Annual ICT testing program covering vulnerability assessments, network security, gap analysis, and source code reviews | Art. 25 | Testing plan, test results, remediation tracking |
| Threat-Led Penetration Testing (TLPT) conducted every 3 years for significant entities | Art. 26 | TLPT scope, methodology, results, remediation plan |
| Testing covers all critical ICT systems and applications supporting critical functions | Art. 25(1) | Critical systems inventory, testing coverage matrix |
| TLPT conducted by qualified independent testers with no conflicts of interest | Art. 27 | Tester qualifications, independence declarations |
TLPT is the most operationally demanding item on any DORA compliance checklist. It goes beyond standard penetration testing by requiring threat-intelligence-led scenarios that simulate real-world advanced persistent threats targeting your specific financial services functions.
The first TLPT cycle for significant entities is expected by H2 2026. If your organization has not yet scoped a TLPT engagement, this should be your highest-priority workstream. Link this to your IT risk management process to ensure findings feed back into your control environment.
Top Compliance Challenges Across the Financial Sector
Figure 2: Deloitte Wave 3 survey data showing the Register of Information as the single most challenging DORA compliance requirement for financial institutions.
Pillar 4: Third-Party ICT Risk Management
| Checklist Item | DORA Reference | Evidence Required |
| Register of Information (ROI) maintained for all ICT third-party service arrangements | Art. 28(3) | ROI database, data quality procedures, submission records |
| Pre-contractual due diligence on ICT providers covering security, resilience, and exit strategies | Art. 28(4) | Due diligence methodology, assessment reports |
| Mandatory contractual provisions in all ICT service agreements (audit rights, SLAs, exit plans, subcontracting transparency) | Art. 30 | Contract templates, clause library, compliance tracker |
| Concentration risk assessment for critical ICT service providers | Art. 29 | Concentration analysis, alternative provider assessment |
| Exit strategies for critical ICT service providers documented and tested | Art. 28(8) | Exit plans, transition procedures, testing evidence |
The Register of Information deserves special attention. this DORA compliance checklist item requires financial entities to maintain a complete, accurate, and up-to-date register of all ICT third-party arrangements, not just the critical ones.
The first submission deadline was April 30, 2025, and regulators are already flagging data quality issues for the next annual cycle in Q1 2026.
According to Deloitte, 46% of institutions cite the ROI as their most challenging compliance requirement. This is where your risk register methodology meets regulatory reporting, and the quality bar is high.
Pillar 5: Information Sharing
| Checklist Item | DORA Reference | Evidence Required |
| Participation in voluntary cyber threat intelligence sharing arrangements | Art. 45 | FS-ISAC membership, sharing protocols, participation records |
| Internal processes for receiving, analyzing, and acting on shared threat intelligence | Art. 45(2) | Threat intelligence procedures, integration with SIEM/SOC |
| Data protection safeguards for shared information | Art. 45(3) | Data handling procedures, classification rules |
Mapping DORA to ISO 27001 and NIST CSF 2.0
US financial firms rarely start from zero. Most organizations operating under SEC, OCC, or NYDFS oversight already maintain some combination of ISO 27001, NIST CSF, SOC 2, and industry-specific controls.
The strategic question is how much of the DORA compliance checklist can be addressed through existing frameworks and where the net-new requirements sit. Organizations with mature GRC frameworks will find significant overlap.
Control Domain Coverage: DORA vs ISO 27001 vs NIST CSF 2.0
Figure 3: DORA provides deeper coverage in risk governance and third-party oversight, while ISO 27001 leads in asset management and access control. Organizations holding both certifications cover approximately 85-90% of DORA requirements.
| DORA Requirement | ISO 27001 Mapping | NIST CSF 2.0 Mapping | Gap for US Firms |
| ICT risk management framework (Art. 6) | A.5 Information security policies; A.8 Asset management | GV.RM Risk Management Strategy; ID.AM Asset Management | DORA requires board-level ICT governance and annual review; ISO/NIST do not mandate board involvement |
| Incident classification and reporting (Art. 17-19) | A.5.24-28 Incident management; A.6.8 Reporting | RS.AN Analysis; RS.CO Communications | DORA mandates specific timelines (4hr/72hr/1mo) and regulatory notification; ISO/NIST are less prescriptive |
| TLPT and resilience testing (Art. 25-27) | A.8.8 Vulnerability management; A.8.34 Penetration testing | PR.PT Protective Technology; DE.CM Monitoring | DORA requires TLPT with independent testers and threat-intelligence-driven scenarios; ISO/NIST allow self-assessment |
| Register of Information (Art. 28) | A.5.19-22 Supplier relationships | GV.SC Supply Chain Risk Management | DORA requires granular register with specific data fields; ISO/NIST address supplier risk at a higher level |
| Concentration risk (Art. 29) | Not explicitly addressed | GV.SC-07 Supply chain risk monitoring | Unique to DORA; requires analysis of dependency on specific ICT providers and substitutability assessment |
| Exit strategies (Art. 28(8)) | A.5.20 ICT supply chain provisions | Not explicitly addressed | DORA mandates documented and tested exit plans for critical ICT providers; neither ISO nor NIST requires testing |
DORA Penalties and Enforcement: What Is at Stake?
Understanding the penalties behind every DORA compliance checklist item is essential, as DORA’s enforcement framework carries real financial consequences. Unlike advisory frameworks, DORA empowers EU national competent authorities (NCAs) and the ESAs to impose penalties that scale with organizational size and the severity of the breach.
Understanding the penalty structure is essential for building the business case for compliance investment and for calibrating your risk appetite statement around regulatory risk.
| Violation Category | Maximum Penalty | Additional Consequences |
| Financial entity: failure in ICT risk management | Up to 2% of total annual worldwide turnover | Public disclosure of breach; suspension of ICT service agreements |
| Financial entity: failure to report major incidents | Up to 2% of total annual worldwide turnover | Increased supervisory scrutiny; remediation orders |
| Critical third-party ICT provider: non-compliance | Up to EUR 5 million (entity) / EUR 500,000 (individual) | Daily periodic penalty payments for up to 6 months at 1% of average daily worldwide turnover |
| Individual accountability: senior management failures | Up to EUR 1 million per individual | Personal liability for board members and ICT risk officers |
The daily penalty mechanism for CTPPs is particularly aggressive. A large US cloud provider facing daily fines of 1% of average daily worldwide turnover could accumulate significant exposure over a six-month enforcement period.
This is the mechanism designed to compel rapid remediation, and it means non-compliance is not a sustainable position. The reputational dimension is equally significant: public disclosure of DORA breaches can trigger client attrition across EU markets.
DORA Compliance Timeline: Key Milestones
Figure 4: Critical DORA compliance milestones from initial entry into force through the first TLPT cycle deadline in H2 2026.
The DORA compliance checklist timeline above shows that DORA is not a future obligation. It is a current enforcement reality. The January 2025 enforcement date has passed, the first ROI submissions have been collected, and CTPPs have been designated.
US firms that have not yet begun their DORA compliance checklist programs are already operating in a gap. The next major milestone, the annual ROI submission in Q1 2026, is imminent, and the TLPT cycle will follow in H2 2026.
Practical Steps: Building Your DORA Compliance Program
A successful DORA compliance checklist implementation program for US firms requires three workstreams running in parallel: governance and gap assessment, operational buildout, and vendor management transformation.
Each workstream maps to specific DORA pillars and produces tangible deliverables that regulators can verify. The approach should integrate with your existing risk management process rather than creating a parallel compliance silo.
Step 1: Conduct a DORA Gap Assessment
Use this DORA compliance checklist to score every requirement as Compliant, Partially Compliant, or Non-Compliant. Map your existing ISO 27001, NIST CSF, and SOC 2 controls to DORA articles. The resulting gap analysis becomes the foundation for your remediation plan and your investment case.
Focus on the areas where DORA requirements exceed your current framework coverage, particularly the ROI, TLPT, and concentration risk requirements. Align this to your RCSA process for maximum efficiency.
Step 2: Establish DORA Governance
This DORA compliance checklist item under Article 6 requires that the management body (board or equivalent) approves, oversees, and is accountable for the ICT risk management framework. For US firms with EU subsidiaries, this means the EU entity’s board must demonstrate active engagement, not just delegation.
Assign a DORA compliance owner, establish a cross-functional steering committee (risk, IT, legal, procurement, operations), and define reporting lines to the board. This governance structure should sit within your three lines model with first-line operational ownership, second-line oversight, and third-line assurance.
Step 3: Build Your Register of Information
The ROI is the most data-intensive item on the DORA compliance checklist. It requires granular data on every ICT third-party arrangement: service descriptions, provider details, subcontracting chains, criticality assessments, and contractual terms. Start by inventorying all ICT vendor relationships, then classify each by criticality using a risk assessment matrix.
The data quality bar is high. Regulators flagged significant quality issues in the first ROI submission cycle, and the Q1 2026 submission will face greater scrutiny.
Step 4: Enhance Incident Reporting Capabilities
The incident reporting section of the DORA compliance checklist has tight timelines: initial notification within 4 hours of classifying an incident as major, intermediate report within 72 hours, and final report within one month.
Map your current incident management playbooks against these timelines and identify where you need faster classification, tighter escalation, or automated reporting capabilities.
The classification criteria (clients affected, transaction impact, duration, geographic spread, data losses) must be embedded in your SOC workflows.
90-Day DORA Implementation Roadmap
This phased roadmap provides a structured approach for US financial firms launching or accelerating their DORA compliance programs. Each phase builds on the previous one, with clear deliverables and success metrics.
| Phase | Actions | Deliverables | Success Metrics |
| Days 1-30: Assess | Conduct DORA gap assessment against all five pillars; inventory ICT vendor relationships; identify regulatory touchpoints with EU subsidiaries/clients; brief board on DORA obligations and risk exposure | Gap assessment report; ICT vendor inventory; board briefing deck; DORA compliance owner appointed | 100% of DORA articles scored for compliance status; all ICT vendors catalogued; board formally acknowledges DORA obligations |
| Days 31-60: Design | Design ROI data architecture and collection process; draft DORA-specific incident response playbooks; develop TLPT scoping document; review and amend ICT vendor contracts for DORA clauses | ROI data model and collection procedures; incident response playbook v1; TLPT scope document; contract amendment templates | ROI data collection piloted with top 10 critical ICT providers; incident classification matrix validated; TLPT vendor shortlist finalized |
| Days 61-90: Execute | Submit ROI (if in deadline window); launch first round of contract amendments; initiate TLPT procurement; implement incident reporting automation; conduct tabletop exercise for major ICT incident | ROI submission; executed contract amendments for top 20 vendors; TLPT engagement letter; automated incident reporting workflow; tabletop exercise report | ROI accepted by competent authority; 80%+ of critical vendor contracts amended; TLPT engagement scheduled; incident report generated within 4-hour SLA in tabletop exercise |
Common DORA Compliance Pitfalls
Organizations that treat the DORA compliance checklist as a documentation exercise rather than an operational transformation consistently fall into predictable traps.
These DORA compliance checklist pitfalls are drawn from practitioner experience across the first year of DORA enforcement and from regulatory feedback on the initial compliance submissions.
| Pitfall | Root Cause | Remedy |
| Treating DORA as an IT project rather than a business risk initiative | CRO and business leadership not engaged; compliance delegated entirely to CISO | Establish board-level governance per Art. 6; make DORA a standing risk committee agenda item; link to enterprise risk appetite |
| Incomplete Register of Information with missing subcontracting data | Vendors unwilling or unable to disclose full subcontracting chains; no contractual leverage | Amend contracts to require subcontracting transparency; use Art. 30 mandatory clauses; escalate non-responsive vendors to concentration risk assessment |
| Confusing standard penetration testing with Threat-Led Penetration Testing | Security teams unfamiliar with TLPT methodology (TIBER-EU framework); budget allocated only for standard pen tests | Engage TLPT-qualified providers; align scope to TIBER-EU; budget separately from standard testing program |
| Mapping DORA to ISO 27001 and declaring compliance without addressing gaps | Over-reliance on existing certifications; failure to identify DORA-specific requirements (ROI, TLPT, concentration risk) | Conduct DORA-specific gap assessment; ISO 27001 covers ~70-80% but the remaining 20-30% contains the hardest requirements |
| Delaying vendor contract amendments until renewal dates | Legal team views DORA clauses as non-urgent; procurement prioritizes cost over compliance | Prioritize critical ICT providers for immediate amendment; Art. 30 clauses are mandatory, not negotiable; establish amendment tracker with escalation |
| No exit strategy for critical cloud providers | Single-cloud architecture with no tested migration path; exit planning seen as theoretical | Document exit procedures per Art. 28(8); test migration of at least one critical workload; maintain multi-cloud or hybrid optionality |
| Incident reporting processes too slow for DORA timelines | SOC classification relies on manual triage; escalation paths unclear for EU regulatory reporting | Automate incident classification using DORA criteria; pre-build notification templates; run quarterly tabletop exercises against 4-hour SLA |
Looking Ahead: DORA in 2026 and Beyond
DORA’s first enforcement year has established the baseline, but the regulatory framework is designed to evolve.
Several developments on the horizon will shape DORA compliance strategy through 2027 and beyond, and US financial firms should be building these into their forward-looking risk assessments.
First, the CTPP oversight framework will expand. The 19 providers designated in November 2025 represent the first wave. As the ESAs refine their designation criteria and gather more data through ROI submissions, additional providers will be designated, potentially including niche US fintech and data analytics providers that currently operate below the radar.
The EBA’s consultation on non-ICT third-party risk management guidelines, launched with an October 2025 deadline, signals a broadening of scope beyond pure technology providers. Organizations should monitor the regulatory risk management landscape closely.
Second, DORA and AI risk governance are converging. The EU AI Act’s risk classification requirements, which began phased implementation in 2025, create overlapping obligations for financial entities using AI in credit decisions, fraud detection, and risk modeling.
The intersection of DORA’s ICT risk management requirements with the AI Act’s transparency and conformity assessment obligations will demand integrated governance frameworks. US firms already navigating AI risk assessment should anticipate a merged compliance workstream.
Third, cross-border regulatory convergence is accelerating. The SEC’s operational resilience expectations, NYDFS 23 NYCRR 500 amendments, and the OCC’s resilience guidance are all moving in the direction DORA has already formalized.
US firms that build DORA-compliant ICT risk management frameworks today will find themselves ahead of domestic regulatory expectations. The investment in business continuity management and digital resilience is not EU-specific; it is becoming a global standard.
Finally, expect enforcement intensity to increase. The first year of any major regulation typically involves supervisory forbearance and guidance. By 2027, NCAs will have the data, processes, and political mandate to pursue enforcement actions against entities that remain materially non-compliant.
The penalty framework, including daily fines for CTPPs, is designed to compel action, and the public disclosure mechanism ensures that enforcement has reputational as well as financial consequences.
Completing this DORA compliance checklist requires deep expertise in ICT risk management, operational resilience, and third-party risk oversight.
At riskpublishing.com, we help financial institutions bridge the gap between regulatory requirements and operational reality. Whether you need a gap assessment, ROI buildout support, or TLPT scoping, our practitioners bring ISO 31000, ISO 22301, and NIST CSF expertise directly to your compliance challenge. Contact us to discuss your DORA compliance roadmap.
References
2. EIOPA. Digital Operational Resilience Act (DORA) Overview
3. IBM. What Is the Digital Operational Resilience Act (DORA)?
4. PwC Malta. Digital Operational Resilience Act (DORA) Compliance
5. Panorays. Is Your DORA Strategy Ready for 2026?
6. Bitsight. Prepare Your DORA Compliance Strategy for 2026
7. FS-ISAC. DORA Implementation Guidance
8. Skadden. The EU’s Digital Operational Resilience Act (DORA) – 2024 Update
10. Aprio. DORA Compliance and ISO 27001 Alignment
11. Thomas Murray. DORA Register of Information: 2026 Outlook and Guidance
12. BOC Group. DORA Compliance Penalties: What Financial Institutions Must Know
13. Numerix. What the DORA Regulation Means for Financial Institutions in 2025
14. ISO. ISO/IEC 27001:2022 Information Security Management Systems
15. NIST. Cybersecurity Framework (CSF) 2.0
Chris Ekai is a Risk Management expert with over 10 years of experience in the field. He has a Master’s(MSc) degree in Risk Management from University of Portsmouth and is a CPA and Finance professional. He currently works as a Content Manager at Risk Publishing, writing about Enterprise Risk Management, Business Continuity Management and Project Management.