Navigating DORA: A CTO's Guide to Digital Operational Resilience in Finance

Here's how we see the core principles of DORA and what they mean for CTOs.

The Digital Operational Resilience Act (DORA) (official reference) is setting a new standard for the financial sector, and as CTOs, we're on the front lines. We need to be ready to not just comply, but to truly elevate our resilience. InfraFIDA has been digging deep into DORA's requirements, and we're sharing our insights to help technology leaders implement these changes effectively. This isn't just about ticking boxes on a compliance checklist; it's about building stronger, more resilient systems that can withstand the real-world challenges we face every single day.

Here's how we see the core principles of DORA and what they mean for CTOs, complete with the kinds of scenarios that keep us up at night.

ICT Risk Management: Building a Solid Foundation

DORA puts a strong emphasis on a comprehensive ICT risk management framework. This is the bedrock upon which everything else is built. But let's be honest, "comprehensive" can feel overwhelming when you're dealing with legacy systems, evolving threats, and limited resources.

What DORA wants: A documented framework that includes identifying, assessing, mitigating, and monitoring ICT risks. It needs to be reviewed regularly and approved at the board level.

The CTO's role (and the headaches it brings):

Implement tools and processes for continuous risk assessment. Think beyond basic vulnerability scanning. Are you incorporating threat modeling to anticipate new attack vectors? How are you dealing with the constant stream of zero-day exploits that seem to appear out of nowhere?
Ensure the framework is integrated into the overall business strategy and risk appetite. This means translating technical risks into business impacts that the board can understand. Are you able to articulate the potential financial losses from a ransomware attack in a way that resonates with your CFO?
Foster a culture of security awareness across the organization. This goes beyond mandatory annual training. How are you ensuring that your developers are coding securely? Are your employees actually spotting phishing attempts, or are they just clicking through to get back to their work? Phishing is becoming increasingly complex and sophisticated, and even the best employees can make mistakes, especially when they are overwhelmed or under pressure. Make sure your employees are not only aware, but are trained in how to recognize and react to phishing attempts.
Make sure your risk management plans cover all your ICT systems and are regularly tested. "All" is the key word here. Do you have shadow IT lurking in some departments? What about that one legacy system that no one understands but everyone relies on? How are you handling end-of-support software that your vendors can't or won't patch? Are you including in your risk assessment systems which you previously considered to be of a low risk? The nature of DORA risk management is such that all systems should be included, not only those that are considered high risk.
Real-world example: Imagine discovering a critical vulnerability in a core banking system that's been running for a decade. The vendor is slow to respond with a patch, and you're left scrambling to implement mitigating controls while facing pressure to maintain uptime. This is the kind of situation DORA aims to prevent through proactive risk management.

ICT Third-Party Risk Management: Extending Your Defenses

DORA recognizes that financial institutions rely heavily on third-party technology providers. Managing this risk is crucial, but it's like herding cats. You're responsible for the security of systems you don't directly control.

What DORA wants: Clear policies for managing third-party risk, including due diligence, ongoing monitoring, and exit strategies for vendors. Key contractual provisions are defined in the regulation.

The CTO's role (and the vendor nightmares):

Establish a robust vendor risk assessment process. This isn't just about checking boxes on a questionnaire. Are you actually evaluating the vendor's security posture, or are you relying on their self-assessment? How are you assessing the risk of your vendors' subcontractors (your fourth parties)?
Ensure contracts with ICT providers have strong security clauses and clear reporting requirements. Think your standard contracts are enough? DORA requires specific language around audits, incident reporting, and even termination rights. Have you updated your contract templates and are your legal and procurement teams aligned? DORA even sets out specific requirements for contracts with vendors, so make sure your templates meet these requirements.
Implement systems for continuous monitoring of vendor performance and security. Are you relying solely on annual audits, or do you have real-time visibility into your vendors' security posture? How are you monitoring their compliance with your SLAs, especially during incidents? Think about those cloud provider outages that have taken down major services. Do you have a plan for when your primary cloud provider goes dark?
Develop and document exit strategies for critical vendors. Make sure these plans are tested. How easy is it to actually switch providers if one of them has a critical issue or is compromised? How long would it take you to transfer your data to a new provider?
Real-world example: Your cloud provider suffers a major breach, exposing sensitive customer data. Are your contracts and processes up to the challenge of ensuring business continuity, even while the vendor is handling the incident? Do you have backups ready to go in a different environment? DORA expects you to have planned for this, including having robust, tested exit strategies.

Digital Operational Resilience Testing: Proving Your Readiness

DORA requires regular testing to ensure your systems can withstand disruptions. This includes basic and, for some organizations, advanced threat-led penetration testing. But testing can be disruptive, and finding the right balance between thoroughness and business continuity is a constant struggle.

What DORA wants: Regular testing of ICT systems and applications, including vulnerability assessments, scenario-based tests, and threat-led penetration testing where required.

The CTO's role (and the testing tightrope):

Develop a comprehensive testing program that covers a range of scenarios. Are you just testing for the most obvious threats, or are you thinking like an attacker? Are you prepared for multi-stage attacks that combine different vulnerabilities? Are you testing for insider threats? How are you simulating the chaos of a real-world incident, including communication breakdowns and decision-making under pressure?
Ensure testing results are actually used to improve your systems and processes. It's easy to get a report and file it away. Are you tracking remediation efforts? Are you seeing a reduction in vulnerabilities over time? How are you prioritizing fixes based on the actual risk they pose to the business?
Oversee the implementation of advanced, threat-led penetration testing if your organization falls into that category. This is a significant undertaking. Do you have the in-house expertise, or will you need to bring in external specialists? How are you ensuring that the testing is realistic but doesn't disrupt your live operations?
Real-world example: You conduct a simulated phishing campaign, and a significant percentage of your employees fall for it. This is a wake-up call. Do you have the training and awareness programs in place to address this vulnerability? DORA requires you to demonstrate that you're learning from these exercises.

ICT-Related Incident Management: Responding Effectively

No matter how well you prepare, incidents will happen. DORA sets out requirements for managing and reporting them, but real-world incidents are messy and unpredictable.

What DORA wants: Processes for detecting, managing, and reporting ICT-related incidents. Major incidents must be reported to competent authorities within specific timeframes.

The CTO's role (and the incident response scramble):

Implement systems for early incident detection and alerting. Think beyond traditional SIEM. Are you using advanced threat intelligence and anomaly detection to spot the early signs of an attack? Are your alerts tuned to avoid alert fatigue, or are your analysts drowning in false positives? Are your alerts reaching the right people at the right time, or are they getting lost in the noise?
Develop and maintain clear incident response plans, ensuring they are regularly tested. Does everyone know their role during an incident? Are your plans up-to-date and reflective of your current infrastructure and threat landscape? How are you coordinating with external parties, such as law enforcement and your incident response vendor?
Establish procedures for reporting major incidents to the relevant authorities. Do you know the reporting requirements and deadlines for different types of incidents? DORA sets out very clear deadlines, so ensure you are aware of them. How are you ensuring that you're providing accurate and timely information?
Ensure root cause analysis is performed after any major incident. This is critical for preventing future incidents. Are you able to identify the underlying causes, or are you just patching the symptoms? How are you sharing the lessons learned with the rest of the organization?
Real-world example: You discover that a threat actor has been lurking in your network for weeks, exfiltrating data. Your incident response plan is put to the test. Are you able to contain the breach quickly? Can you identify the scope of the compromise and determine what data was stolen? DORA expects you to be able to answer these questions and report your findings to the authorities.

Information Sharing: Strengthening the Collective Defense

DORA encourages financial entities to share information about cyber threats and vulnerabilities. This is a great idea in principle, but in practice, it can be challenging to share sensitive information without violating confidentiality or competitive concerns.

What DORA wants: Voluntary arrangements for exchanging cyber threat intelligence and information.

The CTO's role (and the information sharing tightrope):

Make sure that your company is aware of the threat sharing system and monitors the published threats. Is your security team actively participating in information sharing communities? Are you monitoring relevant threat feeds and integrating that intelligence into your security operations?
Figure out how and where will you report your own discovered threats. Are you prepared to share information about vulnerabilities you discover, even if it could potentially impact your reputation? How are you balancing the need for transparency with the need to protect your organization and your customers?
Real-world example: You discover a new malware variant targeting financial institutions. Do you share this information with your peers, even if it means potentially alerting the attackers that their malware has been discovered? DORA encourages this kind of sharing, but it requires careful consideration of the risks and benefits.

Oversight of Critical Third-Party Providers: A New Level of Scrutiny

DORA introduces an oversight framework for critical ICT third-party providers, which will be directly supervised by designated authorities. This adds another layer of complexity to vendor management, and it could have significant implications for both financial institutions and their providers.

What DORA wants: Direct oversight of critical providers by designated EU authorities, with powers to request information, conduct inspections, and issue recommendations.

The CTO's role (and the new world of oversight):

Understand if any of your vendors fall under this category. This requires a thorough assessment of your vendor ecosystem. Are you prepared to answer questions about the criticality of each vendor and the potential impact of their failure on your operations?
If you are a provider, prepare for increased scrutiny and potential audits. Are your security controls and processes documented and auditable? Can you demonstrate that you're meeting DORA's requirements?
Ensure your organization is ready to cooperate with oversight authorities if needed. This could involve providing access to your systems and data. Are you prepared for the potential resource implications of these requests?
Real-world example: One of your key vendors is designated as a critical provider. You now face increased scrutiny of your relationship with that vendor, including potential audits and requests for information. Are you prepared to demonstrate that you're effectively managing the risks associated with that vendor?

InfraFIDA's Perspective: Making DORA Work for You

DORA is more than a regulation; it's a call to action. It's a call to elevate our cybersecurity posture, strengthen our operational resilience, and fortify the financial ecosystem against emerging threats. InfraFIDA is your trusted partner on this journey. Let's embrace the challenge and build a more secure future, together.