ISO 22301 is the international standard for business continuity management. Most published practical guidance on it was written with manufacturing or single-site service organisations in mind. For digital-first organisations — e-commerce platforms, payment processors, technology-enabled services — the standard's framework still applies, but the operational instantiation differs in ways that matter substantively.

Why manufacturing BCM frameworks do not transfer directly

The implicit operating model behind most BCM literature is a manufacturing or service organisation with identifiable physical sites, definable physical and process dependencies, and disruption scenarios that primarily centre on site-loss events: fire, flood, equipment failure, supplier disruption, workforce unavailability. Recovery objectives (RTO and RPO) are typically calibrated to the time and data tolerance the business has for these site-loss scenarios. Recovery strategies tend toward physical alternatives — alternative sites, redundant equipment, supplier diversification.

For a digital-first organisation, the dependencies are different in kind and in distribution. The critical processes do not run at identifiable physical sites in the same way; they run on cloud infrastructure provided by third parties, depending on a stack of services (payment, identity, messaging, mapping, fulfilment, customer support tooling) each of which carries its own continuity posture and recovery characteristics. The disruption scenarios that matter are different: cloud region failure, third-party service degradation, API contract changes, security incidents, regulatory actions on payment infrastructure. Recovery objectives have to be calibrated against business reality measured in minutes for transaction services and hours for adjacent processes — far tighter than manufacturing BCM typically contemplates.

A digital-first organisation that attempts to apply manufacturing BCM frameworks directly produces a BCM programme that satisfies ISO 22301 documentation but does not address its actual operational risk reality. The standard provides the framework. The framework needs intelligent instantiation.

The digital-first dependency map

The dependency mapping question in ISO 22301 (Clause 8.2 — business impact analysis) for a digital-first organisation has to capture multiple dependency types that manufacturing frameworks tend to compress. The dependency map should explicitly identify:

  • Cloud infrastructure dependencies — which cloud provider, which regions, which services within those regions, what the failover topology actually is in operational reality (not just in architecture diagrams)
  • Third-party service dependencies — payment processors, identity providers, messaging providers, fulfilment partners, customer support tooling, observability stack, security tooling — each with its own continuity posture and contractual recovery commitments
  • Internal technology dependencies — the inter-service dependencies within the organisation's own architecture; the cascade pattern when a foundational internal service degrades
  • People dependencies — distinct from manufacturing where critical-skill loss is location-bound; distributed workforces create different continuity questions
  • Regulatory dependencies — particularly for payment, financial services, and regulated digital infrastructure where regulatory permission can be withdrawn or suspended

The mapping exercise is operationally substantial. Most digital-first organisations underestimate the depth of dependency they have on infrastructure they do not own and cannot directly control.

RTO and RPO calibration for digital services

For a manufacturing organisation, an RTO of 24 or 48 hours for a critical process is often plausible — the business may tolerate a day or two of disruption while alternative arrangements activate. For a transaction-processing digital service, an RTO of 24 hours is generally unacceptable: customer attrition, regulatory exposure, and reputational damage accumulate at a per-hour rate that compounds quickly. Most digital-first BCM programmes need to calibrate RTOs in minutes for the front-of-house transaction layer and in hours for the supporting back-office processes.

RPO calibration follows similar logic but with different drivers. Customer transaction data typically has zero-tolerance RPO requirements — no loss of completed transactions is acceptable. Internal operational data has more tolerance. Analytical and reporting data has higher tolerance still. The BIA needs to differentiate these layers explicitly, because the architectural choices needed to support different RPOs differ in cost and complexity by orders of magnitude.

Third-party continuity — the often-forgotten dimension

Manufacturing BCM frameworks treat supplier continuity as one input among many. For digital-first organisations, third-party continuity is structurally central — the organisation's own continuity is bounded by the continuity of the third parties on which it depends. If the payment processor goes down, the e-commerce platform's transactions stop regardless of how well the platform's own infrastructure is operating.

Substantive third-party continuity management for digital services has several requirements: explicit identification of all third parties on the critical path; understanding of the continuity commitments each third party makes contractually; verification of whether those commitments are operationally credible; deployment of fallback or graceful-degradation patterns where critical-path third parties have unsatisfactory continuity postures; explicit exercise scenarios that include third-party failure events.

Most digital-first BCM programmes do the first of these (identification). Many do the second (contract review). Few do the third (operational verification) and even fewer do the fourth (architectural fallback design) substantively. The Flipkart Group engagement structured all four into the standard programme architecture.

Exercise design for digital infrastructure

ISO 22301 Clause 8.5 requires exercise of business continuity plans. For manufacturing organisations, exercises typically take the form of tabletop simulations, evacuation drills, and occasional alternative-site activation tests. For digital-first organisations, the most operationally useful exercises are technical: chaos-engineering exercises that intentionally degrade or fail services to verify that the architectural and operational fallbacks function under representative conditions; dependency-failure exercises that simulate third-party service degradation; full-stack failover exercises that verify the published recovery topology actually works under realistic load.

Tabletop exercises remain relevant for executive-level scenarios — major incidents, regulatory responses, customer-communication coordination — but the operational confidence in continuity capability comes from technical exercise rather than discussion exercise. A digital-first BCM programme that has not actually failed and recovered services under controlled conditions has not tested the most important parts of its continuity capability.

Group-level versus entity-level BCM coordination

Digital-first organisations are often structured as groups of entities sharing infrastructure — the Flipkart-Myntra-Jabong-PhonePe pattern is a clean example, but it recurs across the sector. ISO 22301 implementation in this context has to balance two requirements that are in tension: entity-level fidelity (each entity has its own customers, regulations, and operating model) and group-level coordination (shared infrastructure means correlated failure modes and shared recovery capability).

The pattern that tends to work: a group-level BCM framework defining shared policies, exercise cadence, and incident-management protocols, supplemented by entity-level BCM plans that address entity-specific risks and recovery procedures. Entity-level autonomy preserved where it matters operationally; group-level coordination provided where shared infrastructure makes separate plans illusory.

The pattern that tends not to work: full centralisation (group-level plans that ignore entity- specific operational reality) or full fragmentation (entity-level plans that ignore shared dependencies). Both produce BCM documentation that does not match operational reality, and exercise programmes that fail to test the failure modes that actually matter.