ISO 22301 Clause 6.2: Business Continuity Objectives and Planning to Achieve Them

Quick Reference (60 Seconds)

If you only read one thing: Clause 6.2 is where the BCMS stops being a set of activities and becomes a system with a destination. A 6.2-conformant BCMS is one in which the organisation has decided in advance what continuous-capability targets it is committing to, has translated each target into a measurable objective with a named owner and a due date, has documented the plan to deliver each objective (the actions, the resources, the responsibility, the timing, the evaluation method), and feeds the objective portfolio into the management review every cycle. The certification auditor will examine this discipline ruthlessly, and so will a regulator after a real disruption, when an incident strikes, the third question after "who is in charge?" and "did you know this could happen?" is always "what were you trying to achieve, and did you have a plan to achieve it?". Get 6.2 wrong and however strong the policy, the BIA and the plans, the BCMS will fail the standard's outcomes test because it has no defensible definition of success. Get it right and every other clause becomes evidence-based because the destination is explicit.

What the Standard Actually Requires

The paraphrased requirement

ISO 22301 Clause 6.2 asks organizations to set measurable business continuity objectives and plan the what, who, when, and how of achieving them. The paraphrase compresses a great deal of architectural work into one sentence, and unpacking each phrase is the most useful way to understand what an auditor will look for.

Set means establish deliberately, with top-management approval, with documented rationale, with named owners, and with a review mechanism. Objectives that emerge by accident, that are inherited from a template without context, or that live only in the BCM Manager's spreadsheet without approval are not "set" in the sense the standard requires. The setting is itself a structured activity with inputs (policy, BIA, risk register, regulatory landscape), a process (SMART qualification, cascade, approval, communication), and outputs (the register, the achievement plans, the communication record).

Measurable is the load-bearing word. Every objective must be expressed in a form that allows an independent third party, an auditor, a regulator, a new BCM Manager, to determine whether it has been achieved. This rules out verbs that cannot be measured ("maintain", "ensure", "promote", "strengthen", "support") unless paired with a measurable predicate. "Maintain ISO 22301 certification" is measurable (the certificate either exists or it does not, on a stated date). "Maintain business continuity" is not. "Reduce core-banking-system RTO from 8 hours to 4 hours by 31 March 2026" is measurable. "Improve recovery capability" is not. The measurability test is applied to every objective at the moment of drafting and re-applied at every review.

Business continuity objectives means objectives that are within the scope of the BCMS, the continuity of prioritised activities, the fulfilment of legal, contractual and regulatory obligations relating to availability and resilience, and the protection of interested-party value against disruption. The standard does not authorise the BCMS to set commercial, growth or financial objectives except where those directly underwrite continuity (e.g., the budget to fund a recovery site is a Clause 7.1 input to an objective, not itself an objective). The demarcation test is: is the achievement of this objective something the BCMS produces, or something the wider business produces? If the former, it is a 6.2 objective; if the latter, it belongs in the enterprise performance-management system and may inform the BCMS but is not itself a BCMS objective.

Plan the what, who, when, and how of achieving them is the planning quadruple, and the standard expects each of these to be explicit and documented per objective. The work to be executed is the action breakdown, the sequence of steps that will deliver the objective. The resourcing requirement covers the budget, the people, the technology, the time and the external services needed (a Clause 7.1 input). The accountable owner is the named Objective Owner (a Clause 5.3 role-assignment) who answers for the result. The target timeline is the deadline plus interim milestones. The evaluation approach specifies the measurement method, the evidence standard and the decision rule (achieved / partially achieved / not achieved). An objective without all five is conformant on the surface and defective in substance, and that asymmetry is a frequent Stage 2 finding.

The consistency rules, what every objective must align with

The standard requires objectives to be consistent with several upstream artefacts, and the consistency is not cosmetic. An objective that contradicts its upstream source is either a wrong objective or evidence of an upstream defect, and the auditor will probe both.

Consistent with the BC policy (Clause 5.2). Every objective must trace back to a commitment in the policy. If the policy commits to "the continuity of prioritised activities within their documented recovery objectives", the 6.2 register must contain objectives that operationalise that commitment per prioritised activity. If the policy commits to "compliance with applicable legal and regulatory requirements", the register must contain objectives that operationalise compliance with the specific regulations that apply (RBI MD for banks, SEBI CSCRF for market infrastructure, IRDAI ICS for insurers, CERT-In Directions for every ICT operator in India, DPDP Act 2023 for every Data Fiduciary). A policy-objective traceability matrix is the cleanest way to evidence this consistency.

Consistent with the BCMS scope (Clause 4.3). Objectives outside the scope are not conformant, they either need to be brought in scope (a Clause 4.3 revision) or removed from the register. An objective that says "achieve RTO of 4 hours for the international payments business" is nonconformant if the BCMS scope covers only the domestic payments business.

Consistent with the BIA outputs (Clause 8.2). This is the most-common consistency failure in the Indian growing-company segment. Every RTO objective must be ≤ the corresponding MTPD from the BIA; every RPO objective must derive from the BIA's data-loss tolerance; every MBCO objective must derive from the BIA's minimum-acceptable-delivery level. An RTO objective of 8 hours against an MTPD of 4 hours is structurally incapable of being met, the activity's continuity fails before the objective is delivered. The BIA-to-objective cascade is one of the most important artefacts in a conformant 6.2 system.

Consistent with the risk treatment plan (Clause 6.1). Every high-rated residual risk should generate a corresponding risk-treatment objective. If 6.1 flags supplier-concentration risk as high-rated with a mitigate decision, 6.2 should contain an objective that operationalises the mitigation (e.g., "reduce single-supplier exposure for the top-5 critical activities from 100% to 50% by 30 September 2026"). The 6.1-to-6.2 cascade is the second-most-important integration path.

Consistent with applicable legal, regulatory and contractual requirements (Clause 4.2). For a SEBI-regulated MII, this means objectives that meet or exceed the SEBI MII BCP-DR circular's RTO ≤ 2 hours for critical systems. For an RBI-regulated bank, this means objectives that meet or exceed the RBI MD IT Governance chapter's documented RTO/RPO for critical systems. For an IRDAI-regulated insurer, this means objectives that meet the IRDAI ICS 2023 board-approved BCP/DR expectations. For any Indian Data Fiduciary, this means objectives that operationalise the DPDP Act 2023 Section 8(5) availability duty and Section 8(6) breach-notification duty.

Consistent with the organisation's risk appetite (Clause 5.2 policy and Clause 6.1 charter). Objectives that fall outside risk appetite, for example, an objective to achieve a 15-minute RTO when the risk appetite explicitly accepts up to 4 hours, are nonconformant because they misallocate resources against the organisation's stated tolerance.

What "measurable" actually requires, the SMART-BC pattern

The standard's requirement that objectives be measurable is operationalised through the SMART pattern, adapted for BC. Every objective should be Specific, Measurable, Achievable, Relevant and Time-bound, with two BC-specific extensions: Evidence-eliciting and Reviewable. Together these seven letters form the SMART-BC test the BCM Manager applies to every candidate objective.

Specific, the objective names the prioritised activity, the system, the process, the supplier or the capability it applies to, with no ambiguity. "Reduce RTO for the UPI rails switch processing activity" is specific; "improve recovery" is not.

Measurable, the objective contains a number, a threshold or a binary outcome that an independent party can verify. "Reduce RTO from 8 hours to 4 hours" is measurable; "significantly reduce RTO" is not.

Achievable, the objective is within the organisation's resource, competence and technology reach within the time horizon, given the Clause 7.1 resourcing commitment. An RPO objective of zero data loss for a transactional system may be technically achievable but economically absurd; an objective that is structurally infeasible is not achievable and is therefore nonconformant.

Relevant, the objective traces to the Clause 5.2 policy, the Clause 8.2 BIA, the Clause 6.1 risk register or the regulatory landscape. An objective that does not trace to any of these is nonconformant because it consumes BCMS resources without advancing an outcome.

Time-bound, the objective has a target date and, for multi-quarter objectives, interim milestones. "By 31 March 2026" is time-bound; "in due course" is not.

Evidence-eliciting (BC-specific extension), the objective is drafted so that its achievement generates evidence the auditor can sample. "Deliver a live failover exercise of the core ledger to the DRS with RTO measured and ≤ 4 hours, witnessed by Internal Audit" elicits evidence; "improve failover capability" does not.

Reviewable (BC-specific extension), the objective is drafted so that, at the end of its horizon, the organisation can decide whether to mark it achieved, partially achieved, missed or superseded, and feed that decision into Clause 10.1 corrective action or Clause 10.2 continual improvement.

The planning quadruple, what every Objective-Achievement Plan must contain

The standard requires that the organisation plan how each objective will be achieved, and the planning must address five dimensions: the work to be executed (the action breakdown), the resources needed (budget, people, technology, external services), the accountable owner (a named individual), the target timeline (deadline and milestones), and the evaluation approach (measurement method, evidence standard, decision rule). Each of these is a distinct discipline, and skipping any one produces a nonconformity.

The work to be executed is the action breakdown, the sequence of steps that will deliver the objective. For a "reduce core-banking RTO from 8 hours to 4 hours by 31 March 2026" objective, the action breakdown includes: revise the runbook; upgrade the replication architecture; commission the DRS; train the recovery team; deliver a tabletop exercise; deliver a live failover exercise; measure and report. The action breakdown is the operational substance of the plan and the basis for the resource estimate.

The resources needed cover the Clause 7.1 input, the budget, the people, the technology, the time and the external services. The resource estimate must be specific enough that top management can fund it through the budget cycle. For the example above, the resource estimate might include: ₹2.4 crore for the replication architecture over two years; one full-time-equivalent recovery engineer for six months; ₹18 lakh for the DRS build; ₹6 lakh for the exercises; 240 person-hours of internal time across IT, Operations, Risk and Audit. Vague resource estimates ("we will need some budget for this") are nonconformant.

The accountable owner is the Clause 5.3 role assignment, the named Objective Owner who is accountable end-to-end. The Objective Owner is not always the person doing the work; they are the person who answers for the result. For the example above, the Objective Owner is typically the Head of IT Infrastructure or the CIO, with delegated action owners (the recovery engineer, the DRS vendor) doing the work. A register where every objective is owned by the BCM Manager fails this test.

The target timeline is the deadline plus the interim milestones. The deadline must be realistic given the action breakdown and the resource estimate; an objective with an unachievable date is nonconformant on the "achievable" limb of SMART. The interim milestones allow the Steering Committee to detect slippage early, typical milestones are 30-day, 90-day, 180-day and 365-day checkpoints.

The evaluation approach specifies the measurement method, the evidence standard and the decision rule. The measurement method specifies how the result will be tested (a live exercise, a documented test, a process audit, a sampling review). The evidence standard specifies what counts as evidence (a witnessed exercise report, a third-party penetration test, a Clause 9.2 internal audit finding, a regulator-interaction record). The decision rule specifies how the result will be classified (achieved / partially achieved / not achieved / superseded) and what happens next (Clause 10.1 corrective action for misses, Clause 10.2 continual improvement for successes, Clause 6.3 change management for supersessions).

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

Clause 6.2 is widely misread as "produce an objectives register", open a spreadsheet, list ten targets, label them SMART, file the document. That misreading produces the single most common 6.2 nonconformity in the Indian growing-company segment. Being explicit about what 6.2 does not require protects against two failure modes: under-investing (treating the register as a documentation artefact) and over-reaching (treating 6.2 as the entire enterprise performance-management system).

• 6.2 does not require a specific number of objectives. The standard does not mandate 5 or 50. The right number is whatever fully operationalises the policy, the BIA and the risk register for the organisation's scope, typically 10 to 25 for an Indian growing company, 25 to 60 for a mid-market (250 to 2,000 staff) organisation, and 60 to 200 for a multi-entity enterprise.
• 6.2 does not require objectives to be quantitative only. Binary outcomes (achieved / not achieved) are measurable. Pass/fail objectives ("deliver a live failover exercise by Q3") are conformant. The requirement is measurability, not necessarily a continuous number.
• 6.2 does not require every objective to be achieved. Misses are not nonconformities; undeclared misses, missed misses, and misses without corrective action are. The standard expects misses to be visible, owned and routed to Clause 10.1.
• 6.2 does not require a 12-month horizon specifically. The horizon is the organisation's choice. Some objectives are 90-day; some are 3-year. Leading practice is to mix horizons, quick wins, medium-term and strategic.
• 6.2 does not require objectives to be set annually. Calendar-based setting is common; event-triggered re-validation is essential. An objective may be revised mid-cycle if a trigger fires (Clause 6.3 change, Clause 8.6 incident, Clause 9.2 audit finding, regulatory shift, BIA change).
• 6.2 does not require objectives to be set by top management directly. Drafting is typically delegated to the BCM Manager and function heads; approval is retained by top management. The non-delegable duty is the approval, not the drafting.
• 6.2 does not require objectives to be made public. Internal-only objectives are conformant. Publication to customers, regulators or the public is a strategic choice, sometimes valuable (a public RTO commitment can be a sales argument), sometimes risky (a missed public objective is reputational damage).
• 6.2 does not require a software-hosted register. A spreadsheet is conformant. A GRC platform is leading practice in larger organisations but is not mandated. The standard requires the register to be controlled, versioned and accessible, properties a well-managed spreadsheet has.
• 6.2 does not require objectives to cover every Clause 8 sub-clause. The standard requires the BCMS to have objectives, not to have one per operational clause. The shape of the portfolio is the organisation's choice, calibrated to the policy, the BIA and the risk register.
• 6.2 does not require that objective-setting be a one-off event at BCMS design. Objectives are expected to evolve, new objectives added, completed objectives retired, superseded objectives revised, through the Plan-Do-Check-Act cycle. The Clause 10.2 continual improvement obligation applies directly to 6.2.

What the standard does NOT say about objectives (and what to do about it)

The standard's text on 6.2 is short and high-level; the substantive architecture, the SMART-BC pattern, the cascade logic, the planning-quadruple template, the seven objective families, is practitioner elaboration drawn from ISO 22313:2020 (companion guidance), ISO/TS 22317:2021 (BIA), ISO/TS 22331:2018 (strategy) and the bodies of BCM practice. This guide makes those elaborations explicit so that the BCMS you build is not just minimally conformant but operationally effective. Where the standard is silent on a detail (e.g., what counts as "measurable"), this guide states the practitioner convention and explains the rationale; you may adopt the convention or document an alternative as long as the standard's intent is met.

Why This Control Matters

The business risk

When a disruption strikes, the difference between an organisation that recovers in hours and one that collapses in days is rarely the technical architecture, it is whether the organisation had a clear, measurable, owned, resourced definition of what "recovered" meant before the disruption. A BCMS without measurable objectives has a policy (Clause 5.2) and a risk register (Clause 6.1) but no scoreboard; every recovery decision becomes an argument, every investment becomes a negotiation, every audit becomes an interpretation contest. Clause 6.2 is the clause that turns the BCMS from a documentation exercise into a management discipline with a destination.

Every major Indian incident of the last decade that turned from a contained event into a public crisis shares a 6.2 failure mode. The November 2022 AIIMS Delhi ransomware that took e-Hospital down for days, the post-incident review surfaced that the hospital had no measurable recovery objective for the e-Hospital system, no RTO target that the recovery team was working towards, and no agreed evidence standard for what "restored" meant; the recovery took as long as the technical work happened to take because no one had committed to a number in advance. The November 2020 HDFC digital outage that drew the RBI's ban on new digital products, the public record shows that the bank had RTO commitments in policy documents but no Cascade that translated them into per-system objectives with owners and dates, so repeated smaller outages in 2018 and 2019 were not measured against any target and were treated as IT operations issues rather than BCMS misses. The September 2024 Jio data-centre fire that took a national carrier dark for hours, the BCMS had a generic "high availability" commitment but no objective for single-DC fire recovery, no live-failover test requirement tied to a measurable target, and no evidence standard for declaring recovery complete.

The business risk of weak 6.2 implementation is concentrated in three failure modes. The first is objectives-as-wallpaper, the register exists for the auditor, not for the business; the leadership team has never read it; the BCM Manager updates it the night before the surveillance audit; no one can name the top three objectives from memory. The second is cascade failure, the objectives exist and are SMART, but they do not trace to the BIA, the policy or the risk register, so they describe an arbitrary set of activities rather than the activities that would actually advance the BCMS outcomes. The third is planning-form failure, the objectives exist and cascade correctly, but the Objective-Achievement Plans are missing or generic, so the organisation cannot answer "what will it take to deliver this objective?" until the objective is already overdue. All three failure modes produce the same audit finding: the BCMS does not have a defensible definition of what it is trying to achieve.

The Indian regulatory context

The Indian regulatory environment has, over the last decade, transformed 6.2 from a planning formality into a regulator-supervised performance-management expectation with named targets and named owners. The transformation has happened across every major sector regulator, and the cumulative effect is that an Indian organisation's 6.2 register is now expected to operationalise a concrete set of regulatory targets.

For banks, NBFCs and payment system operators, the RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices (7 November 2023, effective 1 April 2024) requires a board-approved BCP and DR policy with documented RTO and RPO for critical systems and periodic BCP drills. The RTO and RPO figures are, in 6.2 terms, regulator-mandated objectives, the bank's 6.2 register must operationalise them per critical system, with owners and dates. The RBI Cyber Security Framework (2 June 2016) requires a board-approved cyber security policy with baseline cyber security and resilience requirements, again, in 6.2 terms, regulator-mandated objectives that the BCMS must operationalise. The RBI's action against HDFC in December 2020, barring new digital products and fresh credit cards pending an external IT audit, demonstrated that the RBI treats missed continuity targets as a board-level governance failure, not an IT-ops issue.

For SEBI-regulated entities, the Cybersecurity and Cyber Resilience Framework (SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024) defines five cyber resilience goals across six operational functions. Each goal is, in 6.2 terms, a regulator-mandated objective category. The SEBI MII BCP-DR circular (SEBI/HO/MRD1/DTCS/CIR/P/2021/33, 22 March 2021) requires Market Infrastructure Institutions to achieve RTO of ≤ 2 hours for critical systems and to conduct live failover drills, these are the most prescriptive regulator-mandated continuity objectives in Indian law, and any SEBI-regulated MII's 6.2 register must operationalise them per critical system.

For insurers, the IRDAI Information and Cyber Security Guidelines (24 April 2023) require a board-approved Information and Cyber Security Policy including BCP/DR, with DR drills and annual compliance reporting. The board-approval requirement means that the insurer's 6.2 register is in scope of the board's Risk/IT committee, a structural 6.2 escalation.

CERT-In Directions (20(3)/2022-CERT-In, 28 April 2022) indirectly raise the stakes on 6.2: the 6-hour incident-reporting clock presupposes that the organisation has a measurable detection-and-reporting objective. A BCMS without a detection-time or reporting-time objective has no internal standard against which to measure the 6-hour clock.

The DPDP Act 2023 (Act 22 of 2023) introduces two new 6.2 objective categories for every Data Fiduciary. Section 8(5) makes the availability of personal data a statutory duty, meaning the BCMS must now have availability objectives for personal-data-bearing systems. Section 8(6) imposes a breach-notification duty on the Data Protection Board and on affected Data Principals, meaning the BCMS must have breach-detection and notification-time objectives. For Significant Data Fiduciaries, the DPDP Rules 2025 add DPIA, periodic security audits and a DPO obligation, each of which generates a candidate 6.2 objective. Penalties up to ₹250 crore for failure to take adequate security safeguards and up to ₹200 crore for failure to notify a breach convert the 6.2 availability-and-notification objectives from planning targets into financial-risk-mitigation targets.

The 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 the elements of risk that may threaten the existence of the company itself. A 6.2 register with measurable continuity objectives is the strongest evidence a board can produce that the "elements of risk that may threaten the existence of the company" are being managed against specific targets. Section 177 and SEBI LODR Regulation 21 give the Audit Committee and the Risk Management Committee explicit oversight of risk management systems, for listed entities, the 6.2 register is in scope of those committees.

The NDMA Disaster Management Act 2005 and the National Disaster Management Guidelines (Chemical Disasters 2007; Disaster Management Plans 2014) require industrial operators to identify disaster risks and integrate industrial plans with District Disaster Management Plans. The LG Polymers Vizag styrene gas leak (7 May 2020) is the starkest Indian example of what a 6.2 failure looks like at the industrial-hazard end of the spectrum: the operator had no measurable continuity objective for the M6 tank's runaway-polymerisation scenario, no recovery-time target against which to measure the response, and no evidence standard for declaring the situation contained.

The cost of non-compliance

The financial exposure of weak 6.2 implementation is concrete and quantifiable. Sector-specific penalties include RBI monetary penalties under the Banking Regulation Act (typically ₹1 crore to ₹10 crore per failure for SCBs; higher for systemic cases, the HDFC case demonstrated the structural penalty of a business restriction, which dwarfed the direct monetary penalty); SEBI penalties under the SEBI Act (up to ₹25 crore per contravention); IRDAI penalties (monetary penalties for ongoing non-compliance for insurers (verify the current daily limit)); DPDP penalties (up to ₹250 crore for security-safeguard failures, up to ₹200 crore for breach-notification failures); CERT-In enforcement (escalation to MeitY, with downstream consequences for the entity's ability to operate ICT in India).

Beyond direct penalties, the indirect costs typically dwarf the direct ones. Share-price drops after a public disruption (Yes Bank's deposit base halved between March and June 2020); customer churn after a continuity failure (the HDFC outages drove public customer anger and competitor switching); board and executive reputational damage; and the cost of remediation programmes mandated by regulators (HDFC's external IT audit was a precondition for lifting the digital-products ban). Each of these costs is amplified when the organisation cannot demonstrate that it had measurable continuity objectives in place, the regulator and the court treat the absence of objectives as evidence of governance failure.

A well-built 6.2 evidence set does not eliminate these risks but it does three things. First, it makes the organisation's continuity commitments visible, and visible commitments get resourced. Second, it makes the commitments defensible, when a regulator asks "what were you trying to achieve?", the answer is documented. Third, it converts the BCMS from a cost centre into a performance system, every objective is a hypothesis about what continuous-capability looks like, and every review cycle is a chance to test and improve that hypothesis.

Scope and Applicability

Who must implement 6.2

Clause 6.2 applies to every organisation that claims conformity to ISO 22301:2019, whether through formal third-party certification, through self-declaration, or through a customer-mandated alignment. There is no organisation size, sector or geography that is exempt from the objectives-setting obligation; the depth and formality scale with the BCMS scope (Clause 4.3), but the obligation itself is universal.

For Indian growing companies (50 to 250 staff), 6.2 typically produces a 10-to-25-entry objectives register with a single-tier cascade (policy → objective), owned by function heads, reviewed quarterly by the BCM Steering Committee and annually by top management. The Objective-Achievement Plan for each objective is typically one page. The portfolio is reset annually with mid-cycle revisions on triggers.

For growing Indian organisations (250 to 2,000 staff), the register typically grows to 25 to 60 entries with a two-tier cascade (policy → strategic objective → operational objective), and a Risk Management Committee is constituted (mandatory for SEBI LODR Reg. 21 listed companies). The Objective-Achievement Plans are typically multi-page, with detailed work breakdowns and resource estimates. The portfolio is integrated with the enterprise performance-management cycle.

For multi-entity enterprises (2,000+ staff), the 6.2 portfolio is integrated with group strategy cascades, with group BCM objectives cascaded to subsidiary objective registers, and with multi-jurisdiction regulatory overlays, DORA Article 6(8) digital operational resilience strategy and the related indicators for EU financial-sector exposure; APRA CPS 230 paragraphs 16 and 22 tolerance levels and board approval for Australian operations; MAS TRM system-availability and RTO expectations for Singapore operations; HKMA OR-2 impact tolerance setting for Hong Kong operations; RBI MD for Indian banking operations; SEBI CSCRF for Indian market-infrastructure operations.

Scope boundaries

The 6.2 scope mirrors the BCMS scope (Clause 4.3). If the BCMS scope covers the organisation's Indian payments business but not its international payments business, then 6.2 covers objectives affecting the Indian payments BCMS only. Scope-boundary objectives, objectives at the interface between in-scope and out-of-scope, are still 6.2 objectives if they affect the BCMS achieving its outcomes. For example, if the international payments business relies on the same core ledger as the domestic payments business, then the recovery objective for the core ledger is in scope even if the international business is not.

Outsourced activities (Clause 8.1) are in 6.2 scope if their continuity affects the BCMS. A cloud-hosted core banking system, an outsourced BPO process, a third-party logistics provider, all are 6.2-relevant through the supplier-continuity objectives that the organisation must set and the supplier must inherit. The RBI Master Direction on Outsourcing of IT Services (10 April 2023) and the SEBI CSCRF third-party risk expectations require these to be in the BCMS objectives register.

What 6.2 is distinct from

• 6.2 is not enterprise strategy. Enterprise strategy sets commercial, growth and financial objectives across the organisation. 6.2 sets continuity objectives within the BCMS scope. The two should align, continuity objectives should support enterprise strategy, and enterprise strategy should not commit to delivery that the BCMS cannot underwrite, but they are not the same artefact.
• 6.2 is not the BIA. The BIA (Clause 8.2) identifies prioritised activities and the impact of disruption over time, expressed as MTPD, RPO tolerance and MBCO. 6.2 translates those discovered quantities into committed objectives (RTO that is ≤ MTPD, RPO that meets the tolerance, MBCO as the quality target). The BIA is the input; 6.2 is the commitment.
• 6.2 is not the risk register. The risk register (Clause 6.1) identifies the uncertainties. 6.2 translates each high-rated residual risk into a risk-treatment objective. The risk register is the input; the risk-treatment objective is one category of 6.2 output.
• 6.2 is not the policy. The policy (Clause 5.2) sets the commitment. 6.2 operationalises the commitment into measurable, owned, dated objectives. The policy is the parent; 6.2 is the child.
• 6.2 is not operational planning. Clause 8.1 operational planning and control executes the work day-to-day. 6.2 sets the destination that operational planning works towards. The Objective-Achievement Plan is the link between the two, it is a 6.2 artefact that the operational-planning discipline consumes.
• 6.2 is not performance management. The enterprise performance-management system sets and tracks commercial and operational targets for individuals and functions. 6.2 sets and tracks continuity targets for the BCMS. An individual's performance review may reference their Objective Owner role, but the 6.2 register is not a HR artefact.

What 6.2 covers, the seven objective families

A conformant 6.2 portfolio draws from seven objective families. The families are not mandatory categories, the standard does not prescribe them, but they are the practitioner consensus on what a complete objectives portfolio covers, drawn from ISO 22313:2020, ISO/TS 22317:2021 and the bodies of BCM practice. The families overlap and a single objective may sit in more than one; the categorisation is for completeness checking, not for rigid classification.

Family 1, Recovery-capability objectives. The largest family for most organisations. Derived from the Clause 8.2 BIA. Includes per-prioritised-activity RTO objectives, RPO objectives, MBCO objectives, and the technical capability objectives that underwrite them (DRS build, replication architecture, work-area recovery site, manual-mode fallback). Example: "Reduce the core-ledger RTO from 8 hours to 4 hours by 31 March 2026, measured by a witnessed live failover exercise to the DRS."

Family 2, Governance and leadership objectives. Derived from the Clause 5 leadership and policy commitments. Includes board-approval objectives, BCM Steering Committee cadence objectives, executive-sponsor engagement objectives, board Risk Committee skills objectives, and policy-review objectives. Example: "Constitute a BCM Steering Committee with quarterly meetings and a published charter by 30 June 2026, with attendance ≥ 80%."

Family 3, Competence and awareness objectives. Derived from Clauses 7.2 and 7.3. Includes training-delivery objectives, awareness-programme objectives, role-certification objectives, and exercise-participation objectives. Example: "Deliver BCM awareness training to 100% of staff in customer-facing roles by 31 December 2026, with a knowledge-check pass rate ≥ 85%."

Family 4, Communication objectives. Derived from Clause 7.4. Includes internal-crisis-communication objectives, regulator-notification objectives, customer-communication objectives, media-crisis objectives, and supplier-liaison objectives. Example: "Achieve CERT-In 6-hour notification compliance for 100% of reportable incident categories, measured by exercise and actual incidents, by 31 March 2026."

Family 5, Exercise and test objectives. Derived from Clause 8.5. Includes exercise-calendar objectives, exercise-type objectives (tabletop, simulation, full failover), exercise-participation objectives, and exercise-evidence objectives. Example: "Deliver one live failover exercise of the core ledger to the DRS, one tabletop on supplier-failure, and one simulation on ransomware, by 31 March 2026, all with post-exercise reports within 30 days."

Family 6, Supplier and outsourcing objectives. Derived from Clause 8.1 outsourced activities and the RBI MD Outsourcing of IT Services (10 April 2023). Includes supplier-BCP-inheritance objectives, supplier-concentration objectives, supplier-exit objectives, and supplier-exercise objectives. Example: "Reduce single-supplier exposure for the top-5 critical activities from 100% to 50% by 30 September 2026, with documented and tested exit plans for the single-sourced suppliers."

Family 7, Improvement and learning objectives. Derived from Clauses 9 and 10. Includes corrective-action-closure objectives, continual-improvement objectives, benchmark objectives, and maturity-advancement objectives. Example: "Close 100% of major nonconformities within 90 days of identification and 100% of minor nonconformities within 180 days, measured at the 9.3 management review."

A complete portfolio covers all seven families. A portfolio that covers only Family 1 (recovery capability) is the most common Indian growing-company pattern and the one most likely to draw a Stage 1 finding for incompleteness, because it ignores the governance, competence, communication, exercise, supplier and improvement objectives that the BCMS needs to function.

Key Definitions and Terminology

Business continuity objective

A business continuity objective is a specific, measurable, time-bound commitment that the organisation makes, through the BCMS, to deliver a defined continuous-capability outcome. The objective is the operational unit of the BCMS's performance, it is what the organisation has decided to hold itself accountable to. Objectives are distinguished from aspirations (which have no commitment), activities (which have no outcome), and BIA outputs (which describe impact rather than commitment).

Recovery Time Objective (RTO)

RTO is the target time set for the resumption of a prioritised activity after a disruptive incident, or for the restoration of the resources that support it. RTO is forward-measured from the moment of disruption (T=0) to the moment the activity resumes at its MBCO level. RTO is a target the organisation commits to and engineers towards; it is distinct from MTPD, which is a ceiling the BIA discovers. The cardinal rule, derived from ISO/TS 22317:2021 and restated by APRA CPS 230 paragraph 38, is that RTO must be ≤ MTPD with a safety margin, typical practice is RTO ≈ 0.5 × MTPD or less, giving a buffer for execution failure.

Recovery Point Objective (RPO)

RPO is the point in time to which information used by an activity must be restored after a disruption, measured backward from T=0. An RPO of 1 hour means the organisation can tolerate losing at most the last hour of data. RPO is fundamentally a data quantity (not a duration), and it drives backup and replication architecture rather than recovery timing. DORA Article 12(6) requires entities to determine RPO per function; APRA CPS 230 paragraph 38(b) expresses it as "the maximum extent of data loss the entity would accept as a result of a disruption."

Maximum Tolerable Period of Disruption (MTPD)

MTPD, also called Maximum Acceptable Outage (MAO) in older ISO 22301:2012 and pre-2019 practitioner usage, is the duration of time following a disruptive incident after which the activity's tolerable level of impact is exceeded. MTPD is a discovered quantity derived from the BIA's impact-over-time analysis; it caps RTO. ISO 22301:2019 / ISO 22300:2021 prefer MTPD as the canonical label; current practitioner usage employs both. This guide uses MTPD throughout and notes "(also called MAO)" on first use.

Minimum Business Continuity Objective (MBCO)

MBCO is the minimum level of activity or service that must be maintained or restored during a disruption. MBCO is the quality dimension of recovery, how much of the activity must be running during the disrupted period, not when. It answers "what is the minimum acceptable delivery we can limp along on while recovering?". APRA CPS 230 paragraph 38(c) expresses it as "minimum service levels the entity would maintain while operating under alternative arrangements during a disruption", the cleanest regulatory restatement. UK FCA/PRA/CB and HKMA OR-2 express it as "impact tolerance" for Important Business Services.

SMART-BC objective

A SMART-BC objective is a business continuity objective that satisfies the seven-letter test: Specific, Measurable, Achievable, Relevant, Time-bound, Evidence-eliciting, Reviewable. The SMART-BC pattern is the practitioner operationalisation of the standard's "measurable" requirement; it is not mandated by the standard's text but it is the most-cited conformity pattern in the bodies of BCM practice and is the test the certification auditor will apply de facto.

Objective-Achievement Plan

An Objective-Achievement Plan is the documented plan per objective that addresses the five planning dimensions: the work to be executed, the resources needed, the accountable owner, the target timeline, and the evaluation approach. The Objective-Achievement Plan is the operational substance of 6.2, it is what converts the objective from a target to a managed commitment. Each objective has its own plan, and the plans collectively constitute the BCMS's annual delivery roadmap.

Objective Owner

An Objective Owner is the named individual accountable for the end-to-end delivery of an objective, the plan, the resourcing ask, the execution, the evaluation, and the reporting. The Objective Owner is not always the person doing the work; they are the person who answers for the result. Objective Owners are typically function heads (CISO for cyber-recovery objectives; Head of Operations for process-continuity objectives; Head of IT for infrastructure-recovery objectives; Head of HR for people-continuity objectives; Head of Procurement for supplier-continuity objectives). The BCM Manager is the custodian of the register, not the universal Objective Owner, a register where every objective is owned by the BCM Manager fails the Clause 5.3 role-assignment test.

Cascade

A cascade is the structured translation of an upstream artefact into one or more downstream objectives. The three load-bearing cascades for 6.2 are: policy → objective (every Clause 5.2 policy commitment generates one or more objectives), BIA → objective (every Clause 8.2 BIA output generates one or more recovery-capability objectives), and risk → objective (every Clause 6.1 high-rated residual risk generates one or more risk-treatment objectives). The cascade is documented in the traceability matrices and is the strongest evidence the auditor will see that the objectives are derived and not arbitrary.

Baseline

A baseline is the measured starting position for an objective, the value of the indicator before the Objective-Achievement Plan is executed. The baseline is the anchor for the "measurable" test: an objective that says "reduce RTO from X to Y" needs a measured X (the baseline) and a committed Y (the target). An objective without a baseline is structurally non-measurable because the organisation has no way to know whether it has improved.

Target

A target is the committed end-state value for an objective, the destination the organisation has agreed to deliver. The target is what makes the objective time-bound (the target is to be achieved by a specific date) and measurable (the target is a number, threshold or binary outcome). The target must be inside the upstream constraint (RTO target ≤ MTPD; RPO target ≤ tolerance; MBCO target ≥ minimum).

Indicator

An indicator is the measurable quantity that the objective is expressed in. For recovery objectives, the indicators are typically time (hours, minutes), data (records, transactions), throughput (transactions per hour), or availability (percentage uptime). For governance objectives, the indicators are typically counts (meetings held, attendance rate, policies reviewed). The indicator is the unit of measurement; the baseline and target are values of the indicator.

Status

Status is the current state of the objective at the most recent review. The standard four-state pattern is: on-track (achievable by the target date, plan executing as agreed), at-risk (achievable but with identified risks to delivery, plan under revision), off-track (not achievable without intervention, plan being re-baselined), and achieved (target met, evidence on file, objective ready for retirement). A fifth state, superseded, applies when an objective has been revised or replaced per Clause 6.3 change management.

Trigger

A trigger is the event that initiates an objective re-validation outside the calendar cadence. The standard trigger set includes: significant change per Clause 6.3, incident per Clause 8.6, audit finding per Clause 9.2, regulatory shift, BIA change, exercise outcome that invalidated an assumption, and risk-register change that altered the underlying risk profile. The triggers are documented in the Objective Review Cadence Calendar and are the mechanism that keeps the 6.2 portfolio from becoming static.

Terminology variants across frameworks

Different frameworks use overlapping-but-not-identical labels for the same objective concepts. RTO and RPO are near-universal, but the business-impact ceiling is called MAO in older ISO 22301:2012 tradition and pre-2019 practitioner usage, MTPD in ISO 22301:2019 / ISO/TS 22318:2021, and tolerance for the maximum period of disruption in APRA CPS 230 paragraph 38. MBCO is ISO's label for the minimum acceptable delivery level, expressed as minimum service levels in CPS 230 paragraph 38(c) and as impact tolerance in UK FCA/PRA/CB and HKMA OR-2 operational resilience policy. The 6.2 register should state which terminology variants it uses and reconcile them in the multi-framework crosswalk (see Section 16).

Relationship to Other Clauses and Frameworks

Inside ISO 22301:2019

Clause 6.2 is positioned in Clause 6 (Planning) alongside 6.1 (risks and opportunities) and 6.3 (change management). The positioning is architectural: 6.1 identifies the uncertainties, 6.2 sets the targets that respond to those uncertainties (and to the policy and BIA), and 6.3 ensures changes to the BCMS go through the same planning discipline.

The relationships cascade in both directions.

Upstream of 6.2:

• Clause 4.1 (context) supplies the internal and external issues that determine which objectives are relevant.
• Clause 4.2 (interested parties) supplies the needs and expectations that calibrate objective priority, including the regulatory requirements that many objectives must operationalise.
• Clause 4.3 (scope) defines what 6.2 covers.
• Clause 4.4 (the BCMS) is the system that delivers the objectives.
• Clause 5.1 (leadership) sets and resources the objectives, a non-delegable top-management duty.
• Clause 5.2 (policy) is the parent of every objective; the policy-objective traceability matrix evidences the relationship.
• Clause 5.3 (roles) names the Objective Owners.
• Clause 6.1 (risks and opportunities) supplies the high-rated residual risks that cascade into risk-treatment objectives.

Downstream of 6.2:

• Clause 6.3 (change) triggers objective re-validation when the BCMS scope or design changes.
• Clause 7.1 (resources) funds the Objective-Achievement Plans, every objective has a resource ask that the budget cycle must accommodate.
• Clause 7.2 (competence) underwrites the Objective Owner's ability to deliver.
• Clause 7.3 (awareness) ensures the workforce knows the objectives that touch them.
• Clause 7.4 (communication) covers objective communication to internal and external stakeholders.
• Clause 7.5 (Documented Information) controls the register and the Objective-Achievement Plans.
• Clause 8.1 (operational planning and control) executes the work that the Objective-Achievement Plans describe.
• Clause 8.2 (BIA and disruption risk) is the largest single source of objectives, every prioritised activity's RTO, RPO, MTPD and MBCO translates into one or more objectives.
• Clause 8.3 (strategy) selects continuity solutions that must satisfy the recovery-capability objectives.
• Clause 8.4 (plans and procedures) must meet the recovery objectives.
• Clause 8.5 (exercise programme) tests whether the objectives are achievable, every exercise should test at least one objective.
• Clause 8.6 (evaluation) refreshes the objectives based on post-disruption learnings.
• Clause 9.1 (monitoring) tracks the objective KPIs.
• Clause 9.2 (internal audit) tests the SMART discipline and the review cadence.
• Clause 9.3 (management review) receives the objective portfolio, top management reviews the portfolio and decides on revisions.
• Clause 10.1 (corrective action) updates objectives when missed.
• Clause 10.2 (continual improvement) advances objective maturity.

The cleanest framing: 6.2 is the scoreboard of the BCMS. It draws inputs from Clauses 4, 5 and 6.1; it feeds outputs into Clauses 6.3, 7, 8, 9 and 10. A BCMS without a working 6.2 is a team without a scoreboard, the players (BIA, strategy, plans, exercises) work hard but no one knows whether they are winning.

To other ISO management-system standards

ISO/IEC 27001:2022 Clause 6.2 (information security objectives and planning to achieve them) is the direct parallel. Both clauses use the same Harmonized Structure, both require objectives to be consistent with the policy, both require the planning quadruple (what, resources, who, when, how), both require objectives to be monitored and updated. For organisations running both an ISMS and a BCMS, the objective-setting methodologies should align (same SMART pattern, same review cadence) but the registers are separate because the objective populations differ. Common ground: cyber-recovery objectives appear in both registers (ISMS focuses on the information-security dimensions; BCMS focuses on the continuity dimensions). Integration avoids duplicate work and conflicting targets.

ISO 9001:2015 Clause 6.2 (quality objectives and planning to achieve them) is the quality-management parallel. Same Harmonized Structure, same planning quadruple. For organisations running an integrated Quality + BC management system, the 6.2 clauses of both standards can be jointly implemented, a single objective-setting methodology with separate registers, with cross-references where quality and continuity objectives overlap (e.g., a quality objective on process availability may also be a continuity objective).

ISO 14001:2015 Clause 6.2 (environmental objectives and planning to achieve them) follows the same pattern. Less overlap with BCMS for most organisations, but relevant for industrial operators where environmental and continuity objectives intersect (e.g., chemical-spill response objectives that are both environmental and continuity).

ISO 22313:2020 (guidance on the use of ISO 22301) provides companion guidance on Clause 6.2, expanding on what the standard requires without adding new mandatory obligations. The guidance is non-authoritative for certification (only ISO 22301:2019 itself is the certification reference) but it is the most useful practitioner elaboration of 6.2.

ISO/TS 22317:2021 (BIA guidelines) is the source of the BIA-to-objective cascade. The standard's BIA outputs (MTPD, RPO tolerance, MBCO) are the primary inputs to 6.2 recovery-capability objectives, and 22317's process steps for "determine recovery requirements" map directly to the recovery-objective cascade in Section 7 of this guide.

ISO/TS 22331:2018 (business continuity strategy guidelines) is the consumer of 6.2 recovery objectives, the strategy selects solutions that meet the objectives, and the objectives are the test the strategy must pass.

To sector and global frameworks

Section 16 of this guide provides the full multi-framework mapping. The headline anchors: DORA Article 6(8) requires a digital operational resilience strategy including indicators of recovery capability, these indicators are, in 6.2 terms, regulator-mandated objectives; APRA CPS 230 paragraphs 16 and 22 require the board to approve tolerance levels (the BIA triple) and the BCP, these are, in 6.2 terms, regulator-mandated objective categories; FFIEC BCM Booklet structures its governance principle to mirror ISO 22301 6.2; NIST SP 800-34 Rev 1 seven-step contingency planning process begins with a contingency planning policy statement that operationalises as 6.2 objectives; NIST CSF 2.0 Govern and Recover functions cover objective-setting and recovery-target-setting; MAS TRM system-availability and RTO expectations are regulator-mandated objectives; HKMA OR-2 impact tolerance setting is regulator-mandated objective-setting for Important Business Services. Indian regulatory anchors: RBI MD IT Governance 2023 (documented RTO/RPO for critical systems), RBI Cyber Security Framework 2016 (baseline resilience requirements), SEBI CSCRF 2024 (five cyber resilience goals), SEBI MII BCP-DR 2021 (RTO ≤ 2 hours for critical MII systems), IRDAI ICS 2023 (board-approved BCP/DR), DPDP Act 2023, CERT-In Directions 2022, Companies Act 2013 §134(3)(n) and §177, SEBI LODR Reg. 21, NDMA DM Act 2005. A well-built 6.2 evidence set satisfies all of these simultaneously.

Detailed Implementation Guidance, The Eight Objective-Setting Moves

Figure · Process

What Clause 6.2 asks you to do

This section walks through the eight implementation moves that together produce a 6.2-conformant business-continuity-objectives system. The moves are sequenced for a first-cycle implementation; a mature BCMS runs them in parallel on different cadences.

Move 1, Charter the objectives system (principles, hierarchy, cadence)

The first move is to charter the objectives system: agree the principles that govern objective-setting, define the hierarchy of objectives, set the cadence, and name the roles. The output is a BC Objectives Charter (one of the toolkit artefacts) approved by top management.

The charter must specify the following eight elements. First, objective-setting principles, the rules every objective must satisfy (the SMART-BC test; consistency with policy, scope, BIA, risk register, regulation, and risk appetite; the cascade rules; the review rules). Second, hierarchy, whether the organisation uses a single tier of objectives or a multi-tier cascade (strategic objectives → operational objectives → task objectives). Third, time horizons, the mix of short-term (90-day), medium-term (12-month) and strategic (24-to-36-month) objectives the portfolio will carry. Fourth, cascade rules, how policy commitments, BIA outputs and risk-register entries translate into objectives (the traceability matrix logic). Fifth, cadence, the calendar cadence (monthly BCM Manager review, quarterly Steering Committee review, half-yearly Risk Management Committee review, annual top-management review at 9.3) and the event triggers (Clause 6.3 change, Clause 8.6 incident, Clause 9.2 audit finding, regulatory shift, BIA change, exercise outcome). Sixth, roles, the BCM Manager as methodology custodian, function heads as Objective Owners, top management as approver, the Steering Committee as the review forum. Seventh, authority levels, who can approve a new objective (typically top management), who can revise an objective within its current scope (typically the Steering Committee), who can declare an objective achieved or missed (the Objective Owner with Steering Committee countersignature). Eighth, documentation and control, where the register lives, how it is versioned, who has access, what retention applies (per Clause 7.5).

The charter is the single most important 6.2 artefact. A Stage 1 certification audit that finds no charter will typically issue a major nonconformity on 6.2 regardless of how clean the objectives register looks.

Move 2, Carry the policy forward (policy → objective cascade)

The second move is to carry the Clause 5.2 policy commitments forward and translate each into one or more candidate objectives. The policy is the parent of every objective; the cascade ensures that no policy commitment is left un-operationalised.

The recommended cascade process has three steps. First, policy unpacking, list every commitment in the policy and the interested-party needs it addresses. A typical Indian growing-company BC policy contains 8 to 15 commitments (continuity of prioritised activities, compliance with legal and regulatory requirements, protection of interested-party value, exercise of BCP, training of workforce, supplier-continuity oversight, continual improvement, etc.). Second, objective translation, for each commitment, draft one or more candidate objectives that operationalise it. The translation is a facilitated workshop with the BCM Manager, the Executive Sponsor and the relevant function heads; it is not a solo desk exercise. Third, traceability documentation, record the policy-to-objective link in the Policy-Objective Traceability Matrix, with the policy clause, the candidate objective, and the translation rationale.

For example, a policy commitment to "the continuity of prioritised activities within their documented recovery objectives" translates into candidate objectives for each prioritised activity identified in the Clause 8.2 BIA, typically an RTO objective, an RPO objective, and an MBCO objective per activity. A policy commitment to "compliance with applicable legal and regulatory requirements" translates into candidate objectives that operationalise the specific regulations that apply, RBI MD RTO/RPO targets for banks, SEBI MII BCP-DR RTO ≤ 2 hours for MIIs, IRDAI ICS board-approved BCP/DR for insurers, CERT-In 6-hour reporting for any ICT operator in India, DPDP Act Section 8(5) availability for any Data Fiduciary.

Move 3, Carry the BIA forward (BIA → objective cascade)

The third move is to carry the Clause 8.2 BIA outputs forward and translate each into one or more recovery-capability objectives. The BIA is the largest single source of objectives for most organisations; the BIA-to-objective cascade is the most important integration path in 6.2.

The BIA produces four quantities per prioritised activity: MTPD (the discovered disruption ceiling), RPO tolerance (the discovered data-loss tolerance), MBCO (the discovered minimum-acceptable delivery level), and dependencies and resources (the people, technology, facilities, information and suppliers the activity needs). Each quantity translates into one or more objectives.

The translation rules are: RTO objective ≤ MTPD, with a safety margin (typical practice: RTO ≈ 0.5 × MTPD or less); RPO objective ≤ RPO tolerance, with the safety margin set by the criticality of the data; MBCO objective ≥ MBCO level, expressed as a throughput, capacity or service-level target; dependency objectives covering the resources the activity needs (e.g., a work-area-recovery site objective, a supplier-failover objective, a key-person-cross-training objective).

For example, if the BIA identifies the UPI-switch-processing activity at an Indian payments bank with MTPD = 4 hours, RPO tolerance = 0 (no data loss tolerable), MBCO = 80% of normal throughput, and dependencies including the UPI-switch application, the core ledger, the network, the operations team, and the NPCI rail connectivity, then the cascade produces objectives: RTO objective of 2 hours for UPI switch processing (≤ 4-hour MTPD with a 50% margin); RPO objective of 0 (continuous replication); MBCO objective of 80% throughput at RTO; dependency objectives covering each identified dependency (DRS for UPI switch, DRS for core ledger, network diversity, cross-training of operators, NPCI rail failover testing).

The cascade is documented in the BIA-to-Objective Cascade matrix, a per-prioritised-activity table showing the MTPD, RPO tolerance, MBCO, the derived RTO/RPO/MBCO/dependency objectives, and the Objective Owner. The auditor will walk this matrix line by line for a sample of activities; the matrix is the strongest single piece of 6.2 evidence.

Move 4, Carry the risk register forward (risk → objective cascade)

The fourth move is to carry the Clause 6.1 high-rated residual risks forward and translate each into one or more risk-treatment objectives. This cascade ensures that the BCMS's response to its highest-rated risks is operationalised as a measurable commitment, not left as a treatment-decision note in the risk register.

The translation rule is: every high-rated or critical-rated residual risk with a mitigate or avoid treatment decision generates at least one risk-treatment objective. The objective operationalises the treatment decision; it is not the treatment action itself.

For example, a Clause 6.1 high-rated residual risk of "single-supplier concentration for critical API gateway (cloud provider X)" with a mitigate treatment decision translates into an objective: "Reduce single-supplier exposure for the API gateway from 100% to 50% by 30 September 2026, with a documented and tested failover to a secondary provider." A high-rated residual risk of "BCM Manager single-point-of-knowledge on the BCMS" translates into an objective: "Cross-train two deputies on the BCM Manager role by 31 December 2026, with each deputy completing at least one full BCM cycle (planning, exercise, review)."

The cascade is documented in the 6.1-to-6.2 Cascade matrix, a per-high-rated-risk table showing the risk, the treatment decision, the derived objective(s), and the Objective Owner. This matrix is the strongest evidence that the BCMS's risk thinking and its objective-setting are integrated.

Move 5, Apply the SMART-BC test

The fifth move is to apply the SMART-BC test to every candidate objective produced by Moves 2, 3 and 4. The test rejects, reworks or accepts each candidate; only accepted candidates enter the register.

The test runs as a structured workshop with the BCM Manager, the candidate Objective Owner, and a "red team" reviewer (typically the CISO, the Head of Risk or an external advisor). Each candidate is tested against the seven letters:

• Specific, does the objective name the prioritised activity, system, process, supplier or capability it applies to, with no ambiguity? If not, rework.
• Measurable, does the objective contain a number, threshold or binary outcome that an independent party can verify? If not, rework.
• Achievable, is the objective within the organisation's resource, competence and technology reach within the time horizon, given the Clause 7.1 resourcing commitment? If not, rework or defer.
• Relevant, does the objective trace to the policy, the BIA, the risk register or the regulatory landscape? If not, reject.
• Time-bound, does the objective have a target date and, for multi-quarter objectives, interim milestones? If not, rework.
• Evidence-eliciting, is the objective drafted so its achievement generates evidence the auditor can sample? If not, rework.
• Reviewable, is the objective drafted so that, at the end of its horizon, the organisation can decide whether to mark it achieved, partially achieved, missed or superseded? If not, rework.

Candidates that pass the test enter the register with their full SMART-BC specification. Candidates that fail are either reworked (and re-tested) or rejected (with documented rationale). The reject-or-defer log is itself a useful artefact, it shows the auditor that the organisation is making deliberate trade-offs, not chasing everything.

A common Move 5 outcome in Indian growing companies is the rework of "maintain ISO 22301 certification", a generic objective that fails Specific, Measurable, Achievable (in the sense of being trivially achievable and therefore not a stretch), Evidence-eliciting and Reviewable. The rework produces objectives like "achieve Stage 2 certification by 30 September 2026 with zero major nonconformities, and pass Surveillance 1 by 30 September 2027 with zero major nonconformities and ≤ 2 minor nonconformities."

Move 6, Write the Objective-Achievement Plan (the planning quadruple)

The sixth move is to write the Objective-Achievement Plan for each objective, addressing the five planning dimensions. The Plan is the operational substance of 6.2; it is what converts the objective from a target to a managed commitment.

The Plan is a one-to-three-page document per objective with five sections, one per planning dimension.

Section 1, Work to be executed. The action breakdown: the sequence of steps that will deliver the objective, with each action's output, owner and dependency. For a "reduce core-banking RTO from 8 hours to 4 hours by 31 March 2026" objective, the action breakdown includes: revise the recovery runbook (action owner: Head of IT Infrastructure; output: updated runbook; dependency: none); upgrade the replication architecture (action owner: Storage Lead; output: asynchronous replication commissioned; dependency: vendor delivery); commission the DRS (action owner: DRS Vendor; output: DRS live; dependency: replication upgrade); train the recovery team (action owner: BCM Manager; output: trained team; dependency: DRS commissioning); deliver a tabletop exercise (action owner: BCM Manager; output: exercise report; dependency: trained team); deliver a live failover exercise (action owner: BCM Manager; output: witnessed exercise report; dependency: tabletop exercise); measure and report (action owner: BCM Manager; output: achievement report; dependency: live exercise).

Section 2, Resources needed. The Clause 7.1 input, the budget, the people, the technology, the time and the external services. Specific enough that top management can fund it through the budget cycle. For the example: ₹2.4 crore for the replication architecture over two years; one full-time-equivalent recovery engineer for six months; ₹18 lakh for the DRS build; ₹6 lakh for the exercises; 240 person-hours of internal time across IT, Operations, Risk and Audit; ₹4 lakh for an external exercise facilitator.

Section 3, Accountable owner. The Clause 5.3 role assignment, the named Objective Owner who is accountable end-to-end. For the example: Objective Owner, Head of IT Infrastructure. Action owners as listed in Section 1. Reviewer, BCM Steering Committee.

Section 4, Target timeline. The deadline plus the interim milestones. For the example: 31 March 2026 target. Milestones: 30 June 2025, runbook revised; 30 September 2025, replication upgraded; 31 December 2025, DRS commissioned; 31 January 2026, tabletop exercise delivered; 28 February 2026, live failover exercise delivered; 31 March 2026, achievement report.

Section 5, Evaluation approach. The measurement method, the evidence standard and the decision rule. For the example: measurement method = live failover exercise with timing witnesses; evidence standard = exercise report signed by the Objective Owner, the BCM Manager and Internal Audit; decision rule = achieved if RTO ≤ 4 hours as measured; partially achieved if 4 hours < RTO ≤ 6 hours; not achieved if RTO > 6 hours; superseded if the BIA MTPD is revised.

The Objective-Achievement Plan is the document the auditor will spend the most time on. A register with strong objectives but generic or missing Plans is a Stage 2 finding waiting to happen.

Move 7, Approve, resource and communicate

The seventh move is to secure top-management approval, lock in the Clause 7.1 resourcing, and communicate the objectives to the workforce. This move is what makes the objectives load-bearing, without it, the register is a wish list.

Approval, the objectives portfolio is presented to top management for approval. The presentation includes the policy-objective traceability matrix, the BIA-to-objective cascade, the 6.1-to-6.2 cascade, the SMART-BC test results, the Objective-Achievement Plans, the resource estimate, and the proposed review cadence. Top management's approval is recorded in the BCM Steering Committee minutes and reflected on the register.

Resourcing, the Clause 7.1 budget cycle accommodates the Objective-Achievement Plans' resource estimates. Each objective's resource ask is matched to a budget line; objectives without resourcing are flagged as at-risk or deferred. The budget commitment is the test of whether the organisation is serious about the objective, an objective without a budget is a wish.

Communication, the objectives are communicated to every role with a delivery or awareness stake per Clauses 7.3 and 7.4. Communication is multi-channel: the register is published on the BCM intranet; the top 10 objectives are summarised in a one-page brief; Objective Owners brief their teams; the BCM Manager briefs the broader workforce at awareness sessions. Communication is documented in the Objective Communication Record (dates, audiences, channels, attendance).

The approval-resourcing-communication triad is what separates a 6.2-conformant register from a documentation artefact. An approved, resourced, communicated objective is a commitment the organisation can be held to; a register that lacks any of the three is a wish list.

Move 8, Monitor, review and update

The eighth move is to monitor, review and update the objectives portfolio. This move is what keeps 6.2 from becoming a once-and-done exercise; it is the difference between an L2 (objectives-as-wallpaper) and an L4 (living-scoreboard) BCMS.

Monitoring operates on three cadences. Real-time, objective status on the BCM dashboard, alerts on at-risk and off-track objectives, watch on emerging triggers. Periodic, monthly review by the BCM Manager (status updates, blocker escalation), quarterly review by the BCM Steering Committee (portfolio review, slippage decisions, new-objective proposals), half-yearly review by the Risk Management Committee (where constituted), annual review by top management at the Clause 9.3 management review (portfolio reset, achievement celebration, miss routing to Clause 10.1). Event-triggered, objective re-validation whenever a defined trigger fires: significant change to the BCMS (Clause 6.3), incident (Clause 8.6), audit finding (Clause 9.2), regulatory shift, BIA change, exercise outcome that invalidated an assumption, risk-register change that altered the underlying risk profile.

Review operates on two cadences. Calendar review, the portfolio is reviewed annually to confirm the objectives are still the right objectives, the baselines are still accurate, the targets are still achievable and relevant, and the Objective Owners are still the right owners. Trigger review, specific objectives are re-validated whenever a trigger affects them; the re-validation may confirm, revise or retire the objective.

Updating operates through the Objective Update Log, a chronological record of every change to an objective, with the date, the trigger, the change, the approver and the rationale. The Log is the auditor's primary evidence that the portfolio is living; a register without an Update Log is a register that has not been updated.

The five update patterns are: new objective added (trigger: new policy commitment, new BIA finding, new high-rated risk, new regulation); objective revised (trigger: scope change, BIA revision, baseline re-measurement, resource change, target re-calibration); objective achieved (target met, evidence on file, retired with celebration); objective missed (target not met by the date, routed to Clause 10.1 corrective action with root-cause analysis); objective superseded (objective no longer relevant, retired with rationale).

The Clause 10.2 continual improvement obligation applies directly to 6.2: the objectives system must get better over time, not just stay current. Each annual cycle should produce at least one methodological advance, a new objective family added, a quantitative dimension introduced, a new cascade wired up, a new metric tracked, a new evidence standard adopted.

Tools, Technologies, and Solutions

The 6.2 tooling landscape divides into four layers, each with different cost, complexity and integration profiles. Indian growing companies typically start at Layer 1 and progress upward as the BCMS matures; the certification audit does not require any specific layer, only that the artefacts are controlled, versioned and accessible (Clause 7.5).

Layer 1, Spreadsheet and document repository

The default Layer 1 stack for Indian growing companies is a spreadsheet for the objectives register (one row per objective with the SMART-BC specification, the planning quadruple, the status, the review history), a word-processor document for each Objective-Achievement Plan, and a shared folder (typically a cloud drive) for version control. The Policy-Objective Traceability Matrix, the BIA-to-Objective Cascade and the 6.1-to-6.2 Cascade are additional spreadsheet tabs.

Layer 1 is sufficient for organisations with 10 to 30 objectives and a single BCM Manager custodian. The cost is essentially zero (the tools are already licensed); the effort is in the design of the spreadsheet template (the toolkit provides a starter) and the discipline of keeping it current. The risk is spreadsheet drift, multiple versions, undocumented changes, lost update history, which the BCM Manager must actively manage through version control (file-naming convention, change log, single source of truth).

Layer 2, BCM module within an integrated GRC platform

Layer 2 sees the objectives register migrate into a BCM module within a GRC platform (category-level descriptor: a governance-risk-compliance platform with a BCM or operational-resilience module). The platform enforces workflow (objective drafting → SMART test → approval → communication → monitoring → review), provides audit trails (every change logged with user, timestamp, rationale), supports role-based access (Objective Owners see their objectives; the BCM Manager sees the portfolio; top management sees the dashboard), and integrates with related modules (risk register, BIA, exercise programme, audit findings, corrective actions).

Layer 2 is appropriate for mid-market (250 to 2,000 staff) organisations with 30 to 80 objectives, multiple Objective Owners, and a need for audit-trail discipline. Indicative cost: ₹4 lakh to ₹20 lakh per year for a mid-market GRC platform subscription, plus ₹8 lakh to ₹25 lakh of implementation effort in year one. The platform investment should be justified by the integration benefits (single source of truth, automated workflow, reduced audit-effort) and by the regulator-defence value (a defensible audit trail is a strong regulator-interaction asset).

Layer 3, Integrated operational-resilience platform with objective cascades

Layer 3 sees the objectives register integrated with the broader operational-resilience stack, the BIA tool, the risk-register tool, the exercise-management tool, the incident-management tool, the corrective-action tool, the supplier-risk tool, the regulator-reporting tool. Objective cascades are automated (a BIA update triggers a re-validation of the derived objectives; a risk-register change triggers a re-validation of the risk-treatment objectives; an exercise outcome triggers an evidence-eliciting update).

Layer 3 is appropriate for multi-entity enterprises (2,000+ staff) with 80+ objectives, multi-jurisdiction regulatory overlays, and a need for genuine integration across the operational-resilience stack. Indicative cost: ₹25 lakh to ₹1.5 crore per year for the platform subscription, plus ₹40 lakh to ₹2 crore of implementation effort over 12 to 24 months. The investment is justified by the scale benefits (a single integrated stack replaces multiple silo tools) and by the multi-regulator defence value (the same evidence base satisfies RBI, SEBI, IRDAI, DORA, APRA CPS 230, MAS TRM simultaneously).

Layer 4, AI-augmented objective-setting and analytics

Layer 4 (leading edge, 2026-onwards) sees AI augmentation layered onto the integrated platform. Use cases include: AI-assisted objective drafting (the system proposes candidate objectives based on policy, BIA and risk-register inputs); AI-assisted SMART testing (the system flags objectives that fail Specific, Measurable, Achievable, Relevant, Time-bound); AI-assisted baseline measurement (the system continuously measures the indicator and updates the baseline); AI-assisted trigger detection (the system scans regulatory updates, threat intelligence and incident data and flags triggers that require objective re-validation); AI-assisted achievement prediction (the system predicts which objectives are at risk of being missed based on leading indicators).

Layer 4 is appropriate for L4 to L5 maturity organisations with mature data and a willingness to invest in AI augmentation. Indicative cost: ₹50 lakh to ₹3 crore per year depending on scope and scale, plus the underlying Layer 3 stack. The investment is justified by the speed of decision-making and by the predictive capability (catching a missed objective three months earlier is worth substantially more than the AI licence fee).

The selection criteria

The tooling selection should be driven by the BCMS scope, the objective portfolio size, the integration requirements and the budget envelope, not by the platform's brand. The six selection criteria that matter: (1) BCM-specific functionality, does the platform actually support BCM objectives, BIA, strategy, plans and exercises, or is it a generic GRC platform with a BCM veneer?; (2) integration with the existing stack, does it integrate with the ITSM, the risk-register, the audit-management, the supplier-management, the HR and the finance systems?; (3) audit-trail discipline, does every change have a user, a timestamp and a rationale, exportable for the auditor?; (4) role-based access, does it support Objective Owners, BCM Manager, Steering Committee and top management as distinct roles?; (5) regulator-reporting readiness, does it produce the artefacts the Indian regulators expect (board-approved BCP/DR, documented RTO/RPO, exercise reports, incident reports in the formats CERT-In, RBI, SEBI and IRDAI prescribe)?; (6) total cost of ownership, subscription + implementation + integration + ongoing administration, over a 3-to-5-year horizon.

Avoid platforms that score well on feature checklists but poorly on Indian regulatory fit (many global GRC platforms were not designed with RBI MD, SEBI CSCRF or DPDP Act in mind) and platforms that lock the organisation into proprietary templates that do not match the BCMS scope.

Policy and Procedure Templates

The 6.2 documentation set has three apex artefacts and a supporting set. The full templates are in the toolkit; this section summarises their structure so the practitioner can see the shape before customising.

The BC Objectives Policy (the apex 6.2 policy)

The BC Objectives Policy is a short, board-approved document that sets the principles, hierarchy, cadence and roles for the objectives system. Sample "shall" clauses (organisation-drafted, not reproductions of any standard's text):

• "The Organisation shall establish, implement, maintain and continually improve a set of measurable business continuity objectives consistent with the BC Policy, the BCMS scope and the applicable legal, regulatory and contractual requirements."
• "The Organisation shall ensure that every business continuity objective satisfies the SMART-BC test (Specific, Measurable, Achievable, Relevant, Time-bound, Evidence-eliciting, Reviewable)."
• "The Organisation shall maintain a BC Objectives Register as the single source of truth for all approved objectives, controlled per Clause 7.5 of ISO 22301:2019."
• "The Organisation shall ensure that every objective has a named Objective Owner accountable for end-to-end delivery, an Objective-Achievement Plan addressing the five planning dimensions, and a documented review cadence."
• "Top management shall approve the objectives portfolio at least annually and shall receive the objective performance report at every Clause 9.3 management review."
• "The Organisation shall re-validate objectives on event triggers, change per Clause 6.3, incident per Clause 8.6, audit finding per Clause 9.2, regulatory shift, BIA change, exercise outcome, and shall record every re-validation in the Objective Update Log."

The Policy is approved by top management, communicated per Clause 7.4, and reviewed annually. It is the parent document for the 6.2 system; everything else flows from it.

The Objective-Setting and Review Procedure

The Procedure is the operating manual for the 6.2 system. It documents the eight implementation moves, the SMART-BC test process, the cascade rules, the review cadence, the update patterns, and the role assignments. Sample sections:

• Section 1: Purpose and scope. The Procedure operationalises the BC Objectives Policy for the BCMS scope.
• Section 2: Roles and responsibilities. BCM Manager (methodology custodian, register custodian, review facilitator); Objective Owners (accountable end-to-end); BCM Steering Committee (portfolio review, new-objective approval); top management (annual approval); Internal Audit (independent test).
• Section 3: The eight moves. Step-by-step instructions for each move, with inputs, outputs, templates, owners and deadlines.
• Section 4: The SMART-BC test. The seven letters, the test process, the reject-rework-accept decision rule, the documentation.
• Section 5: The cascade rules. Policy → objective, BIA → objective, risk → objective. The traceability matrices.
• Section 6: The review cadence. Monthly BCM Manager review, quarterly Steering Committee, half-yearly Risk Management Committee, annual top management. Event triggers.
• Section 7: The update patterns. New, revised, achieved, missed, superseded. The Update Log.
• Section 8: Documented information. Version control, access, retention.

The BC Objectives Register (template)

The Register is a per-objective row with columns covering the full SMART-BC specification, the planning quadruple, the cascade links, the review history and the status. The toolkit provides a starter spreadsheet. Column structure:

• ID, unique objective identifier (e.g., OBJ-2026-014).
• Objective statement, the SMART-BC specification (e.g., "Reduce the core-ledger RTO from 8 hours to 4 hours by 31 March 2026, measured by a witnessed live failover exercise to the DRS").
• Family, one of the seven families (recovery capability, governance, competence, communication, exercise, supplier, improvement).
• Objective Owner, named individual.
• Baseline, measured starting position.
• Target, committed end-state.
• Indicator, unit of measurement.
• Deadline, target date.
• Milestones, interim checkpoints.
• Cascade links, policy clause, BIA activity, risk-register entry, regulation reference.
• Planning quadruple, work to be executed, resources needed, accountable owner, target timeline, evaluation approach (one-line summary per cell; full detail in the Objective-Achievement Plan).
• Status, on-track / at-risk / off-track / achieved / superseded.
• Last review, date and reviewer.
• Next review, date.
• Update history, link to Update Log entries.

The Objective-Achievement Plan (template)

The Plan is a one-to-three-page document per objective, structured per the five planning dimensions. The toolkit provides a starter template. Section structure per Section 7.6 above.

The traceability matrices

Three matrices document the cascades. The Policy-Objective Traceability Matrix lists every Clause 5.2 policy commitment and the objective(s) that operationalise it. The BIA-to-Objective Cascade lists every Clause 8.2 BIA prioritised activity and the RTO/RPO/MBCO/dependency objectives derived from it, with the MTPD/tolerance/MBCO values that constrain the objectives. The 6.1-to-6.2 Cascade lists every Clause 6.1 high-rated residual risk and the objective(s) that operationalise the treatment decision.

The Objective Update Log

The Log is a chronological record of every change to an objective, with the date, the trigger, the change, the approver and the rationale. The Log is the auditor's primary evidence that the portfolio is living; a register without an Update Log is a register that has not been updated.

Risk Assessment and Treatment

Clause 6.2 is not primarily a risk clause (Clause 6.1 is), but the objectives system carries its own risks, risks that the objectives are wrong, that they are missed, that they drift, that they are gamed. The 6.2-specific risk assessment identifies these risks and treats them. This is distinct from the Clause 6.1 BCMS-level risk assessment; it is a focused assessment of the objectives system itself.

The 6.2-specific risk catalogue

Eight recurring 6.2 risks span the Indian growing-company segment. Each is described with its source, its consequence and its treatment.

Risk 1, Objectives-as-wallpaper. Source: leadership disengagement from the objectives system; the register exists for the auditor, not for the business. Consequence: the BCMS has no defensible definition of success; recovery decisions become arguments; investment becomes negotiation. Treatment: top-management approval (Move 7); communication (Move 7); real-time monitoring (Move 8); Steering Committee quarterly review (Move 8); the dashboard reported at Clause 9.3 (Move 8).

Risk 2, Cascade failure. Source: the objectives are SMART but do not trace to the policy, the BIA or the risk register. Consequence: the portfolio describes an arbitrary set of activities rather than the activities that would advance the BCMS outcomes. Treatment: the cascade matrices (Move 2, 3, 4); the SMART test "Relevant" limb (Move 5); internal audit testing of the cascade (Move 8).

Risk 3, Planning-form failure. Source: the objectives exist and cascade correctly, but the Objective-Achievement Plans are missing or generic. Consequence: the organisation cannot answer "what will it take to deliver this objective?" until the objective is already overdue. Treatment: Move 6; the Objective-Achievement Plan template; internal audit testing of Plan completeness.

Risk 4, Ownership dilution. Source: every objective is owned by the BCM Manager; function heads are absent. Consequence: no one but the BCM Manager is accountable; functional delivery does not happen. Treatment: the role-naming discipline (Move 1); the Objective Owner assignment per Move 7; the Steering Committee review of ownership.

Risk 5, Baseline drift. Source: the baseline was measured once and never re-measured; the indicator's current value is unknown. Consequence: the "measurable" limb fails in practice, the organisation cannot tell whether it has improved. Treatment: the baseline re-measurement cadence (Move 8); the dashboard's real-time indicator updates.

Risk 6, Target gaming. Source: Objective Owners are incentivised to set easy targets and declare easy wins. Consequence: the portfolio shows green but the BCMS capability is not actually improving. Treatment: the SMART test "Achievable" limb with a stretch expectation (Move 5); the cascade from BIA and risk register (which constrains the target); the internal audit testing of target calibration; the Steering Committee challenge.

Risk 7, Miss-without-corrective-action. Source: objectives are missed but not routed to Clause 10.1. Consequence: the same miss recurs cycle after cycle. Treatment: the miss-routing rule (Move 8); the corrective-action log; the Steering Committee review of misses.

Risk 8, Trigger blindness. Source: the event triggers fire but no one re-validates the affected objectives. Consequence: the portfolio becomes stale even though the triggers are documented. Treatment: the trigger-detection mechanism (Move 8); the re-validation rule; the Internal Audit testing of trigger-response latency.

The 6.2 risk register

The 6.2-specific risks are captured in a tab in the objectives register (or in the BCMS risk register with a 6.2 tag, depending on the organisation's preference). Each risk has an owner, a likelihood, a consequence, a treatment, a residual rating and a review date. The 6.2 risk register feeds into the Clause 9.3 management review alongside the broader Clause 6.1 risk register.

The integration with Clause 6.1

The 6.2-specific risk register is distinct from the Clause 6.1 BCMS-level risk register. The 6.1 register asks: what could stop the BCMS itself from working? The 6.2 register asks: what could stop the objectives system from working? The two overlap (a 6.1 risk of "leadership disengagement" is also a 6.2 risk of "objectives-as-wallpaper"), but the registers are separate because the analysis is performed at different altitudes and the treatments differ.

Audit and Compliance Checklist

The certification auditor (and the internal auditor per Clause 9.2) tests 6.2 against a consistent set of evidence and interview questions. This section provides a 25-question audit checklist with the expected evidence and the red flags.

Charter, principles and policy alignment

Q1. Show me the BC Objectives Charter. Expected evidence: a single document specifying the principles, hierarchy, time horizons, cascade rules, cadence, roles, authority levels and documentation control, approved by top management. Red flag: no charter, or a charter without top-management approval, or a charter whose principles do not match the register.

Q2. Show me how objectives are consistent with the BC policy. Expected evidence: the Policy-Objective Traceability Matrix listing every Clause 5.2 policy commitment and the objective(s) that operationalise it. Red flag: no matrix, or matrix with policy commitments that have no objectives, or objectives that have no policy parent.

Q3. Show me how objectives are consistent with the BCMS scope. Expected evidence: every objective references a Clause 4.3 scope element; no objective covers out-of-scope activities. Red flag: objectives that cover entities, activities or geographies outside the BCMS scope.

Q4. Who approves new objectives and revisions? Expected evidence: documented authority levels per the Charter; top-management approval recorded in the Steering Committee minutes; revisions approved at the appropriate authority level. Red flag: every objective approved by the BCM Manager alone, or no documented approval at all.

SMART-BC discipline

Q5. Walk me through the SMART-BC test for objective [X]. Expected evidence: the seven letters applied with documented rationale; the reject-rework-accept decision recorded. Red flag: no SMART-BC test documentation, or test results that are all "pass" with no rationale.

Q6. Show me a candidate objective that was rejected or reworked. Expected evidence: the reject-or-defer log with rationale. Red flag: no candidates ever rejected (suspicious, suggests the test is not actually applied).

Q7. Show me the baseline for objective [X]. How was it measured? Expected evidence: a measured starting value, with the measurement method, date and measurer. Red flag: no baseline, or a baseline that is "estimated" or "assumed" without measurement.

Q8. Show me the target for objective [X]. Why that target and not another? Expected evidence: a target inside the upstream constraint (RTO ≤ MTPD; RPO ≤ tolerance; MBCO ≥ minimum), with rationale. Red flag: a target that exceeds the upstream constraint, or a target with no rationale.

The cascade

Q9. Walk me through the BIA-to-objective cascade for prioritised activity [Y]. Expected evidence: the BIA outputs (MTPD, RPO tolerance, MBCO, dependencies) and the derived objectives (RTO ≤ MTPD with margin, RPO ≤ tolerance, MBCO ≥ minimum, dependency objectives), with the traceability recorded. Red flag: cascade missing, or RTO objective > MTPD, or RPO objective > tolerance.

Q10. Walk me through the 6.1-to-6.2 cascade for high-rated residual risk [Z]. Expected evidence: the risk with its treatment decision and the derived objective operationalising the treatment. Red flag: no cascade, or high-rated residual risks with no corresponding objective.

Q11. Show me the policy-objective traceability for policy commitment [W]. Expected evidence: the policy commitment and the objective(s) that operationalise it. Red flag: policy commitments with no objectives, or objectives that have no policy parent.

The Objective-Achievement Plan

Q12. Show me the Objective-Achievement Plan for objective [X]. Expected evidence: a one-to-three-page document per objective covering the five planning dimensions. Red flag: no Plan, or a generic Plan with no work breakdown.

Q13. What resources are required for objective [X]? Expected evidence: a specific resource estimate, budget, people, technology, time, external services, matched to a Clause 7.1 budget line. Red flag: vague estimates ("some budget"), or estimates not matched to a budget line.

Q14. Who is the Objective Owner for [X]? Expected evidence: a named individual, typically a function head, accountable end-to-end. Red flag: the BCM Manager owns every objective, or the owner is a function rather than a named individual.

Q15. When will objective [X] be completed, and what are the milestones? Expected evidence: a target date and interim milestones. Red flag: no target date, or a date with no milestones for a multi-quarter objective.

Q16. How will the results of objective [X] be evaluated? Expected evidence: the measurement method, the evidence standard and the decision rule. Red flag: no measurement method, or "we will know it when we see it".

Review, monitoring and update

Q17. Show me the review cadence. Expected evidence: documented cadence (monthly BCM Manager, quarterly Steering Committee, half-yearly Risk Management Committee, annual top management) plus event triggers. Red flag: no documented cadence, or "annually" with no event triggers.

Q18. Show me the last threeBCM Steering Committee reviews of the objectives portfolio. Expected evidence: minutes of three reviews with portfolio discussion, status updates, decisions. Red flag: no reviews since the last audit, or reviews with no discussion of objectives.

Q19. Show me the Objective Update Log. Expected evidence: a chronological record of changes with date, trigger, change, approver and rationale. Red flag: no Log, or a Log with no entries since the last audit (suggests the portfolio is static).

Q20. Show me a miss. What happened? Expected evidence: an objective missed, routed to Clause 10.1 corrective action with root-cause analysis. Red flag: no misses ever recorded (suspicious), or misses with no corrective action.

Integration and communication

Q21. How does the objectives portfolio feed the Clause 9.3 management review? Expected evidence: the portfolio (status, trends, misses, achievements) is a mandatory input to the 9.3 review; minutes record top-management discussion. Red flag: no 6.2 input to the 9.3 review.

Q22. How does the exercise programme (Clause 8.5) test the objectives? Expected evidence: every exercise references at least one objective it is testing; exercise outcomes feed back into objective status. Red flag: exercises with no objective reference, or objectives never tested by exercise.

Q23. How are objectives communicated to the workforce? Expected evidence: the Objective Communication Record with dates, audiences, channels and attendance; awareness sessions per Clause 7.3. Red flag: no communication record, or "the BCM Manager has it on their laptop".

Documented information

Q24. Show me the Documented Information control for the register. Expected evidence: version history, approvals, review triggers, retention per Clause 7.5. Red flag: unversioned register, or no approval, or no review history.

Q25. How do you ensure the register is accessible to those who need it? Expected evidence: access controls, distribution list, awareness per Clause 7.3. Red flag: register lives only on the BCM Manager's laptop.

Metrics and KPIs

A 6.2-conformant BCMS measures its objectives-system performance with a small, meaningful KPI set. Too many KPIs produce noise; too few produce blindness. The recommended set has 13 KPIs across four categories.

Coverage KPIs

KPI-1. Policy-objective coverage ratio. Formula: (number of Clause 5.2 policy commitments with at least one operationalising objective) / (total policy commitments). Target: 100%. Frequency: annually. Why it matters: gaps mean policy commitments the BCMS is not delivering.

KPI-2. BIA-activity coverage ratio. Formula: (number of Clause 8.2 prioritised activities with at least one recovery-capability objective) / (total prioritised activities). Target: 100%. Frequency: quarterly. Why it matters: gaps mean activities the BCMS is not committing to recover.

KPI-3. Objective-family coverage. Formula: (objective families represented in the portfolio) / (the seven families). Target: 7/7. Frequency: annually. Why it matters: a portfolio that covers only Family 1 (recovery capability) is incomplete.

SMART discipline KPIs

KPI-4. SMART-BC test pass rate (first attempt). Formula: (number of candidate objectives passing all seven letters on first submission) / (total candidates tested). Target: ≥70% (lower rates suggest pre-screening is weak; 100% is suspicious). Frequency: quarterly. Why it matters: a high first-attempt pass rate means the candidates are well-prepared; a very high rate means the test is not actually applied.

KPI-5. Baseline-measured ratio. Formula: (number of objectives with a measured baseline, not estimated) / (total objectives). Target: 100%. Frequency: quarterly. Why it matters: an objective without a measured baseline is structurally non-measurable.

KPI-6. Objective-Owner assignment ratio (non-BCM-Manager). Formula: (number of objectives owned by named function heads, not the BCM Manager) / (total objectives). Target: ≥90%. Frequency: quarterly. Why it matters: a register where every objective is owned by the BCM Manager is a register without ownership.

Delivery KPIs

KPI-7. On-time achievement rate. Formula: (number of objectives achieved by their target date) / (number due). Target: ≥80%. Frequency: quarterly. Why it matters: a low rate suggests systematic over-commitment or under-resourcing.

KPI-8. At-risk and off-track count. Formula: count of objectives currently rated at-risk or off-track. Target: trend downward; investigate any objective off-track for two consecutive reviews. Frequency: monthly. Why it matters: the count is a single number the Steering Committee can track.

KPI-9. Miss-to-corrective-action conversion rate. Formula: (number of missed objectives routed to Clause 10.1 with root-cause analysis) / (number of missed objectives). Target: 100%. Frequency: quarterly. Why it matters: misses without corrective action recur.

Review and currency KPIs

KPI-10. Update-Log entry frequency. Formula: count of Update Log entries in the last 90 days. Target: at least one per objective per year on average (more for volatile portfolios); zero entries is a red flag. Frequency: monthly. Why it matters: a static Update Log means a static portfolio.

KPI-11. Trigger-response latency. Formula: median days between a trigger firing and the affected objective being re-validated. Target: ≤14 days. Frequency: quarterly. Why it matters: slow trigger response means the portfolio is stale even though the triggers are documented.

KPI-12. Exercise-to-objective test coverage. Formula: (number of objectives tested by at least one exercise in the last 12 months) / (total objectives that are testable by exercise). Target: ≥80%. Frequency: annually. Why it matters: untested objectives are unverified commitments.

KPI-13. Objective-achievement ROI (the strategic KPI). Formula: (realised benefit of achieved objectives) / (cost of the Objective-Achievement Plans). Target: ≥3x over a 24-month horizon. Frequency: annually. Why it matters: this is the KPI that justifies the BCMS investment to top management. It is the strongest single number to report at the Clause 9.3 management review.

Dashboard layout

The KPIs are presented in a single-page dashboard for the BCM Steering Committee and top management. The dashboard has four panels: Coverage (KPI-1, 2, 3), SMART discipline (KPI-4, 5, 6), Delivery (KPI-7, 8, 9), Review and currency (KPI-10, 11, 12). KPI-13 (ROI) is reported separately at the 9.3 management review. Each panel shows the current value, the trend, the target and the status (green / amber / red). The dashboard is the primary top-management-facing artefact of the 6.2 system.

Common Pitfalls and Audit Failures

Thirteen anti-patterns dominate 6.2 nonconformities in the Indian growing-company segment. Each is named, described, traced to its root cause and counter-measured.

"Maintain / ensure / promote", the wallpaper objectives

The single most common 6.2 failure. The register is full of objectives that begin with verbs that cannot be measured: "maintain business continuity", "ensure regulatory compliance", "promote resilience culture", "strengthen recovery capability", "support the BCMS". These objectives fail the Measurable limb of SMART-BC and the auditor will reject them. The root cause is usually that the register was produced from a generic template without the SMART-BC test being applied. The counter-measure is Move 5 (the SMART-BC test) applied ruthlessly, with the reject-or-defer log as evidence.

The BCM Manager as universal owner

The second-most-common failure. Every objective has the BCM Manager as Objective Owner. Function heads are absent. The root cause is usually that function heads were not engaged in Move 7 (approval and ownership) and the BCM Manager filled the gap. The counter-measure is the role-naming discipline in Move 1, the Objective Owner assignment in Move 7, and the Steering Committee review of ownership.

The RTO > MTPD impossibility

A close third. The RTO objective for a prioritised activity exceeds the activity's MTPD from the BIA, making the objective structurally incapable of being met. The root cause is that the BIA and the objectives register were produced by different people at different times and never reconciled. The counter-measure is the BIA-to-objective cascade (Move 3), the cascade matrix, and the internal audit test of cascade integrity.

The Objective-Achievement Plan as one-line entry

The Plan is reduced to a single line in the register ("achieve RTO 4 hours, Q1") with no work breakdown, no resource estimate, no measurement method. The root cause is usually that Move 6 (the Plan) was treated as a tick-box. The counter-measure is the Plan template, the internal audit test of Plan completeness, and the Steering Committee challenge of Plans that do not address the five planning dimensions.

The cascade that exists on paper but not in practice

The Policy-Objective Traceability Matrix, the BIA-to-Objective Cascade and the 6.1-to-6.2 Cascade exist as spreadsheets, but the underlying policy, BIA and risk register have been updated without updating the cascades. The cascades are stale. The root cause is the lack of event-triggered re-validation (Move 8). The counter-measure is the trigger-detection mechanism and the re-validation rule.

The register that lives on the BCM Manager's laptop

The register is a spreadsheet on the BCM Manager's laptop, not in a shared repository, not version-controlled, not accessible to Objective Owners. The root cause is the lack of a Clause 7.5 Documented Information control. The counter-measure is the documentation-control discipline (single source of truth, version history, role-based access).

The miss that was never declared

An objective was due on 31 March; on 15 May it is still showing "on-track" with no achievement report and no corrective action. The root cause is cultural, Objective Owners are reluctant to declare misses. The counter-measure is the miss-routing rule (Move 8), the Steering Committee's escalation of overdue objectives, and a culture that treats misses as learning opportunities rather than failures.

The objective that was achieved but not evidenced

The objective was achieved but no evidence was collected; the achievement is asserted but not demonstrable. The root cause is that Move 6 (the Plan's "how will results be evaluated" dimension) was not implemented. The counter-measure is the evidence-eliciting limb of SMART-BC (Move 5) and the evidence standard in the Plan.

The portfolio that is all recovery-capability, no governance

The register contains only Family 1 (recovery capability) objectives; Families 2 through 7 (governance, competence, communication, exercise, supplier, improvement) are absent. The root cause is that the BCM Manager focused on the technical recovery objectives and ignored the system-management objectives. The counter-measure is the objective-family coverage check (Move 5) and KPI-3 (objective-family coverage).

The objective that has no baseline

The objective says "reduce RTO from X to Y" but X was never measured; it was assumed or estimated. The root cause is that Move 7 (baseline measurement) was skipped or treated as a desktop exercise. The counter-measure is KPI-5 (baseline-measured ratio) and the internal audit test of baseline integrity.

The objective that has no deadline

The objective is SMART except for the Time-bound limb, it has no target date, or the date is "ongoing", or the date is in the past and was never revised. The root cause is that Move 5 (the SMART test) was not applied rigorously. The counter-measure is the SMART-BC test and the Update Log discipline.

The 6.2 register that duplicates the 8.2 BIA

The 6.2 register simply repeats the BIA's MTPD/RPO/MBCO as if they were objectives, confusing the discovered quantities (BIA) with the committed quantities (objectives). The root cause is a misunderstanding of the BIA-to-objective cascade. The counter-measure is the cascade logic (Move 3) and the auditor test of cascade integrity.

The portfolio that is never re-validated

The portfolio was set at BCMS design time and has not been re-validated since, even though multiple triggers have fired (BIA change, regulatory shift, incident). The root cause is cultural, the BCMS treats the portfolio as a one-off. The counter-measure is the trigger-detection mechanism (Move 8), the Update Log, and the Steering Committee's review of trigger-response latency.

Illustrative Scenario 1: Failure, Sagarwati Fintech Services (Illustrative)

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

Disclaimer: The following is an illustrative scenario. Sagarwati Fintech Services is a fictional composite; the events, characters and figures are representative of patterns seen in the Indian Tier-2 digital-lending sector and are not a report of any specific real company or incident.

The company and the BCMS

Sagarwati Fintech Services Pvt. Ltd. is a Bengaluru-based digital-lending non-banking financial company (NBFC) with 320 staff, ₹620 crore assets under management, originating unsecured personal loans of ₹10,000 to ₹2,00,000 through a mobile app and a partner-merchant network. The company achieved ISO 22301:2019 certification in April 2023, driven by the RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices (7 November 2023, effective 1 April 2024), Sagarwati is in scope as an NBFC with asset base ≥ ₹500 crore.

The BCMS was built rapidly in late 2022 to early 2023 to meet the RBI deadline. The Clause 6.2 objectives register was produced as a spreadsheet with 14 entries, most of them generic ("maintain business continuity for the lending platform", "ensure compliance with RBI regulations", "protect customer data", "strengthen DR capability"), owned end-to-end by the BCM Manager (the Head of Compliance, wearing a second hat), with no deadlines, no baselines and no Objective-Achievement Plans. The register was approved by the CEO in a 20-minute meeting and never revisited.

What the register missed

Between certification in April 2023 and the failure event in late 2025, the BCMS context changed in ways the 6.2 register did not capture.

The BIA was revised but the objectives were not. The BIA was updated in late 2024 to reflect a new loan-origination platform (the core lending engine, replacing a legacy system). The new platform's MTPD was 2 hours (down from 8 hours for the legacy system), reflecting the partner-merchant network's dependence on real-time loan decisions. The 6.2 register still contained the legacy "DR capability" objective with no RTO target; no objective operationalised the new 2-hour MTPD.

The regulatory landscape tightened. The DPDP Act 2023 Rules were finalised in 2025, with a 72-hour breach-notification timeline for personal-data breaches. Sagarwati, processing personal data of 4.2 million borrowers, qualified as a Significant Data Fiduciary. The 6.2 register had no objective for breach-detection time, no objective for notification-time, no objective for DPIA cadence.

RBI enforcement intensified. The RBI issued supervisory letters to several peer NBFCs in 2024-25 citing inadequate BCP/DR, with specific RTO/RPO expectations for the lending engine. The 6.2 register had no objective that operationalised RBI MD IT Governance RTO/RPO expectations for the new platform.

Supplier concentration hardened. A single cloud provider hosted the entire lending stack, origination, decisioning, disbursement, collections, KYC. The 6.1 risk register flagged this as critical-rated with a mitigate decision. The 6.2 register had no objective that operationalised the mitigation; the 6.1-to-6.2 cascade was missing.

The BCM Manager left. The Head of Compliance (who wore the BCM hat) resigned in mid-2025; the role was not backfilled for four months. The 6.2 register had no deputy objective, no cross-training objective, no succession objective.

The failure event

On 18 October 2025, a ransomware incident, propagated through a misconfigured cloud-storage service, encrypted the loan-origination platform's primary database and its backups. The platform went dark. Partner merchants could not originate loans. The 72-hour breach-notification clock started (DPDP); the 6-hour CERT-In clock started; the RBI supervisory notification clock started.

The recovery was improvised. There was no RTO target because the 6.2 register had none. There was no exercised failover procedure because there was no exercise objective that tested the new platform. There was no breach-notification runbook because there was no notification-time objective. The BCM Manager acting role (the CISO, holding the fort) had no objective cascade to consult because the cascade had not been updated.

The platform was restored after 11 hours from a cold backup, well beyond the 2-hour MTPD and the partner-merchant network's tolerance. The breach notification to the Data Protection Board was filed at 86 hours, 14 hours late. The RBI was notified at 30 hours, within supervisory expectations but with no evidence of a tested procedure. The partner-merchant network paused origination for 9 days during recovery and remediation; three of the largest partners migrated to a competitor.

The financial and regulatory impact

The financial impact was severe. Nine days of lost origination: approximately ₹11 crore of foregone interest income. Customer remediation costs (free credit-monitoring offers, fee waivers): approximately ₹3 crore. Recovery and remediation cost: approximately ₹4 crore. DPDP penalty exposure: estimated ₹8 to ₹25 crore depending on the Data Protection Board's assessment of the notification delay. Surveillance audit nonconformity on Clause 6.2 (and 8.2, 8.4, 8.5): certification suspended. RBI supervisory action: a restriction on new branch openings for six months pending remediation. Total direct cost: approximately ₹26 to ₹43 crore plus the loss of three major partner-merchants and the reputational damage of public breach disclosure.

Root causes, all 6.2 failures

The post-incident review (per Clause 8.6 and 10.1) identified five root causes, all of which were 6.2 failures.

First, the register was documentation, not a commitment, the 14 generic objectives had never been operationalised. Second, the cascade was missing, the BIA's 2-hour MTPD, the 6.1 critical-rated supplier risk, the DPDP 72-hour notification duty and the RBI MD RTO/RPO expectations had not been translated into objectives. Third, ownership was dilute, the BCM Manager was the universal owner, and when the BCM Manager left, no one was accountable. Fourth, the Objective-Achievement Plans did not exist, there was no work breakdown, no resource estimate, no measurement method. Fifth, the portfolio was never re-validated, the triggers fired (BIA revision, regulatory shift,BCM Manager departure) but no one re-validated the objectives.

Lessons specific to 6.2

The Sagarwati failure is a textbook 6.2 collapse. Every Clause 8.x technical artefact (BIA, strategy, plans, exercises) was weaker than it should have been because the 6.2 objectives system had failed. The lesson is that 6.2 is the upstream cause of BCMS effectiveness, get it wrong and the downstream artefacts degrade silently; get it right and the downstream artefacts stay honest.

The specific correctives: treat the SMART-BC test as load-bearing; wire the three cascades (policy, BIA, risk); assign Objective Owners by function; write Objective-Achievement Plans per objective; re-validate on every trigger; treat the Update Log as the auditor's primary evidence. A well-built 6.2 system would have produced an RTO objective of ≤ 1 hour for the new platform (well inside the 2-hour MTPD), a 6-hour breach-detection objective and a 60-hour notification objective (well inside the 72-hour DPDP window), a supplier-diversification objective operationalising the 6.1 risk treatment, and a deputy-cross-training objective absorbing the BCM Manager departure. Each of those objectives would have produced evidence of execution in the months before October 2025, and the ransomware incident would have been a contained event rather than a public crisis.

Illustrative Scenario 2: Success, Dakshin Logistics Parks (Illustrative, with ROI)

Disclaimer: The following is an illustrative scenario. Dakshin Logistics Parks is a fictional composite; the events, characters and figures are representative of patterns seen in the Indian organised logistics and warehousing sector and are not a report of any specific real company.

The company and the BCMS

Dakshin Logistics Parks Pvt. Ltd. is a Chennai-headquartered organised logistics company with 640 staff, ₹480 crore annual revenue, operating three large warehousing parks (Chennai, Hosur and Vijayawada) serving e-commerce, FMCG and electronics customers. ISO 22301:2019 certified since 2021, with a BCMS scope covering warehouse operations, the warehouse-management-system (WMS) stack, transportation coordination and customer onboarding. The BCM Manager (a dedicated role since 2023) reports solid-line to the COO and dotted-line to the CEO; the BCM Steering Committee meets quarterly; the board Risk Committee (Dakshin is not listed but has voluntarily constituted one) receives a half-yearly BCM report.

The 6.2 system

Dakshin's 6.2 system was rebuilt in 2024 after a 2023 surveillance audit minor nonconformity on SMART discipline and cascade integrity. The rebuild produced the eight-move architecture in Section 7 of this guide.

The Charter was approved by top management in February 2024. The objective-setting principles adopt the SMART-BC test; the hierarchy is two-tier (strategic objectives → operational objectives); the time horizons are 90-day, 12-month and 24-month; the cascade rules follow the policy, BIA and risk register; the cadence is monthly (BCM Manager), quarterly (Steering Committee), half-yearly (Risk Committee), annual (top management at 9.3).

The portfolio runs at 42 active objectives as of late 2025: 18 recovery-capability (Family 1), 5 governance (Family 2), 4 competence (Family 3), 3 communication (Family 4), 5 exercise (Family 5), 4 supplier (Family 6), 3 improvement (Family 7). Objective Owners are named function heads (COO for warehouse-operations continuity, CIO for WMS recovery, Head of Transport for transportation continuity, Head of HR for people-continuity, Head of Procurement for supplier continuity, CFO for insurance, CEO for board-risk-oversight). The BCM Manager is methodology custodian, not universal owner.

The cascades are documented in three matrices. The Policy-Objective Traceability Matrix covers all 12 policy commitments. The BIA-to-Objective Cascade covers all 14 prioritised activities (inbound receiving, putaway, picking, packing, dispatch, inventory accuracy, returns, customer portal, transport coordination, yard management, slot booking, customs documentation for the export warehouse, cold-chain monitoring for the FMCG section, hazardous-goods segregation for the chemicals section). The 6.1-to-6.2 Cascade covers the 9 high-rated residual risks.

The illustrative objective, and the cascade

To make the system concrete, consider objective OBJ-2025-007: "Reduce the WMS recovery time objective at the Chennai park from 8 hours to 4 hours by 31 March 2026, measured by a witnessed live failover exercise to the Hosur failover site, with MBCO of 70% of normal pick-pack-dispatch throughput at RTO."

The cascade links for this objective: policy, operationalises the Clause 5.2 commitment "to recover prioritised activities within their documented recovery objectives"; BIA, derives from the BIA activity "picking, packing and dispatch at the Chennai park", MTPD 6 hours, RPO tolerance 30 minutes, MBCO 70% throughput; the RTO objective of 4 hours is ≤ MTPD with a 33% safety margin; the RPO objective of 30 minutes (continuous replication) is ≤ tolerance; the MBCO objective of 70% is at the BIA-derived floor. Risk, operationalises a 6.1 high-rated residual risk of "single-WMS-instance failure at Chennai park"; treatment decision: mitigate via failover to Hosur. Regulation, operationalises the DPDP Act 2023 Section 8(5) availability duty for the customer-portal data hosted on the same WMS stack.

The Objective-Achievement Plan for OBJ-2025-007 is three pages. Work to be executed: 7-action breakdown (commission Hosur failover infrastructure; configure continuous replication; revise the recovery runbook; train the recovery team of 6; deliver a tabletop exercise; deliver a live failover exercise; measure and report). Resources: ₹85 lakh for the failover infrastructure (servers, storage, network), one FTE infrastructure engineer for 4 months, ₹6 lakh for an external exercise facilitator, 320 person-hours of internal time across IT, Operations, Risk, Audit. Accountable owner: CIO, with delegated action owners. Target timeline: 31 March 2026, with milestones at 30 June 2025 (infrastructure), 30 September 2025 (replication), 31 December 2025 (runbook and training), 31 January 2026 (tabletop), 28 February 2026 (live exercise), 31 March 2026 (report). Evaluation approach: live failover exercise with timing witnesses (Internal Audit plus the external facilitator); evidence standard = signed exercise report plus the system metric log; decision rule = achieved if RTO ≤ 4 hours as measured; partially achieved if 4-6 hours; not achieved if > 6 hours.

The test, A severe Bay of Bengal cyclonic storm (December 2025)

In early December 2025, a severe Bay of Bengal cyclonic storm made landfall near Chennai, flooding large parts of the city including the industrial corridor where Dakshin's Chennai park is located. The park was not directly inundated but lost grid power for 36 hours, lost telecom connectivity for 18 hours, and was inaccessible to staff for 24 hours due to flooding on approach roads.

The 6.2 system responded as designed. The failover to Hosur had been commissioned in October 2025; the live exercise had been delivered on 28 February 2026 (three months before the cyclone, note that in this illustrative timeline the cyclone is treated as occurring at a point consistent with the objective horizon). The recovery team had been trained; the runbook had been revised; the tabletop had been run. When the cyclone hit, the failover was invoked within 35 minutes (well inside the 4-hour RTO objective), Hosur took over pick-pack-dispatch for Chennai's customers within 1 hour 50 minutes, and MBCO of 78% throughput was achieved at the 4-hour mark (exceeding the 70% target). Power and telecom were restored at the Chennai park within 36 hours; operations were repatriated from Hosur within 48 hours.

The objective was achieved three months ahead of its formal deadline, with the cyclone as the unscripted "exam" that validated the system.

The ROI

The cyclone response delivered measurable returns over the following 12 months.

Customer retention. Three e-commerce customers (together representing ₹38 crore of annual revenue) had been considering dual-sourcing their warehouse operations to reduce single-site risk; the demonstrated failover retained all three. One of them, after the cyclone response, expanded the contract from ₹14 crore to ₹22 crore annually, citing Dakshin's demonstrated operational resilience as the deciding factor. New revenue: ₹8 crore per year.

Insurance premium reduction. The business-interruption insurance renewal in Q1 2026 came in 22% lower than the prior year, reflecting the broker's assessment of the demonstrated failover capability. Saving: approximately ₹55 lakh per year.

Regulator and customer audit cost reduction. The customer-audit calendar for 2026 produced zero findings requiring remediation on the Chennai park's continuity capability (down from 4 findings in 2024 and 2 in 2025). The cost avoidance (the audit team's estimate of remediation cost avoided): approximately ₹35 lakh.

ISO 22301 surveillance audit. The 2026 surveillance audit produced zero major nonconformities and one minor on documentation formatting; the certification body's report cited the 6.2 system as a strength of the BCMS.

Speed of repatriation. The cyclone's overall disruption to Dakshin was 48 hours of Hosur failover (with MBCO exceeded) plus 36 hours of degraded operation during repatriation, substantially less than the industry norm of 5-7 days of full outage for a comparable event. The foregone-revenue avoidance: approximately ₹4 crore.

Total realised value over 12 months: ₹8 cr new revenue + ₹0.55 cr insurance saving + ₹0.35 cr audit-cost avoidance + ₹4 cr foregone-revenue avoidance = ₹12.9 crore against ₹85 lakh invested in the failover infrastructure plus ₹6 lakh facilitation plus internal time. ROI: approximately 14x over 12 months. The 6.2 programme was the highest-ROI investment the BCMS made in the period.

Why 6.2 was the cause of success

Every element of the Dakshin success traces back to a 6.2 move. The failover infrastructure investment was a Move 6 Plan output (resourced, dated, owner-named). The 4-hour RTO target was a Move 3 cascade output (derived from the 6-hour MTPD). The supplier-diversification in the customer's eyes was a Move 7 communication output (the customer knew about the objective and its achievement). The insurance premium reduction was a Move 8 monitoring output (KPI-13 ROI). The reduction in customer-audit findings was the cumulative effect of a load-bearing rather than wallpaper 6.2 system.

The lesson is that 6.2 is the highest-use clause in ISO 22301 for organisations willing to invest in it as a scoreboard rather than a documentation artefact. The Dakshin pattern is replicable across Indian sectors with high physical-asset exposure, logistics, manufacturing, pharmaceuticals, BFSI with physical DCs, where natural hazards are a growing threat (per ISO 22301:2019 Amendment 1:2024 on climate) and where demonstrated continuity capability is increasingly a commercial differentiator.

Multi-Framework Mapping

The 6.2 obligation maps to a structured set of anchors across global frameworks and Indian regulations. The mapping below shows the primary anchor for each framework; the full crosswalk (including secondary anchors) is in toolkit document 17.

ISO management-system parallels

Sector and prudential frameworks

Indian regulatory anchors

SOC 2 trust-services mapping

For organisations seeking SOC 2 alignment alongside ISO 22301, the 6.2 obligation maps to the Common Criteria and the Availability criteria. CC3.1 (the entity specifies objectives) is the direct mapping, ISO 22301 6.2 objectives ARE the SOC 2 entity-level objectives for continuity. CC3.2 (the entity identifies risks) intersects via the 6.1-to-6.2 cascade. CC4.1 (the entity uses monitoring) intersects via 6.2 Move 8 monitoring. CC4.2 (the entity evaluates monitoring) intersects via the 9.3 management review of the objective portfolio. The Availability criteria (A), specifically A1.1 (capacity, environmental protections, backup and recovery), A1.2 (recovery infrastructure), A1.3 (recovery testing), are operationalised through Family 1 (recovery-capability) objectives. The mapping is bidirectional, an ISO 22301 6.2 evidence set produces strong SOC 2 objectives and monitoring evidence.

How the mapping is used in an integrated audit

For organisations running multiple management systems (ISO 22301 + ISO 27001 + ISO 9001), an integrated audit tests the 6.2 clauses of all three standards together. The auditor walks a sample of objectives through all three registers to confirm consistency. The integration is enabled by the Harmonized Structure, the same clause number (6.2) and the same planning-quadruple construction across ISO management-system standards.

For organisations responding to sector regulators (RBI, SEBI, IRDAI, CERT-In, DPDP, NDMA), the 6.2 evidence set is the single most reusable artefact. The same objectives register, with appropriate tagging, satisfies the RBI MD IT risk chapter, the SEBI CSCRF five goals, the IRDAI BCP/DR board approval, the CERT-In 6-hour-clock pre-supposition, the DPDP SDF availability-and-notification objectives, and the NDMA industrial-hazard identification. The toolkit's regulatory crosswalk (document 17) provides the clause-level mapping.

Implementation Roadmap

The 6.2 implementation roadmap for a first-cycle Indian growing-company BCMS is sequenced across four horizons. The roadmap assumes a 50-to-250-staff organisation; mid-market (250 to 2,000 staff) and enterprise implementations extend each horizon proportionally.

Days 0-30, Foundation

The first 30 days establish the foundation. Week 1: charter the objectives system, convene top management, agree the principles, the hierarchy, the time horizons, the cascade rules, the cadence and the roles; draft the Charter for approval. Week 2: carry the policy forward, unpack the Clause 5.2 commitments and translate each into candidate objectives; populate the Policy-Objective Traceability Matrix. Week 3: carry the BIA forward, for every Clause 8.2 prioritised activity, derive the RTO/RPO/MBCO/dependency objectives; populate the BIA-to-Objective Cascade. Week 4: carry the risk register forward, for every Clause 6.1 high-rated residual risk, derive the risk-treatment objective; populate the 6.1-to-6.2 Cascade.

Milestones at Day 30: Charter approved; candidate objective set drafted; three cascade matrices populated; Objective Owner candidates named.

Days 31-60, SMART discipline and planning

Days 31-45: apply the SMART-BC test to every candidate objective; reject, rework or accept; populate the reject-or-defer log. Days 46-60: write the Objective-Achievement Plan for every accepted objective, addressing the five planning dimensions; estimate the resource asks; match to budget lines (Clause 7.1 input).

Milestones at Day 60: SMART-BC test complete; register with accepted objectives; Objective-Achievement Plans drafted; resource asks prepared.

Days 61-90, Approval, resourcing, communication

Days 61-75: present the portfolio to top management for approval; secure the resourcing commitments; communicate the objectives to every role with a delivery or awareness stake. Days 76-90: stand up the KPI dashboard; wire the integration paths to Clause 9.1 monitoring and Clause 9.3 management review; run the first BCM Steering Committee review of the portfolio.

Milestones at Day 90: portfolio approved and resourced; communication record complete; KPI dashboard live; first Steering Committee review complete; integration with 9.1 and 9.3 wired.

Days 91-365, Living the system

Days 91-365: run the monthly BCM Manager reviews, the quarterly Steering Committee reviews, the half-yearly Risk Management Committee review and the annual top-management review at 9.3; respond to event triggers (changes, incidents, audit findings, regulatory shifts, BIA updates, exercise outcomes) with objective re-validations; populate the Update Log; route misses to Clause 10.1 corrective action; advance at least one methodological improvement per Clause 10.2.

Milestones at Day 365: first full cycle complete; portfolio reviewed at 9.3; first-year performance report produced; year-2 portfolio reset approved.

Year 2 onwards, Advancing maturity

Year 2 onwards: advance the maturity model (Section 22). Typical advances: migration from a spreadsheet register to a BCM module within a GRC platform (Layer 2); introduction of quantitative dimensions for high-value objectives; extension of the cascade to cover ISO 27001 6.2 and ISO 9001 6.2 (integrated management system); introduction of AI augmentation (Layer 4) for objective drafting and trigger detection.

Resource plan (indicative, INR)

For a 50-to-250-staff Indian growing company: 0.5 to 1 FTE BCM Manager effort (internal); ₹2 to ₹6 lakh of external facilitation for the first cycle; ₹0.5 to ₹2 lakh for the KPI dashboard (spreadsheet-based at Layer 1); zero to ₹4 lakh for the BCM Steering Committee's quarterly review time. For a 250-to-2,000-staff growing organisation: 1 to 2 FTE BCM Manager effort; ₹6 to ₹20 lakh external facilitation; ₹8 to ₹25 lakh GRC platform implementation (Layer 2); ₹2 to ₹6 lakh ongoing platform subscription. For a 2,000+ enterprise: scale proportionally with a 3-to-5-month implementation horizon.

FAQ

Q1. How many objectives should our BCMS have? The right number is whatever fully operationalises the policy, the BIA and the risk register for your scope, typically 10 to 25 for an Indian growing company, 25 to 60 for a mid-market (250 to 2,000 staff) organisation, and 60 to 200 for a multi-entity enterprise. The standard does not prescribe a number. The completeness test is the family coverage (Section 4.4) and the cascade integrity (Section 7).

Q2. What if our BIA-derived RTO is longer than our MTPD? That is a structural impossibility, the BIA is wrong, or the MTPD was mis-derived. Revisit the BIA. The cardinal rule is RTO ≤ MTPD with a safety margin; an RTO > MTPD means the activity's continuity fails before the objective is delivered.

Q3. Can the BCM Manager own every objective? No. The BCM Manager is the methodology custodian, not the universal Objective Owner. Objective Owners are the function heads in whose domain the objective lives (CISO for cyber-recovery objectives; Head of Operations for process-continuity objectives; etc.). A register where every objective is owned by the BCM Manager fails the Clause 5.3 role-assignment test.

Q4. Do objectives have to be quantitative? No. The standard requires objectives to be measurable, which includes binary outcomes (achieved / not achieved) and thresholds (pass / fail). "Deliver a live failover exercise by Q3" is conformant. The requirement is measurability, not necessarily a continuous number.

Q5. What happens if we miss an objective? Misses are not nonconformities; undeclared misses, missed misses, and misses without corrective action are. Route the miss to Clause 10.1 corrective action with root-cause analysis; declare the miss in the Update Log; report the miss at the next Steering Committee; revise the objective or the underlying capability.

Q6. Do we have to use the SMART-BC pattern specifically? No. The SMART-BC pattern is the practitioner operationalisation of the standard's "measurable" requirement; it is not mandated by the standard's text. You may use any objective-setting pattern as long as the standard's intent (measurable, consistent, planned, monitored) is met. The SMART-BC pattern is the most-cited conformity pattern and is the test the certification auditor will apply de facto.

Q7. How often should we review the objectives portfolio? The cadence is your choice. Leading practice is monthly BCM Manager review, quarterly Steering Committee, half-yearly Risk Management Committee, annual top management at 9.3, plus event-triggered re-validation. "Annually with no event triggers" is a red flag.

Q8. Do we need a software-hosted register? No. A spreadsheet is conformant. A GRC platform is leading practice in larger organisations but is not mandated. The standard requires the register to be controlled, versioned and accessible (Clause 7.5), properties a well-managed spreadsheet has.

Q9. How do DPDP Act 2023 objectives fit into the 6.2 register? Section 8(5) availability duty generates Family 1 (recovery-capability) objectives for personal-data-bearing systems. Section 8(6) breach-notification duty generates Family 4 (communication) objectives for breach-detection and notification-time. For Significant Data Fiduciaries, the DPDP Rules 2025 add DPIA, audit and DPO objectives. Penalties up to ₹250 crore convert these from planning targets to financial-risk-mitigation targets.

Q10. How do we operationalise the SEBI MII BCP-DR RTO ≤ 2 hours expectation? For every critical MII system, set a 6.2 objective that operationalises the RTO ≤ 2 hours with margin (typical practice: 90 minutes), with an Objective-Achievement Plan that includes the technical capability, the runbook, the training, the tabletop exercise, and the live failover exercise witnessed by Internal Audit. The cascade link traces to the SEBI circular and to your Clause 8.2 BIA-derived MTPD.

Q11. How do we integrate 6.2 with Clause 9.3 management review? The portfolio (status, trends, misses, achievements) is a mandatory input to the 9.3 review. Minutes record top-management discussion of the portfolio. The KPI dashboard (Section 12) is the primary artefact. The 9.3 review is where top management decides on portfolio revisions, on acceptance of misses, and on the year-ahead portfolio reset.

Q12. Can objectives be public-facing (e.g., a customer commitment)? Yes, public objectives are conformant and can be a commercial differentiator. But a missed public objective is reputational damage, so public objectives deserve extra scrutiny on the Achievable limb. Typical public-facing objectives include RTO commitments to key customers, availability commitments to regulators, and recovery-capability commitments in tender responses.

Q13. How does the 6.2 system relate to enterprise performance management? The 6.2 system is the BCMS-specific instance of the broader enterprise performance-management discipline. An individual's performance review may reference their Objective Owner role, but the 6.2 register is not an HR artefact. The two systems should align (Objective Owner performance in the BCMS should inform the individual's overall performance assessment) but they are not the same artefact.

Q14. How do we handle objectives for outsourced activities? Outsourced activities are in 6.2 scope if their continuity affects the BCMS. The Objective Owner is the internal role (typically Head of Procurement or Head of IT) accountable for the supplier relationship; the supplier's contractual SLA operationalises the objective. The RBI MD Outsourcing of IT Services (10 April 2023) requires suppliers to inherit the RE's BCP/DR standards, that inheritance is a 6.2 objective for the RE.

Q15. What is the single biggest mistake Indian growing companies make on 6.2? The wallpaper register, generic "maintain / ensure / promote" objectives owned by the BCM Manager with no cascade, no baseline, no deadline and no Plan. The fix is the SMART-BC test, the cascades, the Objective-Achievement Plans, and the role-naming discipline.

Industry-Specific Requirements

The 6.2 system scales and specialises by industry. The five industries below cover the bulk of Indian growing-company BCMS implementations.

Banking, financial services and insurance (BFSI)

BFSI is the most regulator-supervised Indian sector for 6.2. For banks and NBFCs (RBI MD IT Governance, 7 Nov 2023, eff 1 Apr 2024), the 6.2 register must include per-critical-system RTO and RPO objectives that meet or exceed the documented figures in the board-approved BCP/DR; cyber-recovery objectives that operationalise the RBI Cyber Security Framework (2 Jun 2016) baseline; supplier-continuity objectives that operationalise the RBI MD Outsourcing of IT Services (10 Apr 2023). For MIIs and SEBI-regulated REs (SEBI CSCRF, 20 Aug 2024; SEBI MII BCP-DR, 22 Mar 2021), the register must include the SEBI MII RTO ≤ 2 hours for critical systems, the five CSCRF cyber resilience goals as objective categories, and live-failover exercise objectives. For insurers (IRDAI Information and Cyber Security Guidelines, 24 Apr 2023), the register must be board-approved and include DR drill objectives, breach-notification objectives (aligned with DPDP and CERT-In), and ICT outsourcing continuity objectives.

The BFSI 6.2 portfolio typically runs 40 to 80 objectives for a mid-market (250 to 2,000 staff) NBFC, 60 to 120 for a mid-sized bank, and 100+ for a large bank or MII. Family 1 (recovery capability) dominates the portfolio; Family 6 (supplier continuity) is the second-largest; Family 4 (communication, including the regulator-notification objectives) is unusually prominent because of the multiple parallel regulators.

Healthcare

Healthcare 6.2 is dominated by patient-safety objectives, the AIIMS Delhi November 2022 ransomware incident is the illustrative scenario of what happens when a healthcare BCMS has no measurable e-Hospital recovery objective. For Indian healthcare providers, Family 1 must include per-critical-system RTO objectives for the electronic medical records system, the diagnostic systems (radiology, pathology), the pharmacy-dispensing system and the patient-registration system; MBCO objectives must reflect patient-safety floors (e.g., emergency department throughput cannot drop below X%). Family 3 (competence) must include manual-mode fallback training objectives, the AIIMS lesson is that paper-based fallback kept the hospital running while the system was down. Family 7 (improvement) must include immutable-backup objectives.

The DPDP Act 2023 applies fully to healthcare Data Fiduciaries (patient data is personal data); Section 8(5) availability objectives and Section 8(6) breach-notification objectives are mandatory. The Clinical Establishments (Registration and Regulation) Act 2010 and state-level clinical-establishment rules add sector-specific continuity expectations.

IT / ITeS and SaaS

IT/ITeS and SaaS 6.2 is dominated by customer-contractual objectives, the BCMS exists in large part to satisfy customer BCM mandates and tender requirements. The 6.2 register typically includes customer-facing availability objectives (often expressed as uptimes, 99.9%, 99.95%, 99.99%), recovery objectives (RTO/RPO per service tier), and supplier-continuity objectives where the SaaS depends on cloud infrastructure (the customer's BCM audit will trace dependencies through the SaaS to the cloud provider). For SaaS providers serving EU customers, DORA Article 6(8) digital operational resilience strategy and Article 12(6) per-function RTO/RPO are customer-flow-down objectives that must appear in the 6.2 register.

Family 2 (governance) is prominent for IT/ITeS because customer audits focus heavily on governance; Family 5 (exercise) is prominent because customer audits require evidence of tested recovery. The portfolio typically runs 25 to 60 objectives for a mid-market (250 to 2,000 staff) SaaS firm.

Manufacturing

Manufacturing 6.2 is dominated by production-continuity objectives, the LG Polymers Vizag styrene gas leak (7 May 2020) is the illustrative scenario of what happens when an industrial operator has no measurable continuity objective for the runaway-polymerisation scenario. For Indian manufacturers, Family 1 must include per-production-line RTO objectives, OT-system recovery objectives (especially where OT/IT segmentation is weak), and utility-continuity objectives (power, water, gas); Family 6 must include single-source supplier-diversion objectives; Family 7 must include continuous-improvement objectives driven by near-miss analysis.

The NDMA Disaster Management Act 2005 and the NDMA Chemical Disasters Guidelines 2007 apply to chemical, petrochemical and pharma manufacturers; the 6.2 register must include industrial-hazard continuity objectives (on-site emergency plan, off-site mutual aid, district DMP integration). Companies Act 2013 Section 134(3)(n) board risk-oversight applies to the highest-rated continuity risks.

Government and public sector

Government and public sector 6.2 is dominated by citizen-service continuity objectives, the digital India stack (UPI, Aadhaar, DigiLocker, GSTN, e-Hospital, various state-level citizen-service portals) has explicit or implicit continuity expectations that must be operationalised as 6.2 objectives. The CERT-In Directions (28 Apr 2022) apply horizontally; the MeitY guidelines on government-cloud continuity apply to government departments using cloud infrastructure; the NDMA framework applies to disaster-response agencies.

Family 2 (governance) is prominent because of the multi-stakeholder nature of government BCM (department, ministry, attached office, state government, central government); Family 4 (communication) is prominent because citizen-communication during disruption is a statutory expectation in many schemes.

Cross-industry themes

Three themes cut across industries. Climate (per ISO 22301:2019 Amendment 1:2024) generates Family 8-style objectives, climate-driven extreme-weather recovery objectives, coastal-infrastructure resilience objectives, water-stress continuity objectives. DPDP Act 2023 generates availability and breach-notification objectives for every sector processing personal data (essentially every sector). Cross-border regulatory flow-down (DORA, APRA CPS 230, MAS TRM, HKMA OR-2) generates objectives for Indian organisations serving overseas customers in regulated sectors.

Maturity Model

The 6.2 maturity model has five levels. Each level is described with its characteristics, the typical artefacts, the audit posture, and an indicative INR investment to reach the next level. The INR figures are illustrative ranges for an Indian growing-company BCMS (50 to 2,000 staff); larger organisations should scale proportionally.

Level 1, Initial (objectives-as-wallpaper)

The 6.2 system at L1 is a spreadsheet produced for the audit and updated only at audit time. There is no documented Charter, no cascade matrices, no SMART-BC test, no Objective-Achievement Plans, no Objective Owners beyond the BCM Manager. The portfolio consists of generic "maintain / ensure / promote" objectives with no baseline, no target, no deadline. The BCM Steering Committee has not discussed the portfolio in the last 12 months. The auditor will issue a major nonconformity.

Audit posture: major nonconformity likely; surveillance audit risk high. Indicative INR to reach L2: 3 to 8 lakh rupees of internal effort plus 4 to 10 lakh of external facilitation.

Level 2, Managed (basic conformity)

At L2 the 6.2 system meets the minimum certification requirements. There is a Charter, a documented objectives register with SMART-BC-qualified objectives, a Policy-Objective Traceability Matrix, a BIA-to-Objective Cascade, a 6.1-to-6.2 Cascade, Objective-Achievement Plans per objective, named Objective Owners, and a quarterly review cadence. The KPI dashboard exists but is spreadsheet-based. Integration with Clause 9.1 monitoring and Clause 9.3 management review is wired up. The portfolio has been reviewed at the 9.3 review at least once.

Audit posture: conformity achievable; minor nonconformities possible on cascade depth, on family coverage, and on Plan completeness. Indicative INR to reach L3: 6 to 15 lakh rupees of internal effort plus 6 to 18 lakh of external advisory for SMART discipline advancement and cascade depth.

Level 3, Defined (living scoreboard)

At L3 the 6.2 system is genuinely living. Event-triggered updates fire on changes, incidents, audit findings, regulatory shifts, BIA changes and exercise outcomes. The Update Log is populated monthly. The portfolio covers all seven objective families. The cascades are bidirectional (BIA changes update the objectives; objective misses trigger BIA re-validation). The SMART-BC test is applied to every new candidate. Family coverage is complete. The KPI dashboard shows trends, not just current values. TheBCM Steering Committee discusses the portfolio substantively at every quarterly review.

Audit posture: strong conformity; the 6.2 system is a strength, not a vulnerability. Indicative INR to reach L4: 10 to 25 lakh rupees of internal effort plus 12 to 30 lakh for GRC platform adoption (Layer 2) and quantitative-dimension introduction.

Level 4, Quantitatively managed (integrated portfolio)

At L4 the 6.2 system is integrated with the enterprise performance-management system, the ISMS objectives register (ISO 27001 6.2), the QMS objectives register (ISO 9001 6.2), the supplier-management tool, the audit-management tool and the GRC platform. Quantitative dimensions (continuous indicators, not just binary outcomes) are applied to high-value objectives. The portfolio has clear ROI tracking; realised benefits are reported to top management. The board Risk Committee receives the portfolio with trends and benchmarks. AI augmentation (Layer 4) is in pilot for objective drafting, SMART testing and trigger detection.

Audit posture: zero nonconformities expected; the 6.2 system is a documented strength of the BCMS. Indicative INR to reach L5: 20 to 50 lakh rupees of internal effort plus 20 to 60 lakh for full AI augmentation and integrated-dashboards advancement.

Level 5, Optimising (industry-leading)

At L5 the 6.2 system is at the leading edge. The methodology has been published (in anonymised form) in industry forums. The objective portfolio produces predictive indicators that drive the Clause 8.5 exercise programme and the Clause 6.1 risk re-assessment cycle. The 6.2 evidence set is used actively in customer tenders, regulator interactions and board risk-reporting. The board Risk Committee has credited the 6.2 system with measurable contribution to enterprise resilience. The portfolio is benchmarked against sector peers and used as a competitive differentiator.

Audit posture: exemplary; the 6.2 system is benchmarked by peers. Indicative INR to maintain L5: ongoing 8 to 20 lakh per year of internal effort plus 8 to 18 lakh of external advisory for horizon-scanning and methodology refresh.

Maturity advancement principles

Three principles govern advancement. First, the maturity ladder is not a race, an organisation can be a conformant L2 for years without business consequence if the BCMS scope and the operating environment are stable. Second, the advancement investment should be justified by a business case (customer-tender wins, audit-cost reduction, regulator-defence, ROI), not by maturity for its own sake. Third, the maturity should advance in lock-step with the maturity of Clauses 5 (leadership), 8 (operation), 9 (evaluation) and 10 (improvement), a high-maturity 6.2 in a low-maturity Clause 8 operation produces integration gaps.

Maturity assessment (self-assessment)

An honest self-assessment against the five levels is the starting point for advancement. The toolkit's Gap Analysis Template (document 12) provides the assessment framework, current state vs target state across the Charter, the SMART discipline, the cascades, the Objective-Achievement Plans, the integration, the review cadence, and the cross-framework coverage. The self-assessment should be done annually by the BCM Manager and validated by Internal Audit per Clause 9.2.

Emerging Trends

Five trends are reshaping the 6.2 landscape over the 2025-2027 horizon.

Trend 1, Climate as a first-class objective category. ISO 22301:2019 Amendment 1:2024 added climate-related risk as an explicit Clause 4.1 context consideration; the natural 6.2 consequence is the emergence of climate-driven recovery objectives as a distinct sub-category of Family 1. Indian organisations in coastal, flood-prone or water-stressed locations (Mumbai, Chennai, Kolkata, coastal Andhra, the Bengaluru water-stress corridor) are particularly exposed. The 6.2 portfolio should include climate-driven extreme-weather recovery objectives, coastal-infrastructure resilience objectives, and water-stress continuity objectives.

Trend 2, AI and ML as both objective and tool. AI introduces new BCMS objectives (AI-system availability objectives, AI-model-recovery objectives, AI-supplier-concentration objectives) and new tools for the 6.2 system itself (AI-assisted objective drafting, AI-assisted SMART testing, AI-assisted trigger detection, AI-assisted baseline measurement). The 6.2 system should add AI-related objectives by 2026; the opportunity to use AI augmentation within the 6.2 system is a leading-practice L4 to L5 advance.

Trend 3, Regulatory convergence on operational resilience. The 2025 wave of operational-resilience regulation, DORA application (17 January 2025), APRA CPS 230 application (1 July 2025), the UK operational-resilience regime, MAS and HKMA OR-2, is converging on a common architecture: identify important business services, set impact tolerances (the BIA triple, which becomes the 6.2 objectives), test against severe-but-plausible scenarios, demonstrate integration. The 6.2 system is the natural locus for this convergence; a well-built 6.2 satisfies multiple regimes simultaneously.

Trend 4, DPDP operationalisation. The DPDP Rules 2025 finalisation introduces operational 6.2 objectives: the 72-hour breach-notification timeline, the SDF designation criteria, the DPIA cadence, the DPO obligations. The 6.2 register must reflect these as measurable objectives, detection-time, notification-time, DPIA-cadence, DPO-coverage, in addition to the underlying Section 8(5) availability objectives.

Trend 5, Integrated audit and the Harmonized Structure. The Harmonized Structure across ISO management-system standards enables genuinely integrated audits (ISO 22301 + ISO 27001 + ISO 9001) and genuinely integrated management systems. The 6.2 clauses of all three standards can be jointly implemented with a single objective-setting methodology and (where scope overlaps) a single register with domain tagging. The integrated-audit trend is reducing audit fatigue and increasing the ROI of the 6.2 system.

The 2026-2027 outlook

By 2026-2027, three further shifts are likely. First, the Digital India Act (in draft) will introduce a new horizontal ICT regulatory layer with objective implications. Second, sector-specific operational-resilience frameworks (the SEBI CSCRF evolution, the IRDAI ICS refresh, the next RBI MD refresh) will continue to align with the global convergence, making the 6.2 system the single integration point for multi-regulator compliance. Third, AI-augmented objective-setting will move from leading-edge to mainstream, with affordable AI-assisted SMART testing and trigger detection reaching the mid-market (250 to 2,000 staff).

The 6.2 system built today should be designed to absorb these shifts, through the Charter's annual review, the event-trigger update protocol, and the maturity-advancement plan. A 6.2 system built as a living-scoreboard (L3 and above) will absorb them naturally; a 6.2 system built as wallpaper (L1) will be rebuilt each time.

References and Further Reading

The standard and companion guidance

• ISO 22301:2019 Security and resilience, Business continuity management systems, Requirements, with Amendment 1:2024 (climate change adaptation). International Organization for Standardization, Geneva.
• ISO 22313:2020 Security and resilience, Business continuity management systems, Guidance on the use of ISO 22301. International Organization for Standardization, Geneva.
• ISO 22300:2021 Security and resilience, Vocabulary (verify whether a 2025 edition has published before citing vocabulary).
• ISO/TS 22317:2021 Security and resilience, Business continuity management systems, Guidelines for business impact analysis. International Organization for Standardization, Geneva. (Note: the 2015 edition is withdrawn.)
• ISO/TS 22318:2021 Security and resilience, Business continuity management systems, Guidelines for supply chain continuity. (Note: the 2015 edition is withdrawn.)
• ISO/TS 22331:2018 Security and resilience, Business continuity management systems, Guidelines for business continuity strategy. International Organization for Standardization, Geneva.
• ISO 31000:2018 Risk management, Guidelines. International Organization for Standardization, Geneva.
• ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection, Information security management systems, Requirements, Clause 6.2 (information security objectives and planning to achieve them).
• ISO 9001:2015 Quality management systems, Requirements, Clause 6.2 (quality objectives and planning to achieve them).
• ISO 14001:2015 Environmental management systems, Requirements with guidance for use, Clause 6.2 (environmental objectives and planning to achieve them).

NIST, FFIEC, FEMA

• NIST SP 800-34 Rev 1 Contingency Planning Guide for Federal Information Systems. May 2010. (Step 1, contingency planning policy statement, is the structural analogue of 6.2.)
• NIST SP 800-160 Vol 1 (Update 2) and Vol 2 Rev 1 (Cyber-Resilient Systems, September 2021).
• NIST Cybersecurity Framework 2.0 (NIST.CSWP.29), 26 February 2024, especially the Govern function (GV.RM) and the Recover function (RC.RP).
• FFIEC IT Examination Handbook, Business Continuity Management Booklet. November 2019 (OCC Bulletin 2019-57; FRB SR 19-13; FDIC FIL-19071). Governance principle and objectives principle.
• FEMA Federal Continuity Directives FCD-1 (17 January 2017) and FCD-2 (13 June 2017) under PPD-40, Mission Essential Functions and the four-phase continuity model.

EU, UK, Singapore, Australia, Hong Kong

• Regulation (EU) 2022/2554 (Digital Operational Resilience Act, DORA). OJ L 333, 27.12.2022, p. 1. Application date 17 January 2025. Article 6(8) digital operational resilience strategy; Article 11(1) ICT BCP; Article 12(6) RTO/RPO per function.
• UK Civil Contingencies Act 2004, c.36.
• MAS Technology Risk Management Guidelines. Monetary Authority of Singapore, 18 January 2021. System-availability and RTO sections.
• APRA Prudential Standard CPS 230 Operational Risk Management. Effective 1 July 2025. Paragraph 16(e) BCP in framework; paragraph 22 board approves BCP and tolerance levels; paragraph 38 tolerance triple (MTPD / RPO / MBCO equivalent).
• HKMA Supervisory Policy Manual TM-G-2 Business Continuity Planning (revised 31 May 2022) and OR-2 Operational Resilience (31 May 2022), Important Business Services impact tolerance setting.

Indian regulators and statutes

• Reserve Bank of India. Master Direction, IT Governance, Risk, Controls and Assurance Practices. 7 November 2023, effective 1 April 2024. RBI portal id 12562. IT Service Continuity / BCM chapter; documented RTO/RPO for critical systems.
• Reserve Bank of India. Cyber Security Framework in Banks. 2 June 2016. DBS.CO/OC.No.114/33.01.001/2015-16. Board-approved cyber policy with baseline resilience requirements.
• Reserve Bank of India. Master Direction, Outsourcing of Information Technology Services. 10 April 2023. RBI portal id 12376.
• Securities and Exchange Board of India. Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities. SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024.
• Securities and Exchange Board of India. Guidelines for Business Continuity Plan (BCP) and Disaster Recovery (DR) of Market Infrastructure Institutions (MIIs). SEBI/HO/MRD1/DTCS/CIR/P/2021/33, 22 March 2021. RTO ≤ 2 hours for critical MII systems; live failover drills.
• Insurance Regulatory and Development Authority of India. Information and Cyber Security Guidelines, 2023. 24 April 2023. Board-approved BCP/DR; DR drills; annual compliance reporting.
• Indian Computer Emergency Response Team. Directions under Section 70B(6) of the IT Act, 2000. No. 20(3)/2022-CERT-In, 28 April 2022. Six-hour incident reporting; 180-day logs.
• Digital Personal Data Protection Act, 2023. Act No. 22 of 2023, 11 August 2023. Section 8(5) availability duty; Section 8(6) breach notification; Schedule penalties up to ₹250 crore.
• Digital Personal Data Protection Rules, 2025. MeitY notification. 72-hour breach notification; SDF criteria; DPIA cadence.
• Companies Act, 2013. Act No. 18 of 2013. Section 134(3)(n) board risk statement; Section 177 Audit Committee. SEBI LODR Regulation 21 (Risk Management Committee).
• Disaster Management Act, 2005. Act No. 53 of 2005. NDMA Chemical Disaster Management Guidelines (2007); Guidelines for Preparation of Disaster Management Plans (2014).
• Information Technology Act, 2000. Act No. 21 of 2000 (as amended 2008). Sections 43, 65, 66, 70A, 70B.

Practitioner and industry guidance

• Practitioner bodies of BCM professional practice (globally recognised frameworks that codify the discipline's methods, including the objective-setting, BIA, strategy, exercise and improvement professional practices). Used as methodological inspiration during research; not named in this output per the IP-and-sourcing rules that govern this series.

Industry data

• BCI Horizon Scan 2025 ("Complex and Interconnected Risk") and BCI Horizon Scan 2024, industry-statistical survey reports on BCM priorities and disruption experience.

On the use of this guide

This guide is Singahi's own work product. The standards and regulations cited above are the subject matter of the mapping; their marquee IDs and dates are verifiable against the issuing bodies' official portals. The paraphrase of ISO 22301 Clause 6.2 used throughout is the only sanctioned requirement statement; the standard's own text is not reproduced. The illustrative scenarios in Sections 14 and 15 are labelled as such and do not report any specific real company or incident. Reference books used as inspiration during research are not named in this output, per the IP-and-sourcing rules that govern this series; competitor names (BCM/GRC platform vendors, ISO 22301 content vendors, compliance-automation vendors) do not appear anywhere in this output, tool categories are described at the category level.

End of guide.