Michael Bergman, CISSP, CCSP explains how he approached achieving and maintaining compliance with the Digital Operational Resilience Act by incorporating it into the organization’s existing risk management framework.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
When the Digital Operational Resilience Act (DORA) landed, we saw the same challenge encountered before with other regulatory frameworks, where compliance, audit and risk management were being treated as separate exercises. Having spent years dealing with ICT risk management, we knew that addressing DORA in separate compliance and IT risk silos would create inefficiencies and unnecessary administrative burdens. The first line of defence (1LoD) was often getting caught in an endless loop of duplicate compliance and risk control assessments, conflicting reporting lines and a general sense of compliance fatigue.
We decided to take a different approach – one that didn’t just tick regulatory boxes but, instead, helps strengthen our organization’s digital resilience in a meaningful way. Rather than treat DORA compliance as a standalone effort, we have embedded it within our existing ICT risk management framework. Here’s what we did.
DORA At the Heart of ICT Risk Management
We created a DORA-based internal control framework and used it as mitigation measures to treat ICT risks and assurance evidence to inform internal and external audits.
By taking this approach, DORA compliance became a meaningful exercise in risk reduction, strengthening our overall digital resilience rather than just focusing on compliance and avoiding regulatory fines.
Breaking Down DORA Into Actionable Components
One of the first things we noticed when reviewing DORA was the breadth and complexity of the paragraph wording. Many paragraphs contained multiple obligations, making it difficult to measure compliance or assign accountability. To make it manageable, we broke down each paragraph of the regulation into specific digital resilience objectives, each tied to actionable and measurable compliance statements. This ensured that we had a well-understood, measurable and actionable set of compliance statements that could be embedded into our existing risk management processes.
To speed up the process, we experimented with a pre-trained transformer (GPT) prompt using Generative AI (Gen AI). This helped to break down DORA's regulatory language into a structured hierarchy of paragraphs, digital resilience objectives, and compliance statements.
Assigning Ownership and Accountability
A major hurdle with DORA is that its requirements don’t map naturally to a single function or team; some cut across risk, vulnerability, asset, and incident management functions. This often leads to confusion about who is responsible for compliance with the paragraph, resulting in fragmented and ineffective compliance efforts.
To fix this, we linked each digital resilience goal and compliance statement to the most appropriate ICT capability so that it could be assigned to the right person. This ensured that each team knew exactly what was expected of it.
Integrate DORA Compliance into Risk Management
Many compliance efforts struggle because they focus solely on meeting regulatory obligations, rather than addressing actual risks. We wanted to avoid this trap so, instead of treating DORA compliance as a separate checklist, we integrated it into our risk management process.
This alignment had a significant impact on efficiency. Instead of running separate control assessments for regulatory compliance and risk management, we could assess the DORA compliance statements once and apply the results to both compliance and IT risk obligations. This streamlined reporting and reduced duplication, freeing up the 1LoD to focus on high-impact activities like vulnerability management and third-party risk assessments.
This integration required a three-step process. First: we defined the risks that threaten the achievement of our digital resilience objectives. Second: we mapped our existing risk management controls to these risks as treatment measures. Finally: we mapped the DORA compliance statements to the risk management controls.
By taking this approach, compliance became a meaningful exercise in risk reduction in which our DORA compliance efforts weren’t just about avoiding fines but about strengthening our overall security posture.
For each digital resilience objective, we asked: What risks threaten the achievement of this objective? Helping us generate a list of potential ICT risks that could prevent us from achieving our digital resilience objectives. Then we evaluated these risks, prioritizing them based on their potential impact across financial, operational, regulatory and reputational dimensions.
With the help of the second line of defense, we selected controls from our existing risk management control that would treat the identified risk to within our tolerance.
One of the biggest wins from this process was the realization that we didn’t need to reinvent the wheel. Most of DORA’s requirements already aligned with existing risk frameworks like NIST CSF, ISO 27001 and IT General Controls. By mapping compliance statements to these frameworks, we were able to integrate DORA into our existing controls rather than creating a new standalone DORA compliance framework.
Risk-Driven DORA Compliance
To realize the benefit of this approach, we addressed the risks identified to drive DORA compliance based on our ICT risk priorities. Doing so has ensured that our efforts are focused on strengthening our digital resilience rather than just our compliance with regulation and avoiding fines.
We addressed the risk by conducting a control self-assessment (CSA) across the compliance statements previously mapped to it. The CSA documented the implementation status of the compliance statements, alongside its review findings and the evidence supporting it.
Performing the CSA provided a clear understanding of the overall degree of compliance with DORA. Through the structured hierarchy of paragraphs, digital resilience objectives and compliance statements, the CSA results are attributed to the ICT risk management effort, providing an up-to-date view of our overall risk profile.
Emphasizing the importance of continuous evaluation, we established an ongoing CSA cycle to ensure that our controls remained effective and that we stayed ahead of evolving threats.
Overall, our approach has significantly reduced the 1LoD workload by creating a dynamic risk management framework that ensures real-time updates to our risk profile, in response to changes in compliance status. I recommend this approach to anyone in a similar situation.
Michael Bergman, CISSP, CCSP, has 10 years of experience in the security, audit and GRC domains. Michael has held both management and technical roles, with responsibility for ensuring that the implementation of their strategic policies have the minimum impact on operational efficiency.
Related Insights