Operational resilience beyond business continuity plans
Traditional business continuity planning is often little more than a box-ticking exercise, resulting in five hundred pages of documentation that no one reads until it is far too late. True operational resilience is not a document; it is a measurable capability to endure stress and maintain core services during a crisis. For the modern founder or security lead, this means moving beyond 'disaster recovery' to a model of constant, graceful degradation.
Michael McCarroll— Founder · 20+ yrs GRC, ISO 27001 lead implementer 16 min read Updated June 2026
The Fallacy of the Dust-Gathering Document
The biggest mistake I see in mid-market firms is treating Business Continuity Plans (BCPs) as an insurance policy rather than an operational manual. A 200-page PDF sitting on a SharePoint drive is useless if the person who wrote it is the one unavailable during a breach. Resilience is about the 'Mean Time to Recovery' (MTTR) and the 'Recovery Time Objective' (RTO) being tested, proven, and integrated into your daily workflow.
Clause 8.2 of ISO 22301 insists on a formal Business Impact Analysis (BIA), but most firms skip the hard part: quantifying the cost of downtime. You need to know exactly how many minutes of downtime your customers will tolerate before they invoke their SLA penalty clauses or seek a competitor. This isn't just about servers going down; it's about the financial and reputational fallout of a service interruption.
Mapping Critical Business Services and Impact Tolerances
You cannot protect everything with equal intensity, so you must prioritise your critical business services. This starts by mapping every dependency required to deliver your core value proposition. If you are a FinTech, this might be your payment gateway; if you are HR-Tech, it’s your data integrity and availability during payroll cycles.
Once these services are identified, you must set an 'Impact Tolerance.' This is the point at which a disruption causes significant harm to your customers or the market's stability. It is often much shorter than founders think. If your RTO is 4 hours but your customers' tolerance is 30 minutes, your business continuity plan is effectively a failure from the start.
Identify the 'Crown Jewels' or primary revenue-generating services.
Assign a Maximum Tolerable Period of Disruption (MTPD) for each service.
Map the 'Service Chain' including third-party APIs, specific personnel, and hardware.
Define the 'Minimum Business Continuity Objective' (MBCO)—the bare minimum output you must maintain to stay legal or solvent.
Stress Testing: Beyond the Tabletop Exercise
Most firms test their resilience with 'tabletop exercises' that are far too polite. Real crises are messy, confusing, and happen on Friday evenings. To build true resilience, you must run stress tests that involve 'Total Loss of Facility' or 'Loss of Key Personnel' scenarios. This isn't just about failing over to a backup server; it's about whether your junior engineer knows what to do when the CTO is on a long-haul flight without Wi-Fi.
Evidence-based resilience requires post-incident reports that are brutally honest. Every time a minor outage occurs, it is a free rehearsal. Use the '5 Whys' technique to get to the root cause. If the root cause was 'human error,' your systems aren't resilient enough—resilient systems are designed to fail-safe even when humans make mistakes. ISO 27001 Clause A.17 expects this level of planning, but the best firms go further by automating their response scripts.
Third-Party Risk: The Hidden Threat to Your Resilience
Your resilience is only as strong as your weakest SaaS provider. In a world of interconnected APIs, a vulnerability in a minor logging tool can take down a global platform. Founders must move beyond just signing a DPA and actually scrutinise the uptime and redundancy of their suppliers. This is often referred to as 'Concentration Risk'—the danger of having too many critical eggs in one cloud provider's basket.
Treat your vendors as an extension of your own infrastructure. If a vendor goes down, your customers won't blame the vendor; they will blame you. You need a 'Degraded Mode' of operation where your platform can still function—perhaps with reduced features—even if a non-core third-party service is offline. This architectural resilience is what separates the winners from the losers in enterprise procurement.
Audit the SOC 2 or ISO 27001 reports of your 'Tier 1' vendors annually.
Maintain an 'Alternative Vendor List' for critical services like SMS gateways or CDN providers.
Review 'Right to Audit' clauses in your contracts to ensure you can verify their resilience.
Implement 'Circuit Breakers' in your code to prevent a third-party API failure from cascading into a total system crash.
Building a Culture of Continuous Improvement
Resilience is a cultural attribute, not a technical one. It requires a 'no-blame' culture where staff feel empowered to report near-misses. If your team is afraid to admit they clicked a suspicious link or misconfigured a S3 bucket, you will never have a true picture of your risk landscape. Transparency is the bedrock of ISO 22301 and ISO 27001 success.
Executive buy-in is also non-negotiable. Resilience costs money—whether it's in redundant infrastructure or extra headcount. To win the budget, frame resilience as a sales enabler. Enterprise buyers are increasingly asking for proof of operational resilience during the RFI stage. Showing a prospective client a live, tested resilience dashboard is a far more powerful sales tool than a generic security policy.
Stop writing plans and start building resilience today.
Moving from static PDF manuals to a living, breathing GRC framework is the only way to prove resilience to enterprise buyers. Use ISO-STANDARD.app to automate your risk assessments, manage documentation, and turn your security posture into a competitive advantage that wins high-value contracts.
ISO-STANDARD.app ships a ready-to-adopt Resilience workspace with the risk register, controls catalogue, policies and audit-ready exports already wired together — no spreadsheet sprawl, no consultant lock-in.
Prefer a conversation? Email hello@iso-standard.app — a real human responds within one business day.
Frequently asked questions
What is the difference between business continuity and operational resilience?
While BCP focuses on how a business recovers after a disaster, operational resilience is the ability of an organisation to absorb and adapt in a changing environment to deliver its objectives. BCP is reactive; resilience is proactive and embedded into the daily operating model.
How do I identify 'Critical Business Services'?
Focus on the 'Minimum Business Continuity Objective' (MBCO) found in ISO 22301. Identify your core products, find the Maximum Tolerable Period of Disruption (MTPD) for each, and map every dependency—software, people, and third parties—required to keep those specific services alive.
How often should we test our resilience plans?
At a minimum, perform a tabletop exercise annually. However, high-growth firms should conduct 'micro-simulations' quarterly. These are 30-minute drills focusing on a single point of failure, such as a localized API outage or the sudden departure of a key staff member.
What is concentration risk in the context of SaaS?
Concentration risk occurs when you rely too heavily on a single provider for multiple critical functions. To mitigate this, ensure your 'Exit Strategy' is documented and tested, and use the 'Plausible Denial' test: if your primary cloud provider went offline for 48 hours, do you have an immutable backup and a manual workaround?
Action checklist PDF
Mirrors this guide with owners, artefacts & a 30/60/90-day plan.
