Preparing for DORA Step 3 - Digital Operational Resilience Testing - Mapping Service Dependencies

As discussed in a previous post there are five key parts to the DORA regulations that both European regulated financial service firms and those that supply them with services must comply with.

      i.         ICT risk Management Frameworks.

     ii.         ICT-related incident reporting.

    iii.         Digital operational resilience testing.

    iv.         ICT third-party risk.

     v.         Information sharing

This post is the third of 5 that will set out five key steps that need to be taken to prepare for DORA compliance.

How can firms identify their gap to DORA compliance?

Both finance firms and their suppliers will need to conduct a gap analysis against the new DORA regulations, with an appropriate action plan for rectification of any gaps identified.

The gap analysis can only be conducted with a rigorous understanding of all the links in the supply chain for the services to customers. It is not enough to have resilience and continuity plans in place for individual applications or systems, DORA places requirements against the whole service and its supporting infrastructure. All the components supporting a customer service must be mapped to understand the dependencies and assess the resilience requirements.

What must firms map to understand their DORA compliance?

To really assess a firm’s ability to comply with DORA and perform a gap analysis against the regulation there is a need to map all of the following items:

  • The services offered to customers and their relative criticality.

  • The end-to-end process and systems chain providing the services.

  • The applications in the chain, their providers, and their dependencies.

  • The infrastructure components supporting the chain, their providers and their dependencies.

  • The people resources supporting the service, the applications, and the related infrastructure.

  • The contracts for the third-party services underpinning the services whether for services, applications, systems, infrastructure, or people resources.

As with the UK Operational Resilience regulation, one of the key and time consuming elements of compliance is associated with understanding the end-to-end processes and associated resources consumed in the delivery of services offered to customers. Taking time to identify the most appropriate tool to capture all this information will be invaluable, not only in the initial work, but just as importantly, during the ongoing business as usual activities required to maintain compliance going forward.

DORA requires a firm to assess which resources in the service chain are critical by assessing the recovery strategy should disruption occur. Non-critical dependencies will have alternative provisions of service available that can preserve the service if a threat materialises, whereas critical dependencies have no alternative service provision. This is particularly relevant to any third-party services in the supply chain. Any component or supplier deemed critical has a higher diligence requirement for resilience planning and testing under the regulation.

Look out for our next publication about ICT third-party risk - ‘Planning and testing operational resilience and service continuity’ – another of the five key areas of DORA.

At Shapes First we work with firms so that they have the tools they need to manage their operational resilience in a commercially sensible way while all the time complying with their regulatory obligations. We have already supported firms with the implementation of the regulations that came before, and work with a partner firm to deliver process and resource mapping via a platform enabling firms to derive business benefit from the information captured. If you would like to hear more about what we can do to help you to implement DORA, please get in touch at info@shapesfirst.com

Previous
Previous

Preparing for DORA step 4 - Planning and Testing Operational Resilience and Service Continuity

Next
Next

Preparing for DORA Step 2 - ICT Related Incident Reporting