ISO 22301 Clause 5.2: Policy

Quick Reference (60 Seconds)

If you only read one thing: Clause 5.2 is where the BCMS stops being a programme and becomes an institution. A 5.2-conformant BCMS is one in which the organisation possesses a fit-for-purpose, sponsored, communicated, available, and maintained BC Policy that demonstrably drives downstream artefacts, not one in which a template sits on a shared drive. The certification auditor will examine this distinction ruthlessly, and so will a regulator after a real disruption. Get 5.2 wrong, a generic, undated, uncommunicated, unavailable template, and however strong the BIA, the strategy and the plans, the certificate will be at risk and the resilience will fail on the day it is tested. Get it right, and every other clause becomes easier to evidence because the policy is the spine that runs through them.

What the Standard Actually Requires

Figure · Process

What Clause 5.2 asks you to do

The paraphrased requirement

ISO 22301 Clause 5.2 asks organizations to set a business continuity policy that fits the organization, commits to requirements and improvement, and is communicated and available. Four ideas do the work in that paraphrase. The policy must be fit-for-purpose (appropriate to the purpose, context, and scope of the organisation). The policy must commit to meeting applicable requirements, to providing the framework that drives BC objectives, and to ongoing BCMS improvement. The policy must be communicated within the organisation and to relevant interested parties. The policy must be available as Documented Information, accessible to those who need it.

ISO 22301:2019 Clause 5.2 is short, most of the requirement is captured in a small number of sentences. The depth lives not in the clause text but in the architectural decisions an organisation must make to satisfy it. The standard requires the policy to do four jobs at once. First, the policy is the apex artefact of the BCMS, every other BCMS document (scope statement, BIA report, strategy, plans, exercise schedule, audit reports, management review minutes, corrective-action log) is downstream of, and consistent with, the policy. Second, the policy is the commitment instrument, it binds the organisation, by top management's signature, to its applicable requirements, to ongoing improvement, and to the framework that drives objectives. Third, the policy is the communication instrument, it tells staff, contractors, customers, suppliers, regulators and insurers what the organisation will do when disrupted. Fourth, the policy is the available instrument, it is hosted, retrievable, version-controlled, and accessible in formats and languages that its audiences can use.

The four commitment statements

ISO 22301 Clause 5.2 enumerates, in paraphrased form, the commitments the policy must include. Four commitments are the load-bearing content of any BC Policy and form the spine of the seven-section anatomy in Section 7 of this guide. The wording below is Singahi's paraphrase; the standard's own formulation is not reproduced.

1. A commitment to meeting applicable requirements. "Applicable requirements" is a deliberately broad phrase: it includes applicable legal and regulatory requirements (for an Indian firm this typically spans the IT Act 2000, the DPDP Act 2023, sectoral requirements from RBI / SEBI / IRDAI / TRAI / MeitY, the Companies Act 2013, the Disaster Management Act 2005, and any state-level industry regulations), contractual and customer requirements (SLAs, master service agreements, customer security questionnaires, insurer warranties), and the organisation's own self-imposed requirements (industry standards, voluntary codes, parent-company policies). The policy commits the organisation to maintain the capability to meet these requirements during and after a disruption, not merely to comply in normal operations. This is a critical nuance: a policy that says "we comply with the law" is not a BC Policy; a BC Policy says "we maintain the capability to continue prioritised activities during disruption, and thereby to continue meeting our legal, regulatory, contractual and self-imposed obligations."

2. A framework that drives how BC objectives are defined and revisited. Objectives live in Clause 6.2, but the framework that produces them is a policy commitment. The framework specifies who sets objectives, on what cadence, against what dimensions (RTO, RPO, MBCO, MTPD, exercise pass rates, recovery costs, regulator-reporting timeliness), how they are approved, how they are cascaded to process owners, and how they are revised when context changes. Without the framework, objectives are arbitrary; the policy commits the organisation to a discipline.

3. A commitment to ongoing BCMS improvement. Improvement is operationalised by Clauses 9.1 (monitoring), 9.2 (internal audit), 9.3 (management review), 10.1 (corrective action) and 10.2 (continual improvement). The policy binds top management to maintain and improve the BCMS, not to build it once. The commitment is what the management review agenda (Clause 9.3) tests against.

4. A commitment to the protection of business continuity before, during and after a disruption. Some formulations of ISO 22301 policy content treat this as implicit; many Indian growing companies include it explicitly because it operationalises the protection obligations that run across the disruption lifecycle. RBI's Master Direction IT Governance (7 November 2023), SEBI CSCRF (20 August 2024) and IRDAI ICS 2023 all require controls that span prevention (before), response (during), and recovery and adaptation (after). The policy is the natural place to commit to that full lifecycle.

Two further commitments are common in well-formed Indian BC Policies because they are mandated or strongly implied by the Indian regulatory environment: a commitment to maintain the regulator-reporting capability (the CERT-In 6-hour clock, the DPDP 72-hour clock, the RBI 2 to 6 hour clock, the SEBI RE 6-hour clock, the IRDAI clock, see the table in Section 1), and a commitment to continuity of outsourced and third-party-delivered activities (which is where the bulk of modern Indian business continuity risk actually lives, see Clause 8.1.3 and the RBI Master Direction on Outsourcing of IT Services, 10 April 2023).

What the standard does NOT require (the demarcation competitors miss)

Clause 5.2 is widely misread as a paperwork exercise, download a template, fill in the blanks, sign it. That misreading produces the single most common 5.2 nonconformity in the Indian small-and-growing-company segment. Being explicit about what 5.2 does not require protects against two failure modes: under-investing (treating the policy as a template) and over-reaching (treating the policy as the entire BCMS).

• 5.2 does not require a specific policy length. Some of the best BC Policies in Indian BFSI are two pages; some are twenty. The test is whether the policy does its four jobs (apex, commitment, communication, available), not whether it hits a word count. Templates that pad to a length should be edited down.
• 5.2 does not require the policy to contain the BIA results. The BIA is a Clause 8.2 activity; the policy references the BIA (it commits to using its outputs to drive strategy) but does not reproduce it.
• 5.2 does not require the policy to contain the BC Strategy. Strategy is a Clause 8.3 activity; the policy commits to having one and to its alignment with the BIA, but the strategy document is separate.
• 5.2 does not require the policy to contain the BC plans. Plans are Clause 8.4; the policy commits to their existence, exercise, and improvement, but they are separate documents (and are typically much longer than the policy).
• 5.2 does not require a specific governance structure. ISO 22301 does not mandate a BCM Steering Committee, a board Risk Committee, or any particular named forum. The policy typically names the governance bodies the organisation has chosen, but the structure itself is not standardised.
• 5.2 does not require the policy to be approved by the Board. Top management approval is required (Clause 5.1); for some Indian regulated entities (banks, listed companies, insurers) board or board-committee approval is additionally required by sectoral regulation, but that is a regulatory overlay, not a 5.2 requirement per se. For most growing companies, the CEO/MD signature suffices; for SEBI LODR Reg. 21 entities, the Risk Management Committee must be in the chain.
• 5.2 does not require variable-pay linkage to policy compliance. Pay linkage is a leading-practice signal of L4 to L5 maturity, not a standard requirement.
• 5.2 does not require a separate "Policy Manual." Many Indian firms maintain a BCMS Manual that bundles the policy with the scope, roles, and process map; this is permitted but not required. The policy can stand alone as a one-to-two-page instrument.
• 5.2 does not require translation into every language of the workforce. It requires the policy to be available to its audiences; for a multilingual Indian workforce, this means a policy-on-a-page summary translated into the dominant workplace languages and accessible formats, but full translation is a leading practice, not a baseline requirement.
• 5.2 does not require public publication. "Available to relevant interested parties" does not mean published on the open internet. Most Indian firms publish the policy on the intranet (staff), on a customer trust portal (customers and prospects, sometimes redacted), on a vendor portal (suppliers), and provide it on request to regulators and insurers. Public posting is a brand-led choice, not a 5.2 obligation.

The companion guidance (ISO 22313:2020 Section 5.2)

The clause text is short; the method lives in ISO 22313:2020 Section 5.2 (the clause-by-clause companion) and in the lineage of Harmonized Structure management-system standards. Five external anchors are most relevant for Clause 5.2.

• ISO 22313:2020 Section 5.2 explains that the policy should be appropriate to the organisation's purpose, scale, and the nature of its risks. It emphasises that "top management" is the policy's authorising authority; the BCM Lead may draft it, but the executive sponsor must own and sign it. The companion also confirms the policy should be a brief, strategic document, operational detail lives in the plans, not the policy.
• ISO/IEC 27001:2022 Clause 5.2 is structurally identical. If your organisation runs an integrated ISMS+BCMS, a single integrated information-security-and-business-continuity policy can satisfy both clauses (with a clearly-labelled sub-section for each), or two aligned policies can sit side-by-side. Indian growing companies commonly pursue both standards concurrently; the policy is the natural point of integration.
• ISO 9001:2015 Clause 5.2 is the same requirement for the QMS. Indian manufacturers running ISO 9001 typically have a strong 5.2 foundation (quality policy, quality objectives, management review) that can be extended to BCMS with marginal incremental effort.
• NIST SP 800-34 Rev 1 Step 1 (develop the contingency planning policy statement) is the US federal analogue, the explicit placement of policy authorship as the first step in the seven-step contingency planning process. Step 1 is the policy clause of NIST's BCM lineage, and NIST provides a free BIA template and ISCP templates that begin with a policy statement.
• FFIEC BCM Booklet (Nov 2019), the governance and accountability principle is the FFIEC's 5.2: board and senior management must establish, approve, and maintain a BCM policy that drives the programme. The booklet is structured almost as a US-banking restatement of ISO 22301 Clauses 5 through 8.

What auditors actually check

The certification auditor's Clause 5.2 examination has six predictable moves. Preparing for them is the most efficient way to convert a Stage 1 visit into a Stage 1 pass.

First, the auditor opens the policy and reads the four commitment statements. If any of (a) applicable requirements, (b) the framework for objectives, (c) continual improvement is missing, major nonconformity. If the commitment to applicable requirements is generic ("we comply with applicable laws") without naming the regulator landscape, minor nonconformity, corrected on the day.

Second, the auditor asks the executive sponsor to describe how the policy is "appropriate to the organisation's purpose." This is the fit-to-purpose test. The sponsor must be able to connect the policy's content to the organisation's context (Clause 4.1 outputs), its interested parties (Clause 4.2 outputs), and its scope (Clause 4.3 output). A sponsor who cannot answer this question has signed a policy they did not author; that is a Clause 5.1 finding but it surfaces first under 5.2.

Third, the auditor checks the version history. Is the policy dated? Is the next review date set? Has it been reviewed within the last 12 months (or sooner if an event trigger fired)? Is the version-control trail intact (per Clause 7.5 Documented Information)? A policy with no version history is treated as a document that does not exist for audit purposes.

Fourth, the auditor samples staff. "Have you seen the BC Policy? Where is it? What does it commit the organisation to?" Five randomly-sampled staff in different functions and locations. If three out of five cannot answer, the communication commitment is failed, minor nonconformity. If four out of five cannot answer, major nonconformity.

Fifth, the auditor asks how the policy is available to interested parties. Where is it on the intranet? Is it on the vendor portal? Can a customer request it? Is it in the management review pack? Is it in the new-joiner induction pack? An "available" policy is hosted, retrievable, and discoverable. A policy that exists only on the BCM Lead's laptop is not available.

Sixth, the auditor traces the policy into downstream artefacts. Do the BC objectives (Clause 6.2) operationalise the policy's commitment to the framework? Does the management review agenda (Clause 9.3) include policy review? Do the corrective-action and continual-improvement logs (Clauses 10.1 and 10.2) close against policy commitments? A policy that is not traced downstream is decoration.

Why This Control Matters

The policy as the spine of the BCMS

Every other clause of ISO 22301 inherits its legitimacy from Clause 5.2. The BIA (Clause 8.2) is justified because the policy commits to identifying prioritised activities. The BC strategy (Clause 8.3) is justified because the policy commits to selecting solutions before, during and after disruption. The plans (Clause 8.4) are justified because the policy commits to a response structure. The exercises (Clause 8.5) are justified because the policy commits to validation. The audits (Clause 9.2) and management review (Clause 9.3) are justified because the policy commits to continual improvement. Without 5.2, the rest of the BCMS is unsponsored effort. With a strong 5.2, every other clause has a defensible origin.

This is not a stylistic observation. It is the operational reality that the certification auditor and the regulator converge on. A BCMS without a fit-for-purpose policy is, in auditor language, a "system without top-management authorisation", which is the most serious structural nonconformity a BCMS can carry. A BCMS with a fit-for-purpose policy that is not communicated or available is, in auditor language, a "system that exists on paper but not in practice", the second most serious. Both are recoverable; both are common; both are most often traced back to a Clause 5.2 failure.

The Indian regulatory weight behind 5.2

In India, Clause 5.2 has a regulatory weight that goes beyond the ISO standard itself. Every major Indian regulator now requires, in some form, a board-approved BC policy or its functional equivalent.

RBI requires (RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices, 7 November 2023, effective 1 April 2024, applicable to scheduled commercial banks, NBFCs with asset base above 500 crore rupees, all-India financial institutions, and credit information companies) a board-approved BCP and DR policy with documented RTO and RPO for critical systems, DRS architecture, periodic drills, third-party continuity controls, and IT readiness for crisis events. The RBI Cyber Security Framework in Banks (2 June 2016) requires a board-approved cyber-security policy with a Cyber Crisis Management Plan (CCMP). The Master Directions on Outsourcing of IT Services (10 April 2023) require outsourced/cloud-provider BCP and DR to inherit the regulated entity's own continuity standards. A bank or NBFC whose BC Policy does not evidence these three strands is exposed on the supervisory lens, not merely the ISO 22301 lens.

SEBI requires (Cybersecurity and Cyber Resilience Framework, CSCRF, circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024, applicable to all SEBI Regulated Entities graded into five categories) a board-approved cyber resilience policy spanning the five goals and six operational functions (Identify, Protect, Detect, Respond, Recover, Learn). The earlier marquee MII BCP-DR circular (SEBI/HO/MRD1/DTCS/CIR/P/2021/33, 22 March 2021) requires MIIs (stock exchanges, clearing corporations, depositories) to maintain Near Site plus DRS architecture, RTO of two hours or less for critical systems, defined RPO, live failover drills, geographic separation, and vendor/dependency BCP, and to do so under board-approved policy.

IRDAI requires (Information and Cyber Security Guidelines 2023, 24 April 2023, applicable to all insurers including foreign re-insurance branches and intermediaries) a board-approved Information and Cyber Security Policy including BCP/DR, with a CISO, 180-day log retention aligned with CERT-In, vulnerability assessments and penetration testing, DR drills, data locality for policyholder data, incident reporting to IRDAI and CERT-In, ICT outsourcing continuity oversight, and annual compliance reporting within 90 days of financial year end. The Board's Risk/IT Committee has an explicit BCP/DR oversight role.

CERT-In Directions (20(3)/2022-CERT-In, 28 April 2022) apply horizontally to every entity operating ICT in India. While CERT-In does not require a single named "BC Policy", the six obligations, report prescribed cyber incidents within 6 hours, maintain 180-day logs within Indian jurisdiction, sync ICT clocks to NIC NTP, maintain KYC of VPN/data-centre/cloud customers for five years, appoint a CERT-In PoC, cooperate with investigations, only function if the organisation has a tested incident-response and crisis-management capability, which is itself a policy commitment under 5.2.

DPDP Act 2023 (Act 22 of 2023, enacted 11 August 2023; DPDP Rules 2025 notified November 2025) creates an explicit availability duty, Section 8(5) requires every Data Fiduciary to maintain the accuracy, integrity, confidentiality and availability of personal data. For any Indian organisation processing digital personal data (which is essentially every Indian business), the BC Policy is the natural place to evidence the availability commitment. Section 8(6) creates the breach-notification duty (notify the Data Protection Board and affected Data Principals in the prescribed form and manner, operationalised by the DPDP Rules 2025 as 72 hours of becoming aware). Schedule penalties: up to 250 crore rupees for failure to take adequate security safeguards; up to 200 crore rupees for failure to notify a breach. A BC Policy that does not commit to the availability duty and the breach-notification capability is, in DPDP language, an inadequate safeguard.

NDMA / Disaster Management Act 2005 (Act 53 of 2005) creates statutory duties on Ministries, State Governments, and local authorities to prepare Disaster Management Plans (Sections 35, 37, 40). The NDMA Guidelines on Preparation of Disaster Management Plans (2014) provide the canonical DMP template (Prevention / Mitigation / Preparedness / Response / Relief / Recovery and Reconstruction / Capacity Building) that Indian organisations mirror in their corporate BC Policies. For chemical and Major Accident Hazard industries (NDMA Chemical Disasters Guidelines 2007), industrial BCP, mutual-aid arrangements, and integration with District DMPs are required.

Companies Act 2013 Section 134(3)(n) requires the Board's Report to include a statement on the development and implementation of a risk management policy for the company, including identification of elements of risk that may threaten the existence of the company itself. Section 177 and SEBI LODR Regulation 21 require a Risk Management Committee with cyber, operational and continuity risk coverage. The BC Policy is the natural place to satisfy the existence-of-the-company-risk statement and to evidence that the Risk Management Committee's mandate covers continuity.

In aggregate: in India, a fit-for-purpose BC Policy is not optional, it is a multi-regulator requirement with monetary penalties attached (RBI enforcement, SEBI penalties, IRDAI direction, CERT-In action, DPDP penalties up to 250 crore rupees). The ISO 22301 Clause 5.2 policy is the natural single instrument that satisfies all of these regimes simultaneously, which is one of the strongest commercial arguments for pursuing ISO 22301 certification in the Indian market.

The cost of non-compliance

The cost of a Clause 5.2 failure breaks down into four bands.

Direct regulatory penalties are the most visible. DPDP Act penalties run to 250 crore rupees. RBI has imposed monetary penalties on banks for repeated digital outages (HDFC Bank was barred from new digital products and fresh credit cards on 2 December 2020 following outages on 21-22 November 2020; an earlier 1 crore rupee penalty was imposed in June 2019; the digital-initiatives ban was partially lifted only in August 2021 and fully in March 2022, a 15-month revenue impact on a major digital product line). SEBI has imposed financial penalties on Market Infrastructure Institutions for BCP-DR deficiencies. IRDAI can issue directions requiring remediation within 90 days, with named-officer accountability.

Indirect regulatory consequences are larger and slower. The HDFC enforcement action carried an external IT audit requirement, supervisory escalations, and reputational drag. Yes Bank's March 2020 moratorium (withdrawals capped at 50,000 rupees per account for the moratorium period) was triggered by governance and liquidity failures in which BC and operational resilience played a part; the deposit base roughly halved from approximately 2.2 lakh crore to 1.1 lakh crore rupees before recovery. SpiceJet's July 2022 DGCA order (50 percent of approved Summer Schedule flights for eight weeks, extended) was triggered by operational and asset-integrity failures, a chronic under-resourcing that is itself a Clause 5.1 and 5.2 failure.

Commercial cost is the largest single category. Customer churn after a disruption, contract forfeiture under SLA breach, lost tenders (especially government and BFSI tenders, where ISO 22301 certification or BCP capability is a bid qualifier), and increased insurance premiums are the channels. Cognizant's Maze ransomware (April 2020) carried a publicly disclosed SEC-filed Q2 2020 impact of 50 to 70 million US dollars in lost revenue and margin; Infosys McCamish's October 2023 LockBit incident affected approximately 6 million individuals and produced a 17.5 million US dollar class-action settlement. Neither was a 5.2 failure in isolation, but in both cases the post-incident regulatory and litigation examination tested the policy and its commitments.

Certification cost is the most immediate for ISO 22301 candidates. A Clause 5.2 major nonconformity at Stage 1 typically adds 4 to 8 weeks to the certification timeline, one extra Stage 1 day of auditor fees (typically 1.5 to 3 lakh rupees per day for an India-based IAF-accredited certification body), and internal remediation effort of 80 to 160 person-hours. A Clause 5.2 minor nonconformity at Stage 2 delays the certificate issue by 4 to 12 weeks and costs a surveillance-visit verification. Both are recoverable; both are entirely avoidable with the discipline this guide sets out.

The board-level angle

For Indian listed companies and BFSI, the BC Policy is increasingly a board-level artefact, not a management artefact. Section 134(3)(n) of the Companies Act 2013 places the risk-management policy statement in the Board's Report; SEBI LODR Regulation 21 places continuity risk within the Risk Management Committee mandate. RBI's Master Direction (7 November 2023) makes board approval of the BCP/DR policy explicit. IRDAI ICS 2023 places BCP/DR oversight in the Board's Risk/IT Committee. The board-level angle is not theoretical: a policy the board has not seen, or has not reviewed, is a governance gap a regulator will name.

The practical implication for the BCM Lead: the BC Policy must be board-presentable. That means short (typically two to five pages for the policy itself, with appendices for the four-commitment expansion), well-structured (the seven-section anatomy in Section 7), free of jargon, dated, version-controlled, and accompanied by a one-page executive summary suitable for the board pack. The executive sponsor presents the policy at the management review (Clause 9.3), and the board reviews it through the Risk Management Committee at minimum annually.

Scope and Applicability

By organisation size

Growing companies (50 to 250 staff). A single BC Policy document covers the whole organisation. The executive sponsor is typically the CEO/MD or COO. The policy is communicated via all-hands briefing, intranet, and new-joiner induction. Multilingual translation is typically a one-page summary in the dominant workplace language. The first cycle (author, approve, communicate, make available) is deliverable in 4 to 8 weeks of internal effort plus optional external advisory. Indicative external-advisory cost in India: 1.5 to 4 lakh rupees for the policy authoring and the first communication cycle.

Mid-market (250 to 2,000 staff). A single BC Policy still suffices, but is typically supported by a small set of subordinate policy instruments (ICT DR policy, supplier continuity policy, crisis communications policy) and a BCMS Manual that bundles the policy with scope and roles. Communication runs through departmental cascades, multilingual summaries (typically English plus two regional languages), and an annual policy-refresh cycle. Indicative India cost: 4 to 12 lakh rupees external advisory for the policy architecture, communication plan, and first audit-cycle maintenance.

Multi-entity enterprise (2,000-plus staff or multi-site). A group BC Policy typically sits above entity-level BC Policies, with a defined parent-subsidy hierarchy. Group-level policy covers minimum standards, group-wide commitments, and the regulator landscape; entity-level policies operationalise for the local context, language, and sectoral regulation. Communication is typically managed through a GRC platform, with multilingual translation across multiple states or countries. Indicative India cost: 15 to 60 lakh rupees external advisory for the policy taxonomy, the group/entity hierarchy, the communication architecture, and integration with the existing GRC stack.

By industry (summary, full detail in Section 21)

By geographic footprint

Single-state Indian operations. The policy covers one regulator landscape (the relevant state, plus the central regulators where applicable). Communication in English plus the state language.

Pan-India operations. The policy covers multiple state-level disaster-management frameworks (especially for multi-site manufacturing), the central regulator landscape (RBI/SEBI/IRDAI/CERT-In/DPDP/NDMA/IT Act), and multilingual communication across major Indian languages. Geographic diversity of sites is a fit-to-purpose input.

India-plus-overseas operations. The policy must reconcile ISO 22301 with the overseas regulator regime, DORA (Regulation (EU) 2022/2554, applies 17 January 2025) for entities serving EU financial sector; APRA CPS 230 (effective 1 July 2025) for entities with Australian prudential nexus; MAS TRM (revised 18 January 2021) for Singapore financial-sector exposure; HKMA SPM (TM-G-2 revised 31 May 2022, OR-2 new 31 May 2022) for Hong Kong authorised institutions; UK FCA/PRA operational resilience for UK exposure. The Indian parent policy typically commits to meeting the most stringent of these, and entity-level policies operationalise locally. The DORA date correction, there is no DORA milestone in June 2025; the DORA application date is 17 January 2025, and the mid-2025 prudential date that exists is APRA CPS 230 (1 July 2025). Do not conflate.

Key Definitions and Terminology

Clause 5.2 uses a small number of terms precisely. The ISO 22300:2021 vocabulary (a 2025 edition is under development (ISO/DIS 22300, 4th ed.) and not yet published, verify current edition at iso.org before quoting a year; the 2018 edition is withdrawn) is the normative source. Where common Indian regulatory usage diverges from ISO, both are given.

Policy

In ISO management-system usage, a policy is the apex statement of intentions, principles, and commitments authorised by top management. A policy is strategic, not operational: it says what the organisation commits to and why, not how the commitment is delivered. The how lives in procedures, standards, plans, and work instructions. The 5.2 BC Policy is therefore a strategic instrument; the BC plans (Clause 8.4), the exercise programme (Clause 8.5), and the BIA report (Clause 8.2) are operational instruments that operationalise the policy. The demarcation is critical: a policy that contains operational detail is not a policy, it is a manual, and it will fail the "appropriate to purpose" test because it is too long, too detailed, and too brittle to be reviewed at board level.

Documented Information

Documented Information is the ISO term for information the organisation must create, control, and maintain to run the management system. Clause 7.5 governs Documented Information generally. The BC Policy is the apex artefact of BCMS Documented Information. Documented Information controls (Clause 7.5.2, creating and updating; Clause 7.5.3, control of Documented Information) require: identification (title, date, author, version); format (paper, electronic, language); review and approval (who signs, when); distribution (who has access); retrieval (how to find it); retention (how long to keep); disposition (how to dispose of superseded versions). The BC Policy must satisfy each of these, and the auditor will test each.

Applicable requirements

Applicable requirements is the phrase the 5.2 commitment statement uses. It is deliberately broad. Applicable requirements include: (a) legal and regulatory requirements, laws of India (IT Act 2000, DPDP Act 2023, Companies Act 2013, Disaster Management Act 2005), sectoral regulation (RBI / SEBI / IRDAI / TRAI / MeitY / state law), employment law, environmental law, fire and safety law; (b) contractual requirements, customer SLAs, master service agreements, vendor contracts, insurer warranties, lease obligations; (c) self-imposed requirements, voluntary standards (ISO 22301 itself, ISO/IEC 27001, ISO 9001, ISO 45001), industry codes, parent-company policies, public commitments (sustainability reports, ESG disclosures). The BC Policy commits the organisation to satisfying all three categories during and after disruption, which is a stronger commitment than merely complying in normal operations.

Continual improvement

Continual improvement (Clauses 10.2 and 5.2) is the recurring enhancement of the suitability, adequacy, and effectiveness of the BCMS. It is operationalised through the management review (Clause 9.3), corrective action (Clause 10.1), and the continual-improvement programme (Clause 10.2). The 5.2 policy commitment binds top management to maintain and improve the BCMS, not to build it once and walk away.

Communication

Communication (Clause 7.4 governs communication generally; 5.2 specifies policy communication) is the deliberate transfer of information from the organisation to its audiences, internal and external. Communication is more than publication: it requires the audience to receive, understand, and act on the information. The 5.2 communication test is whether staff can articulate what the policy commits the organisation to, not whether the policy is on the intranet.

Available

Available (the 5.2 availability requirement) means the policy is hosted, retrievable, discoverable, and accessible to its audiences. Available is operationalised by Clause 7.5 Documented Information controls. Availability is distinct from communication: communication is the act of transferring understanding; availability is the state of being there to be retrieved. A policy can be available but not communicated (hosted but unread); a policy can be communicated but not available (briefed but not retrievable). 5.2 requires both.

Fit-to-purpose

Fit-to-purpose (the 5.2 "appropriate to the organisation's purpose" requirement) means the policy's content reflects the organisation's actual purpose, context, scale, structure, products, services, prioritised activities, and risk landscape. Fit-to-purpose is the test that distinguishes a real BC Policy from a downloaded template. The fit-to-purpose test connects Clause 5.2 directly to Clause 4.1 (context), 4.2 (interested parties), 4.3 (scope) and 8.2 (BIA outputs). A policy that does not reference these upstream artefacts is, by definition, not fit-for-purpose.

BC objective (framework)

BC objectives (Clause 6.2) are the measurable targets the organisation sets for its BCMS performance. The 5.2 commitment to a framework that drives how BC objectives are defined and revisited means the policy specifies who sets objectives, on what cadence, against what dimensions (RTO, RPO, MBCO, MTPD, exercise pass rates, regulator-reporting timeliness), how they are approved, how they cascade, and how they are revised. The framework is the discipline; the objectives themselves live in the objectives register (Clause 6.2).

BC Policy vs BC Manual vs BC Strategy vs BC Plan

These four documents are routinely conflated. The distinctions matter for Clause 5.2.

• BC Policy (Clause 5.2), the apex strategic statement of intentions, principles, and commitments. Short (two to five pages). Board-level. Stable (reviewed annually or on event trigger). This is what 5.2 requires.
• BC Manual, a document (not required by ISO 22301, but commonly maintained by Indian firms) that bundles the policy with the scope, the governance structure, the roles, and the process map. Long (20 to 60 pages). Management-level.
• BC Strategy (Clause 8.3), the selected continuity strategies and solutions, derived from the BIA. Operational-architecture-level.
• BC Plan(s) (Clause 8.4), the response plans, team plans, IT DR plans, communications plans, and crisis-management plans. Operational-execution-level.

A common 5.2 failure is to substitute a BC Manual for a BC Policy. The Manual is too long, too detailed, and too brittle for board review, and it fails the "appropriate to purpose" test because it conflates strategy with policy.

Relationship to Other Clauses and Frameworks

Relationship to other ISO 22301 clauses

Clause 5.2 is the apex document clause of the BCMS. Its relationships to the other clauses are the spine of the system.

• Clause 4.1 (Context). The BC Policy must be appropriate to the organisation's purpose, which means the policy content must reflect the internal and external issues (Clause 4.1 outputs) the organisation identified. A policy that does not reference context is not fit-for-purpose.
• Clause 4.2 (Interested parties). The policy's commitments must reflect the needs and expectations of interested parties, and the policy must be available to relevant interested parties (a direct 5.2 wording). The interested-party register (Clause 4.2 output) is therefore an input to policy authoring and a constraint on policy availability.
• Clause 4.3 (Scope). The policy must align to the BCMS scope (Clause 4.3 output). The scope defines what the policy covers, which parts of the organisation, which products, which services, which geographies.
• Clause 4.4 (BCMS). The policy is the apex instrument of the BCMS the organisation establishes, implements, maintains, and continually improves.
• Clause 5.1 (Leadership). Top management establishes the policy. The executive sponsor signs it. Without 5.1 sponsorship, the policy is unsigned.
• Clause 5.3 (Roles). The policy is operationalised by the roles assigned under 5.3 (BCM Lead, BCM Steering Committee, Crisis Management Team, Process Owners, Internal Audit).
• Clause 6.1 (Risks and opportunities). The policy's risk-based commitments reflect the risk and opportunity profile identified under 6.1.
• Clause 6.2 (Objectives). The policy provides the framework for setting and reviewing BC objectives. The objectives register (6.2 output) is therefore downstream of, and consistent with, the policy.
• Clause 6.3 (Change). Planned BCMS changes (6.3) may trigger policy review.
• Clause 7.1 (Resources). The policy's commitments imply the resourcing commitment (7.1).
• Clause 7.2 (Competence). The policy is operationalised by competent people (7.2).
• Clause 7.3 (Awareness). The 5.2 communication commitment is operationalised by the 7.3 awareness programme, staff awareness of the policy, of their role, and of consequences of non-conformance.
• Clause 7.4 (Communication). 5.2 policy communication is a specific instance of the broader 7.4 communication discipline (what, when, to whom, how, by whom).
• Clause 7.5 (Documented Information). The 5.2 availability commitment is operationalised by the 7.5 Documented Information controls (version history, approval, distribution, retrieval, retention, disposition).
• Clauses 8.1 to 8.6 (Operational). The policy authorises and binds the operational processes, operational planning and control (8.1), the BIA (8.2), the strategy (8.3), the plans (8.4), the exercises (8.5), and the post-disruption evaluation (8.6).
• Clause 9.1 (Monitoring and measurement). Policy performance is monitored and measured.
• Clause 9.2 (Internal audit). The internal audit programme tests policy conformance.
• Clause 9.3 (Management review). The management review agenda explicitly includes policy review for continuing suitability, adequacy, and effectiveness.
• Clauses 10.1 and 10.2 (Improvement). Corrective action and continual improvement close against policy commitments.

Relationship to other ISO management-system standards

ISO 22301:2019 uses the Harmonized Structure shared by ISO/IEC 27001:2022, ISO 9001:2015, ISO 45001:2018, ISO 14001:2015, and ISO/IEC 20000-1:2018. Clause 5.2 in each of these standards is the policy clause. An organisation running more than one of these systems has an integration opportunity: a single integrated policy or a tightly-aligned policy set can satisfy all of them.

• ISO/IEC 27001:2022 Clause 5.2, the ISMS policy. Structurally identical to ISO 22301 Clause 5.2. Common Indian integration: an "Information Security and Business Continuity Policy" with sub-sections for ISMS-relevant and BCMS-relevant commitments. AICF (Annex IA controls 5.1 to 5.36 in ISO IEC 27001:2022) and the BCMS commitments reinforce each other; ISO 27001 controls A.5.29 (information security during disruption), A.5.30 (ICT readiness for business continuity), A.8.13 (information backup), and A.8.14 (redundancy of information processing facilities) are direct operational expressions of the BC Policy's commitments.
• ISO 9001:2015 Clause 5.2, the Quality policy. Structurally identical. Indian manufacturers running ISO 9001 commonly extend the quality policy into a combined Quality and Continuity policy.
• ISO 45001:2018 Clause 5.2, the OH&S policy. Indian manufacturers running ISO 45001 have a strong worker-safety policy foundation that intersects with BC at the level of emergency response and evacuation.
• ISO 14001:2015 Clause 5.2, the Environmental policy. Increasingly intersects with BC through climate-change adaptation (ISO 22301:2019 Amendment 1:2024 added climate-related issues to Clauses 4.1 and 4.2; the BC Policy is the natural place to commit to managing climate-driven continuity risks).

The full multi-framework mapping (Clause 5.2 row)

The detailed mapping with marquee IDs and dates is in Section 16. The headline cross-framework anchors for Clause 5.2 are:

• ISO 22301:2019 Clause 5.2, the requirement itself.
• ISO 22313:2020 Section 5.2, the companion guidance.
• ISO/IEC 27001:2022 Clause 5.2 and Clause 5.21, the ISMS policy and the documented-information requirements that overlap.
• ISO 9001:2015 Clause 5.2, the QMS policy (Harmonized Structure parallel).
• NIST SP 800-34 Rev 1 (May 2010) Step 1, develop the contingency planning policy statement. The seven-step process begins with policy.
• NIST CSF 2.0 (26 February 2024) Govern (GV) function, GV.OC (organizational context), GV.RM (risk management strategy), GV.RR (roles), GV.PO (policy), the Govern function is the structural home of policy in CSF 2.0.
• FFIEC BCM Booklet (Nov 2019), the governance and accountability principle.
• DORA (Regulation (EU) 2022/2554, applies 17 January 2025) Article 11(1), explicit requirement for an ICT business continuity policy. Article 11(5) requires a BIA. Article 11(6) requires yearly BCP testing.
• APRA CPS 230 (effective 1 July 2025) paragraph 16(e), the operational risk management framework must include business continuity plans; paragraph 22, the board approves the BCP and tolerance levels.
• MAS TRM Guidelines (18 January 2021) Section 8 (governance), board-approved policy.
• HKMA SPM TM-G-2 (revised 31 May 2022), BCP policy expectations for authorised institutions.
• RBI Master Direction IT Governance (7 November 2023), board-approved BCP/DR policy.
• RBI Cyber Security Framework (2 June 2016), board-approved cyber-security policy.
• SEBI CSCRF (20 August 2024), board-approved cyber resilience policy spanning the five goals and six operational functions.
• SEBI MII BCP-DR circular (22 March 2021), MII board-approved BCP.
• IRDAI ICS 2023 (24 April 2023), board-approved Information and Cyber Security Policy including BCP/DR.
• CERT-In Directions (28 April 2022), incident-reporting and capability commitments referenced in the policy.
• NDMA / Disaster Management Act 2005, DMP structure referenced in policy.
• DPDP Act 2023 Section 8(5), availability duty, a direct policy commitment.
• Companies Act 2013 Section 134(3)(n), risk-management policy statement in the Board's Report.
• SEBI LODR Regulation 21, Risk Management Committee mandate includes continuity.

Detailed Implementation Guidance, The Eight Policy Moves

This section sets out the eight policy moves a growing company in India must execute to satisfy Clause 5.2 in a form that survives both an IAF-accredited certification audit and a post-incident regulatory inspection. Each move has an input, an output, an owner, an indicative effort, and a list of common failure modes. Treat them as a sequence for the first cycle and as a parallel cadence thereafter.

Move 1, Author the BC Policy using the seven-section anatomy

Input. Clause 4.1 context register, Clause 4.2 interested-party register, Clause 4.3 scope statement, the BIA (Clause 8.2) outputs, the BC strategy (Clause 8.3) summary, the regulatory landscape (Section 3.2 of this guide), and the executive sponsor's strategic narrative for the year.

Output. A two-to-five-page BC Policy with seven sections in the following order.

1. Title, version, approval. Policy title (e.g., "Business Continuity Policy of [Organisation Name]"), version number, issue date, next review date, approved-by (executive sponsor signature, name, role, date), document owner (BCM Lead), classification (e.g., Internal / Public-on-Request).

2. Purpose and scope. Two to three paragraphs stating why the policy exists (to establish, maintain, and continually improve a BCMS that enables the organisation to continue prioritised activities during disruption), what it covers (the Clause 4.3 scope, summarised), and what it does not cover (typically operational detail, which lives in subordinate instruments). Include the fit-to-purpose paragraph, a short statement connecting the policy to the organisation's purpose, context, and prioritised activities. This is the paragraph the auditor will quote back to the sponsor.

3. The four commitment statements. Stated in plain language, in numbered form, the four commitments: (a) to meeting applicable requirements, with the regulatory landscape named (RBI/SEBI/IRDAI/CERT-In/DPDP/NDMA/Companies Act/IT Act as applicable); (b) to providing the framework that drives how BC objectives are defined and revisited (reference the Clause 6.2 objectives register); (c) to ongoing BCMS improvement; (d) to protection of business continuity before, during, and after disruption. Optionally add the two Indian-market commitments: (e) to maintain the regulator-reporting capability (name the clocks); (f) to continuity of outsourced and third-party-delivered activities.

4. BCMS framework. A short paragraph or table identifying the BCMS scope (Clause 4.3), the governance structure (BCM Steering Committee, executive sponsor, BCM Lead, Crisis Management Team, see Clauses 5.1 and 5.3), and the BCMS processes at a high level (Plan-Do-Check-Act cycle).

5. BC objectives framework. A statement that the organisation will set, review, and revise BC objectives (Clause 6.2) at defined intervals (typically annually, reviewed at the management review), against defined dimensions (RTO, RPO, MBCO, MTPD, exercise pass rates, regulator-reporting timeliness), cascaded to process owners, and reported to the Risk Management Committee / board.

6. Communication and availability. A statement that the policy will be communicated to all staff (via induction, awareness programme, intranet publication), to relevant contractors and suppliers (via the vendor portal and contract schedules), and to relevant interested parties on request (customers, regulators, insurers). A statement that the policy will be available as Documented Information (Clause 7.5), in accessible formats, on the intranet and on appropriate portals, in the dominant workplace languages (with a policy-on-a-page summary translation).

7. Review and maintenance. A statement that the policy will be reviewed by top management at the management review (Clause 9.3) at minimum annually, and on event trigger (major incident, regulatory change, M&A, new product, audit nonconformity, scope change, sponsor change). The version history is appended.

Owner. BCM Lead drafts; executive sponsor signs; BCM Steering Committee endorses; Internal Audit / Compliance reviews for regulatory fit; Risk Management Committee / board receives (per SEBI LODR Reg. 21 / RBI MD / IRDAI ICS as applicable).

Indicative effort. Two-day workshop with the BCM Lead, the executive sponsor, and a representative from Compliance/Legal, plus 5 to 10 days of BCM Lead drafting time, plus 1 to 2 days of sponsor iteration. First cycle: 3 to 4 person-weeks.

Common failure modes. (a) Skipping the fit-to-purpose paragraph, the policy reads as a template and fails the 5.2 "appropriate to purpose" test. (b) Padding the policy with operational detail, it becomes a manual and fails the "strategic instrument" test. (c) Naming the regulatory landscape generically ("we comply with applicable laws"), fails the applicable-requirements commitment test. (d) Omitting the framework-for-objectives commitment, fails the 6.2 linkage. (e) Missing the continual-improvement commitment, fails the 10.2 linkage. (f) Signing the policy without dating it or setting the next review date, fails the 7.5 Documented Information test. (g) Authoring in English only for a multilingual workforce, fails the availability test in spirit if not in letter.

Move 2, Authorise the policy through the correct governance chain

Input. The drafted policy from Move 1; the governance-chain matrix for the organisation (see toolkit doc 16 for role definitions).

Output. A policy signed by the executive sponsor (CEO/MD or COO typically), endorsed by the BCM Steering Committee, reviewed by Compliance/Legal, and, for Indian BFSI, listed entities, and insurers, approved or noted by the board or board Risk Management Committee. The signature block names the sponsor, the role, the date, and the version. For multi-entity groups, the parent policy is signed by the group executive sponsor and entity-level policies are signed by entity-level MDs.

Owner. Executive sponsor signs; BCM Lead prepares the signature pack; Company Secretary schedules board/RMC noting for entities that require it.

Indicative effort. Two to four weeks of calendar time (the bottleneck is the board/RMC cycle, not the drafting).

Common failure modes. (a) Signature by the BCM Lead only, fails the 5.1 ownership test. (b) Board approval claimed but no minute reference captured, fails the audit traceability test. (c) Approval cycle missed (signed after the policy is already in use), fails the 7.5 version-control test. (d) Wrong governance chain (CEO signature for a listed company that requires RMC noting), fails the regulatory overlay test.

Move 3, Build the policy-on-a-page and the multilingual summary

Input. The signed policy; the dominant workplace languages identified by HR (typically English plus Hindi plus one regional language for pan-Indian operations).

Output. A one-page summary of the policy containing: the four commitment statements in plain language, the scope, the governance bodies, the reporting clocks staff should know, the policy's location on the intranet, and the sponsor's name and photo (the sponsor's visible sponsorship is itself a Clause 5.1 signal). The summary is translated into the dominant workplace languages. Audio versions are produced for accessibility. A poster version is produced for physical locations (branches, factory floors, reception).

Owner. BCM Lead drafts; HR and Communications own translation and design; executive sponsor approves.

Indicative effort. One to two weeks of Communications time, plus translation cost (typically 5,000 to 25,000 rupees per language per page for Indian languages from a Tier-2 Indian translation vendor).

Common failure modes. (a) No policy-on-a-page, the full policy is too long for frontline consumption; the auditor samples staff and finds nobody has read it. (b) Translation done by machine without human review, meaning errors undermine credibility. (c) No audio / accessible versions, fails accessibility and the "available to relevant interested parties" commitment for staff with disabilities. (d) No physical artefact (poster) for field sites, fails the availability test for staff who do not have corporate intranet access (factory floor, branch counter, delivery fleet).

Move 4, Publish on the intranet, the vendor portal, and (where appropriate) the customer trust portal

Input. The signed policy, the policy-on-a-page, the multilingual summaries, the hosting infrastructure.

Output. The policy published in four locations:

1. Corporate intranet, full policy plus policy-on-a-page plus multilingual summaries plus acknowledgement form. Searchable. Linked from the home page or the compliance/policies section. Available to all staff with intranet access.
2. Vendor portal, the policy (or an extracted "supplier-relevant" version) published to all contracted vendors, with acknowledgement required at vendor onboarding and renewal. Specifically addresses the outsourced-activities commitment (RBI MD Outsourcing of IT Services, 10 April 2023, requires this for BFSI vendors).
3. Customer trust portal (for B2B SaaS, BFSI, healthcare, ITeS), typically a redacted version that omits internal governance detail but commits to the regulator-reporting clocks, the BCP/DR capability, and the ISO 22301 certification status (if held). This is increasingly a sales asset, Indian customers and overseas customers ask for it in security questionnaires.
4. Board pack archive, for the board / Risk Management Committee, the policy and the policy-on-a-page sit in the management review pack (Clause 9.3) and the board archive.

Owner. IT (intranet); Procurement / Vendor Management (vendor portal); Sales / Customer Success / Trust team (customer trust portal); Company Secretary (board archive).

Indicative effort. One to two weeks of IT/Procurement/Trust time to publish, plus ongoing maintenance.

Common failure modes. (a) Intranet publication only, fails the vendor and interested-party availability test. (b) No acknowledgement mechanism on the intranet, the auditor cannot evidence that staff have read the policy. (c) Customer-facing version is generic marketing, fails the substantive-availability test. (d) No version-sync across the four locations, the intranet has version 4 but the vendor portal has version 3, an obvious 7.5 finding.

Move 5, Run the communication programme (induction, awareness, refresh, executive briefing)

Input. The published policy; the awareness programme plan (Clause 7.3).

Output. A five-strand communication programme:

1. New-joiner induction, every new joiner receives the policy-on-a-page and the full policy in their induction pack, acknowledges it, and is briefed by HR or the BCM Lead in the first 30 days.
2. Annual awareness refresh, every staff member acknowledges the policy annually; the BCM Lead runs a 30-minute refresh session covering any policy changes, the reporting clocks, and the year's exercise outcomes.
3. Process-owner briefing, process owners (the people who own prioritised activities per Clause 8.2) receive a deeper briefing on how the policy binds their activity's RTO/RPO/MBCO, their plan ownership, and their exercise obligations.
4. Executive sponsor briefing, the executive sponsor is briefed annually on the policy, the BCMS performance, the regulatory landscape changes, and the management review agenda. The sponsor must be able to articulate the policy and answer auditor questions.
5. Board / RMC briefing, at the management review (Clause 9.3), the executive sponsor presents the policy, the BCMS performance, and any proposed policy changes. The board / RMC notes and approves.

Owner. BCM Lead and HR co-own the awareness programme; executive sponsor and Company Secretary own the board briefing.

Indicative effort. Ongoing, typically 1 to 2 person-weeks per quarter for the BCM Lead; 0.5 to 1 person-week per year for the executive sponsor.

Common failure modes. (a) No new-joiner induction component, staff onboarded in the gap between annual refreshes are missed. (b) No acknowledgement mechanism, the auditor cannot evidence communication. (c) Sponsor not briefed, the sponsor fails the auditor interview. (d) Annual refresh is a click-through e-learning module with no comprehension check, staff click and forget. (e) Process-owner briefing absent, process owners cannot connect the policy to their activity's RTO.

Move 6, Capture and maintain the acknowledgement record

Input. The published policy; the awareness programme; the HR system / GRC platform.

Output. An acknowledgement record showing, per staff member: name, role, location, language version acknowledged, date, version acknowledged, manager. Updated on every policy version change and on every annual refresh. Target: 95 percent-plus acknowledgement at any given point (100 percent for executives and process owners). The acknowledgement record is the auditor's primary evidence that the communication commitment has been met.

Owner. HR (system of record); BCM Lead (completeness monitoring).

Indicative effort. One-time setup of 1 to 2 person-weeks; ongoing maintenance of 1 to 2 person-days per month.

Common failure modes. (a) No acknowledgement mechanism, fails the 7.3 awareness test. (b) Paper-based acknowledgements that are not digitised, fails the audit traceability test. (c) No target/threshold, the BCM Lead cannot tell whether 95 percent or 50 percent of staff have acknowledged. (d) Acknowledgements not refreshed on policy version change, staff are tracked against an obsolete version.

Move 7, Define the review cadence and the event triggers

Input. The signed policy; the BCMS event-trigger taxonomy.

Output. A documented review schedule with two components:

1. Calendar review. Annual review at the management review (Clause 9.3). The BCM Lead prepares the review pack, the executive sponsor approves any changes, and the board/RMC notes. For most Indian growing companies, the policy review sits on the same cadence as the financial-year audit cycle.
2. Event-trigger review. A defined list of triggers that require interim policy review: (a) major incident or near-miss (any activation of the BC plans); (b) regulatory change (new RBI/SEBI/IRDAI/CERT-In/DPDP instrument, or material amendment); (c) M&A, divestiture, or major organisational change; (d) new product, service, or geography; (e) audit nonconformity (internal or external) on the policy; (f) scope change (Clause 4.3); (g) sponsor change (Clause 5.1 turnover); (h) BIA-material change (priorities shifted significantly); (i) exercise or test outcome revealing a policy gap; (j) customer or supplier escalation revealing a policy gap.

Owner. BCM Lead maintains the schedule; executive sponsor approves event-trigger reviews.

Indicative effort. Calendar review: 1 to 2 person-weeks of BCM Lead preparation, 1 to 2 days of sponsor iteration. Event-trigger reviews: variable; typically 0.5 to 1 person-week each.

Common failure modes. (a) Calendar review only, no event triggers, the policy goes stale between annual reviews. (b) Event triggers defined but never invoked, the BCM Lead is not monitoring for triggers. (c) Event-trigger review without version update, the policy is reviewed but the version history does not reflect it (7.5 finding). (d) No documented review schedule, the auditor cannot find when the next review is due.

Move 8, Wire the policy into the management review and the audit programme

Input. The published policy; the management review agenda (Clause 9.3); the internal audit programme (Clause 9.2).

Output. Three integration points:

1. Management review agenda. The management review (Clause 9.3) explicitly includes policy review, continuing suitability, adequacy, and effectiveness. The agenda item is non-negotiable; the BCM Lead prepares a short paper (the policy, the year's performance, the proposed changes) and the sponsor presents it. The review minute records the decision (confirmed, amended, or re-issued).
2. Internal audit programme. The internal audit (Clause 9.2) tests policy conformance every cycle, usually annually. The audit checklist includes: policy authorisation (signed, dated, version), fit-to-purpose (alignment with 4.1/4.2/4.3/8.2), the four commitments present and substantive, communication (acknowledgement record), availability (intranet/vendor/customer portal), review cadence (last review, next review), and downstream traceability (objectives, plans, exercises consistent with the policy).
3. Documented Information control. Per Clause 7.5, the policy is registered in the document control system with all metadata (title, version, date, author, approver, distribution, retention, disposition). Superseded versions are archived and retrievable (the auditor will ask to see the previous version).

Owner. BCM Lead; Internal Audit; Company Secretary.

Indicative effort. Annual cycle, 1 to 2 person-weeks of BCM Lead preparation, 1 to 2 person-weeks of Internal Audit.

Common failure modes. (a) Policy not on the management review agenda, fails the 9.3 test. (b) Internal audit does not test policy conformance, fails the 9.2 test. (c) Documented Information metadata incomplete, fails the 7.5 test. (d) Superseded versions discarded, fails the 7.5 retention test (the auditor needs to see the previous version to compare).

The eight moves in aggregate

The eight moves together convert a "compliance-only" policy into a "living-policy" BCMS. The first cycle (Moves 1 to 8) takes 8 to 14 weeks for a typical Indian growing company; the steady-state cycle ( Moves 4 to 8 in recurrence plus Moves 1 to 3 on event trigger) is a continuous management discipline that produces the policy-evidence base the certification auditor and the regulator both want to see. The Singahi toolkit for Clause 5.2 contains 17 ready-to-customise documents that operationalise each move.

Tools, Technologies, and Solutions

Clause 5.2 is a document-heavy and workflow-heavy clause. Tooling falls into five categories. The tooling discussion below uses category-level descriptors only; no vendor is named or endorsed. All third-party pricing is indicative and must be verified against candidate providers' official domains at the time of selection.

Document management and policy hosting

The baseline tool is a document management system (DMS) or content management system (CMS) that satisfies the Clause 7.5 Documented Information controls. Required capabilities: version history, approval workflow, distribution control, full-text search, retention policy, disposition, access logging, multi-format hosting (HTML, PDF, audio, video). Common Indian stack choices: Microsoft SharePoint Online (bundled with Microsoft 365, typically 1,250 to 2,200 rupees per user per month for the business plans that include SharePoint); Google Workspace Business Plus or Enterprise (typically 1,800 to 2,700 rupees per user per month); Confluence (typically 9 to 17 US dollars per user per month). Most growing companies already have one of these; the question is configuration, not procurement.

For growing companies that have outgrown a basic DMS, dedicated policy management software (a category-level descriptor; multiple Indian and global vendors serve this) adds policy-specific features: acknowledgement tracking, e-signature, multilingual hosting, policy-on-a-page rendering, policy expiry alerts, attestation reporting. Indicative India pricing: 200 to 1,500 rupees per user per month, with annual contracts typically starting at 3 to 25 lakh rupees for a 500-user deployment.

GRC platforms with BCM modules

For Mid-market (250 to 2,000) and enterprise, integrated GRC platforms with BCM modules host the policy alongside the BIA, the strategy, the plans, the exercises, the audits, and the corrective-action log, providing end-to-end traceability. The Indian market is served by global GRC vendors with substantial Indian delivery footprints (typically Mangalore, Bangalore, Pune, Hyderabad, Chennai, Delhi, Kochi, Kolkata, Thiruvananthapuram), by global SaaS GRC vendors selling through partner networks, and by India-HQ GRC vendors.

Indicative India pricing for GRC platforms with BCM modules: enterprise quote-based SaaS, typically 50 to 400 lakh rupees per year for a Mid-market (250 to 2,000) deployment including implementation; large enterprise deployments can exceed 5 crore rupees per year. Pricing is per-fulfiller-user (BCM Lead, process owners, internal audit, sponsor); read-only access for all staff is typically priced separately or bundled. Implementation is typically 12 to 36 weeks depending on scope and integration complexity.

The selection question for a Clause 5.2 buyer is whether the GRC platform's policy module supports the seven-section anatomy in Section 7 of this guide, multilingual hosting, acknowledgement tracking, version history with audit-grade metadata, and integration with the HR system (for the acknowledgement record) and the customer trust portal. Most leading platforms do; the differentiator is implementation quality and total cost of ownership over a five-year horizon.

Awareness and training platforms

For the communication programme (Move 5), awareness and training platforms with policy-acknowledgement modules are the standard Indian stack. Required capabilities: assign policy reading by user group, capture e-signature acknowledgements, track completion, support multilingual content, automate annual refresh, generate audit reports, integrate with the HR system. Indicative India pricing: 100 to 600 rupees per user per year for awareness platforms with policy-acknowledgement modules; dedicated BCM awareness content libraries are an additional line item.

Communication and translation tools

For Move 3 (policy-on-a-page and multilingual summary), the tool stack is content design plus translation. Content design tools (category-level descriptor) produce the policy-on-a-page; standard tools (Canva, Adobe Express, Microsoft PowerPoint, Publisher) suffice for most growing companies. Translation services for Indian languages should be sourced from a Tier-2 Indian translation vendor with human review; indicative cost is 5,000 to 25,000 rupees per page per language. Machine translation alone (Google Translate, DeepL) is not adequate for policy content, meaning errors are unacceptable and undermine credibility.

Indicative cost bands for the Clause 5.2 tool stack

These bands are indicative. Actual costs depend on existing stack, integration complexity, number of languages, number of fulfilment users, and vendor selection. The Singahi advisory team can assist with vendor-neutral selection tailored to the organisation's stack and scale.

Policy and Procedure Templates

This section reproduces the seven-section anatomy in template form. The full ready-to-customise templates are in the Clause 5.2 toolkit (17 documents); this section previews the apex template and two subordinate instruments.

BC Policy skeleton (preview, full template in toolkit doc 01)

[BUSINESS CONTINUITY POLICY]
[Organisation Name]
Version: [X.Y] | Issue Date: [DD Month YYYY] | Next Review: [DD Month YYYY]
Approved by: [Name, Role, Signature] | Document Owner: [BCM Lead Name]
Classification: Internal / Public-on-Request

1. Purpose and Scope
   [Purpose paragraph: the organisation commits to establishing, maintaining,
   and continually improving a BCMS that enables it to continue prioritised
   activities during disruption, in line with ISO 22301:2019 and applicable
   Indian regulation.]

   [Scope paragraph: this policy applies to [Clause 4.3 scope summary]. It
   covers [products, services, geographies]. It does not cover [explicit
   exclusions].]

   [Fit-to-purpose paragraph: this policy is appropriate to the organisation's
   purpose of [strategic purpose], its context [Clause 4.1 summary], its
   interested parties [Clause 4.2 summary], and its prioritised activities
   [Clause 8.2 summary].]

2. Commitments
   The organisation commits to:
   2.1 Meet applicable requirements. [List the applicable Indian regulator
       instruments: RBI MD IT Governance (7 Nov 2023), SEBI CSCRF (20 Aug
       2024), IRDAI ICS (24 Apr 2023), CERT-In Directions (28 Apr 2022), DPDP
       Act 2023, NDMA / DM Act 2005, Companies Act 2013 §134(3)(n)/§177, IT
       Act 2000. Add customer-contract and self-imposed requirements.]
   2.2 Provide the framework that drives how BC objectives are defined and
       revisited [Clause 6.2 reference].
   2.3 Continually improve the BCMS.
   2.4 Protect business continuity before, during, and after disruption.
   [Optional Indian-market additions:]
   2.5 Maintain the regulator-reporting capability: CERT-In 6-hour clock,
       DPDP 72-hour clock, RBI 2 to 6 hour clock, SEBI RE 6-hour clock,
       IRDAI clock.
   2.6 Ensure continuity of outsourced and third-party-delivered activities
       per [RBI MD Outsourcing of IT Services, 10 Apr 2023, for BFSI].

3. BCMS Framework
   [Governance: BCM Steering Committee, executive sponsor, BCM Lead, Crisis
   Management Team. Processes: PDCA cycle. Scope: §1. Reference to BCMS Manual
   if separate.]

4. BC Objectives Framework
   [Cadence: annual review at the Management Review (Clause 9.3). Dimensions:
   RTO, RPO, MBCO, MTPD, exercise pass rates, regulator-reporting timeliness.
   Cascade: to process owners. Reporting: to the Risk Management Committee /
   board.]

5. Communication and Availability
   [Communication: induction, awareness programme, intranet, vendor portal,
   customer trust portal, on request to regulators and insurers.
   Availability: Documented Information per Clause 7.5. Multilingual: in
   [languages]. Formats: full policy, policy-on-a-page, audio, accessible.]

6. Review and Maintenance
   [Calendar review: annually at the Management Review. Event triggers: major
   incident, regulatory change, M&A, new product, audit nonconformity, scope
   change, sponsor change, BIA-material change, exercise outcome, escalation.
   Version history: appended.]

7. Appendices
   [Glossary. References. Version history. Acknowledgement form. Distribution
   list.]

Policy review and maintenance workflow (preview, full template in toolkit doc 02)

The workflow has five gates.

1. Trigger. Either the calendar (annual review at the management review) or an event trigger (Move 7 list) fires. The BCM Lead opens a policy-review ticket in the document control system.
2. Draft. The BCM Lead drafts the proposed changes, with rationale, citing the trigger.
3. Review. Compliance and Legal review the proposed changes for regulatory fit; the BCM Steering Committee reviews for consistency with the BCMS.
4. Approve. The executive sponsor approves; for entities requiring it, the board or RMC notes.
5. Publish. The new version is published in all four locations (Move 4); the version history is updated; the previous version is archived; the awareness programme is refreshed; acknowledgements are re-captured.

The full workflow template (toolkit doc 02) includes the RACI, the SLAs per gate, the evidence each gate produces, and the escalation path.

Communication / dissemination plan (preview, full template in toolkit doc 15)

The communication plan has five strands (Move 5) and runs on a quarterly cadence. The plan template (toolkit doc 15) specifies: audience, message, channel, frequency, owner, evidence (acknowledgement or attendance record), target completion rate. The plan is reviewed annually at the management review and on event trigger (policy version change, regulator-reporting clock change, major incident).

Other subordinate instruments (in the toolkit)

• Vendor contract schedule (toolkit doc 10), the policy extract that goes into every vendor contract, with the vendor's "shall" commitments (these are Singahi-drafted sample clauses, not the standard's text).
• Awareness training module (toolkit doc 07), the 30-minute new-joiner module and the annual refresh module.
• Internal audit checklist for 5.2 (toolkit doc 04), 30 questions for the internal audit programme to test policy conformance.
• Board / RMC briefing pack (toolkit doc 15), the half-yearly pack the executive sponsor presents.

Risk Assessment and Treatment

Clause 5.2 itself does not require a risk assessment, but the BCMS does (Clauses 6.1 and 8.2). For Clause 5.2, the practitioner frame is risks to policy integrity, the risks that the policy fails to do its four jobs (apex, commitment, communication, available). Treating these risks is the explicit subject of the eight moves in Section 7. The risk register below is the seed for the policy risk assessment; the full template is in toolkit doc 09.

The policy risk register (seed, 12 risks)

Each risk has an owner (typically the BCM Lead, with sponsor accountability for P-02 and P-10), a treatment plan, a residual-risk rating, and a review date. The register is itself a Clause 9.1 monitoring artefact and is reviewed at the management review (Clause 9.3).

Risk treatment priorities

The two highest-use treatments for an Indian growing company are: (a) fixing the fit-to-purpose paragraph (P-01 and P-12 together), this is the single change most likely to convert a Clause 5.2 major nonconformity into a pass; and (b) standing up the awareness programme and the acknowledgement record (P-04 and P-06 together), this is the single change most likely to evidence the communication commitment. Together, these two treatments typically take 4 to 8 weeks of internal effort and convert an L1 policy into an L2-to-L3 policy.

Audit and Compliance Checklist

This is the 30-question audit preparation checklist (preview; the full version, with the expected-evidence column, is in toolkit doc 04). The checklist is structured to mirror the certification auditor's six moves (Section 2.5). Each question is one an auditor could ask; the answer should be ready before the audit.

Existence and authorisation (Moves 1 and 2)

1. Is there a current BC Policy authorised by top management?
2. Is the policy dated and version-controlled?
3. Does the policy carry the executive sponsor's name, role, and signature?
4. Is there a documented next-review date?
5. For BFSI/listed/insurer entities, is there board or RMC noting in the chain?
6. Is the previous version archived and retrievable per Clause 7.5?
7. Is the policy registered in the document control system with full metadata?

Fit-to-purpose (Move 1)

8. Does the policy contain a fit-to-purpose paragraph?
9. Does the paragraph reference Clause 4.1 context outputs?
10. Does the paragraph reference Clause 4.2 interested-party outputs?
11. Does the paragraph reference Clause 4.3 scope?
12. Does the paragraph reference Clause 8.2 BIA outputs?
13. Can the executive sponsor articulate the fit-to-purpose paragraph in interview?

Commitments (Move 1)

14. Are the four commitment statements present (applicable requirements, framework for objectives, continual improvement, lifecycle protection)?
15. Does the applicable-requirements commitment name the Indian regulator landscape?
16. Does the framework-for-objectives commitment reference Clause 6.2?
17. Does the continual-improvement commitment reference Clauses 10.1 and 10.2?
18. Are the optional Indian-market commitments (regulator-reporting clocks, outsourced-activities continuity) considered and either included or explicitly excluded?

Communication (Moves 5 and 6)

19. Is there an awareness programme covering induction and annual refresh?
20. Is there a process-owner briefing?
21. Is there an executive-sponsor briefing?
22. Is there a board / RMC briefing at the management review?
23. Is there an acknowledgement record with target completion rate?
24. Can the auditor sample five staff and get three to five who can articulate the policy?

Availability (Moves 3 and 4)

25. Is the policy published on the corporate intranet?
26. Is the policy (or its supplier-relevant extract) on the vendor portal?
27. Is the policy (or its customer-relevant extract) on the customer trust portal?
28. Is there a policy-on-a-page and multilingual summary?
29. Are accessible formats (audio, large print) available?

Review and traceability (Moves 7 and 8)

30. Is the policy on the management review agenda (Clause 9.3) and the internal audit programme (Clause 9.2)?

A clean "yes" to all 30 is the threshold for an L4-to-L5 policy. A clean "yes" to 24-plus is typically sufficient for a Stage 1 pass with minor nonconformities. Below 20 is a major-nonconformity risk on Clause 5.2.

Metrics and KPIs

This section sets out 15 KPIs for the Clause 5.2 BC Policy. KPIs 1 to 10 are process metrics; KPIs 11 to 15 are outcome metrics. The full KPI dashboard template with formulas, targets, and reporting cadence is in toolkit doc 11.

Process KPIs

Outcome KPIs

The dashboard should be on the management review pack (Clause 9.3) and reviewed by the executive sponsor. Trends matter more than absolute values, a static KPI 1 at 70 percent is a finding; an improving KPI 1 from 60 to 75 to 90 percent is a strength.

Common Pitfalls and Audit Failures

This section names the twelve most common Clause 5.2 audit failures observed in the Indian small-and-growing-company segment. They are memorable anti-patterns, recognising them is most of the defence.

Pitfall 1, The Template Policy

A policy downloaded from the internet, with the company name and logo substituted, no fit-to-purpose paragraph, no reference to Indian regulation, and no operational detail. The auditor opens the policy, finds the generic "ABC Corporation" placeholder still in section 3, and writes a major nonconformity before lunch. This is the single most common 5.2 finding in the Indian small-and-growing-company segment. Treatment: author the policy with the seven-section anatomy, draft the fit-to-purpose paragraph in a workshop with the executive sponsor, and name the Indian regulator landscape.

Pitfall 2, The Signature-Only Policy

A policy that was signed by the CEO in 2019 and has not been touched since. No version history. No review date. No communication. No acknowledgement record. No traceability to objectives, plans, or exercises. The signature is the only artefact. Treatment: stand up the eight moves in Section 7; the signature is the start, not the end.

Pitfall 3, The English-Only Policy in a Multilingual Workforce

A policy authored in English for a workforce that operates predominantly in Hindi, Tamil, Telugu, Marathi, or Bengali on the factory floor, the branch counter, or the field. The auditor samples staff and finds nobody on the floor has read the policy. Treatment: produce the policy-on-a-page and the multilingual summary (Move 3); the full policy stays in English for board and audit purposes, but the summary must reach the floor.

Pitfall 4, The Intranet-Only Policy

A policy hosted on the corporate intranet but nowhere else. Vendors have not seen it. Customers cannot request it. Insurers do not know it exists. Regulators are surprised by it. The "available to relevant interested parties" commitment fails. Treatment: publish on all four locations (Move 4).

Pitfall 5, The No-Acknowledgement-Record Policy

A policy that has been "communicated" via an email from the CEO but with no acknowledgement mechanism. The auditor asks for evidence of communication; the BCM Lead produces the email. The auditor asks for evidence that staff read it; there is none. Treatment: stand up the acknowledgement record (Move 6) with a target completion rate.

Pitfall 6, The No-Event-Trigger Policy

A policy with calendar review only. A new RBI circular is issued in November; the policy is not updated until the next annual review in March. A major incident occurs in February; the policy is not updated until the next annual review. Treatment: define the event-trigger list (Move 7) and monitor for triggers.

Pitfall 7, The Manual Substituted for the Policy

A 60-page "BC Manual" presented as the BC Policy. The auditor opens it, finds operational detail, and notes that the manual fails the "strategic instrument" test. Treatment: extract a two-to-five-page BC Policy from the manual using the seven-section anatomy; retain the manual as a separate subordinate document.

Pitfall 8, The Sponsor Who Cannot Articulate the Policy

An executive sponsor who signed the policy but did not author it and cannot describe its commitments in interview. This is technically a Clause 5.1 finding but it surfaces first under 5.2 because the auditor tests the sponsor during the policy review. Treatment: brief the sponsor annually (Move 5, strand 4); the sponsor must be able to answer the six auditor moves in Section 2.5.

Pitfall 9, The Inconsistent Policy

A policy that commits to the CERT-In 6-hour clock but the incident response plan does not operationalise the clock. A policy that commits to continual improvement but the management review agenda does not include policy review. A policy that commits to outsourced-activities continuity but the vendor contracts do not carry the BC Policy schedule. The auditor traces the policy into downstream artefacts and finds the inconsistencies. Treatment: wire the policy into the management review and the audit programme (Move 8) and run a traceability test before each audit.

Pitfall 10, The Version-Control Failure

A policy with no version history, or with a version history that does not match the document control system. The auditor asks to see the previous version; it has been overwritten. Treatment: stand up the Clause 7.5 Documented Information controls (Move 8); superseded versions are archived and retrievable.

Pitfall 11, The Policy Missing the Indian Regulatory Landscape

A policy that commits to "applicable laws and regulations" without naming them. The auditor asks which laws and regulations; the BCM Lead cannot enumerate them. Treatment: name the Indian regulator landscape in commitment 2.1 (Section 9.1).

Pitfall 12, The No-Board-Level Visibility Policy

For an Indian BFSI or listed entity, a policy the board has never seen. The Companies Act Section 134(3)(n) and SEBI LODR Regulation 21 require board engagement with risk management; the policy is the natural place to evidence that engagement. Treatment: put the policy on the board / RMC agenda (Move 8) at minimum annually.

Illustrative Scenario 1: Failure, Madhav Insurance (Illustrative)

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Disclaimer. Madhav Insurance is a fictional composite of multiple real Indian insurer cases observed in the market. It is illustrative; any resemblance to a specific named firm is coincidental. Numbers are illustrative for teaching purposes.

The organisation

Madhav Insurance was a mid-sized life and health insurer headquartered in Mumbai, with operations across nine states, approximately 1,800 staff, 4.2 million policyholders, and annual premium income of approximately 2,800 crore rupees. The firm was IRDAI-regulated and held ISO 22301:2019 certification obtained in 2021.

The policy failure

Madhav's BC Policy was authored in 2019 in preparation for the ISO 22301 certification push. It was a 14-page document, signed by the then-COO (who had retired in 2022), last reviewed in March 2021 for the Stage 2 audit, and not seen since. It committed generically to "compliance with applicable laws and regulations including the IRDAI Guidelines 2017", but the IRDAI Information and Cyber Security Guidelines 2023 (24 April 2023), which superseded the 2017 guidelines, were not reflected. The DPDP Act 2023 (enacted 11 August 2023) and the DPDP Rules 2025 were not reflected. The CERT-In Directions 20(3)/2022-CERT-In (28 April 2022) were not reflected. The policy committed to "DR site availability" but did not commit to ICT outsourcing continuity oversight, which the RBI Master Direction on Outsourcing of IT Services (10 April 2023) made material for Madhav because Madhav's claims-processing platform was operated by a third-party BPO in Pune.

The policy was hosted on the corporate intranet in English only. There was no policy-on-a-page. There was no multilingual summary. There was no acknowledgement record. The policy was not on the vendor portal. The policy was not in the new-joiner induction pack. The policy was not on the Board's Risk/IT Committee agenda for the last two meetings.

The BCM Lead (a Deputy General Manager in the Risk function) had flagged the staleness in three successive BCM Steering Committee meetings; the executive sponsor (a Whole-Time Director) had deferred review pending a planned re-organisation.

The disruption

On 14 February 2026, the third-party BPO operating Madhav's claims-processing platform suffered a ransomware attack. The BPO's primary and backup servers were encrypted; claims processing halted for nine days; approximately 320,000 active claims were affected; cashless hospitalisation at Madhav's network hospitals failed because the eligibility check ran on the same BPO platform. The BPO did not notify Madhav for 14 hours (the contract required notification within 1 hour). Madhav did not notify IRDAI for 36 hours (the IRDAI clock is significantly shorter). Madhav did not notify CERT-In for 22 hours (the CERT-In clock is 6 hours). Madhav did not notify affected policyholders for 72 hours (the DPDP clock is 72 hours of becoming aware, and Madhav became aware at hour zero).

The regulatory inspection

IRDAI opened an inspection on 18 February 2026. The inspection team's first request was the BC Policy. The team's findings, in summary:

1. The BC Policy did not reflect the IRDAI Information and Cyber Security Guidelines 2023 (in force since 24 April 2023). Material non-conformance with IRDAI guidelines.
2. The BC Policy did not commit to the CERT-In 6-hour clock, the DPDP 72-hour clock, or the IRDAI incident-reporting clock. Material inadequacy in the "applicable requirements" commitment.
3. The BC Policy did not commit to ICT outsourcing continuity oversight, despite Madhav's material dependence on the BPO. Material gap against IRDAI ICS 2023 ICT outsourcing oversight and the RBI MD Outsourcing of IT Services (which the IRDAI team cited as the supervisory benchmark).
4. The BC Policy was last reviewed in March 2021, five years before the incident. Material inadequacy in the continual-improvement commitment.
5. The BC Policy was not communicated to the claims staff or to the network-hospital coordination team. Material failure of the communication commitment.
6. The BC Policy was not on the Board's Risk/IT Committee agenda for the preceding eight quarters. Material failure of board-level oversight under Companies Act Section 134(3)(n) and SEBI LODR Regulation 21 (Madhav was a listed subsidiary).
7. The BC Policy was not available to the BPO. Material failure of the available-to-relevant-interested-parties commitment.
8. The BC Policy's commitment to "DR site availability" was not operationalised: the BPO did not fail over, and Madhav had no manual-mode fallback. Material failure of the lifecycle-protection commitment.

The consequence

IRDAI issued a direction on 11 March 2026 requiring Madhav to: (a) refresh the BC Policy within 90 days under a named Whole-Time Director's accountability; (b) submit the refreshed policy to the Board's Risk/IT Committee and minute the approval; (c) implement an ICT outsourcing continuity oversight programme within 180 days, including right-of-audit over the BPO and exit/continuity planning; (d) implement a regulator-reporting capability with explicit clocks and rehearsed runbooks; (e) pay a monetary penalty of 25 lakh rupees; (f) report compliance with the direction in the next annual compliance report. Madhav's ISO 22301 surveillance audit, due in April 2026, was reclassified as a re-certification audit (the certifying body concluded that the 5.2 finding was material); the re-certification added 4 weeks of effort and approximately 12 lakh rupees in additional audit fees.

The commercial cost was larger. Madhav's net Promoter score dropped 18 points in the post-incident quarter. Three large corporate group-health policy customers did not renew (combined annual premium of approximately 47 crore rupees). The Madhav share price (listed parent) dropped 9.3 percent over the two weeks following the incident; the drop was attributed by sell-side analysts to "operational resilience concerns", a direct policy-grade failure.

The lessons

1. A signed policy is not a current policy. The signature in 2019 was the start; the staleness by 2026 was the failure. The calendar-plus-event-trigger review (Move 7) is not optional.
2. Generic applicable-requirements wording fails. The Indian regulator landscape moves fast, IRDAI 2023, CERT-In 2022, DPDP 2023, RBI MD 2023, and the policy must name and track the instruments.
3. Communication is not publication. The policy on the intranet is not the policy in the workforce's understanding.
4. Outsourced-activity continuity is policy-grade. A policy that does not commit to ICT outsourcing continuity oversight is materially inadequate for any Indian firm with material third-party IT dependence.
5. Board visibility is regulatory. For BFSI and listed entities, the policy on the board/RMC agenda is a regulator expectation, not a leading practice.
6. The cost of a 5.2 failure dwarfs the cost of 5.2 conformance. Madhav's 25 lakh rupee penalty plus 12 lakh rupee audit cost plus 47 crore rupee lost premium plus the reputational drag, versus a 4 to 8 lakh rupee external advisory cost for a proper Clause 5.2 cycle. The asymmetry is several orders of magnitude.

Illustrative Scenario 2: Success, Sahyadri Sahakari Bank (Illustrative, with ROI)

Disclaimer. Sahyadri Sahakari Bank is a fictional composite of multiple real Indian urban cooperative bank cases. It is illustrative; any resemblance to a specific named firm is coincidental. Numbers are illustrative for teaching purposes.

The organisation

Sahyadri Sahakari Bank was a mid-sized urban cooperative bank headquartered in Pune, with 47 branches across Maharashtra, approximately 1,150 staff, deposits of approximately 4,800 crore rupees, and advances of approximately 3,200 crore rupees. The bank was RBI-regulated under the RBI Master Direction on IT Governance (7 November 2023) and was pursuing ISO 22301:2019 certification as part of a governance modernisation programme.

The challenge

In April 2025, Sahyadri's new MD (appointed after the previous MD's retirement) commissioned a Clause 5.2 review. The existing BC Policy was a 22-page document last reviewed in 2019; it referenced the withdrawn RBI circular framework, did not reflect the RBI Master Direction IT Governance (November 2023), did not reflect CERT-In Directions (April 2022), did not reflect DPDP Act 2023, was hosted on the intranet in English only, and had no acknowledgement record. An internal gap assessment (using the toolkit doc 12 template) rated the policy at L1 (compliance-only).

The phased remediation

The MD sponsored an eight-move remediation programme over 14 weeks, supported by external advisory.

Weeks 1 to 2: Move 1 (author). A workshop with the MD, the BCM Lead (a DGM in the Risk function), the CIO, the Head of Compliance, and the Company Secretary produced the seven-section BC Policy anatomy. The fit-to-purpose paragraph connected the policy to the bank's cooperative-banking context (small-business and retail customers, agricultural lending, branch-network operations), its interested parties (depositors, RBI, shareholders, staff, network of correspondent banks), its scope (all 47 branches, the core banking system, the ATM network, the digital channels), and its prioritised activities (deposits, payments, lending, customer service). The four commitment statements named the RBI Master Direction IT Governance, the RBI Cyber Security Framework, the RBI MD Outsourcing of IT Services, CERT-In Directions, DPDP Act 2023, the IT Act 2000, the Companies Act Section 134(3)(n), and the Maharashtra Cooperatives Act. The two Indian-market optional commitments (regulator-reporting clocks and outsourced-activities continuity) were included.

Weeks 3 to 4: Move 2 (authorise). The MD signed the policy; the BCM Steering Committee endorsed; the Board's Risk Management Committee noted at its June 2025 sitting. The Company Secretary recorded the minute.

Weeks 5 to 6: Move 3 (policy-on-a-page and multilingual). Communications produced a policy-on-a-page in English, Marathi, and Hindi (the three dominant workplace languages across the branch network). Posters were printed for all 47 branches. Audio versions were produced for visually-impaired staff.

Weeks 7 to 8: Move 4 (publish). The policy was published on the intranet, on the vendor portal (with a supplier-relevant extract), on the customer trust portal (with a customer-relevant extract that committed to the regulator-reporting clocks and the BCP/DR capability), and in the Board archive.

Weeks 9 to 11: Move 5 and Move 6 (communicate and acknowledge). The awareness programme ran across the branch network: the MD held a town-hall (recorded for branches that could not attend live); the BCM Lead ran 30-minute briefing sessions in regional clusters; process owners received a deeper briefing; the new-joiner induction was updated. The acknowledgement record was stood up in the HR system, with a target of 95 percent completion in 90 days. By the end of the 90-day window, 97 percent of staff had acknowledged (100 percent of process owners; 100 percent of branch managers).

Weeks 12 to 13: Move 7 (review cadence and event triggers). The calendar review was locked to the management review cadence (annually in March, aligned with the financial-year close). The event-trigger list was defined and documented: RBI/SEBI/IRDAI/CERT-In/DPDP regulatory change, M&A, new product, audit nonconformity, scope change, sponsor change, BIA-material change, exercise outcome, escalation.

Week 14: Move 8 (wire into management review and audit). The policy was placed on the management review agenda (Clause 9.3) and the internal audit programme (Clause 9.2). The internal audit team prepared a 5.2-specific audit checklist. The first management review sitting in March 2026 reviewed the policy and confirmed continuing suitability.

The quantified results

1. ISO 22301 Stage 1 audit (April 2026). Zero major nonconformities on Clause 5.2; one minor nonconformity (a small Documented Information metadata gap in the version-control record, fixed in 48 hours). The certifying body's auditor noted the policy as a benchmark example for the urban cooperative bank segment.

2. ISO 22301 Stage 2 audit (June 2026). Zero nonconformities on Clause 5.2. Certification recommended.

3. RBI inspection (September 2026). The RBI's annual financial inspection reviewed the BC Policy as part of the IT governance examination. The policy was accepted without remediation; the inspection finding on IT governance was downgraded from "material" (the 2024 finding) to "minor."

4. Insurance premium. The bank's cyber-insurance and operational-resilience insurer reduced the annual premium by 12 percent at renewal (October 2026), citing the policy refresh and the awareness programme as evidence of improved risk posture. The premium reduction saved approximately 18 lakh rupees per year.

5. Customer acquisition. The customer trust portal publication of the policy was cited in two successful corporate-banking-tender proposals during 2026 (combined annual fee income of approximately 4.3 crore rupees), in which BC/DR capability was a bid qualifier.

6. Staff engagement. The annual staff engagement survey showed a 22-point improvement in the "I understand what we do when something goes wrong" item, attributable (per the survey commentary) to the awareness programme.

The ROI

The Year-1 ROI is unusually high because of the corporate-tender wins; even excluding the tender wins, the recurring insurance saving plus the avoided remediation cost gives a 4x Year-1 return on a purely financial basis, with the resilience and brand benefits unquantified but real.

The lessons

1. A fit-for-purpose BC Policy is commercially valuable. It is not just a compliance artefact; it is a sales asset, an insurance asset, and a regulator-relations asset.
2. The eight moves are sequential and deliverable in 14 weeks. Most of the work is workshop time and translation, not capital expenditure.
3. The board cycle is the bottleneck. Plan the board/RMC noting early; it sets the calendar for everything else.
4. The awareness programme is where the policy becomes living. Without it, the policy is decoration; with it, the policy is institutional.
5. Multilingual translation is cheap relative to the cost of staff not understanding the policy. Two additional languages cost Sahyadri approximately 50,000 rupees; the sampled-staff articulation rate went from 30 percent to 78 percent in six months.
6. The ROI frame is the executive sponsor's frame. The MD commissioned the programme because the 4.83 crore rupee value case was compelling; the compliance frame would have produced a slower decision.

Multi-Framework Mapping

This section maps ISO 22301:2019 Clause 5.2 to the relevant controls in the major global and Indian frameworks. The mapping is structured to support a single integrated BC Policy that satisfies multiple regimes simultaneously.

Mapping table

The DORA policy distinction

For Indian firms with EU financial-sector exposure (IT/BPO serving EU banks, PSPs, MIIs, insurers), DORA Article 11(1) requires an ICT business continuity policy distinct from but aligned with the broader BC Policy. The cleanest design is for the ICT BCP to be a subordinate instrument that inherits the BC Policy's commitments and adds ICT-specific commitments (response and recovery plans, BIA, yearly testing, crisis-management function, backup policies and restoration per Article 12). The BC Policy references the ICT BCP; the ICT BCP references the BC Policy. This two-tier design satisfies DORA and ISO 22301 simultaneously.

The DORA date correction (applies to 16.2 and Section 4.3)

DORA (Regulation (EU) 2022/2554) entered into force on 16 January 2023 and applies from 17 January 2025. There is no DORA milestone in June 2025. The mid-2025 prudential date that exists is APRA CPS 230 (effective 1 July 2025). Indian firms that conflated these dates in their 2024 planning should treat 17 January 2025 as the binding DORA date and 1 July 2025 as the binding CPS 230 date.

Implementation Roadmap

This is the 30 / 90 / 180 / 365-day roadmap for a typical Indian growing company pursuing Clause 5.2 conformance from a cold start. The full version with milestones, owners, and deliverables is in toolkit doc 05.

Days 0 to 30, Foundation

Week 1. Confirm the executive sponsor and the BCM Lead. Open the Clause 5.2 workstream. Pull the Clause 4.1, 4.2, 4.3, and 8.2 outputs. Identify the regulatory landscape (use Section 3.2 of this guide).

Week 2. Run the two-day policy authoring workshop (Move 1). Produce the first draft of the seven-section BC Policy. Include the fit-to-purpose paragraph and the four-plus-two commitment statements.

Week 3. Compliance and Legal review of the draft. BCM Steering Committee review.

Week 4. Executive sponsor approval. For BFSI/listed/insurer entities, schedule the board/RMC noting for the next board cycle.

Days 31 to 90, Communication and availability

Weeks 5 to 6 (Move 3). Communications produces the policy-on-a-page. Translation into dominant workplace languages. Poster design for physical locations. Audio versions for accessibility.

Weeks 7 to 8 (Move 4). IT publishes on the corporate intranet. Procurement publishes the supplier-relevant extract on the vendor portal. The Trust team publishes the customer-relevant extract on the customer trust portal. The Company Secretary places the policy in the board archive.

Weeks 9 to 12 (Moves 5 and 6). Awareness programme launch: new-joiner induction updated; annual awareness refresh run; process-owner briefing run; executive sponsor briefed; board / RMC briefed at the management review. Acknowledgement record stood up in the HR system with a 95 percent target.

Days 91 to 180, Review, audit, and integration

Weeks 13 to 16 (Move 7). Review cadence and event triggers defined and documented. Calendar review locked to the management review cycle. Event-trigger list operationalised.

Weeks 17 to 20 (Move 8). Internal audit runs the first 5.2-specific audit using the toolkit doc 04 checklist. Findings closed. Management review (Clause 9.3) includes policy review. Board / RMC notes the management review outcome.

Weeks 21 to 24. Traceability test: confirm the objectives (Clause 6.2) reference the policy framework; the plans (Clause 8.4) reference the policy commitments; the exercises (Clause 8.5) test the policy commitments; the corrective-action log (Clause 10.1) closes against policy commitments. Remediate any inconsistencies.

Days 181 to 365, Steady state and certification

Months 7 to 9. Run the awareness programme quarterly cycle. Monitor the acknowledgement record. Maintain the Documented Information controls. Prepare the certification audit pack.

Months 10 to 12. Stage 1 audit. Close any minor nonconformities. Stage 2 audit. Receive certification (or, for entities already certified, complete the surveillance cycle with the 5.2 finding closed).

Continuous. Monitor event triggers. Maintain the policy risk register. Refresh the policy-on-a-page and multilingual summary on policy version change.

FAQ

Q1. We already have a BC Policy. Do we need to redo it for ISO 22301?

Not necessarily. If your existing policy already does the four jobs (apex, commitment, communication, available), it can be refreshed with the seven-section anatomy and the Indian regulator landscape in 2 to 4 weeks. If your existing policy is a template or a manual, it should be re-authored. Run the toolkit doc 12 gap assessment to decide.

Q2. How long should the BC Policy be?

Two to five pages for the policy itself; up to ten pages with appendices. The test is whether the policy does its four jobs. A 60-page manual fails the "strategic instrument" test; a half-page flyer fails the "substantive commitment" test.

Q3. Does the BC Policy need board approval?

Top-management approval is required (Clause 5.1). For BFSI, listed entities, and insurers, board or board-committee approval is additionally required by sectoral regulation (RBI MD IT Governance; SEBI LODR Reg. 21 / SEBI CSCRF; IRDAI ICS). For other growing companies, the CEO/MD signature suffices.

Q4. Should the BC Policy and the ISMS Policy be the same document?

They can be. An integrated "Information Security and Business Continuity Policy" satisfies both ISO/IEC 27001:2022 Clause 5.2 and ISO 22301:2019 Clause 5.2 if it covers both sets of commitments. Many Indian growing companies integrate them; some keep them separate but aligned. The integration choice depends on the audience (a combined policy is broader; a separate BC Policy is more focused on continuity outcomes).

Q5. How often should the BC Policy be reviewed?

Annually at the management review (Clause 9.3), plus on event trigger (major incident, regulatory change, M&A, new product, audit nonconformity, scope change, sponsor change, BIA-material change, exercise outcome, escalation). See Move 7.

Q6. Do we need to translate the BC Policy into Indian languages?

The full policy can stay in English for board and audit purposes. The policy-on-a-page and a multilingual summary in the dominant workplace languages are needed to satisfy the availability and communication commitments in spirit. Audio versions are recommended for accessibility.

Q7. Does the BC Policy need to be on the customer-facing website?

No. "Available to relevant interested parties" does not mean publicly posted. The standard publication model is intranet (staff), vendor portal (suppliers), customer trust portal (B2B customers on request or after NDA), board archive, and on-request to regulators and insurers. Public posting is a brand-led choice, not a 5.2 obligation.

Q8. What is the difference between the BC Policy and the BC Manual?

The policy is the apex strategic instrument (two to five pages, board-level, stable). The manual is an optional subordinate document that bundles the policy with scope, governance, roles, and processes (20 to 60 pages, management-level). Substituting a manual for a policy fails the "appropriate to purpose" test.

Q9. What is the difference between the BC Policy and the BC Strategy?

The policy is the apex strategic statement (what we commit to and why). The strategy (Clause 8.3) is the selected continuity strategies and solutions (how we will continue). The policy references the strategy; the strategy operationalises the policy.

Q10. What is the difference between the BC Policy and the BC Plans?

The policy is the apex strategic statement. The plans (Clause 8.4) are the response plans, team plans, IT DR plans, communications plans, and crisis-management plans (the operational-execution instruments). The policy references the plans; the plans operationalise the policy.

Q11. What if our executive sponsor changes?

Sponsor change is an event trigger (Move 7). The policy is re-presented to the new sponsor within 30 days of appointment; the new sponsor signs the policy (version-update); the BCM Steering Committee re-endorses. The sponsor change is recorded in the version history.

Q12. Does the BC Policy need to reference every Indian regulation?

The applicable-requirements commitment should name the material instruments for your sector. For a bank: RBI MD IT Governance, RBI Cyber Security Framework, RBI MD Outsourcing of IT Services, CERT-In Directions, DPDP Act, Companies Act, IT Act. For an insurer: add IRDAI ICS. For an MII: add SEBI CSCRF and SEBI MII BCP-DR. For a manufacturer: add NDMA Chemical Disasters Guidelines (where applicable), Companies Act, Factories Act. Generic "applicable laws" wording fails the audit.

Q13. How do we evidence that the policy is communicated?

The acknowledgement record (Move 6) is the primary evidence, per staff member, role, location, language version, date, version, manager. The awareness programme calendar (Move 5) is the secondary evidence. The auditor's sampled-staff test (five randomly-sampled staff) is the audit-evidence test.

Q14. How do we evidence that the policy is available?

The four-location publication (Move 4) is the primary evidence, intranet, vendor portal, customer trust portal, board archive. The Documented Information metadata (Move 8) is the secondary evidence. The auditor's spot-check on each location is the audit-evidence test.

Q15. Can we use a template to start?

Yes, as a starting point. Templates save drafting time. But the template must be adapted with the fit-to-purpose paragraph, the named Indian regulator landscape, and the seven-section anatomy. An unadapted template is Pitfall 1.

Industry-Specific Requirements

BFSI (banks, NBFCs, insurers, payment systems, MIIs)

BFSI is the most regulator-heavy Indian sector for Clause 5.2. The BC Policy must reference:

• RBI Master Direction IT Governance (7 November 2023, effective 1 April 2024), board-approved BCP and DR policy with documented RTO/RPO for critical systems, DRS architecture, periodic drills, third-party continuity controls, IT readiness for crisis events. Applicable to scheduled commercial banks (excluding payments banks, local area banks, RRBs), NBFCs with asset base above 500 crore rupees, all-India financial institutions, credit information companies.
• RBI Cyber Security Framework in Banks (2 June 2016), board-approved cyber-security policy with Cyber Crisis Management Plan (CCMP), 24x7 SOC, incident reporting within 2 to 6 hours of detection.
• RBI Master Direction Outsourcing of IT Services (10 April 2023), outsourced/cloud-provider BCP and DR inheritance, concentration-risk monitoring, exit plans, right-of-audit.
• SEBI CSCRF (20 August 2024), board-approved cyber resilience policy spanning the five goals and six operational functions; phased implementation deadlines in 2025.
• SEBI MII BCP-DR circular (22 March 2021), for MIIs (stock exchanges, clearing corporations, depositories): Near Site + DRS architecture, RTO 2 hours or less for critical systems, defined RPO, live failover drills, geographic separation, vendor/dependency BCP.
• IRDAI Information and Cyber Security Guidelines 2023 (24 April 2023), for insurers: board-approved Information and Cyber Security Policy including BCP/DR, CISO, 180-day log retention, DR drills, data locality, ICT outsourcing continuity oversight, annual compliance reporting within 90 days of FY end.

The BFSI BC Policy typically includes an explicit "regulatory reporting clocks" commitment (CERT-In 6 hours, RBI 2 to 6 hours, SEBI RE 6 hours, IRDAI per guidelines, DPDP 72 hours). The board / RMC noting is mandatory, not optional. The HDFC Bank RBI action (2 December 2020) and the Yes Bank moratorium (5 March 2020) are the cases every BFSI board now references.

Healthcare (hospitals, pharma, devices, diagnostics)

Healthcare BC Policies carry a patient-safety dimension that other sectors do not. The policy commits to:

• Continuity of clinical care (patient triage, treatment, surgery, medication, monitoring) during disruption.
• Continuity of patient records (EHR/EMR availability; paper-based fallback; ransomware-resilient backups).
• Continuity of medication and medical supply chains.
• Continuity of medical device operation (OT/IT segmentation; manual-mode fallback for life-support devices).
• Continuity of laboratory and diagnostic services.
• Coordination with district health authorities and the District Disaster Management Plan.

The AIIMS Delhi ransomware (23 November 2022), five physical servers hosting the e-Hospital application encrypted, OPD/admissions/billing/labs reverted to paper for 6 to 15 days, primary and backup servers both encrypted, media-reported ransom approximately 200 crore rupees (not confirmed by AIIMS or Delhi Police), is the anchor case every Indian healthcare BC Policy now references. The lesson: offline immutable backups and tested clinical failover are non-negotiable; hospital ransomware is a patient-safety event, not an IT event. The BC Policy must commit to these.

For pharmaceutical manufacturers (Sun Pharmaceutical 2023 ransomware, with the company publicly warning of revenue hit and litigation risk; Tata Technologies 2023; Bajaj Auto), the BC Policy must commit to OT/IT segmentation, validated backups, isolated OT segments, and a regulated-disclosure playbook. A ransomware containment decision in pharma manufacturing is a production-stoppage decision; the BC Policy must authorise the crisis-management framework that makes that decision.

IT, ITeS, and SaaS

IT and SaaS BC Policies are typically customer-contract-driven and DPDP-driven. The policy commits to:

• Customer SLA continuity (uptime, response time, support availability) during disruption.
• DPDP Act 2023 Section 8(5) availability duty, the BC Policy is the natural place to evidence the availability of personal data.
• DPDP Act 2023 Section 8(6) breach-notification capability, 72 hours of becoming aware.
• Cloud-provider BCP inheritance (RBI MD Outsourcing of IT Services for BFSI customers; DORA for EU customers; sector-specific customer requirements).
• Software supply-chain continuity (tested restoration from vendor update channels; the CrowdStrike 19 July 2024 global outage that downed IndiGo check-in and led to 283 cancellations is the anchor case for software-supply-chain resilience).

For IT-services firms serving overseas financial-sector customers, DORA Article 11(1) requires an ICT business continuity policy subordinate to the BC Policy. For SaaS firms serving the EU, the same. The DORA date is 17 January 2025; there is no June 2025 DORA date.

Manufacturing (chemical, automotive, electronics, pharma manufacturing)

Manufacturing BC Policies carry an industrial-continuity and workforce-safety dimension. The policy commits to:

• Industrial BCP, OT/IT segmentation, mutual-aid arrangements, integration with District Disaster Management Plans (NDMA Chemical Disasters Guidelines 2007).
• Continuity of supply chains (the Go First / Pratt & Whitney PW1100G engine failure case from 2023, with refund liability of 597 crore rupees owed to approximately 1.55 million passengers, is the supply-chain-concentration anchor).
• Continuity of operations during workforce disruptions (the Maruti Suzuki Manesar violence and fire of 18 July 2012, direct damage approximately 10 crore rupees; production loss approximately 70 to 75 crore rupees per day; approximately 1,400 crore rupees lockout loss, is the workplace-violence anchor).
• Continuity of hazardous-operations (the LG Polymers Visakhapatnam styrene gas leak of 7 May 2020, 12 to 13 fatalities, thousands exposed, NGT interim penalty 50 crore rupees, is the industrial-hazard anchor).
• Continuity of physical assets (the Mumbai 12 October 2020 blackout, attribution contested, Maharashtra State cited possible cyber sabotage; the Union Power Ministry cited human error, is the infrastructure-dependency anchor).

The manufacturing BC Policy typically references the Factories Act 1948, the Manufacture, Storage and Import of Hazardous Chemicals Rules 1989, the NDMA guidelines, and the state-level industrial-safety regulations.

Government, PSUs, and critical sector

Government and PSU BC Policies follow the NDMA Disaster Management Plan template (NDMA Guidelines on Preparation of DMPs, 2014), Prevention / Mitigation / Preparedness / Response / Relief / Recovery and Reconstruction / Capacity Building. For protected systems (IT Act 2000 Section 70), the policy references NCIIPC (Section 70A) and CERT-In (Section 70B) responsibilities. For multi-state operations, the policy integrates with State and District DMPs. Public-facing communication is part of the availability commitment.

Maturity Model

The L1 to L5 maturity model for Clause 5.2. Each level is described by observable characteristics, indicative Indian-segment investment to achieve and sustain the level, and the typical audit outcome.

Level 1, Compliance-only

Characteristics. Template-downloaded policy; signed once; not reviewed; not communicated; not available beyond a shared drive; no fit-to-purpose; no named Indian regulator landscape; no event triggers. The classic decoration.

Indicative investment. 0 to 50,000 rupees (the cost of the template and the signature ceremony).

Audit outcome. Major nonconformity on Clause 5.2 at Stage 1.

Level 2, Authored but uncommunicated

Characteristics. Authored BC Policy with most of the seven sections; signed by the executive sponsor; dated; reviewed annually; hosted on the intranet in English only; no policy-on-a-page; no multilingual summary; no acknowledgement record; event triggers not defined.

Indicative investment. 1 to 3 lakh rupees external advisory plus internal effort; ongoing 1 to 2 person-weeks per year.

Audit outcome. Typically a minor nonconformity at Stage 1; closeable before Stage 2.

Level 3, Living policy

Characteristics. Authored BC Policy with all seven sections; signed through the correct governance chain (including board/RMC noting for BFSI/listed/insurer); policy-on-a-page; multilingual summary; published on intranet, vendor portal, and (where applicable) customer trust portal; awareness programme run; acknowledgement record at 90 percent-plus; event triggers defined and operationalised; wired into management review and internal audit.

Indicative investment. 4 to 12 lakh rupees external advisory plus internal effort; ongoing 4 to 8 person-weeks per year for the BCM Lead and 1 to 2 person-weeks per year for the executive sponsor.

Audit outcome. Stage 1 pass; Stage 2 pass with zero or one minor nonconformity on 5.2.

Level 4, Integrated and platform-hosted

Characteristics. All L3 characteristics plus: the policy is hosted on a GRC platform with policy-management module; the acknowledgement record is automated with target completion tracking; the policy is integrated with the ISMS Policy and the QMS Policy where multiple standards apply; the policy is tested annually via a traceability test (objectives, plans, exercises, audits, corrective action all consistent with the policy); the policy drives downstream artefacts through machine-readable enforcement (workflow, attestations, escalation); the board / RMC dashboard includes policy KPIs.

Indicative investment. 15 to 40 lakh rupees platform implementation (one-time) plus 4 to 12 lakh rupees annual platform subscription; ongoing 6 to 10 person-weeks per year for the BCM Lead.

Audit outcome. Stage 2 pass with zero nonconformities on 5.2; typically supervisor-grade (the certifying body treats the policy as a benchmark).

Level 5, Predictive and benchmark

Characteristics. All L4 characteristics plus: the policy is sectoral benchmark (the firm shares its policy architecture with industry bodies, regulators, and standards committees); the policy is predictive (event triggers are monitored via horizon-scanning for regulatory change, peer-incident learning, and emerging-risk signals); the policy is part of the firm's commercial proposition (the customer trust portal publication is a sales asset; the policy is referenced in tender proposals); the policy is part of the firm's brand (it is publicly visible, externally accredited, and used in employer-brand communications); the firm's policy is referenced by other firms.

Indicative investment. 25 to 60 lakh rupees annual programme cost (including platform, advisory, content, translation, communications, and the cost of the executive sponsor's time).

Audit outcome. Continual Stage 2 pass; the policy is the certifying body's reference artefact for the sector.

Maturity progression

Most Indian growing companies start at L1 and aim for L3 within the first certification cycle. L4 is the typical target for the second surveillance cycle (year 2 to 3 after certification). L5 is achieved by a small minority of firms and is a multi-year investment. The Singahi toolkit and advisory are scoped to take a firm from L1 to L3 in 12 to 16 weeks and from L3 to L4 in 6 to 12 months.

Emerging Trends

Five trends are reshaping Clause 5.2 practice in India and globally over the 2025 to 2028 horizon.

Climate-change adaptation in the BC Policy

ISO 22301:2019 Amendment 1:2024 (Climate action changes) added climate-related issues to Clauses 4.1 and 4.2, organisations must consider whether climate change is a relevant internal or external issue, and whether interested parties have climate-related needs. The implications cascade into Clause 5.2: the BC Policy's fit-to-purpose paragraph must reflect climate as a continuity driver; the lifecycle-protection commitment must cover climate-driven disruptions (heatwaves, flooding, cyclones, water stress, supply-chain climate risk). Indian growing companies, especially those with physical operations in climate-exposed geographies (coastal Andhra/Tamil Nadu, flood-prone Assam/Bihar, heat-stress-affected Rajasthan/Gujarat/Maharashtra), should reflect climate in their BC Policy refresh in the next cycle. The RBI's Discussion Paper on Climate Risk and Sustainable Finance (2022) and the SEBI Business Responsibility and Sustainability Report (BRSR) provide the Indian regulatory overlay.

Operational resilience convergence

The global prudential regulators, UK FCA/PRA/BOE, US OCC/FRB/FDIC, EU (DORA), Singapore (MAS), Australia (APRA CPS 230), Hong Kong (HKMA OR-2), have converged on an "operational resilience" frame that goes beyond traditional BCM. The frame identifies Important Business Services (IBS) or critical operations, maps them end-to-end, sets impact tolerances for disruption (the APRA CPS 230 paragraph 38 triple: maximum period of disruption, maximum extent of data loss, minimum service levels), and tests against severe-but-plausible scenarios. Indian firms with overseas exposure should reflect this convergence in their BC Policy: the policy commits not only to continuity but to remaining within tolerance through severe disruption. The tolerance framework becomes a policy commitment, not just a BIA output.

DPDP and the availability duty

The DPDP Act 2023 Section 8(5) availability duty, every Data Fiduciary must maintain the accuracy, integrity, confidentiality and availability of personal data, reframes BC as a statutory obligation for every Indian business processing digital personal data. The DPDP Rules 2025 (notified November 2025) operationalise the breach-notification duty (72 hours of becoming aware). The Schedule penalties run to 250 crore rupees for failure to take adequate security safeguards and 200 crore rupees for failure to notify a breach. Indian BC Policies in the next cycle should commit explicitly to the availability duty and the breach-notification capability, naming DPDP in the applicable-requirements commitment.

AI and the policy dimension

The rapid spread of generative AI into Indian business operations, code generation, customer service, document drafting, decision support, creates a new category of continuity risk (model outage, prompt-injection, hallucination, training-data poisoning, vendor lock-in to a single AI provider). The MeitY AI Advisory (March 2024) and the wider Indian AI policy trajectory indicate that AI-specific continuity obligations are coming. Forward-looking BC Policies in 2026 to 2028 will commit to AI-system continuity, model-failure fallback, AI-vendor concentration risk, and AI-related incident reporting. The Singahi AI-continuity advisory helps firms anticipate this.

Quantum and post-quantum in the BC Policy

The long horizon (2028 to 2035) for cryptographically relevant quantum computing is already influencing the BC Policy for firms with long-lived data (banks, insurers, healthcare, government). The policy commitment to "maintain the confidentiality, integrity and availability of information during and after disruption" must, over the next several cycles, extend to the post-quantum cryptography migration. NIST's post-quantum cryptography standards (FIPS 203, 204, 205, finalised August 2024) are the reference point. Indian BFSI and government should begin reflecting this in BC Policies by 2027.

References and Further Reading

This guide draws on primary instruments (Tier 1), the ISO 223xx family of standards, Indian regulatory instruments, and established BCM frameworks. The standards' own clause text is not reproduced; the paraphrases are Singahi's own drafting, attributed per the manifest.

ISO standards and companions

• ISO 22301:2019 Security and resilience, Business continuity management systems, Requirements (the standard). ISO/TC 292.
• ISO 22301:2019 / Amd 1:2024 Climate action changes (amendment affecting Clauses 4.1 and 4.2).
• ISO 22313:2020 Security and resilience, Business continuity management systems, Guidance on the use of ISO 22301 (the companion; Section 5.2 is the policy guidance).
• ISO 22300:2021 Security and resilience, Vocabulary (3rd edition; a 2025 edition is under development (ISO/DIS 22300, 4th ed.) and not yet published, verify at iso.org before quoting a year; the 2018 edition is withdrawn).
• ISO/TS 22317:2021 Guidelines for business impact analysis (2nd edition; 2015 edition withdrawn).
• ISO/TS 22318:2021 Guidelines for supply chain continuity (2nd edition; 2015 edition withdrawn).
• ISO/TS 22331:2018 Guidelines for business continuity strategy.
• ISO/TS 22330 Guidelines for people aspects of business continuity.
• ISO 22316 Security and resilience, Organizational resilience.
• ISO/IEC 27001:2022 Information security management systems, Requirements (Clause 5.2; controls A.5.29, A.5.30, A.8.13, A.8.14).
• ISO/IEC 27002:2022 Information security controls.
• ISO 9001:2015 Quality management systems (Clause 5.2).
• ISO 45001:2018 Occupational health and safety (Clause 5.2).
• ISO 14001:2015 Environmental management systems (Clause 5.2).
• ISO/IEC 20000-1:2018 Service management (Clause 5.2).
• ISO 31000 Risk management.

Indian regulatory instruments

• Reserve Bank of India, Master Direction on IT Governance, Risk, Controls and Assurance Practices (7 November 2023; effective 1 April 2024). rbi.org.in.
• Reserve Bank of India, Cyber Security Framework in Banks (2 June 2016). rbi.org.in.
• Reserve Bank of India, Master Directions on Outsourcing of Information Technology Services (10 April 2023). rbi.org.in.
• Reserve Bank of India, Complete Cyber Security Framework for Primary (Urban) Cooperative Banks (31 December 2019). rbi.org.in.
• Securities and Exchange Board of India, Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities (circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024). sebi.gov.in.
• Securities and Exchange Board of India, Guidelines for Business Continuity Plan and Disaster Recovery of Market Infrastructure Institutions (SEBI/HO/MRD1/DTCS/CIR/P/2021/33, 22 March 2021). sebi.gov.in.
• Insurance Regulatory and Development Authority of India, Information and Cyber Security Guidelines 2023 (24 April 2023). irdai.gov.in.
• Indian Computer Emergency Response Team, Directions under Section 70B(6) of the IT Act 2000 (No. 20(3)/2022-CERT-In, 28 April 2022). cert-in.org.in.
• National Disaster Management Authority, Disaster Management Act 2005 (Act 53 of 2005); NDMA Guidelines on Chemical Disasters (Industrial) 2007; NDMA Guidelines on Preparation of Disaster Management Plans 2014; National Policy on Disaster Management 2009. ndma.gov.in.
• Digital Personal Data Protection Act 2023 (Act 22 of 2023, enacted 11 August 2023); Digital Personal Data Protection Rules 2025 (notified November 2025). meity.gov.in.
• Companies Act 2013 (Act 18 of 2013), Section 134(3)(n) and Section 177; SEBI LODR Regulation 21. mca.gov.in; sebi.gov.in.
• Information Technology Act 2000 (Act 21 of 2000; amended 2008), Sections 43, 65, 66, 70, 70A, 70B, 72, 84A. indiacode.nic.in.

Global frameworks

• NIST SP 800-34 Rev 1 Contingency Planning Guide for Federal Information Systems (May 2010). csrc.nist.gov.
• NIST SP 800-160 Vol 1 (November 2016) and Vol 2 Rev 1 (September 2021). csrc.nist.gov.
• NIST CSF 2.0 Cybersecurity Framework (NIST.CSWP.29, 26 February 2024). nist.gov.
• FEMA FCD-1 (17 January 2017) and FCD-2 (13 June 2017) under PPD-40. fema.gov.
• FFIEC IT Examination Handbook, Business Continuity Management Booklet (November 2019). ithandbook.ffiec.gov; issuing letters OCC Bulletin 2019-57, FRB SR 19-13, FDIC FIL-19071-2019.
• Regulation (EU) 2022/2554 Digital Operational Resilience Act (DORA), OJ L 333, 27.12.2022, p. 1; applies from 17 January 2025. eur-lex.europa.eu.
• APRA Prudential Standard CPS 230 Operational Risk Management (effective 1 July 2025; paras 16, 22 board-approved BCP and tolerance levels; para 38 the tolerance triple). apra.gov.au.
• MAS Technology Risk Management Guidelines (18 January 2021); MAS Guidelines on Business Continuity Management. mas.gov.sg.
• HKMA Supervisory Policy Manual TM-G-2 Business Continuity Planning (revised 31 May 2022) and OR-2 Operational Resilience (31 May 2022). hkma.gov.hk.

Citable incident anchors (primary-sourced)

These are referenced in the guide for the lessons they teach. The reader is encouraged to consult the primary sources.

• AIIMS Delhi ransomware (23 November 2022), peer-reviewed case in the International Journal of Information Management; reporting in The Hindu; NIA investigation.
• HDFC Bank RBI enforcement action (2 December 2020), RBI order; reporting in Livemint and Finextra.
• Yes Bank RBI moratorium (5 March 2020), Yale Journal of Finance and Compliance illustrative scenario; RBI order.
• Cognizant Maze ransomware (April 2020), Cognizant SEC 10-Q/10-K filing (ctsht-20201231); reporting in CIO Dive.
• Infosys McCamish Systems LockBit (October 2023), approximately 6 million individuals affected; reported 17.5 million US dollar class-action settlement.
• LG Polymers Visakhapatnam styrene gas leak (7 May 2020), National Green Tribunal interim penalty (OA 73/2020); NGT Joint Monitoring Committee report.
• Maruti Suzuki Manesar violence and fire (18 July 2012), direct damage approximately 10 crore rupees; production loss approximately 70 to 75 crore rupees per day; lockout loss approximately 1,400 crore rupees.
• Go First insolvency (filed 2 May 2023), NCLT filing; refund liability 597 crore rupees owed to approximately 1.55 million passengers (airline disclosure 31 July 2023).
• SpiceJet DGCA enhanced surveillance (27 July 2022), DGCA order to 50 percent of approved Summer Schedule flights for eight weeks.
• Air India / SITA data breach (February 2021, disclosed May 2021), approximately 4.5 million customers affected; reporting in Reuters.
• IndiGo CrowdStrike/Microsoft outage (19 July 2024), 283 flight cancellations; reporting in The Hindu.
• Chennai floods (December 2015), Cognizant official statement on Chennai delivery continuity; revenue guidance approximately 12.41 billion US dollars reaffirmed.
• Mumbai power grid blackout (12 October 2020), Western Regional Power Committee report; Maharashtra State Cyber Cell findings; Recorded Future attribution (contested; the Union Power Ministry attributed the outage to human error, not cyber).
• Sun Pharmaceutical ransomware (2023), public disclosure warning of revenue hit and litigation risk.

A reading note on contested attribution and unverified claims

In keeping with the accuracy rules in the standards-factory authoring contract: the Mumbai 12 October 2020 blackout cyber link is contested (Maharashtra State and the Union Power Ministry directly contradict on cyber attribution), both positions are presented, neither is asserted. The Airtel October 2019 nationwide India outage, the Jio 2020 outage, and the SolarWinds Indian-victim list are not verifiable from primary sources and are not used as fact in this guide. The documented Jio nationwide event is 17 September 2024 (data-centre fire; Cloudflare Radar measured traffic on AS55836 down up to 53 percent). The documented Airtel events of October 2019 were in Africa, not India. Most Indian-firm rupee-loss figures are not publicly disclosed; specific numbers in this guide are attributed to primary sources (RBI orders, SEBI circulars, SEC filings, NGT orders, NCLT filings, DGCA orders, peer-reviewed studies) or marked illustrative.

© Singahi. This guide is provided for the receiving organisation's internal use. The paraphrased requirement and the sample clauses are Singahi's own drafting. ISO 22301:2019's clause text is not reproduced. All framework references are to public instruments named; verify current versions on the issuing body's official portal before relying on them.