To sum up, the Operational Resilience Maturity Assessment Framework is a tool that measures the level of operational resilience of an organization.

What is Operational Resilience?

We believe that Operational Resilience (OpRes) is a young but increasingly unavoidable issue for our clients, especially for those in the financial sector. The United Kingdom has been a pioneer in this field, with an Operational Resilience Framework coming into force in March 2022, imposed by the Bank of England, the Prudential Regulation Authority (PRA) and the Financial Conduct Authority (FCA). Similarly, the European Union is set to follow suit, with its Digital Operational Resilience Act (DORA). The underlying principle for both legal frameworks is the acknowledgement that many events, both internal and external, can disrupt the activities of banks and other organizations.

Operational resilience therefore involves different sources of threats: from third parties (partners, suppliers, or service providers), pandemics, power failures, fire, to name but a few. From an organisational point of view, resilience is very often a program driven by the Head of Operational Resilience, the IT department or the risk division, and less often by a CISO.

Why did you create this tool? What problem does it solve for clients?

Under pressure from regulators, our clients have launched programs to increase their level of resilience, and therefore have had to measure their maturity level, both before and after these programs. Compliance is a good starting point, but it doesn’t go far enough! The idea of our Operational Resilience Maturity Assessment Framework is to provide a tool that encompasses both these new guidelines, and the best practices observed in the field. The tool is useful because it:

• Measures the maturity of an organization, in terms of the methodologies and processes in place to address Operational Resilience.
• Reports on the actual resilience capabilities at a given moment by analysing the tools and capabilities in place.
• Facilitates the formalisation of a risk reduction plan and the management of resilience by highlighting the main areas that require more investment.
• Integrates all Wavestone’s field experience in resilience from all our offices! Especially in the UK, where Operational Resilience is more advanced than the European Union countries, we have been working on resilience projects for over 3 years.

It assesses the organisation’s processes and operational implementation with a form consisting of ninety questions spanning twelve major topics. For each question, a resilience score between 0 and 5 is assigned, and a list of evidence is provided to support this score.

Customers are always keen to benchmark, and this has been incorporated into the assessment. Everything has been thought out to standardise the evaluations and thus allow clients to position themselves in the market; it’s a real value-add!

As the regulatory landscape matures, we’ve identified a need to maintain a global view; firms must implement Horizon Scanning functions to stay ahead of regulators and the competition. Therefore, working in conjunction with our maturity assessment tool, we have an Operational Resilience Regulatory Radar which maps regulations across the globe according to the same themes. It is a live document, updated every quarter that provides a holistic view of OpRes regulation and allows the user to compare by both geography and topic.

Can you tell us about the last time you used it?

The trigger for the creation of the Operational Resilience Maturity Assessment was a UK project supporting a major bank. Initially, we provided a 360° analysis of their resilience during which we developed our first assessment framework. With it, we were able to establish four maturity levels of resilience: 1) “Insufficient”, 2) “Compliant”, 3) “Good Level” and 4) “Leader”. We were then able to position them on these 4 levels and provide relevant advice and feedback accordingly.

Recently, we received a second assignment from another banking company, providing an opportunity to modify the assessment and make it more precise and extensive. We also modified our list of proofs that are used to position an organization against the correct maturity level, and added a 5th level of maturity, “The Pioneer”.

Currently, we use this framework in the financial sector, which has a high level of maturity given the regulatory constraints and the sensitivity of the data it processes. For clients in other sectors, we would adapt the levels to align with the overall maturity of the market.

Any final thoughts?

We think we can go even further in assessing resilience in a few years. The more feedback we get from the field, the more precise we will be on the required conditions to reach a level. For example, a player will be considered mature if it has the capacity to rebuild its AD in 3 hours. Just like on the CyberBenchmark. The next step would therefore be to define quantitative and/or qualitative indicators… And the only way to do this is to continue to confront the framework with reality!

Although everything can be improved, we are still very proud of this tool which was built in collaboration with our customers and experts, and has already proved its worth.

Cet article [INTERVIEW] Operational resilience, how to recover after an attack! est apparu en premier sur RiskInsight.

The European Union published the Digital Operational Resilience Act, or “DORA”, on December 27^th, 2022, and it entered into force on January 16^th, 2023. It sets new rules for financial entities and their ICT third-party service providers in terms of ICT resilience. Compliance to the text will be mandatory starting January 17^th, 2025.

The Digital Operational Resilience Act aims at simplifying and improving the resilience of financial service organisations by establishing a robust regulatory framework and oversight body. As previously shared in details, in our article Decrypting DORA: what does it mean for resilience of financial organisations?, it introduces requirements across five pillars: 

• ICT risk management
• ICT-related incident management, classification and reporting​
• Digital Operational resilience testing
• Managing of ICT third-party risk​
• Information and intelligence sharing (optional)

Main DORA topics and articles applying to financial entities
(article references between brackets)​

When analysing the content of the regulation and while taking into account the current maturity of the financial sector, the complexity largely differs depending on the topic addressed. As ICT frameworks are already a best practice widely adopted within the financial services sector, the effort will mainly focus on bringing more consistency across the organization. Similarly, ICT-related incident management has already integrated within its processes and tools numerous regulatory constraints in terms of classification and notification. Consequently, integrating the DORA requirements should not present major difficulties.

Nevertheless, meeting the requirements to be compliant will still have its challenges… And opportunities!

An ambitious regulation that puts the finger on known fragilities

The first challenge for many organisations will be to onboard the top management in the initiative. As DORA appoints them as accountable for monitoring, approving, reviewing, and setting the direction in terms of operational resilience, their involvement is key to the success of a potential program. Early onboarding will allow to gain precious time in identifying and validating critical functions in the scope, prioritizing the main threat scenarios, and set the pace on the topic. However, this will imply for the teams to carefully think about the proper and comprehensible KPIs and KRIs to report on the operational resilience level of the organization. As much as possible, give them quickly an overview of the regulation content and their expected role in this context!

The second challenge will be to raise the bar in terms of third-party risk management. Large organisations often have hundreds, if not thousands of third-party providers implying a fastidious sorting to focus on the most critical. Third-party operational resilience risk management mainly relies today on integrating steps within the purchasing processes and, in the end, including specific clauses within the contracts. DORA asks for more with responsibility falling on financial services to make sure third-party compliance to these requirements are met. It also requires working on potential exit strategies and joint testing where relevant. This step up may define a shift in how business is done with suppliers in the future and should be anticipated by the concerned third parties to be able to provide proofs of their operational resilience risk management.

Finally, testing is a crucial point and a challenge within DORA. Organisations will need to structure and regularly test their resilience to continually assess risks and the suitability of their resilience strategies. It requires to gain a strategic vision on the topic, which rarely pre-exists as the tests are often managed in silos (vulnerability tests, penetration tests, business continuity tests…). In this context, they will also need to ensure the proper coverage of their critical functions over the years within the testing approach. Organizations are also expected to conduct threat-led penetration tests in live production every three years at least and potentially including ICT third-party providers.

Overcoming these challenges will not be an easy journey. It is key to start working on these topics quickly as they will ask for true changes for the concerned organizations. Obviously, a detailed gap analysis with the regulation requirements is a good starting point.

Resilience first, compliance second?

Clearly, a regulation such as DORA brings along opportunities for those who will try to see beyond the compliance constraints.

First, the regulation introduces a holistic approach to ICT risk management that could bring more consistency across the organizations. It could constitute a first step in putting together a unified framework, allowing a better assessment of the organization’s ICT risks and simplifying overall reporting to the top management. It could also initiate the idea of a converged governance on ICT risk management gathering cybersecurity, business continuity and IT service continuity. 

Second and foremost, it is a unique opportunity to work on your real resilience level by asking yourself complex questions. If you were to face a no-IT situation tomorrow, would your organization survive? Would your existing capabilities fully cover the needs that such situation asks for? And are you confident that your resilience solution would work on D-day?

Cet article <strong><u>DORA: challenges and opportunities</u></strong> est apparu en premier sur RiskInsight.

Dashboards and KPIs that convey concrete messages and calls for action are often what drives the success of operational resilience initiatives.

Operational resilience brings together and harmonises multiple disciplines that were previously managed in silos: business continuity, IT and disaster recovery, incident and crisis management (IT, business and cyber), cyber defence, third party management, and operational risk management.

In order to coordinate and orchestrate these disciplines effectively to establish an accurate picture of the overall resilience, companies need to analyse their data in relation to these topics. This requires a complete mapping of critical services (Important Business Services), their dependencies (business processes, applications, suppliers, teams, buildings, etc.) and testing.

To make this possible, there is a real need for tools and automation. This is also why we are seeing more end-to-end solutions for operational resilience management emerging in the market, from specialist vendors such as Fusion Risk Management, Castellan to non-specialist ones, such as ServiceNow.

What are the challenges in the field?

Depending on the company’s maturity, each stage of the process may pose challenges or difficulties.

Challenge 1: Data Model

The operational resilience data model must be created in consideration of Important Business Services and their respective dependencies. Preferably, an organisation would reuse existing inventories (e.g. CMDB, supplier inventories, BIAs, HR systems, etc.) and run workshops to leverage on the knowledge of their business representatives and IT experts, suppliers, etc. The challenge stems from the need to rationalise all the elements into a format that enables data analysis. This means that even if one starts with Excel, it is important to firstly define the precise rules (common referencing system, one piece of information per line, etc.).

Challenge 2: Identifying gaps

Once this mapping is carried out, companies need to identify threats linked to the end-to-end service and existing resilience capabilities to mitigate them. These capabilities can be specific to a dependency or broader. This allows the creation of indicators that show resilience gaps. Overall, there can be two types of gaps:

1. A dependency with insufficient contingency plans

This can be identified in the initial analysis, through existing controls, or through testing.

Example: A person wants to withdraw cash. Normally, this service is available through an ATM. Several elements are necessary for ‘normal’ service to function properly:

• Physical ATM itself
• Customer authentication system via their bank card
• Customer account management software provided by a third party to check the balance

The following threats may affect this service:

• Major IT loss (whether or not caused by a cyberattack)
• Loss of the software provider
• Physical incident affecting the ATM

We shall assume that 4 hours is the period before the inability to withdraw cash becomes an intolerable source of harm to the customer – which is also known as the impact tolerance). With this context in mind, the bank needs to consider the following questions to identify resilience gaps:

• Recovery Time Objective (RTO): In the event of a computer loss, can the ATM and authentication system be brought back online within 4 hours according to their RTO? Has it been tested?
• Exit plan: In the event of a major breakdown or bankruptcy of the account management software provider, is there an alternate provider the bank can turn to for delivering the service without intolerable delay? Alternatively, is there a way to bring the activities in-house?
• Contingencies: Is there a degraded process for dispensing cash, for example, by replacing a faulty ATM? What are the dependencies for this process? Can it be done without an IT system?

Once these gaps have been identified, you can then calculate resilience scores for individual components.

2. Absence of a core resilience capability

A range of operational resilience capabilities is needed in every organisation, which includes business and IT continuity, third party management, cyber defence, disaster recovery and crisis management. We have identified a list of 50 generic core capabilities, linked to the most common threats, and are deploying this framework with our clients to measure the overall operational resilience maturity level.

Examples of key capabilities include:

• Crisis management: alternative communication channel
• Disaster recovery: Cyber vault
• Third party management: Crisis SLAs with third parties
• Business and IT continuity: degraded processes without IT
• Cyber defence: emergency authentication procedure

Challenge 3: Governance

Finally, governance is required to ensure that operational resilience data is maintained up to date, such that accurate reporting can be delivered to aid decision-making in the right forums. For instance, any initiatives to remediate identified resilience gaps requires management buy-in and funding, and management can only make the right decision and prioritise initiatives based on what is being reported on official reports.

Finally, what should be measured? 

The underlying question in MI is: how well is your organisation prepared to withstand a major incident?

• Are the dependencies identified?
• Are the necessary documentations in place?
• Are the threats known?
• Are controls in place to indicate a gap?
• Are the company’s employees prepared to respond and minimise the operational impact of a major incident?

What are customers’ expectations?

As of today, through supporting our clients in their Operational Resilience program, we have identified three common themes with regards to our clients’ expectations around operational resilience projects:         

1. Clients need help with creating an inventory and rationalising multiple sources with various data formats to be incorporated into the data model.
2. Clients regularly require support with creating reporting. This can be in the form of designing useful KPIs that can be translated into actionable items and a driver for decision-making process, or creating dashboards in data visualisation tools such as PowerBI.
3. There is an increasing demand for sourcing and deployment of operational resilience tools. Wavestone can help companies find the right tool that suits their needs via:
   • Performing a benchmark
   • Gathering requirements and specifications through workshops with future users
   • Creating an RFP and a suitable scoring mechanism to evaluate vendors

In fact – a great example showcasing our expertise around this particular area around helping our clients with sourcing and the deployment of operational resilience tools would be Wavestone’s second edition of the Operational Resilience Tooling Panorama – it captures the main market players across a range of topics such as emergency notifications, resilience management (mapping, testing, dashboards), crisis management and business or cyber incident simulation (cyber range). The radar is also built to encompass a wide spectrum of players – from disruptive innovators to traditional players, and from start-ups to large organisations.  

Any final advice for readers?

For French clients who have not yet launched an operational resilience program, there are two pieces of advice:

• As soon as the mapping is done, you need to think about how to store the data (i.e. the data model). Excel may not be sufficient as a tool to ensure the sustainability of the model
• Do not hesitate to re-use what your company already has in terms of business and IT continuity, third party management, cyber defence, IT reconstruction and crisis management.

Cet article MI and tooling at the heart of operational resilience management, Roxane Bohin interview est apparu en premier sur RiskInsight.

Why Digital Operational Resilience Act (DORA)?

DORA is part of an EU-wide “Digital Finance Package”, aimed at making sure the financial sector can leverage opportunities brought by technology and innovation whilst mitigating the new risks associated. This package involves regulation on crypto assets, blockchain technology, and digital operational resilience.  

With the Digital Operational Resilience Act, the EU aims to make sure financial organisations mitigate the risks arising from increasing reliance on ICT systems and third parties for critical operations. Organisations need to be able to “withstand, respond and recover” from the impacts of ICT incidents, thereby continuing to deliver critical and important functions and minimising disruption for customers and for the financial system. This means establishing robust measures and controls on systems, tools and third parties, having the right continuity plans in place, and testing their effectiveness.  

This global, large scope regulation is coming in to rationalise an increasingly fragmented regulatory landscape on the topic, with a number of local regulatory initiatives in member states and smaller scope EU guidelines on related topics (e.g. testing requirements, management of ICT third party dependencies, cyber resilience). Setting up a global regulatory framework will ensure there are no overlaps or gaps in regulation and maintain good conditions for competition in the single market.  

DORA also fits into a worldwide trend in regulation on resilience for the financial sector, pioneered by the Bank of England’s (FCA and PRA) consultation papers on operational resilience and impact tolerances, and followed by principle-based papers on operational resilience from the Bank of International Settlements (BIS) and the Federal Reserve.  

DORA in a nutshell: what does it change?

Contrary to the FCA/PRA, the Federal Reserve and the BIS, DORA focuses on solely resilience to ICT-related incidents and introduces very specific and prescriptive requirements. It is not just a set of guidelines but rather criteria, templates and instructions that will shape how financial organisations manage ICT risk. It demonstrates that EU regulators want to be very hands-on on the topic, with a lot of reporting, communication and assessments that need to happen frequently, enabled by standardised MI and reporting.  

DORA introduces requirements across five pillars:  

• ICT risk management 
• ICT incident reporting 
• Digital Operational resilience testing 
• ICT third-party risk management  
• Information and intelligence sharing 

Some of the requirements are straight-forward and largely built on what is already being done in organisations (for example, the risk management framework that needs to be developed is similar to industry standards like NIST); but some are also challenging and will mean organisations need to launch some work to be compliant. We have summarised the requirements and these key challenges to start addressing now for each of the 5 pillars.  

1. ICT risk management

Why? Ensure specific measures and controls are in place to limit the disruption to the market and to consumers caused by incidents, and ensure accountability of the management body on ICT risk management.   

Key requirements: Firms will need to follow governance principles around ICT risk, with a focus on accountability of the management body. They will need to identify their risk tolerance for ICT risk, based on the risk appetite of the organisation and the impact tolerance of ICT disruptions. They will also need to have a risk management framework in place that includes identification of critical and important functions, risks associated and a mapping of the ICT assets that underpin them; as well as specific protection, prevention, detection, response and recovery plans and capabilities, continuous improvement processes and metrics, and a crisis communication strategy with clear roles and responsibilities.  

Biggest challenge: As part of the continuous improvement processes, DORA introduces compulsory training on digital operational resilience for the management body but also for the whole staff, as part of their general training package.  

2. ICT incident reporting

Why? Harmonise and centralise reporting of incidents to enable the regulator to react fast to avoid spreading of the impact, and to promote collective improvement and firms’ knowledge of current threats to the market. 

Key requirements: DORA introduces a standard incident classification methodology with a set of specific criteria (number of users affected, duration, geographical spread, data loss, severity of impact on ICT systems, criticality of services affected, economic impact) with thresholds that are yet to be published. Following this methodology, incidents classified as major will have to be reported to the regulator within the same business day, following a certain template. Follow-up reporting will also be required after a week, and after a month. These reports will all be anonymised, compiled, and released regularly to the whole community.  

Biggest challenge: Firms will need to change their incident classification methodology to fit with the requirements. They will also need to set up the right processes and channels to be able to notify the regulator fast in case a major incident occurs. Based on what gets classified as “major”, this might happen frequently. To help organisations prepare, we anticipate that the incident classification methodology will align with the ENISA Reference Incident Classification Taxonomy.  

3. Digital Operational Resilience testing

Why? Ensure that financial entities test the efficiency of the risk management framework and measures in place to respond to and recover from a wide range of ICT incident scenarios, with minimal disruption to critical and important functions, in a way that is proportionate to their size and criticality for the market. 

Key requirements: With DORA, all firms must put in place a comprehensive testing programme, including a range of assessments, tests, methodologies, practices and tools, with a focus on technical testing. The most critical firms will also have to organise a large-scale threat-led live penetration test every 3 years (red team type exercise), performed by independent testers, covering critical functions and services and involving EU-based ICT third parties. The scenario will have to be agreed by the regulator in advance and firms will receive a compliance certificate upon completion of the test. More guidance for these tests, as well as the criteria which defines a critical firm, will be published in 2021. 

Biggest challenge: It is likely that critical firms will need to organise this threat-led penetration test by the end of 2024 and this type of test requires a lot of preparation. The fact that it needs to involve critical ICT third parties will also mean they need to be involved in the preparation. Firms that believe they will be in scope (might be firms already in the scope of NIS regulation) should start thinking about the scenario as soon as possible to enable validation with the regulator at least 2 years before the deadline.  

4. ICT third party risk management

Why? Ensure that financial organisations have an appropriate level of controls and monitoring of their ICT third parties, especially the ones that underpin critical functions; and set up specific oversight on providers that are critical to the market as a whole.  

Key requirements: With this regulation, the EU introduces requirements on both financial organisations and critical ICT providers.  

• Financial organisations will need to have a defined multi-vendor ICT third-party risk strategy and policy owned by a member of the management body. They will need to compile a standard register of information that contains the full view of all their ICT third-party providers, the services they provide and the functions they underpin; and report on changes to this register to the regulator once a year. They will need to assess ICT service providers according to certain criteria before entering a contract (e.g. security level, concentration risk, sub-outsourcing risks), and they will need to plan for an exit strategy in case of failure of a provider. DORA also contains guidelines for contract contents and reasons for termination of contract, which has to be linked to a risk or evidence of non-compliance at the provider level.  
• Under a new Oversight Framework, critical providers will be the subject of annual assessments against resilience requirements such as availability, continuity, data integrity, physical security, risk management processes, governance, reporting, portability, testing… These assessments will be performed directly by the regulator and will result in penalties for non-compliance.  

Biggest challenge: Collating information on all ICT vendors (not only the most critical), with the services provided and functions they underpin for the register of information will be a very big task for large financial organisations that typically rely on thousands of big and small providers and legacy contract management systems that make it difficult to mine data from.  

5. Information and intelligence sharing

Why? Promote sharing of information and intelligence on cyber threats between financial organisations to enable them to be better prepared.  

Key requirements: DORA introduces guidelines on setting up information sharing arrangements between firms for cyber threats, including confidentiality requirements and the need to notify the regulator.  

Biggest challenge: We do not see any particular challenge in this space as many organisations already have such agreements in place. It will be an opportunity to make local initiatives, networks or associations visible and encourage more companies to become part of them.  

What happens next?

DORA is currently going through the EU legislative process and it is expected to take 6-12 months before it becomes law. A few questionable topics might lead to some debates and slow down the process, especially on third-party management: restrictive criteria for organisations to terminate contracts, banned non-EU based critical third parties, penalty system and financing of the Oversight framework by the critical providers. There are also details that still need to be published to clarify some of the requirements (e.g. templates, criticality criteria and thresholds…), which might also create some debates.  

Once DORA is passed, firms should have one year to get into compliance with most of the requirements (i.e. probably by the end of 2022 – but this one-year deadline is short and we anticipate it may shift to 18 months following market feedback) and 3 years to organise a large-scale penetration test if required (i.e. probably by the end of 2024).  

In order to be ready, we recommend organisations take the following steps in 2021:  

• Perform a maturity assessment against the DORA requirements, with associated gap analysis and mitigation plan to reach compliance by the end of 2022 
• Begin thinking about a scenario for the large-scale penetration test, aiming to get it validated by the regulator by mid-2022 
• Start work on consolidation of the register of information for all ICT third party providers 

Cet article Decrypting DORA: what does it mean for Resilience of financial organisations? est apparu en premier sur RiskInsight.