The impact of DORA is both broad and in-depth. While some areas may not be entirely new for many organisations, DORA reinforces much of the engineering good practices advocated by industry experts in DevOps and DevSecOps over the years. However, a transformative approach may be required due to the magnitude of potential change.
As with evolving technology-focused regulatory requirements across industries, good cyber security hygiene forms their foundation.
How Control Frameworks (CFs) underpin DORA
Control Frameworks underpin a large part of DORA, from ICT risk management, reporting and testing to governance. Most organisations already leverage a robust Risk and Control Framework along with one or more CFs, varying in complexity based on organisational needs.
Often, all that is required is for the organisation to view these controls through a different lens to focus attention on operational resilience. A solid meta-framework is essential, mapping to necessary Control Frameworks and linking to implementation controls required to meet the necessary control requirements.
Frameworks directly mapping to DORA articles are emerging, such as the Secure Controls Framework, allowing organisations to expand their control assessment processes and assess controls applicable to DORA. This aids internal reporting and regulatory compliance.
Governance
Key to achieving DORA compliance is the understanding that a single team or business function cannot meet the requirements in isolation. Accountability and responsibility for meeting the requisite controls lie with multiple areas of the business. It cannot solely fall on the IT Team, Governance Risk and Compliance (GRC) or senior board members.
Questions organisations can ask include:
“Does the organisation coordinate technology, cybersecurity, privacy and business alignment through a steering committee or advisory board, composed of key executives, which meets formally and on a regular basis?”
Pillar 1 - ICT Risk Management
Adequate risk management is crucial for organisations to identify and assess systems, services and data being processed and then determine whether everything has been done to achieve the required level of resilience. Questions to assess the maturity of ICT Risk Management include:
“Does the organisation identify and document risks, both internal and external?”
“Does the organisation’s cyber security strategy align to the key areas of identification, protection and prevention, detection, response and recovery, and backups and recovery as well as adequately covering learning & development and communications?”
“Does the organisation conduct regular assessments of risk that includes the likelihood and magnitude of harm, from unauthorised access, use, disclosure, disruption, modification or destruction of the organisation's systems and data?”
“Does the organisation create recurring backups of data, software and/or system images, as well as verify the integrity of these backups, to ensure the availability of the data to satisfy Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs)?”
Appropriate Controls are then applied to manage any identified risk exposure, allowing proportionate controls to be used cost-effectively. The use of a centralised Control Framework allows the organisation to understand what Technological, People & Process controls are in place (through automation, process or otherwise), or identify any gaps.
A range of Control Sets can be used aligning with On-Premise, Cloud or Hybrid Infrastructure. Selecting the appropriate set helps organisations understand what is in place and identify any gaps. Some examples are:
No one-size-fits-all approach exists for selecting your primary control set, For example, there is strong alignment between the risk management areas within DORA and the NIST functions and the SCF contains mappings to DORA. However, while the CSA CCM may provide a better starting point for less mature risk functions as it provides broad coverage with fewer controls, the use of the most appropriate control set is key. This will not only support an organisation meeting the requirements of DORA but will also help achieve a range of other regulatory, industry, supplier or government requirements as well as help organisations to deploy and embrace security best practice. This would lead to the undisputed benefit of a safer and more secure environment for conducting business and protecting sensitive information.
It's also possible to cross-reference DORA-specific controls with PCI DSS or ISO 27K, allowing evidence to be captured once and used for wider regulatory and compliance requirements. A solid meta-framework referencing multiple standards and frameworks assists with this and helps to avoid duplication.
Following the selection of controls thought needs to be given to how each control is assessed or verified.
Does the compliance team need to visit a specific team to request documentary evidence? Or is it possible to configure the GRC tooling of choice to automatically trigger a vulnerability scan of defined assets and determine if there are any vulnerabilities on a specific server?
It may then be possible to configure automated follow up actions within the ticketing system to assign resources to apply a missing patch to a server. Moreover, it becomes possible to investigate why the server has not been automatically patched in line with the scheduled job.
With the rate of technological advancement, it is becoming increasingly important to move away from periodic manual attestations wherever possible and to leverage the power of automation. The process of determining which controls can be automated and investing in their automation. frees up the compliance team resources to assess remaining controls that cannot be automatically assessed. This, in turn, reduces manual processes and speeds up the ongoing compliance processes.
It may be possible to configure automated follow-up actions within the ticketing system to assign resources to go and apply a missing patch to a system component. But also investigate why automated patching has not taken place in line with the scheduled job.
Pillar 2 – ICT-Related Incident Reporting
To maintain critical systems and minimise any disruption it is important to ensure that incident management processes are in place to provide early warning indications and to respond to incidents promptly should they occur. Organisations must also ensure that communications and reporting channels are in place when required to deal with follow-up actions promptly and ensure the necessary senior managers and stakeholders are informed.
Having controls in place to cover incident management will greatly assist an organisation in gauging and meeting its DORA requirements for incident management and reporting. Questions to assess the current maturity of an organisation’s ICT Related Incident reporting include:
“Does the organisation establish an integrated team of cybersecurity, IT and business function representatives that are capable of identifying, categorising and addressing cybersecurity and privacy incidents and respond accordingly?”
Internally to organisational incident response personnel within organisation-defined time-periods; and
Externally to regulatory authorities and affected parties, as necessary?”
Pillar 3 - Digital Operational Resilience Testing
To fully understand whether systems are adequately protected from attacks by highly capable threat actors, it is key to ensure that penetration testing is carried out. This will enable their ability to withstand highly motivated and highly capable threat actors. Therefore, the DORA regulations require that Threat-Led Penetration Testing (TLPT) be carried out by larger firms on all critical and important systems at least every 3 years. But unlike normal penetration testing there is a requirement to carry out TLPT on live production systems for a real view rather than conducting testing on non-live versions of systems.
With this type of testing, it is key to select the appropriate intelligence gathering partner as well as the penetration testing partner. This activity requires intensive planning and needs input and support from a range of internal stakeholders to ensure the full scope of critical systems are included. It is also important that internal teams are not aware of the details of the testing, as this may impede the effectiveness of the testing with response teams having an unfair advantage in responding to attacks. Questions to assess the maturity of the organisation’s testing approach include:
DORA refers to the need for appropriate testing such as vulnerability assessments and scans, open-source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing. This approach is nothing new but what it does do is seek to codify good DevOps practice.
The organisation must implement security good practice within the build and deployment pipeline. Regular monitoring will also enable systems and services to be built securely and checked regularly to identify any compliance drift as early as possible allowing the security processes to be fine-tuned when non-compliances are identified. This type of approach is called ‘Shift Left’ meaning security testing is done earlier in the process resulting in quicker time to market with new products, increased resilience, as well as cost savings from avoiding costly rework late in the delivery pipeline. Questions an organisation could ask regarding their current state testing capability include:
“Does the organisation facilitate the implementation of industry-recognised cybersecurity and privacy practices in the specification, design, development, implementation and modification of systems and services?”
Pillar 4 - ICT 3rd Party Risk
Not only should the organisation understand risks from the operation of its systems and services but it should be aware of how any third-party suppliers impact the risk landscape of their ongoing operations.
DORA provides an oversight framework for the direct supervision of critical ICT third-party service providers, however, organisations cannot neglect their obligations to manage ICT third-party risk as an integral component of ICT risk within their ICT risk management framework. Again, this necessitates the need for adequate controls in this area within the control framework under Pillar 1.
While DORA has not yet defined any criticality criteria for third-party service providers, a no regret activity in the interim should be for organisations to focus on the arrangements in place for the suppliers that provide services or technology that they have identified as critical or important to their organisation. Examples of critical types of reliance may be upon the availability of public cloud infrastructure from the likes of Google, AWS or Azure. But it could also be just as applicable to the supply of external networking connectivity or the operation of secure boundary controls such as 3rd party managed Firewalls or content delivery networks.
“Does the organisation identify, regularly review and document third-party confidentiality, Non-Disclosure Agreements (NDAs) and other contracts that reflect the organisation’s needs to protect systems and data?”
“Does the organisation develop a plan for Supply Chain Risk Management (SCRM) associated with the development, acquisition, maintenance and disposal of systems, system components and services, including documenting selected mitigating actions and monitoring performance against those plans?”
Pillar 5 - Information Sharing
DORA requires organisations to share cyber threat information and indicators of compromise, tactics and techniques etc. but this needs to be done in a controlled manner with trusted parties from within the community in a closed user group with the intent of enhancing their digital operational resilience by raising awareness in relation to cyber threats as well as limiting or impeding the cyber threat’s ability to spread. The details of information being shared should be sufficient to help other members of the community to benefit and potentially to respond or take preventive action to protect themselves while still protecting the personal data of all those impacted and/or targeted. Information sharing agreements should be used as a mechanism to set out the terms of operation within the community, and rules should be in place to ensure that all parties adhere to business confidentiality and data protection laws.
In addition, organisations need to have adequate incident management processes in place as well as monitoring and alerting in a timely manner to allow them to react accordingly and share the necessary information as appropriate. Questions to consider related to an organisation's current incident management maturity include:
“Does the organisation establish contact with selected groups and associations within the financial services, cybersecurity & privacy communities to:
Facilitate ongoing cybersecurity and privacy education and training for organisational personnel.
Maintain currency with recommended cybersecurity and privacy practices, techniques and technologies; and
Share current security-related information including threats, vulnerabilities and incidents?”
Practical application of control frameworks
With the ever-increasing number of regulatory requirements emerging, all for good reason, it is key to ensure that organisations move away from managing security controls on a spreadsheet and that investment is in place to industrialise GRC processes by leveraging automation to move to continuous control assessment and continuous compliance.
There are several GRC tools available that allow an organisation to align to their chosen Control Set / Framework and allow tooling to be leveraged to reduce the burden on the GRC teams and automate control testing and evidencing with ability to automatically test the control and populate evidence within the GRC Tooling. This option is more related to technical evidence such as Infrastructure vulnerability scans, Testing for encryption being correctly enabled and configured or validating Firewall rules are in place for specific conditions.
Summary
Organisations need to ensure their current people, process and technology can protect the operation of the business and can respond accordingly to any malicious or accidental action that could disrupt the normal operation of critical systems and services.
Operational resilience is key to ensuring businesses can cope with and recover from disruptive events however they are caused to avoid intolerable harm to consumers, damage to market integrity and/or irreparable harm to themselves by enabling the swift return to operations of their critical business services.
Cognizant can help with all aspects of your DORA compliance journey, take a look at our article on Why you need a multi-disciplinary partner to implement the Digital Operational Resilience Act to find out more. To learn more, visit the Consulting section of our website.
