The luxury market continues to grow globally and is expected to reach €2.5 trillion by 2030[1]. The health of this sector is therefore having an increasingly significant impact on the economy. This is especially true for France, where the sector is well represented in the CAC 40[2]. Thus, in this machine made of leather and silk, a single grain of sand can cost tens of millions of euros and have a lasting impact on the image of these companies. Yet, the risk factors are numerous.

Like all sectors, luxury is impacted by geopolitical instability and climate change:
On one hand, due to the high internationalization of its value chain (in 2023, French luxury companies exported goods worth €50.6 billion[3]); on the other hand, because of its high dependence on high-quality natural resources, particularly leather, textiles, and minerals.

In recent years, luxury companies have significantly accelerated the digitalization of their business processes, from manufacturing to sales. Their critical functions increasingly rely on assets exposed to IT incidents, whether caused by cyberattacks or not. Notably, the growing use of AI and IoT is a strong differentiator from a business perspective, but it also increases exposure to technological risks that are still partially identified and mitigated due to their novelty.

As a result, the sector faces a key challenge: how to ensure its sustainability in the context of growing threats? In response, a fundamental concept is gaining traction among major luxury Houses: operational resilience. What is the state of the art in the luxury sector regarding operational resilience? What mechanisms are being deployed by luxury brands to ensure the resilience of their critical activities?

Operational Resilience Applied to Luxury

Armed forces were among first to adopt the concept of operational resilience, defining it as:

“The ability to face the consequences of a traumatic crisis and bounce back, acting effectively despite a degraded environment and the human, organizational, and technical damages they [the military] may have suffered.”[4]

While this definition has a strong military tone, it nonetheless conveys a goal that any organization can pursue: the ability to withstand major disruptions and recover. Today, operational resilience has begun to permeate all sectors, from energy to healthcare, including luxury. This trend has been notably driven by the rise of regulations and standards dedicated to operational resilience, especially in the financial sector (DORA, Solvency II, PCI DSS…).

At Wavestone, we consider operational resilience to be structured around seven key pillars, inspired by best practices, notably the ISO 22301[5] standard, as well as European regulations. The luxury sector is well-suited to building these pillars, provided its specificities are considered.

          Pillar 1: Critical activities and assets knowledge

This involves identifying and improving knowledge of what needs to become resilient among all business processes and assets of the organization. Two approaches exist:

• An exhaustive approach, based on a Business Impact Assessment (BIA) across all organizational processes, providing a global view of activities and identifying critical processes and their supporting assets (IT infrastructure, applications, workshops…). However, this approach is time-consuming and does not add significant value to implementing an efficient resilience strategy.
• A pragmatic approach, based on a limited impact analysis concerning organization’s critical processes, identified beforehand by top management. This faster and higher-value approach allows early focus on analyzing processes recognized as vital by the business, then tracing back to applications and infrastructures that support them.

This mapping is a crucial starting point to focus efforts on what truly matters for the organization. In the luxury sector, particular attention should be paid to the following asset categories: human resources with rare expertise, raw materials, manufacturing tools, and assets related to logistics and payment.

       Pillar 2: Risks Management

The goal is to tailor operational resilience measures to the entity’s risk profile, focusing efforts on preventing the most impactful and likely risk scenarios.

In the luxury sector, it is useful to consider all risks that could affect the entity’s operations, especially those related to geopolitical instability, climate change, and IT/OT, which could impact the supply of rare raw materials, production, and distribution.

       Pillar 3: Implementation and Continuous Improvement of Continuity Solutions

The target is to implement relevant resilience measures, notably through business continuity plans that address identified risks and focus on critical activities.

In the luxury sector, it is useful to define these measures with business teams in a pragmatic and essential way. The idea is for resilience measures to integrate seamlessly into business processes, improving their quality while avoiding being perceived as an additional constraint.

Moreover, luxury professions are often artisanal, with people being the sole holders of a clear vision of their processes (in other words, their craft). The resilience of their work largely depends on them. An interesting approach would be to reverse the usual method: instead of formalizing a continuity procedure and then testing it, conduct a workshop/test with business teams to formalize a procedure based on the best practices they would naturally implement.

       Pillar 4: Third-party risk management

The objective is to have sufficient knowledge of the third parties involved in the entity’s critical activities and to ensure they do not pose an obstacle to their resilience. In the luxury sector, the nature of third parties presents specific characteristics that must be considered. On one hand, they are often artisans or very small businesses (VSBs) that have not worked on their own resilience. On the other hand, some third parties are the only ones able to deliver the level of quality sought by the luxury House, which may place the latter in a position of dependency. A dedicated reflection is therefore needed to co-develop resilience solutions with these third parties, notably through crisis management exercises.

       Pillar 5: Crisis management capability

This involves setting up a framework to manage all types of crises that may arise and that the entity will need to manage: IT, cyber, safety, and business-related. Entities in the luxury sector, due to their “manufacturing” nature, often operate numerous geographically dispersed sites, hosting a variety of professions. These elements must be taken into account to adapt the crisis management framework and ensure that relevant exercises are conducted.

       Pillar 6: IT systems resilience

Given its central role and the technical complexity, it entails, the information system requires particular attention to ensure it is sufficiently protected against threats and can maintain the continuity of its critical services, even in degraded conditions. In the luxury sector, where digitalization process remains relatively recent or still ongoing, a major strategic opportunity emerges integrate resilience considerations from the design phase.

       Pillar 7: Resilience culture and governance

At the heart of the approach, developing an operational resilience strategy is essential, led by clearly identified stakeholders. It is equally important to build on the unique corporate culture of each luxury House — a true driver of employee engagement — by progressively embedding a culture of resilience.

The state of operational resilience in the luxury sector

To establish this overview, we relied on the results of our CyberBenchmark and OpResBenchmark. These two tools respectively assess the maturity level of entities in terms of cybersecurity and operational resilience, while positioning them relative to the rest of the market.

The combination of these tools allowed us to consolidate data from the evaluation of over 150 entities, including a significant number from the luxury sector.
These insights enable us to present the overview below, illustrating the sector’s maturity level across all seven pillars of operational resilience.

According to 2025 data of the Wavestone’s CyberBenchmark and OpRes Benchmak

Upon reviewing this data, the most obvious finding lies in the market average (47.5%):
Entities across all sectors appear to be not very resilient. However, there are significant disparities, particularly depending on the level of regulation in each sector.
Naturally, the financial sector, currently undergoing compliance with DORA (Digital Operational Resilience Act), shows a high level of maturity across all pillars.
Meanwhile, the energy sector, also regulated, must contend with complex industrial systems and heavy legacy infrastructures, which complicate its operational resilience.

The context of the past five years – marked by major challenges to business continuity (COVID-19, military conflicts, rising cyber threats, etc.) – along with the operational resilience recognition in several regulatory texts (e.g., DORA, CER, CRA, NIS 2) seems to be reversing the trend. We are seeing more entities becoming aware of the importance of operational resilience and beginning to launch significant initiatives to address the issue.

In terms of maturity, the luxury sector stands out with an average of 53.4%.
Even though it is not directly targeted by regulation, we have observed a proactive approach to the topic, particularly from CISOs of luxury Houses, who have initiated numerous resilience-related projects. Accustomed to the pursuit of excellence, the luxury sector is embracing the topic voluntarily, convinced that it represents a strategic challenge for the future.

This position even seems to allow it to leverage best practices established by regulation, focusing on what matters most, without being burdened by compliance constraints or oversight from authorities (incident reporting, audit preparation, evidence sharing…).

In practice, this translates into the sector being ahead of many other unregulated industries in terms of operational resilience — even though we are still at the beginning of the journey.

       On crisis management and IT resilience

The consequences of poorly managed crises are often severe — financially, legally, and reputationally. We can easily imagine, for a luxury House, the impact of being unable to process customer payments or a fire affecting a raw materials warehouse. Luxury brands have therefore long been structured to manage the crises they face.

However, these crises now frequently originate from incidents affecting information systems.
In 2022, 62% of luxury sector companies were victims of ransomware attacks, resulting in average financial losses of around €5 million per incident. At the same time, stolen data is increasingly circulating on the Dark Web. According to Dark Web Monitor, listings offering sensitive information — such as upcoming product plans or confidential marketing strategies — have increased by 78%. For example, in 2022, the Italian House Moncler suffered a data breach, with a ransom demand of $3 million to prevent the disclosure of information related to its wealthiest clients[6].

Crisis management therefore relies heavily on IT resilience mechanisms, which materialize the decisions made by the crisis unit. These mechanisms include backups, flow blocking, and workaround solutions. They also play a key role in incident prevention and detection, through tools such as EDRs, IDS/IPS probes, automated patch deployment, and regular configuration testing.

      On third-party risk management

The sector’s maturity on this pillar is largely due to the historical awareness among luxury companies of the criticality of their value chains, both upstream (leather, silk, precious stones sourcing…) and downstream (finished product distribution). These value chains involve numerous external providers — extraction, maritime or road transport, logistics hubs — whose failure can lead to major commercial consequences.

Among the suppliers of major luxury Houses, one often finds small artisanal businesses, holders of rare and hard-to-replace expertise. At first glance, their small size might suggest low risk management maturity. However, due to their strategic value, these artisans receive special attention. Luxury Houses adopt a collaborative approach to support them in managing their risks, including in the IT domain, even though IT systems remain limited in these artisanal structures. This collaboration takes the form of regular audits, sharing of best practices, and in some cases, acquisitions that allow for full integration and maturity development aligned with the standards of the luxury House.

       On understanding critical activities and assets

This pillar is particularly complex to master for luxury entities, which are generally divided into Houses/entities with very different business lines, sometimes spread across multiple continents. This structure gives a certain autonomy to the various business units, which can complicate the proper sharing of information with the teams responsible for resilience at the group level.

       On governance and resilience culture

This pillar is the least well mastered by the sector. Luxury even ranks slightly below the market average. Indeed, roles and responsibilities are rarely clearly defined, and a common governance structure is often nonexistent. As a result, several similar projects may compete with one another, or be handled incompletely (e.g., from an IT perspective without considering BIAs conducted by business teams).

Our recommendations to improve operational resilience in the luxury sector

Wavestone supports multiple entities across all sectors in their operational resilience initiatives. Considering specificities of the luxury sector mentioned earlier, we identify four key recommendations:

Draw inspiration from regulations while remaining pragmatic (DORA, CER, NIS 2, Solvency II, LPM, etc.): Luxury is not directly subject to these regulations, yet it is relevant to leverage them as best practice frameworks. With DORA, the financial sector is progressing rapidly on the topic, and its feedback and experience can be valuable to the luxury sector. Obviously, it is essential to remain pragmatic and retain only the measures that are relevant to the specific luxury entity and its characteristics. It is important to avoid overloading business teams with purely regulatory requirements, which are primarily designed to help supervisory authorities fulfill their role.

Test and learn: Testing is an essential component of an operational resilience strategy.
It is through testing that one can measure the effectiveness of continuity solutions (BCP, DRP, crisis management tools, etc.), draw lessons, and continuously improve them.
Notably, threat-based penetration testing (as described in DORA and the TIBER-EU framework) allows for end-to-end testing of operational teams, including third parties, and can therefore be highly insightful even outside the financial sector.

Establish a Group-level strategy: This helps avoid contradictory initiatives at the entity level and/or between IT/Cyber teams and business units, while also enhancing efficiency. Moreover, this strategy allows for the definition of a target maturity level, tailored to the specific needs of each entity.

Build on existing foundations: Due to their specificities, luxury entities may have already implemented continuity solutions and/or governance structures suited to operational resilience (third-party management, crisis management, cybersecurity programs, etc.).
It is important not to start from scratch, but rather to capitalize on existing assets to initiate a tailored approach.

[1] Luxury in Transition: Securing Future Growth, Bain & Company

[2] The main French stock index

[3] Le luxe français : pourquoi ce secteur déjoue toutes les crises, La Fabrique de l’industrie

[4] Doctrine interarmées, DIA-3.4.1_RESILIENCE, N° 23/ARM/CICDE/NP du 08 février 2022.

[5] This standard defines features of a “business continuity management system”

[6] À quels enjeux de cybersécurité les grands noms du luxe sont-ils confrontés ?, L’Usine Digitale

Cet article Operational resilience in the luxury sector est apparu en premier sur RiskInsight.

In recent years, regulators have consistently urged insurers to adopt holistic strategies that extend far beyond traditional disaster recovery—embedding resilience throughout business operations and the entire software development lifecycle.

This paper aims to offer a comprehensive perspective on resilience, bringing together operational continuity, cyber defence, and third-party risk management. It can serve as a strategic guide for CxOs, outlining how to identify the Minimum Viable Company (MVC), market insights into sector-wide impact tolerance, and anticipate the evolving landscape of regulatory and cyber resilience through 2030.

Minimum Viable Company (MVC) framework

The FCA’s Operational Resilience Policy Statement (PS21/3) challenges insurers to pinpoint their Important Business Services (IBS) and develop strategies for maintaining these during severe disruptions. Though MVC is not named explicitly in PS21/3 (FCA’s Policy Statement on Building Operational Resilience, published in March 2021) organizations are advised to define their “minimum operational footprint,” closely aligning with MVC principles.

Think of the MVC as your organisation’s lifeline: those indispensable services, processes, technologies, and teams that maintain trust and financial stability, even when everything else must be paused.

Most organizations keep their MVC lean, just 15–17% of total business activity, backed by robust lists of mission-critical applications, core infrastructure, key data, and vital third-party relationships. This isn’t just compliance: it’s about identifying a modular, scalable foundation that lets your business isolate issues, recover fast, and keep delivering during systemic risks.

Informed by our extensive work with top UK and global insurance organisations, an indicative list of Core Services typically is:

Further examination of trends in impact tolerance, detailing standard timeframes observed and strategic rationale for core services identified within MVC.

Note: The following ranges are intended as guidance, reflecting our market study and regulatory advisory. Actual tolerances may vary based on factors such as the jurisdictions involved, the organization’s risk profile, and its financial capacity.

Regulatory trends: 2025–2030 outlook

As the insurance industry navigates evolving operational demands, it is equally crucial to anticipate the shifting regulatory landscape that will define the coming years. The following outlook highlights the major regulatory trends projected for 2025 through 2030, outlining key compliance requirements and anticipated changes that will shape the UK insurance sector’s risk management and reporting frameworks.

It is important to recognise that as regulations in this area continue to develop, UK regulators such as the FCA and PRA are moving towards greater alignment with major European frameworks, including the EU Digital Operational Resilience Act (DORA) and the Network and Information Security (NIS) Directive.

This alignment reflects a recognition of the interconnectedness of financial markets and critical services across borders, and the need for consistent, elevated standards of operational and cyber resilience.

The FCA and PRA have issued consultations and guidance signalling their intent to integrate core DORA and NIS principles—such as enhanced third-party risk management, harmonised incident reporting obligations, and sector-wide resilience testing—into the UK’s regulatory regime. This convergence ensures that UK financial institutions, insurers, and service providers are prepared not only for domestic regulatory expectations but also for the demands of operating within a global and digitally integrated market.

Boardroom resilience checklist

In light of these forthcoming regulatory changes and strategic reforms, it is essential for boardrooms to evaluate and reinforce their organisational resilience frameworks. The following checklist is designed to guide leadership teams in proactively assessing their preparedness, ensuring robust governance, and embedding resilience into core decision-making processes.

• MVC coverage: Is your Minimum Viable Company (MVC) clearly defined, mapped, and stress-tested across operations to maintain delivery of essential services
• Impact tolerance benchmarking: Have you validated realistic impact tolerances through scenario analysis, and benchmarked them against peer institutions and regulatory frameworks
• Third-Party risk visibility: Do you maintain real-time insight into key external dependencies, supported by contingency planning and contractual resilience provisions
• Integrated resilience functions: Are your operational resilience, cyber security, third-party risk, and enterprise risk teams aligned in strategy, decision-making, and board reporting to support a cohesive resilience posture
• Incident Response preparedness: Do you have robust mechanisms for multi-channel incident reporting (internal and external) and active regulator engagement, supported by rehearsed playbooks
• Cyber insurance alignment: Is your cyber insurance coverage tailored to your specific risk landscape, and tested against evolving threat scenarios across business-critical assets
• Board accountability: Have board members been trained in resilience and security oversight, and do they receive regular briefings from integrated risk functions to ensure informed governance
• Resilience culture: Is a resilience-aware culture embedded across the organization —from executive leadership to operational teams — fostering proactive risk ownership and continuous improvement
• Regulatory awareness & horizon scanning: Are we tracking global and local regulatory developments (e.g. EU DORA, FCA SS1/21, SEC cyber rules), and ensuring readiness and board-level awareness of compliance obligations

The UK insurance and reinsurance sector is well-capitalised, digitally evolving, and strategically positioned for growth. But resilience (operational, cyber, and third-party) remains the defining factor for long-term success. 

By thoughtfully harmonizing operational resilience strategies across function with leading global standards, organizations can elevate their industry standing and secure enduring stakeholder confidence. This proactive approach not only ensures compliance with a rapidly evolving regulatory landscape but also fortifies the ability to mitigate cross-border risks and respond decisively to unforeseen disruptions. In a world where digital threats and supply chain vulnerabilities transcend geographic boundaries, developing internationally recognised resilience is both a regulatory imperative and a cornerstone of successful, forward-looking business strategy.

In conclusion, executives must embed robust, integrated resilience frameworks for sustained growth and stability. By cultivating a culture of proactive risk management and regulatory awareness, institutions can position themselves at the forefront of operational excellence, prepared not just to withstand challenges, but to transform them into opportunities for long-term success.

Cet article Resilience by design: strategic imperatives for UK General & Reinsurance Insurers (2025 – 2030) est apparu en premier sur RiskInsight.

To learn more about the regulation’s details, you can refer to this article: What does DORA mean for Resilience of financial organisations?

The key deadline of January 17, 2025, marks the theoretical compliance date for financial entities. It also signals the beginning of supervisory operations by regulatory authorities.

In this context, Damien LACHIVER and Etienne BOUET, Senior Managers at Wavestone and experts in DORA compliance, with extensive experience supporting CAC40 entities, share their insights into the practical challenges and opportunities brought by this regulation, as well as the regulators’ expectations and essential actions for effective preparation.

How does DORA go beyond mere regulatory compliance?

E.BOUET: DORA should not be seen merely as a compliance exercise. Yes, there are regulatory requirements to meet, but the real challenge lies in building resilience. The question to ask is: how can compliance with DORA effectively enhance operational resilience? This connection is not always straightforward. For instance, gap analyses or cybersecurity audits often reveal vulnerabilities, and compliance alone is insufficient if it doesn’t come with genuine improvements in resilience.

D.LACHIVER: Many entities are still focused on compliance since DORA addresses areas already well established, such as cybersecurity, business continuity, and IT risk management. Large organizations, in particular, already benefit from high compliance levels due to decades of experience.

However, beyond this compliance phase, it is crucial to shift towards remediation and anticipation, implementing initiatives that will not be fundamentally different from the historical programs already initiated. The real focus should be on identifying new scenarios or solutions that can strengthen resilience.

What are the critical scenarios to consider for improving resilience?

D.LACHIVER: Two major scenarios require significant attention and investment:

• Total loss of internal IT systems: how can information systems be restored and fully rebuilt after a large scale cyberattack?
• The sudden loss of a critical third party: what happens if I lose a partner or service provider whose operational disruption has a significant structural impact on my business?

E.BOUET: The growing dependence on third parties has noy yet been fully recognized as a major risk. The associated scenarios are not sufficiently integrated into strategic priorities, leading to a lack of investment in preparedness.

Will financial entities be ready by January 17, 2025?

E.BOUET: It is unlikely that all companies will be fully ready by January. The market as a whole faces delays, although significant progress has been made. For instance, most of the normative documents required for compliance have been finalized, and priorities have been aligned with risk management needs.

D.LACHIVER: Indeed, January 17, 2025, will mark more of a milestone than a conclusion. Most operational projects, such as third-party management, remain to be addressed and will require ongoing effort.

What are the main challenges in implementing DORA?

E.BOUET: Initially, the main challenge was mobilizing a wide range of stakeholders: cybersecurity, risk management, procurement, legal, business, IT… While the topics addressed by DORA were already familiar to these teams, the regulation raises expectations and introduces additional requirements to roles thar are already well-defined.

D.LACHIVER: Historically, these areas have often been handled in a fragmented, siloed manner. However, DORA demands significant and measurable progress in resilience, which requires a more coherent and integrated approach. Today, two key priorities stand out:

• Third-party management, which represents a massive challenge.
• Threat-Led Penetration Testing (TLPT), an ambitious but complex novelty.

Why is third-party management such a significant challenge?

E.BOUET: Third-party management (TPRM) is one of the key challenges posed by DORA. Third parties are everywhere, but they are often poorly managed. It’s not always clear whether they are critical or not, and relationships often lack proper structure. Managing reliance on critical third parties is common sense, but it goes far beyond contractualization: organizations need to identify their third parties, assess their criticality, and manage this dependency operationally, a challenge for many.

D.LACHIVER: Historically, this has been a neglected area, often handled in silos by procurement, cybersecurity, business continuity, and other functions. There is a lack of a comprehensive view of third-party risks. DORA’s aims is precisely to move beyond this fragmented approach and build a cohesive end-to-end management framework throughout the contract lifecycle.

What does “testing exit strategies” with critical third parties mean?

D.LACHIVER: Testing exit strategies means anticipating how an organization would respond if a third party’s services were interrupted, whether voluntarily or involuntarily. For example, in the case of a cyberattack on a service provider, it may be necessary to sever the relationship to protect the organization’s own information systems.

E.BOUET: Tabletop exercises help assess reliance on third parties and theoretically simulate the procedures to follow in different scenarios. They also encourage organizations to rethink their relationships with certain providers, particularly those unable to align with DORA’s requirements.

What makes TLPT (Threat-Led Penetration Testing) a specific challenge?

D.LACHIVER: TLPT is one of the key innovations introduced by DORA. It involves threat-led penetration tests guided by the DORA regulation, the theoretical TIBER framework and adapted by national authorities. While the theoretical framework is well-defined, practical implementation remains challenging, as these tests are not yet common in the financial sector. Their limited frequency (one test every three years) and the regulator’s resources reduce the immediate urgency, but they are crucial for strengthening resilience.

E.BOUET: These tests still raise many questions, as they require a new approach for some players, especially those less experienced with this type of exercise. Currently, we are in a waiting phase, with a few dry-run initiatives underway. The actual implementation will depend on the regulator’s planning and the lessons learned from the first fully executed TLPTs in the coming months.

How can DORA transform IT risk governance?

D.LACHIVER: DORA promotes a unified approach to IT risk management by breaking down silos between various functions, such as cybersecurity, business continuity, and procurement. This involves:

• Harmonizing key terminologies and concepts (for example, ensuring that the concept of criticality is understood consistently across all functions) to streamline and improve interactions with business units.
• Implementing structural changes (such as adopting a CSO model – Chief Security Officer) to establish unified governance across functions, enabling more effective and coherent decision-making.

What are the concrete requirements to comply with DORA by January 17, 2025, and beyond?

E.BOUET: The first major expectation for January 17 is the ability to identify a major incident according to DORA’s criteria and notify the regulator. This requires well-defined operational processes to ensure rapid detection and reporting. This requirement is justified, given the history of IT and security teams in a sector accustomed to managing critical incidents.

D.LACHIVER: Then, by April 30, 2025, financial entities will need to produce a register of information on their third parties. I believe organizations will be able to provide such a register by this date. However, additional work will likely be needed to improve its quality and completeness.

E.BOUET: Finally, throughout 2025, what matters is demonstrating that entities are making progress. Regulators expect projects to be initiated, identified gaps to be gradually addressed, and tangible advancements to be made. The key is to have a clear and structured roadmap to meet DORA’s expectations.

What are the long-term benefits expected from DORA?

D.LACHIVER: DORA has the potential to create a virtuous cycle by strengthening risk management, business alignment, and operational resilience within the sector. It encourages entities to go beyond compliance and integrate these priorities into their overall strategy.

E.BOUET: One key aspect is the reaffirmed responsibility of executive leadership. Their involvement, particularly through regular risk validation, enhances overall awareness and drives the investments necessary to improve resilience.

D.LACHIVER: This connection between operational teams and leadership aligns strategic and operational priorities, fostering a culture of continuous improvement. It also empowers IT risk teams and supports the transformation of organizations toward greater digital resilience.

For any support in achieving DORA compliance, you can contact:

• damien.lachiver@wavestone.com
• etienne.bouet@wavestone.com

Cet article DORA – The Challenges of Digital Resilience in the Financial Sector by 2025 est apparu en premier sur RiskInsight.

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.

Reminder of the state of the threat

ANSSI states in ÉTAT DE LA MENACE RANÇONGICIEL – À L’ENCONTRE DES ENTREPRISES ET INSTITUTIONS[1] published on 05/02/2020: «  Since 2018, ANSSI and its partners have observed that more and more cybercriminal groups with significant financial resources and technical skills favour the targeting of particular companies and institutions in their ransomware attacks. ».

Faced with this observation, it is more necessary than ever to secure information systems. This involves applying the fundamentals of security: applying patches, managing accounts and passwords, managing network segmentation etc. As a reminder, the application of these initial measures permits a significant reduction in the probability that an information system will be subject to a ransomware but can in no way guarantee that this will not happen.

Specificity of the industrial sector

However, even though new defensive solutions are continually being developed, the cost and complexity of deploying some of them ultimately make them little used. This is truer in an industrial environment, where their integration can be complex, as some systems are fixed in a functional configuration. Moreover, the budgets allocated to IT security in an industrial environment, although increasing in recent years, are still not sufficient for many sites.

Furthermore, an industrial information system shares a common base with a conventional information system and is therefore subject to the same attacks. Of course, attacks such as Stuxnet, Triton, or BlackEnergy (on a smaller scale) require additional skills. However, it is always worth remembering that the targets of interest for groups possessing this type of means are generally already subject to regulatory obligations (LPM in France, NIS directive etc.), which if respected, greatly limit the risks of a successful attack against them. However, these systems are not invulnerable, and must therefore also be prepared to respond to an attack.

Inevitable attack on industrial systems: how to minimise the impact and restart operations quickly?

It therefore appears that:

• Protecting oneself from the threat is often limited to the application of basic security measures if there is no regulatory obligation applicable to the target information system;
• Identifying the sources of threat and detecting an attack before it reaches its objective requires in most cases resources that are too important in relation to the budgets of current industrial information systems.

If the probability of an information system undergoing a successful cyber-attack, and more specifically a ransomware, is almost certain, the following question arises: “How can we prepare for a major cyber-attack, maintain critical activities in a degraded mode, while rapidly regaining confidence in the industrial information system? ».

The answer to this question is covered by the last two pillars of computer security according to the NIST framework: respond and recover. An attempt to answer this question is presented in this article.

Note: the first part of this article “How to respond to an attack before it is too late?” is not necessary to implement the recommendations detailed in the second part “How to recover after an attack if it could not be contained? ». Although the implementation of network filtering measures is highly recommended, it may be interesting for sites where the implementation of such filtering measures takes too long to implement, to start with the preparation part of the remediation of a cyber-attack, which is easier to implement.

How to respond to an attack before it is too late?

Involving industrial teams

Before talking about the measures that can be put in place to respond to a digital security incident, it may be interesting to remember that industrial staff are used to crisis management.

Indeed, many industries regularly organise crisis management exercises (fire, chemical risk, natural disasters, etc.). On many sensitive sites, procedures are therefore already available to respond to this type of incident, under the direction of a dedicated manager. In addition, autonomous physical protection is generally available: pressure relief valve, non-return valve, sprinkler etc., although these are sometimes replaced by connected instrumented safety systems.

The context is therefore appropriate for adding a new procedure in order to respond to a computer attack. This will generally consist of isolating the industrial information system from the outside via a procedure known as the “red button”. In order to draw up the associated procedure, the involvement of site personnel will be essential, particularly to ensure that the application is not more harmful than the attack itself.

A prerequisite for the implementation of the isolation posture: the control of its flows and the implementation of network partitioning/filtering.

It is necessary to measure the impacts generated using the “red button”. To do this, it is necessary to list the interconnections of the industrial site with other systems.

List the interconnections with other information systems.

It may be interesting to start by listing the flows between the industrial information system and the outside. First of all, it is necessary to define what this system contains. In a basic case, it includes the PLCs, the supervision, as well as the equipment necessary for the interconnection of the first two.

Other equipment can then be added: an Historian server, client stations for supervision, a NAS, etc. This network, later called an industrial network, is generally connected with other networks in order to share information with the equipment of the latter.

It is possible to mention:

• Exchanges with the company’s ERP (whether an MES – Manufacturing Execution System is present or not), generally located on the office network;
• Exchanges with partners: regulation of electricity, water and gas networks, etc.;
• Exchanges with service providers: weather, cloud solutions for energy optimisation, predictive maintenance, etc.

These flows, although useful to simplify operations, can generally be temporarily cut off or replaced by alternative means (telephone call to indicate production levels for example).

Moreover, each industrial site is different, and therefore manages these interconnections differently. It is common to see MPLS networks dedicated to industrial sites when the company owns several of them. In other cases, the office network will be used to federate them. It is also true for the connection needs between these industrial networks and the Internet, which sometimes pass first through the office network, or benefit from a direct output.

List its internal flows

After listing the interconnections between the industrial network and the outside, the internal flows remain to be listed. Most of these flows should be strictly necessary for the proper functioning of the industrial process, such as those between supervision and PLCs. Cutting off these connections would therefore require stopping the industrial process, or at least making it safe.

It may then be interesting to separate the equipment and associated flows into several zones:

• Supervision;
• Field network;
• Others (supervision client stations, historian server, etc.).

Setting up these zones allows the exposure of these components to be drastically reduced. Indeed, only the supervision should have access to the field networks, while the “Others” category should only have access to the supervision.

Other zones may be necessary to implement such as:

• An administration zone: which could also be used to program the PLCs according to the distribution of roles and responsibilities on site;
• A DMZ: which can accommodate a relay server so that equipment outside the industrial site does not connect directly to the supervision system to retrieve production data, etc.

Depending on the services offered (WSUS server, antivirus server, Terminal Server for remote access etc.) other zones can of course be added.

Evaluate the real need for these flows

After listing all these flows, it is interesting to identify the real need for each of them. For example, is it necessary to be able to access e-mails from a supervision server?

In order to limit the exposure of the industrial network to the outside, it could also be necessary to take some equipment out of it. For example, if a database accessed from the office network is fed by the supervision, but not useful to it, hosting it directly on the office network may prove simpler than trying to limit access.

Once the necessary flows have been clearly identified, the associated filtering rules must be configured in detail (source IP address, destination IP address, destination port). This work generally requires a significant human investment, mainly from the teams in charge of the industrial site, as well as a significant material cost to acquire security equipment. However, it is a prerequisite for setting up the fallback postures described below. In an ideal case, application filtering (level 7 of the OSI model) could also be implemented.

This work, although essential to the implementation of isolation postures, is also one of the fundamental actions to be carried out within the framework of securing an information system (industrial or not). Indeed, each flow cut off is a flow that does not need to be monitored, as well as one that is less exploitable by an attacker.

Preparing fallback postures

Complete isolation of all the equipment in an industrial information system is not always desirable, even in the event of an attack. After having listed these flows, it may be interesting not to set up a single isolation posture, but several fallback postures, allowing in some cases to continue working almost normally.

Preventive fallback posture: isolate the plant in the event of an attack on an external network

After identifying the flows between the industrial network and the outside, it is possible to create an associated fallback posture in order to deactivate them if necessary. The objective of this posture is to cut all interconnections of the industrial network with the outside in order to prevent any propagation of an attack. A proven solution is to group these flows on a few dedicated Ethernet ports. Thus, it is sufficient to indicate in the associated procedures to disconnect the associated cables to activate the fallback posture. This also avoids having to intervene on the configuration of firewalls in the event of a cyber security incident.

In addition, it is also necessary to define the cases in which this posture should be activated. If it can be activated without posing any problem to production, or adding too much work to the site staff, the question may arise as to whether these flows are necessary.

If this posture does have an impact on the site’s industrial activities, a good balance must be found between triggering it too early (as soon as the antivirus software on an office workstation raises an alert), or too late (after the first industrial workstations have been encrypted). This will also depend on the context of the company and its resources (dedicated or non-dedicated security monitoring team, etc.).

Specificity (distributed sites, non-autonomous sites, etc.)

If all flows with the outside do not have the same destination, it may also be interesting to define several specific fallback positions. Indeed, if the service provider in charge of managing the site’s cameras warns that he is undergoing a ransomware attack, it seems more optimal to disconnect only the flows between this service provider and the factory network, rather than all the flows, including those to the ERP.

In the case where the industrial process is distributed over several sites (production and distribution plant in particular), the activation of the preventive fallback posture should not cut off the flows between these different sites. Indeed, specific links should be dedicated to this. If this is not the case, use of the office network to ensure these connections, for example, a project to overhaul the industrial network is probably to be expected (deployment of a dedicated VRF, or a SDWAN network for example).

Finally, it is always good to remember that each factory is different, so a local study will have to be carried out on each one to understand its specificities.

Last resort fallback position: switch off the information system in the event of a proven attack on the plant

Finally, it may be interesting to prepare a last resort fallback posture. This should consist of isolating each VLAN (if defined, preferably with a local HMI per VLAN to ensure a degraded mode) or each piece of equipment (turn off the switches) in order to prevent the attacker from continuing his actions, which in the most advanced cases of attack, could directly target the site’s industrial process.

The objective is then to secure the site or ensure its essential services. The activation of this posture implies working without an information system and should only be applied in the event of proven compromise of at least one piece of equipment on the site, since it leads to the same immediate result as a ransomware, if not worse.

An upstream work with the operators will be necessary in order to list all the actions to be carried out when this posture is activated and to define degraded modes. Indeed, this will generally require the activation of on-call duty in order to manually perform certain tasks: checking the correct operation of equipment, especially on remote sites, use of local HMIs, etc. Moreover, some industrial processes are no longer manually controllable today, and will therefore have to be stopped since no degraded mode is available.

In order to estimate the impacts of activating such a posture, it may be interesting to look at the impacts listed in the event of fire or a general power failure. Moreover, only a real test of this posture can ensure its operational impacts.

How to recover after an attack if it has not been contained?

In some cases, the activation of fallback postures may not be sufficient to protect the entire industrial information system, especially if they are activated too late. It is then essential to be able to proceed with the reconstruction of all or part of the said system in a sufficiently short time to limit the associated impacts.

The main prerequisites for restoring an industrial information system are listed below.

What must be backed up to be able to restore its PLCs?

In order to be able to restart the factory, it is necessary in most cases to start restoring PLCs, which requires two main elements.

Having an up-to-date copy of your PLC programs

PLCs are spared in most current attacks, probably because targeting Windows workstations is enough for attackers to achieve their intended objectives. However, attacks are likely to be increasingly targeted, and most PLCs currently in use are not secure (unencrypted and unauthenticated communications, default passwords, administration functionality that cannot be deactivated, etc.).

It is therefore necessary to save these programs, which is already generally the case, particularly on the programming station (sometimes belonging to a service provider) used when the device is commissioned. It should be noted that these backups should be stored on at least one off-line medium, so that they are not encrypted in the same way as the workstation hosting them.

These observations remain valid even for the new generations of PLCs, which, although benefiting from a level of security that is far superior to that of their predecessors, are not invulnerable.

Save a means of downloading these programs to the PLCs

Many PLCs require dedicated software to be programmed. This is even the case if you just want to download an already written program. It is therefore advisable to have a copy of these programs.

In some cases, a programming station disconnected from the network and reserved for this purpose can be a solution. It should be noted, however, that maintaining such a station in a safe condition can quickly become complex. If this solution is selected, this station could also host the copy of the PLC programs. Keeping a second backup set off-line (external hard disk for example) would however be an additional security measure.

Furthermore, if new generations of PLCs are used, with the latest security features enabled, other elements should be backed up such as: PLC program passwords, certificates used for certain communications (or a means of regenerating them) etc.

These prerequisites are also valid for network equipment (firewalls, switches etc.).

What needs to be backed up to be able to restore essential computer hardware?

Identifying what is really needed

Restoring SCADA system, and associated client workstations, is generally equivalent to restoring a Windows system and associated programs. Several questions must be asked to identify the items to be backed up:

• What equipment is needed? An engineering workstation, a SCADA server, a few operator workstations?
• Is it possible to reinstall the SCADA system from scratch (new installations of Windows and the supervision software) and then deposit a backup of the SCADA configuration? Is this feasible in a sufficiently short time?
• Would not a complete copy of the SCADA server disk be simpler? It would indeed be sufficient to insert the saved disk to reboot.
• Are changes regularly made to the supervision software? If yes, is it necessary to back them all up? In this case, it seems complex to make a complete copy of the disk each time.

Backing up intelligently

In many cases, backups of Windows workstations are made in the same way as those of PLC programs, by copy/paste. It could then be interesting to look at automatic backup mechanisms. However, these are probably to be avoided for factories starting from scratch and not having enough budget to install them serenely. Indeed, implementing this type of solution in a secure manner is generally more complex than making a simple bit-by-bit copy of a hard disk.

Do not neglect documentation and training

However, it is not enough to have complete backups available. It is also necessary to draw up detailed operating procedures for restoring these backups. Indeed, if a crisis were to occur, the stress of the teams and the potential unavailability of some of the knowledge could lead to handling errors in the absence of documentation.

These procedures are not intended to enable a complete restoration of all systems, but at least to enable the essential elements previously identified to be restarted:

• An engineering workstation with the associated PLC programming software;
• A SCADA server;
• Two to three operator workstations;
• The plant’s essential PLCs.

In addition, it is generally recommended to have at least two sets of backups, one to be stored near the equipment concerned, the other to be stored on another physical site, with access limited to a limited number of people. It may be tempting to store an additional set of backups online, but it should be noted that in the event of a cyber-attack, and activation of fallback procedures, it is complex to download these backups and deposit them on the systems to be restored.

Finally, it is essential to test all these procedures to ensure that they are exhaustive. A test could, for example, be the opportunity to realise that the backup of the SCADA configuration does not include the licence key, or that the passwords configured when the complete disk was copied have since been modified without keeping the history.

Conclusion

Crisis management is an important component of the business for many industrial system operators. These same people are also the most experienced in their perimeter. However, they are generally not IT experts. Pragmatic measures, adapted to their context, will therefore be far more useful than a generic 200-page guide containing all the good practices to be applied to an information system.

As in development with the KISS principle (Keep it simple, stupid), fallback postures, as well as restoration procedures, should be kept simple to understand, and stupid to apply.

Furthermore, although the application of a strict network filtering policy can only be advised, it is not strictly necessary for the implementation of backup and recovery actions. Thus, even if the probability of a successful attack is increased, it will still be possible to restore critical systems.

Finally, it should be noted that more and more industrial processes are nowadays operating in a just-in-time mode. In this type of context, the preservation of the industrial system from an attack, or the ability to restore it quickly, would not be sufficient to maintain the level of production if the management of orders or distribution, for example, are unavailable. Cyber resilience must therefore be considered at the company level, and not only at the level of the industrial site.

Key elements

To respond to an attack before it is late, it is necessary:

• To involve the industrial teams (without which it is highly likely that the computer will survive the attack, but without the factory continuing to fulfil its primary mission);
• To control its flows and implement network partitioning/filtering in order to be able to set up fallback postures:
  • Preventive, in order to isolate the factory in the event of an attack on an external network without having too significant an impact on the industrial process;
  • As a last resort, in order to shut down the information system in the event of a proven attack on the factory before the attacker modifies the industrial process.
• To test these fallback postures, in order to ensure that their activation is not worse than the attack.

And in the case where the attack could not be contained, the following elements are generally necessary in order to recover from the said attack:

• Possess an up-to-date copy of your PLC programs;
• Save a means of downloading these programs to the PLCs;
• Have at least one copy of all critical backups on an off-line medium (external hard disk for example);
• Identify its essential computer equipment (in particular so as not to restore the history server before the supervision server, etc.);
• Backing up intelligently, sometimes a bit-by-bit copy of the hard disk is more efficient than an automatic copy on a dedicated server, generally encrypted at the same time as the system whose backups it hosts;
• Don’t neglect documentation and training (otherwise a forgotten license key, or someone on holiday could quickly sign the end of the restore…).

[1] www.cert.ssi.gouv.fr/uploads/CERTFR-2020-CTI-001.pdf

A new version of the threat assessment was published at the beginning of the year: https://www.cert.ssi.gouv.fr/uploads/CERTFR-2021-CTI-001.pdf

Cet article Cyber resilience in an industrial environment 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.