From Compliance to Competitive Advantage: What Operational Resilience Actually Requires

Most disaster recovery plans get tested the same way: during an actual disaster. While regulators enforcing DORA and NIST2 are only just starting to hand out penalties, we're already seeing the cost of non-compliance in news headlines. The global CrowdStrike glitch incident grounded major airlines a couple of years ago, causing losses in the hundreds of millions.

That's the gap Ardoq and Protiviti addressed on Ardoq's latest Jumpstart webinar. Sean Gibson, Ardoq's Principal Enterprise Architecture Researcher, joined Protiviti's Michael Lawrence, Director of Cybersecurity Transformation, and Roland Carandang, Managing Director for CISO and CIO Services. They discussed what separates a routine, audit-compliant resilience program from one that survives an actual incident.

Watch the full webinar, or keep reading for the highlights.

Why This Matters Even if You Are Not Regulated

Roland opened with the pressure most architecture leaders are already carrying. Organizations are trying to modernize and protect the business in roughly equal measure, while facing more scrutiny from regulators, customers, and their customers' own regulators. Simplifying the technology estate in one area, for good reasons like cost and security, often introduces new complexity elsewhere, especially as AI capabilities are added. At the same time, a shift toward domain and product operating models is putting pressure on shared service teams to keep pace.

For those early in their modernization journey, that means reconciling old and new systems. For those further along, it can mean concentration risk that needs managing. Either way, as the integration points multiply, so does the web of people, process, and technology behind every service a customer touches.

What Monzo Got Right When Its Banking Platform Went Down

Michael's example of "good" came from the headlines rather than a case study. When UK fintech Monzo hit an issue with its main banking platform, it activated what it calls "stand-in architecture," a completely separate environment on Google Cloud, built apart from its primary AWS setup. Customers lost access to some functionality, but the essentials, the things that were actually needed to run a bank, stayed up.

Most companies will never build a fully duplicate architecture, and Michael was upfront that this isn't the bar everyone is expected to clear. The major takeaway is the thinking behind it: understand and map your environment, plan for the scenarios that could take it down, and actually test that the organization can keep operating as a minimum viable business. A plan nobody has rehearsed is not sufficient.

Planning Isn't Proof

This is where Michael drew the line between disaster recovery, the technical and more familiar piece, and business continuity, which covers the people and processes around it. Static planning satisfies neither. Real evidence means building scenarios, testing them, learning from what breaks, and feeding that back into the plan, particularly if a regulator ever asks to review it. It's easier said than done, and disaster recovery in particular tends to sit deep inside IT, disconnected from the rest of the business.

Beyond the Dusty DR Binder: A Look Inside the Live Demo of Data-Driven Operational Resilience

Sean's description of the default state was blunt: most organizations have disaster recovery plans that, in practice, sit in an old, dusty binder in a filing cabinet, drafted several application iterations ago. DORA and NIST2 turn that from an operational embarrassment into a compliance gap, since organizations now need to prove they can restore services, not just describe how they would.

Ardoq's approach starts from an organization's existing application portfolio, often already ingested from a CMDB like ServiceNow, and layers two component types on top: a disaster recovery plan, capturing what the organization actually does today, and an impact assessment, capturing what the business needs from a given application. Comparing the two surfaces the gap between promise and delivery. In his demo, out of 147 applications in the portfolio, 62 were classified as critical, yet 55 of those had no disaster recovery plan in place. This scenario reflects what many disaster recovery plans usually don't account for.

The comparison also catches specifics a spreadsheet would miss. One flagged example: an intrusion prevention system with a 12-hour recovery requirement, sitting against a DR plan that could only deliver a 24-hour restore point because backups ran daily. With Ardoq, AI agents in the platform can pull the full picture for a given application, such as an SAP ERP instance, into a more accurate blast radius report that reflects the connected infrastructure, dependent capabilities, and the people and business units that would feel it if that application went down. This is the level of detail that a dynamic disaster recovery plan should include for true operational resilience.

Learn more about The Critical Role of EA in Cyber and Operational Resilience.

Making the Business Case: Carrot, Stick, and Buy-In

Funding conversations came up early in the session's Q&A. Roland and Sean recommended splitting the pitch into two halves: the carrot and the stick. The carrot is cost avoidance, mapping toward a minimum viable business makes it much easier to put a number on what an outage actually costs. The stick is regulatory, and it goes beyond the fine itself.

"There's something less quantifiable but very impactful with regulators, which is scrutiny itself, separate from any fine. When you have to respond to and remediate issues under regulatory scrutiny, it compresses your timeframes significantly, and you may end up doing things dictated by a specific regulator, with much less self-determination than you'd have otherwise had."

Roland Carandang, Managing Director for CISO and CIO Services at Protiviti

Buy-in was the harder problem. Michael pointed out that this kind of work is rarely a side-of-desk task, and skipping the effort to secure real seniority behind it tends to come back around a year or two later. Sean advised stopping the treatment of disaster recovery as purely an IT conversation.

"That lets you move out of the 'IT bubble,' which is a trap a lot of enterprise architecture functions fall into, and into the business, using the business as an ally to justify investment in infrastructure or disaster recovery capabilities."

Sean Gibson, Principal Enterprise Architecture Researcher at Ardoq

Dependency Mapping Extends to Third-Party Risk

One audience question pushed the discussion toward suppliers. Roland noted that most high-risk supplier lists are built on spend data alone, missing smaller vendors that may sit deep in a customer-facing service without anyone noticing. Sean added that Ardoq's model already treats third-party organizations and their contracts as part of the same graph as internal applications and teams, so the same blast-radius view that flags an internal gap can flag a supplier one too.

Takeaways for Architecture and Compliance Leaders

None of this is a new discipline. Mapping dependencies, understanding impact, and proving readiness are things Enterprise Architecture has always been asked to do. What's changed is the audience. DORA and NIST2 mean a regulator might ask for the evidence directly, and an operational resilience program that only exists on paper will not hold up.

If DORA, NIST2, or a general prove-it-don't-just-plan-it mandate is on your desk this year, Ardoq's regulatory compliance solution shows how to connect obligations directly to your architecture, so evidence is something you can rapidly generate rather than scramble to assemble under pressure.