ISO 22301 Clause 6.3: Planning Changes to the BCMS

Quick Reference (60 Seconds)

If you only read one thing: Clause 6.3 is where the BCMS is treated as an engineering system rather than a documentation set. A 6.3-conformant BCMS is one in which the organisation has decided in advance how the BCMS itself will evolve, has documented the workflow (request, impact assessment, decision, scheduling, communication, execution, validation, post-change review), has named the roles and authorities, has kept a register of every change with full audit trail, and feeds the change portfolio into the management review every cycle. The certification auditor will examine this discipline ruthlessly, and so will a regulator after a change-induced disruption, when a change goes wrong, the second question after "what happened?" is always "was this change authorised, assessed and validated?". Get 6.3 wrong and however strong the policy, the BIA and the plans, the BCMS will silently drift from operational reality between audits. Get it right and the BCMS becomes a controlled system that improves with every change rather than degrading.

What the Standard Actually Requires

The paraphrased requirement

ISO 22301 Clause 6.3 asks organizations to make changes to the BCMS deliberately and in a planned way, considering purpose, consequences, resources, and responsibilities. The paraphrase compresses a substantial management-of-change discipline into one sentence, and unpacking each phrase is the most useful way to understand what an auditor will look for.

Deliberately means the change was the product of an authorised decision, not an accident, a side effect, a vendor push, an undocumented operational convenience or an emergency improvisation that was never retro-reviewed. The deliberate-change test is: can the organisation produce, for any BCMS change in the look-back period, the request, the impact assessment, the approval, the validation and the closure record? If yes, the change was deliberate; if no, the change was uncontrolled and the BCMS has drifted.

In a planned way means the change was processed through a defined workflow. The workflow has at least the following stages: request (the change is articulated, with purpose and scope), impact assessment (the consequences are analysed across the BCMS), decision (the change is approved, rejected, deferred or returned for rework), scheduling (the change is sequenced with other changes and with operational events), communication (the change is communicated to affected roles), execution (the change is implemented per a runbook), validation (the BCMS is tested post-change to confirm it still meets its objectives) and post-change review (the change is closed with lessons captured). A change that skipped any stage is nonconformant, even if the change itself was beneficial.

Considering purpose means the change-rationale is documented. The purpose statement answers: what is the organisation trying to achieve, why now, what is the alternative (do nothing, do something else), and what is the cost of not changing? A change without a documented purpose is a change the organisation cannot defend later, to an auditor, to a regulator, to a customer, or to itself in a post-incident review. The purpose is also the basis for the impact assessment: a change whose purpose is "comply with the new RBI Master Direction" has a different impact profile from a change whose purpose is "save ₹40 lakh a year by consolidating two DRS sites".

Considering consequences means the impact on the BCMS is analysed before the change is approved. The standard lists four consequence dimensions in substance, though not in those exact words, and the practitioner expansion adds three more. The four standard dimensions are: integrity of the BCMS (does the change preserve the system's ability to meet its policy, objectives and regulatory obligations?); resources (does the organisation have the people, budget, time and technology to design, test, deploy and validate the change?); responsibilities (who will request, assess, approve, execute, validate and review the change?); and purpose (already covered). The three practitioner extensions are: dependencies (which BCMS components, BIA, strategy, plans, exercises, supplier arrangements, does the change touch?); interested parties (which internal and external stakeholders need to know?); and legal/regulatory obligations (does the change affect the organisation's compliance posture, and is the regulator notifiable?).

Considering resources means the change is sized before approval. Resources include the budget (the direct cost of the change plus the indirect cost of disruption during the transition), the people (the requester, the assessor, the approver, the implementer, the validator, the communicator), the time (the calendar window in which the change can be executed, including any regulatory blackout windows, e.g., SEBI MIIs cannot make production changes during trading hours or in the run-up to a settlement), the technology (any tooling, sandbox, test environment, monitoring, or rollback capability), and the external services (vendor support, consultants, test labs). A change approved without a resource estimate is a wish, not a commitment.

Considering responsibilities means the roles are named before execution. The RACI for every change, Requester, Assessor, Approver, Implementer, Validator, Communicator, Reviewer, must be filled by named individuals, not by role-only labels. The standard requires responsibilities to be assigned (Clause 5.3) and the change-management workflow to honour them (Clause 6.3); a register where the "Approver" column reads "Management" or "IT" fails the test. The responsibility assignment also defines the authority levels: who can approve a Category-A (scope/policy) change (typically top management), a Category-B (BIA/strategy) change (typically the BCM Steering Committee), a Category-C (plans/runbooks) change (typically the BCM Manager with CAB noting) and a Category-D (operational) change (typically the BCM Manager under delegated authority).

The five planning dimensions, what every change must address

The standard's four-item enumeration (purpose, consequences, integrity, resources, responsibilities) is a checklist, not a methodology. The practitioner expansion, the five planning dimensions every BCMS change must address, is the operational form of the requirement. Together they form the Change-Impact Assessment (CIA) template that every consequential change must complete.

Dimension 1, Purpose. The change rationale: what problem or opportunity triggered the change, what the organisation expects to achieve, what the alternative courses of action were considered, and what the cost of inaction is. The purpose must be specific enough to be testable post-change ("reduce core-ledger RTO from 8 hours to 4 hours by 31 March 2026 by deploying continuous replication to the DRS" is testable; "improve recovery capability" is not).

Dimension 2, Consequences. The impact analysis across seven sub-dimensions: (a) integrity of the BCMS, does the change preserve the system's ability to meet its policy, objectives, regulatory obligations and risk appetite?; (b) dependencies, which BIA activities, RTO/RPO/MBCO commitments, plans, procedures, exercises, supplier arrangements, contact trees and documented-information items does the change touch?; (c) interested parties, which internal roles, customers, regulators, suppliers, partners and (for some changes) the public need to be informed, and how?; (d) legal and regulatory obligations, does the change affect the organisation's compliance posture under RBI, SEBI, IRDAI, CERT-In, DPDP, NDMA, Companies Act or sector-specific rules? Is the regulator notifiable, and on what timeline?; (e) operational risk during transition, what is the risk of disruption during the change window, and what is the rollback plan?; (f) financial impact, what is the direct cost, the indirect cost, the expected benefit, and the ROI horizon?; (g) strategic alignment, does the change support or contradict the BCMS policy, the BC objectives and the enterprise strategy?

Dimension 3, Integrity of the BCMS. The integrity test: how will the organisation confirm that the BCMS still works after the change? The integrity test is operationalised through validation activities, a documented test, a parallel run, an exercise, an internal-audit sample, or a regulator-reporting dry run. The integrity test is the single most consequential element of the CIA because it is the difference between a planned change and an uncontrolled change. A change without an integrity test is nonconformant regardless of how well it was approved.

Dimension 4, Resources. The resource plan: budget (direct + indirect), people (named individuals and FTE-equivalents), time (calendar window + duration), technology (tooling, test environment, rollback capability), external services (vendor support, consultants). The resource plan must be specific enough that top management can fund it through the budget cycle and the CAB can sequence it against other changes.

Dimension 5, Responsibilities. The RACI for the change: Requester, Assessor, Approver, Implementer, Validator, Communicator, Reviewer, all named individuals, with authority levels aligned to the change category. The responsibility assignment is the operational form of Clause 5.3 (roles, responsibilities and authorities) applied to the change in question.

The seven change categories

The standard does not prescribe change categories, but the practitioner consensus, drawn from ISO 22313:2020 guidance on Clause 6.3, the Harmonized Structure's treatment of "change" across ISO management-system standards, and the bodies of BCM practice, is that every BCMS change falls into one of seven categories. The category drives the depth of the CIA, the approval authority and the validation rigour.

Category A, Strategic and scope changes. Changes to the BCMS scope (Clause 4.3), the BCMS policy (Clause 5.2), the top-management sponsorship (Clause 5.1), or the BCMS charter. Examples: in-scope of a new business unit; out-of-scope of a divested business; a policy revision following a regulatory shift; a change of executive sponsor. These are the highest-consequence BCMS changes and always require top-management approval.

Category B, Regulatory changes. Changes triggered by a new or revised legal, regulatory, contractual or standards obligation. Examples: the SEBI CSCRF (20 August 2024) drove a Category-B change programme for every SEBI-regulated entity; the RBI MD IT Governance (7 November 2023, effective 1 April 2024) drove a Category-B change programme for every bank and large NBFC; the DPDP Act 2023 drove a Category-B change programme for every Data Fiduciary; ISO 22301:2019 Amendment 1:2024 on climate drove a Category-B change for Clause 4.1 context. Category-B changes require regulatory-tracking input, legal review, and (often) regulator-notification consideration.

Category C, Corrective changes. Changes triggered by Clause 10.1 corrective action, a nonconformity, an incident, an audit finding, an exercise failure, a near-miss. Examples: revising a BIA after the AIIMS-style ransomware exposed a missing MTPD; updating a contact tree after the BCM Manager left; adding an immutable-backup control after a near-miss. Category-C changes are the highest-volume category in mature BCMSs.

Category D, Improvement changes. Changes triggered by Clause 10.2 continual improvement, opportunities to advance BCMS maturity, to reduce cost, to improve user experience, to benchmark against peers. Examples: migrating from a spreadsheet register to a GRC-platform BCM module; introducing quantitative dimensions into the BIA; adopting AI-assisted trigger detection. Category-D changes are typically scheduled into the annual improvement plan.

Category E, BIA, strategy and plan revisions. Changes to the technical artefacts of the BCMS, the BIA, the strategy, the plans, the procedures, the contact trees, the exercise programme. Examples: revising an RTO from 8 hours to 4 hours after a capability upgrade; adding a new scenario to the exercise programme; updating a crisis-communications procedure after a regulator feedback. Category-E changes are the most frequent changes in a healthy BCMS, they reflect that the BCMS is being used and refined, not that it is unstable.

Category F, Organisational changes. Changes to the organisation itself that affect the BCMS, restructures, mergers, acquisitions, divestitures, leadership transitions, role redefinitions, key-personnel changes. Examples: a restructure that moves the BCM Manager from COO to CEO reporting line; an acquisition that adds a new entity to the BCMS scope; a leadership transition that requires a new executive sponsor. Category-F changes are notoriously under-managed because they are typically owned by HR rather than the BCM team; the MOC system must capture them.

Category G, Technological and supplier changes. Changes to the technology stack or the supplier ecosystem that affect the BCMS, a new core system, a cloud migration, a supplier swap, a contract renewal with revised SLAs, a fourth-party change surfaced through a supplier. Examples: migrating the core banking system to cloud; swapping the DRS vendor; onboarding a new SaaS provider whose availability affects the BCMS; a supplier's own breach requiring emergency BCMS changes. Category-G changes are the second-most-consequential after Category-A because they directly affect RTO/RPO/MBCO capability.

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

Clause 6.3 is widely misread as "produce a change register" or "follow ITIL change management", both are partial and both miss the BCMS-specific obligation. Being explicit about what 6.3 does not require protects against two failure modes: under-investing (treating the register as a documentation artefact) and over-reaching (treating 6.3 as the enterprise change-management system).

• 6.3 does not require every operational change to go through the BCMS MOC. Day-to-day operational changes, a server patch, a password rotation, a user-provisioning tweak, a runbook micro-edit, are Clause 8.1 operational-planning-and-control events, not Clause 6.3 BCMS-change events. The 6.3 scope is changes to the BCMS itself (the system), not changes within the BCMS scope (the operations). The demarcation test: does this change alter the BCMS's design, objectives, capability or dependencies? If yes, it is a 6.3 change; if no, it is an 8.1 change.
• 6.3 does not require the BCMS MOC to be identical to the ITSM/ITIL change process. The two systems overlap (especially for Category-G changes) but they have different scopes (BCMS vs IT services), different stakeholders (BCM Steering Committee vs CAB) and different validation criteria (BCMS integrity vs service availability). For most Indian growing companies, integrating the two, a single change ticket that triggers both ITSM and BCMS workflows where applicable, is more efficient than running them in parallel; but integration is a choice, not a requirement.
• 6.3 does not require a specific number of changes per year. The standard does not mandate a minimum or maximum. A BCMS that processes zero changes in a year is suspicious (it suggests the MOC is bypassed or the BCMS is stagnant); a BCMS that processes 500 changes a year is also suspicious (it suggests operational changes are being routed through the BCMS MOC unnecessarily). The right number is whatever the BCMS's evolution requires, typically 20 to 80 changes per year for an Indian growing company.
• 6.3 does not require every change to have a full CIA. The depth of the CIA must be proportionate to the consequence of the change. A Category-A scope change requires a full CIA with seven-dimension analysis; a Category-E contact-tree update may require only a one-line purpose, a one-line integrity test (the new contact tried and confirmed), and a register entry. The proportionality rule is part of the MOC Procedure, not an optional shortcut.
• 6.3 does not require zero failed changes. Changes that are approved, executed and then rolled back because validation failed are conformant, provided the rollback was clean, the failure was analysed, and the lessons were captured. The integrity test exists precisely to catch failures before they damage the BCMS. A register with zero rollbacks is suspicious; a register with thoughtful rollbacks and documented lessons is healthy.
• 6.3 does not require top-management approval for every change. Authority is delegated by category in the MOC Procedure. Category-A and Category-B changes require top-management approval; Category-C and Category-E changes typically require BCM Steering Committee approval; Category-D and Category-G changes may be delegated to the BCM Manager with CAB noting; routine Category-F changes are typically delegated to HR with BCM-team review.
• 6.3 does not require a software-hosted register. A spreadsheet is conformant. A GRC-platform BCM module 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.3 does not require the BCMS to be change-proof. The standard does not expect the BCMS to be a frozen artefact; it expects the BCMS to evolve under control. A BCMS that never changes is a BCMS that is not being used. The integrity test exists to ensure the BCMS keeps working as it evolves, not to prevent evolution.
• 6.3 does not require a Change Advisory Board specifically. The CAB is the practitioner form of the BCM Steering Committee's change sub-function. A small BCMS may use the full BCM Steering Committee for all change approvals; a large BCMS may use a dedicated CAB. The requirement is that the approval authority is named, documented and exercised.
• 6.3 does not require emergency changes to be pre-approved. The standard recognises that disruptions will require emergency BCMS changes (invoking a manual workaround, swapping a failed supplier, suspending a compromised system). The MOC Procedure must define an emergency path with retro-review rules, the change is executed under incident-commander authority and reviewed at the next CAB for ratification, validation evidence and lessons captured.

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

The standard's text on 6.3 is short and high-level; the substantive architecture, the seven change categories, the five planning dimensions, the eight-stage MOC workflow, the integrity-test patterns, the emergency-change rules, the retro-review discipline, is practitioner elaboration drawn from ISO 22313:2020 (companion guidance on Clause 6.3), ISO 31000:2018 (risk management for changes), the Harmonized Structure's treatment of "planning of changes" across ISO management-system standards, 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 "the BCMS integrity preserved after change"), 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 BCMS as practised matches the BCMS as documented. A BCMS that has drifted silently from its certified state is worse than no BCMS, because the organisation's leaders are making recovery decisions based on assumptions that are no longer true. Clause 6.3 is the clause that keeps the BCMS synchronised with operational reality across every change, every audit cycle, every leadership transition and every regulatory shift.

Every major Indian incident of the last decade that turned from a contained event into a public crisis shares a 6.3 failure mode. The November 2022 AIIMS Delhi ransomware that took e-Hospital down for days, the post-incident review surfaced that the BCMS documentation described a recovery capability that the actual infrastructure no longer matched, because three significant technology changes had been made since the last BIA revision without going through the MOC. The November 2020 HDFC digital outage that drew the RBI's ban on new digital products, the public record shows that the data-centre power-failure scenario that triggered the outage had been identified in a 2019 BIA, the recommended mitigation (active-active DC architecture) had been approved as a Category-G improvement change in early 2020, but the change had been repeatedly deferred without rollback of the underlying risk acceptance. The Cognizant Maze ransomware (April 2020), the SEC-filed disclosure noted that the attacker exploited a federated-network architecture that had been migrated six months earlier without a corresponding BCMS update; the BCMS documentation still described the pre-migration segmentation, and the recovery procedures failed because they did not match the new topology.

The business risk of weak 6.3 implementation is concentrated in four failure modes. The first is silent drift, the BCMS in operation evolves away from the BCMS in documentation through thousands of small uncontrolled changes, until the documentation is fiction. The second is resource-starved change, changes are approved without resource estimates, executed under-budget and under-staffed, and either fail in execution or compromise the BCMS integrity through corner-cutting. The third is un-validated change, changes are deployed without an integrity test, and the resulting drift is discovered only when the BCMS is activated in a real disruption and fails. The fourth is emergency-change debt, disruptions drive emergency changes that are never retro-reviewed, accumulating as a debt that the BCMS eventually cannot carry.

The Indian regulatory context

The Indian regulatory environment has, over the last decade, transformed 6.3 from an internal governance nicety into a regulator-supervised change-management expectation with named process requirements. The transformation has happened across every major sector regulator, and the cumulative effect is that an Indian organisation's MOC system is now expected to be audit-defensible and regulator-interaction-ready.

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 formal change-management process for IT and BCMS changes, with segregation of duties between the requester, approver and implementer, test evidence, rollback plans, and Change Advisory Board (or equivalent) approval. The Master Direction treats change management as a cyber-resilience control, a poorly-managed change is a leading cause of outages and security incidents. The RBI's action against HDFC in December 2020 demonstrated that the RBI treats change-related outages as a board-level governance failure, not an IT-ops issue. The RBI Master Direction on Outsourcing of IT Services (10 April 2023) extends change management to material outsourced-IT changes, the RE must be notified in advance of changes that materially affect the outsourced service, and major changes require RE consent.

For SEBI-regulated entities, the Cybersecurity and Cyber Resilience Framework (SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024) embeds change management as a Protect-domain control, with secure-SDLC expectations for in-house-built systems, change-advisory processes for production changes, and explicit blackout windows during trading and settlement hours. The SEBI MII BCP-DR circular (SEBI/HO/MRD1/DTCS/CIR/P/2021/33, 22 March 2021) requires MII BCP/DR document revisions to be board-notable, every Category-A and Category-B change to the MII BCP/DR is in scope of the board's Risk/IT committee.

For insurers, the IRDAI Information and Cyber Security Guidelines (24 April 2023) require change management as a board-overseen control, with annual compliance reporting. The board-approval requirement means that the insurer's MOC system is in scope of the board's Risk/IT committee, a structural 6.3 escalation.

CERT-In Directions (20(3)/2022-CERT-In, 28 April 2022) indirectly raise the stakes on 6.3: the 6-hour incident-reporting clock presupposes that the organisation can distinguish an incident from a planned change (an uncontrolled change that causes an outage is an incident, not a change). The 180-day log-retention requirement applies to change-related logs; the NTP-sync requirement must be preserved through infrastructure changes; the customer-KYC requirement must be preserved through data-centre or cloud changes.

The DPDP Act 2023 (Act 22 of 2023) introduces two new 6.3 angles for every Data Fiduciary. Section 8(5) makes the availability of personal data a statutory duty, meaning every BCMS change that touches a personal-data-bearing system must be assessed for availability impact. Section 8(6) imposes a breach-notification duty, an uncontrolled change that causes a personal-data breach is a reportable event under DPDP. For Significant Data Fiduciaries, the DPDP Rules 2025 add DPIA, periodic security audits and a DPO obligation, each of which generates a candidate Category-B or Category-C change. Penalties up to ₹250 crore for failure to take adequate security safeguards convert the 6.3 change-management discipline from a quality control into a financial-risk-mitigation control.

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.3-conformant MOC system is the strongest evidence a board can produce that changes to risk-management arrangements are controlled. 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 MOC system 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 keep on-site and off-site emergency plans current, every change to the industrial process, the hazard inventory or the response organisation is a Category-E change requiring regulator-notable revision. The LG Polymers Vizag styrene gas leak (7 May 2020) is the starkest Indian example of what a 6.3 failure looks like at the industrial-hazard end of the spectrum: the operator's emergency plan had not been updated to reflect the changed process conditions (the M6 tank stored for longer periods during the COVID lockdown), the response organisation was not trained on the revised scenario, and the off-site mutual-aid arrangements were not synchronised with the changed risk profile.

The cost of non-compliance

The financial exposure of weak 6.3 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; 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 change-induced public disruption (the September 2024 Jio data-centre fire caused a reported drop in Reliance Industries' intraday price); customer churn after a change-induced continuity failure; 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, and the audit explicitly examined the change-management discipline). Each of these costs is amplified when the organisation cannot demonstrate that the change was authorised, assessed, resourced, executed and validated, the regulator and the court treat the absence of MOC evidence as evidence of governance failure.

A well-built 6.3 evidence set does not eliminate these risks but it does three things. First, it makes the BCMS's evolution visible, and visible changes get resourced, sequenced and validated. Second, it makes the changes defensible, when a regulator asks "was this change authorised?", the answer is documented. Third, it converts the BCMS from a static artefact into an engineering system, every change is a hypothesis about how the BCMS should evolve, and every validation cycle is a chance to test that hypothesis.

Scope and Applicability

Who must implement 6.3

Clause 6.3 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 planned-change 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.3 typically produces a 20-to-40-entry annual change register, a single-tier MOC workflow, a BCM Steering Committee that doubles as the CAB, and a quarterly change-portfolio review. The CIA is a one-page template applied proportionately, full for Category-A/B changes, lightweight for Category-E routine updates. The register is a spreadsheet; the change-related KPIs are tracked on the BCM dashboard.

For growing Indian organisations (250 to 2,000 staff), the register typically grows to 40 to 100 entries per year, a dedicated CAB is constituted as a sub-committee of the BCM Steering Committee, and the MOC workflow is integrated with the ITSM change process (especially for Category-G changes) and the HR org-change process (for Category-F changes). The CIA template is multi-tier, a short form (1 page), a standard form (3 to 5 pages) and a full form (10+ pages with regulatory-impact section), applied by category and consequence.

For multi-entity enterprises (2,000+ staff), the MOC system is integrated across entities, with group BCM changes cascaded to subsidiary BCMSs, with multi-jurisdiction regulatory change-tracking (DORA, APRA CPS 230, MAS TRM, RBI MD, SEBI CSCRF) feeding the change pipeline, and with the CAB functioning as a forum for cross-entity change coordination. The change-related KPIs are benchmarked across entities and reported to the group risk committee.

What "change" means in 6.3 scope

The 6.3 scope is "changes to the BCMS", meaning changes to the system itself, not changes within the system's scope. The demarcation is critical because it determines which changes go through the BCMS MOC and which go through Clause 8.1 operational planning and control.

In scope (BCMS changes, Clause 6.3 applies):

• Changes to the BCMS scope (Clause 4.3).
• Changes to the BCMS policy (Clause 5.2).
• Changes to the BCM Steering Committee, the executive sponsor or the BCM Manager role (Clause 5.1, 5.3).
• Changes to the BC objectives (Clause 6.2).
• Changes to the risk register that affect BCMS risk treatment (Clause 6.1).
• Changes to the BIA (Clause 8.2), including MTPD, RPO tolerance, MBCO revisions, prioritised-activity additions or removals.
• Changes to the BC strategy (Clause 8.3).
• Changes to the BC plans and procedures (Clause 8.4), including invocation procedures, contact trees, crisis-communications procedures.
• Changes to the exercise programme (Clause 8.5), including new scenarios, revised frequencies, new participant groups.
• Changes to the supplier-continuity arrangements (Clause 8.1 outsourced activities), including supplier swaps, contract renewals with revised SLAs, fourth-party changes surfaced through a supplier.
• Changes to the documented information set (Clause 7.5) that affect the BCMS.
• Changes to the BCM training and awareness programme (Clause 7.2, 7.3).
• Changes triggered by Clause 10.1 corrective action.
• Changes triggered by Clause 10.2 continual improvement.
• Changes triggered by Clause 9.2 internal audit findings.
• Changes triggered by Clause 9.3 management review decisions.

Out of scope (operational changes, Clause 8.1 applies, not 6.3):

• Routine IT operational changes, patches, password rotations, user provisioning, server restarts.
• Routine process operational changes, a customer-onboarding flow tweak, a billing-run adjustment, a procurement-process step revision.
• Routine HR operational changes, a new hire, a leaver, a transfer (unless the change is to a BCM-named role).
• Routine supplier operational changes, a contract amendment that does not affect continuity SLAs.

The demarcation test is: does this change alter the BCMS's design, objectives, capability, dependencies or documentation? If yes, it is a 6.3 change; if no, it is an 8.1 change. Borderline cases (e.g., a cloud migration that affects both IT operations and BCMS capability) are routed through both processes, the ITSM change for the operational migration, and the BCMS MOC for the consequential BIA, strategy, plan and exercise updates.

Boundary cases, where 6.3 meets other clauses

Several boundary cases require explicit handling in the MOC Procedure.

Boundary case 1, Change-induced incident. An uncontrolled change that causes an outage is simultaneously a Clause 8.4 incident (the response) and a Clause 10.1 corrective action (the root-cause correction) and a Clause 6.3 change (the original change, now re-reviewed under retro-MOC). The MOC Procedure must define the handover: the incident is managed under Clause 8.4 first; once stabilised, the original change is re-reviewed under retro-MOC; the corrective action is tracked under Clause 10.1; the lessons feed Clause 8.6 evaluation.

Boundary case 2, Emergency change during incident. A disruption that requires an immediate BCMS change (invoking a manual workaround, swapping a failed supplier, suspending a compromised system) is managed under the emergency-change path of the MOC Procedure. The incident commander authorises the change; the BCM team validates it as soon as the incident is stabilised; the CAB retro-reviews it at the next meeting. The 6.3 audit trail is preserved through retro-documentation.

Boundary case 3, Supplier-initiated change. A supplier that changes its own infrastructure, processes or sub-contractors in a way that affects the BCMS is a Category-G change. The supplier's contract must require advance notification (the RBI MD Outsourcing of IT Services requires this for material outsourced-IT changes); the BCM team assesses the impact and decides whether the change is acceptable, requires RE countermeasures, or triggers a supplier-swap consideration.

Boundary case 4, Cumulative change. A series of small changes, each individually below the CIA threshold, can cumulatively constitute a significant BCMS change. The MOC Procedure must include a cumulative-impact review, typically every quarter, the BCM Manager reviews the register for cumulative patterns and flags any cluster that should have been a single full-CIA change.

Boundary case 5, Regulatory change with phased implementation. A new regulation (e.g., the SEBI CSCRF phased deadlines) drives a multi-change programme rather than a single change. The MOC Procedure treats the programme as a portfolio of related changes, each with its own CIA, sequenced against the regulatory deadline and tracked as a programme at the BCM Steering Committee.

What 6.3 covers, the seven change categories revisited

A conformant 6.3 system recognises all seven change categories (see Section 2.3) and routes each through the appropriate CIA depth, approval authority and validation rigour. A MOC system that handles only Category-C (corrective) and Category-E (BIA/plan) changes, the typical pattern in Indian growing companies, leaves the highest-consequence changes (Category-A scope/policy, Category-B regulatory, Category-F organisational, Category-G technological) unmanaged. The 6.3 audit will sample across categories; a register dominated by one category is a red flag.

Key Definitions and Terminology

BCMS change

A BCMS change is any addition, modification or removal that alters the BCMS's design, objectives, capability, dependencies, or documented information. BCMS changes are the input to the MOC system and the unit of analysis in the change register. A change is distinguished from an operational event (which does not alter the BCMS) and from a corrective action (which is a sub-type of change triggered by Clause 10.1).

Management of Change (MOC)

Management of Change is the disciplined process by which BCMS changes are requested, impact-assessed, decided, scheduled, communicated, executed, validated and reviewed. The MOC system is the operational form of Clause 6.3; it is the workflow that converts the standard's requirement into day-to-day practice. The acronym MOC is the practitioner standard; some organisations use MoC or change management, but MOC is preferred to avoid confusion with organisational change management (which is a Category-F subset).

Change Request (CR)

A Change Request is the formal articulation of a proposed BCMS change, submitted to the MOC system. The CR contains, at minimum: the requester, the date, the category, the purpose, the scope of the change, the proposed implementation window, and a preliminary resource estimate. The CR is the input to the impact assessment; a CR without these minimum elements is nonconformant.

Change-Impact Assessment (CIA)

A Change-Impact Assessment is the structured analysis of the proposed change across the five planning dimensions: purpose, consequences (across the seven sub-dimensions), integrity of the BCMS, resources, and responsibilities. The CIA is the substantive artefact of the MOC system, it is what the approver reviews, what the validator tests against, and what the auditor samples. The CIA template is proportionate to the change category (short form, standard form, full form).

Change Advisory Board (CAB)

A Change Advisory Board is the standing sub-committee of the BCM Steering Committee that reviews and authorises BCMS changes above the BCM Manager's delegated authority. The CAB has a written charter defining membership, quorum, cadence (typically weekly for routine changes, monthly for portfolio review, ad-hoc for emergency retro-review), authority levels (by category) and escalation paths. The CAB is the practitioner form of the approval authority; a small BCMS may use the full BCM Steering Committee for all change approvals.

Change Register

A Change Register is the controlled, versioned, accessible record of every BCMS change. The register contains, per change: the unique ID; the requester; the date submitted; the category; the purpose; the scope; the CIA reference; the approver and approval date; the implementer and implementation date; the validation method and result; the post-change review outcome; the status (open, in-flight, approved, rejected, deployed, validated, closed, rolled-back, deferred, superseded); and the link to the related Clause 6.1 risk, Clause 6.2 objective, Clause 8.2 BIA activity, Clause 10.1 corrective action, or Clause 9.2 audit finding as applicable. The register is the auditor's primary evidence; a MOC system without a register is nonconformant.

Change category

A change category is the classification of a BCMS change that drives the depth of the CIA, the approval authority and the validation rigour. The seven categories (A, strategic/scope; B, regulatory; C, corrective; D, improvement; E, BIA/strategy/plan; F, organisational; G, technological/supplier) are the practitioner consensus; an organisation may add categories (e.g., a separate category for cyber-driven changes) but should not collapse them (combining A and B weakens the regulatory-change trail).

Integrity test

An integrity test is the validation activity that confirms the BCMS still works after a change. The integrity test is operationalised through one or more of: a documented test (e.g., a recovery-time test against the RTO objective); a parallel run (the new arrangement runs alongside the old for a defined period); an exercise (a tabletop, simulation or full failover that exercises the changed component); an internal-audit sample (a Clause 9.2 audit of the changed area); a regulator-reporting dry run (a mock breach-notification exercise against the changed process). The integrity test is the difference between a planned change and an uncontrolled change.

Emergency change

An emergency change is a BCMS change executed during an active disruption under the authority of the incident commander, without pre-approval through the standard MOC workflow. Emergency changes are retro-reviewed at the next CAB meeting for ratification, validation evidence and lessons captured. The emergency-change path is part of the MOC Procedure, not an exception to it.

Retro-review

A retro-review is the post-hoc application of the MOC workflow to a change that was executed without pre-approval, either an emergency change (legitimate) or an uncontrolled change (a nonconformity being corrected). The retro-review produces the CIA, the approval record (or the ratification decision), the validation evidence and the lessons captured. Retro-reviews are part of the discipline; a register with thoughtful retro-reviews is healthy, a register with no retro-reviews is suspicious.

Rollback

A rollback is the reversion of a deployed change to the pre-change state, executed when the integrity test fails or when post-deployment issues exceed the tolerance. The rollback is part of the MOC Procedure; every consequential change must have a documented rollback plan. A clean rollback, the change failed validation, was rolled back, the failure analysed, the lessons captured, is conformant. A failed rollback (the rollback itself did not work) is a serious nonconformity, because it means the BCMS is now in an undefined state.

Cumulative impact

A cumulative impact is the aggregate effect of a series of small changes that, individually, were below the CIA threshold but together constitute a significant BCMS change. The MOC Procedure includes a quarterly cumulative-impact review to surface and re-assess clusters.

Change requester, assessor, approver, implementer, validator, communicator, reviewer

The seven roles in the MOC RACI. The requester articulates the change and submits the CR. The assessor conducts the CIA. The approver authorises (or rejects) the change against the CIA. The implementer executes the change per the deployment runbook. The validator conducts the integrity test. The communicator executes the change-communication plan per Clause 7.4. The reviewer captures the lessons at the post-change review. In a small BCMS, one individual may hold multiple roles (typically: requester = a function head; assessor = BCM Manager; approver = BCM Steering Committee; implementer = IT or process team; validator = BCM Manager with Internal Audit witness; communicator = BCM Manager; reviewer = BCM Manager). In a large BCMS, segregation of duties applies, the requester, approver and implementer must be different individuals.

Authority matrix

An authority matrix is the documented mapping of change categories to approval authority. A typical Indian growing-company authority matrix: Category-A (scope/policy), top management; Category-B (regulatory), top management with legal review; Category-C (corrective), BCM Steering Committee; Category-D (improvement), BCM Steering Committee for major, BCM Manager under delegated authority for minor; Category-E (BIA/strategy/plan), BCM Steering Committee for major, BCM Manager for routine; Category-F (organisational), top management (HR-led with BCM-team review); Category-G (technological/supplier), BCM Steering Committee for major, BCM Manager under delegated authority with CAB noting for routine.

Terminology variants across frameworks

Different frameworks use overlapping-but-not-identical labels for change concepts. MOC is the BCM/ISO 22301 practitioner label. ITIL/ITSM change management is the IT-services label; the underlying discipline is similar but the scope is narrower (IT services) and the artifacts differ (RFC, Request for Change, instead of CR; CAB, Change Advisory Board, same; FSC, Forward Schedule of Changes, instead of a change-portfolio view). Configuration management (ISO 10007) overlaps for changes to configuration items. Engineering change management (ISO 9001 Clause 6.3, Clause 8.1, Clause 8.5) overlaps for changes to product/process design. The 6.3 system 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.3 is positioned in Clause 6 (Planning) alongside 6.1 (risks and opportunities) and 6.2 (objectives). The positioning is architectural: 6.1 identifies the uncertainties, 6.2 sets the targets, and 6.3 ensures the system itself evolves under control. Without 6.3, the BCMS becomes a snapshot, accurate at certification, drifting ever since.

The relationships cascade in both directions.

Upstream of 6.3 (triggers):

• Clause 4.1 (context), changes to internal or external issues (climate per Amendment 1:2024, regulatory, market, technological) fire 6.3 triggers.
• Clause 4.2 (interested parties), changes to interested-party needs (a new regulator, a new customer with BCM flow-downs, a new industry body).
• Clause 4.3 (scope), scope changes are the highest-consequence 6.3 trigger (Category-A).
• Clause 4.4 (the BCMS), the BCMS itself is what gets changed.
• Clause 5.1 (leadership), leadership transitions are an organisational-change trigger (Category-F); leadership sets the MOC authority matrix.
• Clause 5.2 (policy), policy changes are Category-A; policy commitments operationalise through 6.3.
• Clause 5.3 (roles), role changes are Category-F; role assignments define the MOC RACI.
• Clause 6.1 (risks and opportunities), risk-register changes that affect BCMS risk treatment interlock with 6.3; new high-rated residual risks may trigger Category-C or Category-D changes.
• Clause 6.2 (objectives), objective revisions are a downstream consequence of 6.3 (a change may require objective re-validation); objective revisions are themselves Category-D changes.

Downstream of 6.3 (consequences):

• Clause 7.1 (resources), every consequential change has a resource ask that the budget cycle must accommodate.
• Clause 7.2 (competence), new roles, new systems, new procedures may require new competence (training, certification).
• Clause 7.3 (awareness), the workforce must be made aware of consequential changes (a change-communication plan is part of the CIA).
• Clause 7.4 (communication), every change has a communication plan for internal and external stakeholders.
• Clause 7.5 (documented information), every consequential change produces a document update; the version control of BCMS documents is the visible artefact of 6.3.
• Clause 8.1 (operational planning and control), operational changes are the day-to-day cousin of BCMS changes; the two systems interlock at the boundary (Section 4.3).
• Clause 8.2 (BIA), BIA revisions are a high-frequency Category-E change; BIA outputs (MTPD, RPO tolerance, MBCO) are the integrity-test thresholds.
• Clause 8.3 (strategy), strategy revisions cascade from BIA changes; strategy changes are Category-E.
• Clause 8.4 (plans and procedures), plan updates cascade from strategy changes; plan changes are Category-E.
• Clause 8.5 (exercise programme), exercise findings are a top-three source of Category-C corrective changes; the exercise programme itself is revised through 6.3.
• Clause 8.6 (evaluation), post-disruption evaluations drive corrective changes.
• Clause 9.1 (monitoring), change-related KPIs (lead time, validation rate, retro rate, incident-correlation) are tracked.
• Clause 9.2 (internal audit), tests the MOC discipline annually; audit findings drive Category-C changes.
• Clause 9.3 (management review), receives the change portfolio; top-management decisions at 9.3 drive Category-D changes.
• Clause 10.1 (corrective action), every corrective action is a Category-C change.
• Clause 10.2 (continual improvement), every improvement action is a Category-D change.

The cleanest framing: 6.3 is the change-control valve of the BCMS. It receives trigger inputs from Clauses 4, 5, 6.1, 6.2, 8.5, 8.6, 9.2 and 9.3; it produces consequential outputs in Clauses 7, 8, 9 and 10. A BCMS without a working 6.3 is a ship without a rudder, the crew (BIA, strategy, plans, exercises) works hard but the ship driftives wherever the current takes it.

To other ISO management-system standards

ISO/IEC 27001:2022 Clause 6.3 (changes to the ISMS) is the direct parallel. Both clauses use the same Harmonized Structure, both require changes to be carried out in a planned way, both require consideration of purpose and consequences. For organisations running both an ISMS and a BCMS, the MOC methodologies should align (same workflow, same CIA depth tiers, same authority-matrix principles) but the registers are separate because the change populations differ. Common ground: technology changes (Category-G) typically appear in both registers (ISMS focuses on the security dimensions; BCMS focuses on the continuity dimensions). Integration avoids duplicate work and conflicting decisions.

ISO 27001 Annex A control 8.32 (change management) is the operational-level change-management control in the 2022 Annex A. It applies to information-processing facilities and systems; the BCMS MOC and the 8.32 control are complementary, 8.32 governs the operational change, the BCMS MOC governs the consequential BCMS updates. For a major technology change, both systems are invoked.

ISO 9001:2015 Clause 6.3 (planning of changes) is the quality-management parallel. Same Harmonized Structure, same purpose-and-consequences discipline. For organisations running an integrated QMS + BCMS, the 6.3 clauses of both standards can be jointly implemented, a single MOC methodology with separate registers, with cross-references where quality and continuity changes overlap (e.g., a process change that affects both product quality and process availability).

ISO 14001:2015 Clause 6.3 follows the same pattern. Less overlap with BCMS for most organisations, but relevant for industrial operators where environmental and continuity changes intersect (e.g., a process change that affects both environmental performance and chemical-spill response capability).

ISO 45001:2018 Clause 6.3 (determination of legal and other requirements and change management) and Clause 8.1.3 (change management) overlap with the BCMS MOC for organisations running OHS + BC management systems, particularly relevant for manufacturing and chemical-industry operators.

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

ISO 31000:2018 (risk management) is the source of the risk-thinking discipline applied to changes, every consequential change is itself a source of new risk that must be assessed.

To sector and global frameworks

Section 16 of this guide provides the full multi-framework mapping. The headline anchors: DORA Article 9(4)(e) explicitly requires change management as a protection-and-prevention control for ICT systems; APRA CPS 230 paragraph 45 requires BCP updates and paragraph 59 requires APRA notification of new or changed critical-operation arrangements; NIST SP 800-34 Rev 1 Step 7 (plan maintenance) is the structural analogue of the MOC system; NIST CSF 2.0 Govern function (GV.RM) covers change-governance; FFIEC BCM Booklet structures its governance principle to mirror ISO 22301 6.3; MAS TRM Guidelines include change-management expectations for Singapore FIs; HKMA OR-2 and TM-G-2 cover change-management expectations for HK AIs. Indian regulatory anchors: RBI MD IT Governance 2023 (formal change-management chapter), RBI Cyber Security Framework 2016 (change management as a cyber-resilience control), RBI MD Outsourcing of IT Services 2023 (material-change notification), SEBI CSCRF 2024 (change management as a Protect-domain control), SEBI MII BCP-DR 2021 (board-notable BCP/DR changes), IRDAI ICS 2023 (board-overseen change management), DPDP Act 2023 (availability preservation through changes), CERT-In Directions 2022 (log integrity through changes), Companies Act 2013 §134(3)(n) (board risk statement reflecting post-change risk position), NDMA DM Act 2005 (industrial-emergency-plan revisions). A well-built 6.3 evidence set satisfies all of these simultaneously.

Detailed Implementation Guidance, The Eight-Stage MOC Workflow

Figure · Process

What Clause 6.3 asks you to do

This section walks through the eight implementation stages that together produce a 6.3-conformant BCMS-change-management system. The stages are sequenced for a first-cycle implementation; a mature BCMS runs them in parallel on different cadences and uses software automation to reduce the workflow burden.

The eight stages are: (1) Request, (2) Impact Assessment, (3) Decision, (4) Scheduling, (5) Communication, (6) Execution, (7) Validation, (8) Post-Change Review. Each stage has a defined input, output, owner, evidence requirement and integration with the other BCMS clauses. Together they constitute the MOC workflow that operationalises Clause 6.3.

Stage 1, Request (the Change Request)

The first stage is to articulate the change as a formal Change Request (CR). The CR is the entry point to the MOC system; without a CR, there is no change in the register and no audit trail.

The CR contains, at minimum: (a) a unique ID (the register allocates the next sequential or structured ID, e.g., CR-2026-042); (b) the requester (a named individual, with role and contact); (c) the date submitted; (d) the category (A through G, Section 2.3); (e) the purpose statement (one paragraph: what is the requester proposing, why, and what is the cost of inaction?); (f) the scope of the change (what is in scope and out of scope, including a preliminary list of BCMS components affected); (g) the proposed implementation window (a date or a window, with any constraints, e.g., "after the Q2 SEBI compliance reporting cycle" or "before the monsoon season"); (h) a preliminary resource estimate (rough order of magnitude, internal effort, external cost, technology, time); (i) any related CRs, risks, objectives, BIA activities, audit findings, incidents or regulator interactions that the requester is aware of; (j) the requested approver (per the authority matrix) and the requested priority (routine, expedited, emergency).

The requester is typically a function head, an objective owner (per Clause 6.2), the audit lead (per Clause 9.2), the corrective-action owner (per Clause 10.1), or the BCM Manager (for BCM-programme-level changes). For Category-A and Category-F changes, the requester is typically top management. For Category-B changes, the requester is typically the compliance or legal lead. For Category-C changes, the requester is typically the corrective-action owner. For Category-E changes, the requester is typically the BCM Manager. For Category-G changes, the requester is typically the CIO or Head of IT Infrastructure.

The CR is logged in the register on submission. The BCM Manager (or a delegated MOC coordinator) performs a triage review within two working days, confirming the category, the priority, the proposed approver, the proposed CIA depth, and the preliminary resource estimate. Triage may upgrade or downgrade the category, request more information from the requester, or close the CR as duplicate / not-a-BCMS-change / superseded.

Audit evidence: the CR record (with all minimum elements), the triage decision, the register entry.

Stage 2, Impact Assessment (the Change-Impact Assessment)

The second stage is to conduct the Change-Impact Assessment (CIA), the structured analysis of the proposed change across the five planning dimensions. The CIA is the substantive artefact of the MOC system; it is what the approver reviews, what the validator tests against, and what the auditor samples.

The CIA depth is proportionate to the change category and consequence. A typical Indian growing-company MOC Procedure defines three depth tiers:

Short-form CIA (1 page). For Category-E routine changes (a contact-tree update, a single-procedure revision, a routine plan refresh) and for low-consequence Category-D changes. Contains: purpose (one paragraph); consequences (one-line per sub-dimension, with N/A where not applicable); integrity test (the specific validation activity, typically a documented test or a peer review); resources (rough estimate); responsibilities (the RACI); approval recommendation.

Standard-form CIA (3 to 5 pages). For Category-C corrective changes, Category-D major improvements, Category-E significant BIA/strategy revisions, and Category-G routine technology/supplier changes. Contains: purpose (full statement, alternatives considered, cost of inaction); consequences (full seven-sub-dimension analysis); integrity test (validation approach with success criteria, evidence standard, decision rule); resources (detailed estimate with budget lines); responsibilities (full RACI with authority levels); dependencies (which BCMS components are touched); communication plan (audiences, channels, timing); rollback plan (the reversion procedure and the rollback decision criteria); approval recommendation.

Full-form CIA (10+ pages with regulatory-impact section). For Category-A scope/policy changes, Category-B regulatory changes, Category-F major organisational changes (e.g., a merger or acquisition), Category-G major technology changes (e.g., a core-system migration or a cloud migration), and any change with potential regulator notification. Contains everything in the standard form, plus: regulatory-impact analysis (which regulations are affected, what the regulator-notification consideration is, what the compliance-risk profile is, usually prepared with legal review); financial-impact analysis (direct cost, indirect cost, expected benefit, ROI horizon, payback); strategic-alignment analysis (how the change supports or contradicts the BCMS policy, the BC objectives, the enterprise strategy); stakeholder-impact analysis (which internal and external stakeholders are affected, how, and what the engagement plan is); cumulative-impact analysis (how this change interacts with other in-flight or planned changes).

The assessor is the BCM Manager for routine changes; for complex Category-G changes, the assessor is typically the Head of IT Infrastructure or the CISO with the BCM Manager as facilitator; for Category-B regulatory changes, the assessor is typically the compliance or legal lead; for Category-F organisational changes, the assessor is typically the Head of HR with the BCM Manager as facilitator.

The CIA must be conducted with segregation of duties from the requester where the change is consequential, the assessor is not the requester. For routine changes, the same individual may hold both roles (with the BCM Manager as assessor typically being both the requester for BCM-programme changes and the assessor of routine changes, with the CAB as the segregation-of-duties backstop).

Audit evidence: the CIA document, the assessor's credentials, the segregation-of-duties record, the integration links to Clause 6.1 (risk), Clause 6.2 (objectives), Clause 8.2 (BIA), Clause 7.5 (documents) as applicable.

Stage 3, Decision (approval, rejection, deferral, rework)

The third stage is to decide, approve, reject, defer, or return for rework. The decision is made by the approver per the authority matrix; the approver reviews the CR, the CIA, and any CAB or subject-matter-expert input.

The decision rule is approve if the CIA demonstrates that the change is purposeful, the consequences are acceptable, the integrity test is adequate, the resources are available, and the responsibilities are clear. The decision rule is reject if the CIA demonstrates that the change is not purposeful, the consequences are unacceptable, the integrity test is inadequate, the resources are not available, or the responsibilities are unclear. The decision rule is defer if the change is appropriate but the timing is not (e.g., a Category-D improvement deferred to the next budget cycle). The decision rule is return for rework if the CIA is incomplete or the assessor has missed a sub-dimension.

The decision is recorded in the register with the approver's name, the decision date, the decision rationale (one paragraph), any conditions attached to the approval (e.g., "approved subject to a successful tabletop exercise before deployment"), and the next steps (scheduling, communication, execution, validation).

For Category-A and Category-B changes, the decision is typically made by top management (the CEO, the board Risk Committee, or the BCM Steering Committee at a level above the standard CAB). For Category-C, Category-D, Category-E and Category-G changes, the decision is typically made by the CAB. For routine Category-E and Category-D changes, the decision may be delegated to the BCM Manager under the MOC Procedure's delegated-authority rules.

The CAB meets on a published cadence, typically weekly for routine changes (a 30-to-60-minute review of all CRs in the week) and monthly for portfolio review (a 90-to-120-minute review of the entire register, cumulative impact, KPIs, trends). Emergency CAB meetings can be convened on demand for expedited Category-C and Category-G changes. The CAB minutes are the audit evidence.

Audit evidence: the decision record, the approver's authority verification, the CAB minutes (for CAB-level decisions), the conditions-attached record.

Stage 4, Scheduling

The fourth stage is to schedule the change, sequence it against other changes, against operational events, and against regulatory blackout windows. The scheduling produces the Forward Schedule of Changes (FSC), a calendar view of approved changes over the next 30, 60, 90 days.

The scheduling principles are: (a) dependency sequencing, if change X depends on change Y, X must be scheduled after Y; (b) conflict avoidance, two changes that touch the same BCMS component should not be scheduled in the same window unless the CAB explicitly approves the parallel execution; (c) regulatory blackout avoidance, for SEBI-regulated MIIs, no production changes during trading hours or in the run-up to settlement; for RBI-regulated banks, no production changes during the RBI compliance-reporting cycle or the year-end close; for IRDAI-regulated insurers, no production changes during the renewal peak season; (d) operational window selection, schedule consequential changes in low-risk windows (weekends, holidays, off-peak hours); (e) resource availability, schedule changes when the implementation team, the validation team, and the vendor support are all available; (f) cumulative-impact windowing, avoid stacking too many changes in a single window (a typical Indian growing-company MOC Procedure caps at three Category-C/E/G changes per weekend per BCMS component).

The scheduling is done by the BCM Manager (or MOC coordinator) in consultation with the implementer. The FSC is published to all affected stakeholders.

For Category-A, Category-B, Category-F, and major Category-G changes, the scheduling includes a change window plan, a detailed hour-by-hour plan for the change execution, with named implementers, validation checkpoints, and a rollback decision point.

Audit evidence: the FSC, the change window plan (for major changes), the blackout-window-compliance verification, the dependency-sequencing verification.

Stage 5, Communication

The fifth stage is to communicate the change to all affected stakeholders per Clause 7.4. The communication plan is part of the CIA (for standard-form and full-form CIAs) and is executed in the days leading up to the change and on the day of the change.

The communication plan maps each audience to the channel, the timing, and the message. Typical audiences: the BCM Steering Committee (summary of approved changes for the period); the objective owners (Clause 6.2) whose objectives are touched by the change; the function heads whose operations are touched; the workforce (for awareness of any change that affects their role in a disruption); the internal audit (for awareness of validation windows); the customers (for customer-facing changes, e.g., a planned DR failover that may briefly affect service); the suppliers (for supplier-affecting changes); the regulators (for Category-B changes that require regulatory notification, though most BCMS changes do not require advance regulator notification, some sector-specific rules do); the board Risk Committee (for Category-A and Category-F changes that are board-notable).

The communication channels: email (formal notification), intranet (announcement), town-hall or team meeting (for workforce-affecting changes), customer-account portal or direct customer email (for customer-affecting changes), supplier portal or contract-manager communication (for supplier-affecting changes), regulator portal (for regulator-notifiable changes), board papers (for board-notable changes).

The communication timing: typically 7 to 14 days advance notice for consequential changes; 24 to 72 hours advance notice for routine changes; immediate communication for emergency changes (post-execution, as part of the retro-review).

The communication record (dates, audiences, channels, attendance where applicable) is the audit evidence. A change that was deployed without communication is nonconformant regardless of the technical correctness of the deployment.

Audit evidence: the communication plan (from the CIA), the communication record, the audience reach confirmation.

Stage 6, Execution

The sixth stage is to execute the change per the deployment runbook. The execution is led by the implementer (named in the CIA's RACI) and produces a deployment record, a step-by-step log of what was done, when, by whom, with what outcome at each step.

The deployment runbook is part of the CIA (for standard-form and full-form CIAs) or a separate document referenced by the CIA. The runbook contains: (a) the pre-deployment checklist (backups taken, snapshots taken, validation baselines recorded, stakeholders notified, rollback plan ready); (b) the deployment steps (numbered, with the implementer, the duration, the expected output, the rollback decision point at each step); (c) the post-deployment verification (the immediate "does it work" check before the formal integrity test); (d) the rollback procedure (the reversion steps, the rollback decision criteria, typically "if validation fails or post-deployment issues exceed tolerance within X hours, roll back").

For consequential changes, the deployment is witnessed, a second individual (typically a senior implementer or the BCM Manager) observes the execution and countersigns the deployment record. Witnessing is the segregation-of-duties backstop at the execution layer.

For emergency changes (change-during-incident), the deployment is executed under the incident commander's authority, with the BCM team in support. The deployment record is created as the change is executed (or reconstructed immediately after stabilisation); the retro-CIA and retro-CAB review follow at the next CAB meeting.

The execution produces the deployment record, the audit evidence that the change was implemented as approved, by the named implementer, on the scheduled date, with the predicted outcome (or, where the outcome differed, with the documented deviation and the decision to proceed or roll back).

Audit evidence: the deployment runbook (or reference), the deployment record, the witness countersignature (for consequential changes), the deviation log (if any).

Stage 7, Validation (the integrity test)

The seventh stage is to validate the change, the integrity test that confirms the BCMS still works. This is the single most consequential stage of the MOC workflow because it is the difference between a planned change and an uncontrolled change.

The validation approach is defined in the CIA and operationalised in the integrity test. The integrity test patterns are:

Pattern 1, Documented test. A defined test against the post-change BCMS, with pass/fail criteria. For a BIA revision: re-test the MTPD assumption with a key stakeholder workshop. For a contact-tree update: call each contact and confirm currency. For a plan revision: walk through the revised plan with the response team and confirm role-clarity. For a runbook update: walk through the revised runbook with the implementer and confirm executability.

Pattern 2, Parallel run. The new arrangement runs alongside the old for a defined period, with comparison of outcomes. For a recovery-site migration: run the old and new DRS in parallel for 30 days, comparing replication latency, failover time and recovery-point accuracy. For a supplier swap: dual-source the activity for 60 days, comparing service quality and continuity readiness.

Pattern 3, Exercise. A tabletop, simulation or full failover that exercises the changed component. For a strategy revision: a tabletop on the revised strategy with the BCM Steering Committee. For a plan revision: a simulation of the revised invocation procedure with the response team. For a recovery-site migration: a full failover exercise to the new DRS, with timing witnesses.

Pattern 4, Internal-audit sample. A Clause 9.2 audit of the changed area. For a major process change: an internal-audit sample of the new process over the first 30 days, with findings routed to Clause 10.1 corrective action.

Pattern 5, Regulator-reporting dry run. A mock regulator-reporting exercise against the changed process. For a breach-notification procedure revision: a mock breach-notification exercise against the new procedure, with timing measured against the 6-hour CERT-In clock or the 72-hour DPDP clock.

The integrity test must have success criteria (defined in the CIA), an evidence standard (what counts as evidence, typically a signed test report, a witnessed exercise report, an audit memo, a regulator-acknowledged dry-run record), and a decision rule (pass / conditional pass / fail, with the conditional-pass conditions and the fail-response procedure, typically rollback).

The integrity test is executed by the validator (named in the CIA's RACI), typically the BCM Manager with Internal Audit as witness, or for complex changes, a dedicated validation team with subject-matter expertise.

A change without a validation record is nonconformant, the integrity test is the audit's primary evidence that the BCMS still works after the change. The register's "validated" status is conditional on the validation record; a register full of changes marked "validated" without underlying validation records is the second-most-common 6.3 audit finding (after the empty register).

Audit evidence: the integrity-test plan (from the CIA), the validation record (test report, exercise report, audit memo, dry-run record), the success-criteria evaluation, the decision (pass / conditional pass / fail), the witness countersignature.

Stage 8, Post-Change Review

The eighth stage is to review the change after closure, capturing lessons, confirming value, identifying follow-ups. The post-change review is what keeps the MOC system improving; without it, the same change mistakes recur indefinitely.

The post-change review is conducted within 30 days of the change closure (or, for major changes, at the next BCM Steering Committee meeting). It is led by the BCM Manager (or MOC coordinator) with the requester, the assessor, the implementer and the validator as participants.

The review covers: (a) outcome against purpose, did the change achieve what it set out to achieve? If yes, document the value delivered (this feeds the ROI tracking for Clause 10.2 continual improvement); if no, route to Clause 10.1 corrective action; (b) MOC process quality, was the CIA accurate? Was the integrity test sufficient? Were the resource estimates realistic? Was the communication effective? If no, capture lessons for the MOC Procedure revision; (c) incidents and near-misses, did the change cause any incidents or near-misses? If yes, route to Clause 8.6 evaluation and Clause 10.1 corrective action; (d) follow-up changes, does the change require follow-up changes (e.g., a strategy change that requires a plan revision that requires an exercise update)? If yes, raise the follow-up CRs; (e) cumulative-impact update, does the change affect the cumulative-impact picture for other in-flight or planned changes? If yes, flag for the next quarterly cumulative-impact review.

The post-change review produces a lessons-captured record, a one-page summary of the change, the outcome, the lessons, and the follow-ups. The record is filed in the register and is sampled at the Clause 9.3 management review.

For major changes (Category-A, Category-B, Category-F, major Category-G), the post-change review is escalated to the BCM Steering Committee with a formal presentation, including the ROI realised, the lessons captured, and the next-change implications.

Audit evidence: the post-change review record, the lessons-captured log, the follow-up CRs raised, the escalation record (for major changes), the integration with Clause 9.3 management review.

The MOC workflow as a closed loop

The eight stages form a closed loop, every change enters at Stage 1, progresses through Stages 2 to 8, and produces lessons that feed back into the MOC Procedure (improving Stage 2 impact assessments), the authority matrix (refining Stage 3 decisions), the FSC discipline (improving Stage 4 scheduling), the communication plan (refining Stage 5), the deployment runbook template (improving Stage 6), the integrity-test pattern library (improving Stage 7), and the post-change review format (improving Stage 8).

A mature MOC system is recognisable by three signatures. First, the register is alive, entries are added, updated, escalated and closed continuously, not in a pre-audit burst. Second, the lessons compound, the same mistakes do not recur because the MOC Procedure is updated to prevent them. Third, the change-related KPIs improve over time, lead time shortens, validation rate rises, retro rate falls, incident-correlation falls (see Section 12).

The MOC workflow is the operational form of Clause 6.3; a BCMS without a working MOC workflow is a BCMS that drifts. The eight-stage pattern is the practitioner consensus drawn from ISO 22313:2020, ISO 31000:2018, the Harmonized Structure's treatment of "planning of changes", and the bodies of BCM practice. It is not mandated by the standard's text in this exact form, but it is the workflow pattern the certification auditor will look for de facto.

Tools, Technologies, and Solutions

The 6.3 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 register and document repository

The default Layer 1 stack for Indian growing companies is a spreadsheet for the change register (one row per change with the eight-stage evidence, the category, the status, the validation record), a word-processor document for each CIA (proportionate to the depth tier), and a shared folder (typically a cloud drive) for version control. The Forward Schedule of Changes is an additional spreadsheet tab or a shared calendar.

Layer 1 is sufficient for organisations with 20 to 60 changes per year 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 change 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 (CR submission → CIA drafting → CAB review → approval → scheduling → communication → execution → validation → closure), provides audit trails (every change action logged with user, timestamp, rationale), supports role-based access (requesters see their CRs; 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, supplier register).

Layer 2 is appropriate for mid-market (250 to 2,000 staff) organisations with 60 to 200 changes per year, multiple stakeholders, and a need for audit-trail discipline. Indicative cost: ₹6 lakh to ₹25 lakh per year for a mid-market GRC platform subscription, plus ₹10 lakh to ₹30 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 change cascades

Layer 3 sees the change 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, the ITSM change-management module (for Category-G coordination), the HR org-change module (for Category-F coordination). Change cascades are automated (a BIA update triggers a re-validation of the derived RTO/RPO objectives; a risk-register change triggers a re-validation of the risk-treatment objectives; an exercise outcome triggers an evidence-eliciting change).

Layer 3 is appropriate for multi-entity enterprises (2,000+ staff) with 200+ changes per year, multi-jurisdiction regulatory overlays, and a need for genuine integration across the operational-resilience stack. Indicative cost: ₹30 lakh to ₹1.8 crore per year for the platform subscription, plus ₹50 lakh to ₹2.5 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, CERT-In, DPDP, DORA, APRA CPS 230, MAS TRM simultaneously).

Layer 4, AI-augmented change analytics and predictive integrity

Layer 4 (leading edge, 2026-onwards) sees AI augmentation layered onto the integrated platform. Use cases include: AI-assisted CIA drafting (the system proposes a CIA based on the CR, the historical change patterns, and the BCMS component being changed); AI-assisted integrity-test selection (the system recommends the validation pattern based on the change category and the historical pass/fail patterns); AI-assisted cumulative-impact detection (the system scans the register and flags cumulative patterns the BCM Manager may have missed); AI-assisted regulatory-impact analysis (the system scans regulatory updates and flags change CRs that may have regulatory implications); AI-assisted change-risk prediction (the system predicts which changes are at elevated risk of failure based on historical patterns and current conditions); AI-assisted lessons capture (the system mines post-change reviews for patterns and surfaces recurring lessons).

Layer 4 is appropriate for L4 to L5 maturity organisations with mature data and a willingness to invest in AI augmentation. Indicative cost: ₹60 lakh to ₹3.5 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 high-risk change before deployment is worth substantially more than the AI licence fee).

The selection criteria

The tooling selection should be driven by the BCMS scope, the change volume, 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 change management with the seven categories and the eight-stage workflow, or is it a generic ITSM tool with a BCM veneer?; (2) integration with the existing stack, does it integrate with the ITSM/ITIL change module, the risk register, the audit management, the supplier management, the HR system, and the document repository?; (3) audit-trail discipline, does every change action have a user, a timestamp and a rationale, exportable for the auditor?; (4) role-based access, does it support requester, assessor, approver, implementer, validator, communicator, reviewer as distinct roles?; (5) regulator-reporting readiness, does it produce the artefacts the Indian regulators expect (board-approved BCP/DR, regulator-notable change records, validation evidence 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.3 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 BCMS Change Management Policy (the apex 6.3 policy)

The BCMS Change Management Policy is a short, board-approved document that sets the principles, categories, authority matrix and roles for the MOC system. Sample "shall" clauses (organisation-drafted, not reproductions of any standard's text):

• "The Organisation shall plan, control and document all changes to the BCMS through a formal Management-of-Change (MOC) system, in accordance with ISO 22301:2019 Clause 6.3."
• "The Organisation shall classify every BCMS change into one of seven categories (A, strategic/scope; B, regulatory; C, corrective; D, improvement; E, BIA/strategy/plan; F, organisational; G, technological/supplier) and shall apply a proportionate Change-Impact Assessment depth based on the category and consequence."
• "The Organisation shall ensure that every consequential BCMS change is requested, impact-assessed, decided, scheduled, communicated, executed, validated and reviewed by named individuals, with segregation of duties between the requester, the approver and the implementer for consequential changes."
• "The Organisation shall maintain a BCMS Change Register as the single source of truth for all BCMS changes, controlled per Clause 7.5 of ISO 22301:2019."
• "The Organisation shall ensure that every consequential BCMS change has a documented integrity test, with success criteria, evidence standard and decision rule, executed before the change is closed."
• "Top management shall approve Category-A (scope/policy) and Category-B (regulatory) changes; the BCM Steering Committee shall approve Category-C, Category-D, Category-E and major Category-G changes; the BCM Manager under delegated authority may approve routine Category-D, Category-E and Category-G changes per the authority matrix."
• "The Organisation shall define an emergency-change path for BCMS changes required during an active disruption, with retro-review at the next Change Advisory Board meeting."
• "The Organisation shall re-validate Clause 6.2 BC objectives whenever a BCMS change affects the underlying capability, and shall record the re-validation in the BC Objectives Update Log."
• "The Organisation shall preserve the availability, integrity and confidentiality of personal data through every BCMS change that touches a personal-data-bearing system, in accordance with Section 8(5) of the Digital Personal Data Protection Act 2023."
• "The Organisation shall operationalise, through the MOC system, the change-management expectations of the [RBI Master Direction IT Governance / SEBI CSCRF / SEBI MII BCP-DR / IRDAI Information and Cyber Security Guidelines / CERT-In Directions / DPDP Act 2023] as applicable to the Organisation."

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

The MOC Procedure

The Procedure is the operating manual for the 6.3 system. It documents the eight-stage workflow, the CIA template, the categories, the authority matrix, the CAB charter, the emergency-change rules, the retro-review rules, and the role assignments. Sample sections:

• Section 1: Purpose and scope. The Procedure operationalises the BCMS Change Management Policy for the BCMS scope.
• Section 2: Roles and responsibilities. BCM Manager (methodology custodian, register custodian, workflow facilitator); CAB (approval authority above delegated threshold); top management (Category-A/B approval); requester/assessor/approver/implementer/validator/communicator/reviewer (the seven MOC roles); Internal Audit (independent test).
• Section 3: The seven change categories. Definitions, examples, typical CIA depth.
• Section 4: The eight-stage workflow. Step-by-step instructions for each stage, with inputs, outputs, templates, owners and deadlines.
• Section 5: The CIA template. Short-form, standard-form, full-form. The five planning dimensions. The seven sub-dimensions for consequences.
• Section 6: The integrity-test patterns. Documented test, parallel run, exercise, internal-audit sample, regulator-reporting dry run. The success-criteria discipline.
• Section 7: The authority matrix. The category-to-approver mapping with delegated-authority thresholds.
• Section 8: The emergency-change path. Incident-commander authority, retro-review rules, lessons-captured.
• Section 9: The Forward Schedule of Changes. Publication, blackout windows, cumulative-impact review.
• Section 10: Documented information. Version control, access, retention.

The BCMS Change Register (template)

The Register is a per-change row with columns covering the eight-stage workflow, the category, the status, the validation record and the integration links. The toolkit provides a starter spreadsheet. Column structure: ID; requester; date submitted; category; purpose; scope; CIA reference (and depth tier); assessor; CAB/approver; approval date and decision; scheduled window; communication record; implementer; deployment date and outcome; validator; validation method and result; post-change review outcome; status; related CR / risk / objective / BIA activity / audit finding / incident; lessons captured.

The Change-Impact Assessment (template)

The CIA template has three depth tiers (short, standard, full). The toolkit provides all three. The standard-form template covers the five planning dimensions with sub-sections for each of the seven consequence sub-dimensions, the integrity test, the rollback plan, the communication plan, and the approval recommendation.

The CAB charter

The CAB charter is a one-to-two-page document defining the CAB's membership, quorum, cadence (weekly routine, monthly portfolio, ad-hoc emergency), authority levels (per category), escalation paths, and decision rules. The charter is approved by the BCM Steering Committee.

The Forward Schedule of Changes (template)

The FSC is a calendar view of approved changes over the next 30, 60, 90 days, with dependency sequencing, blackout-window flags, and resource-conflict markers. The toolkit provides a starter template (spreadsheet or shared-calendar format).

Risk Assessment and Treatment

Every consequential BCMS change is itself a source of new risk, risk of deployment failure, risk of integrity loss, risk of regulatory exposure during transition, risk of cumulative impact, risk of emergency-change debt. The 6.3 system interlocks with the Clause 6.1 risk-management discipline to ensure that change-related risk is identified, assessed, treated and monitored.

The change-risk register

A mature 6.3 system maintains a change-risk register as a sub-view of the Clause 6.1 risk register. The change-risk register tracks, per consequential change: the change-specific risks (deployment-failure risk, integrity-loss risk, transition-disruption risk, regulatory-exposure risk, cumulative-impact risk, rollback-failure risk); the likelihood and impact assessment; the treatment decision (mitigate, accept, transfer, avoid); the treatment actions (the rollback plan, the validation plan, the communication plan, the parallel-run period, the staged deployment); the residual risk; the risk owner; the monitoring KPIs.

The change-risk register is updated at each stage of the MOC workflow: at Stage 2 (the CIA includes the risk assessment), at Stage 3 (the decision includes the risk acceptance), at Stage 6 (the deployment includes the risk monitoring), at Stage 7 (the validation confirms the residual risk), at Stage 8 (the post-change review updates the risk position).

The seven change-risk categories

The change-risk taxonomy covers seven categories, each with characteristic patterns, mitigation strategies, and Indian-context examples.

Risk 1, Deployment-failure risk. The risk that the change cannot be executed as planned (technical failure, human error, vendor non-delivery, environment mismatch). Mitigation: deployment runbook with pre-deployment checklist; witnessed execution; staged deployment; rollback plan. Indian-context example: a core-banking-system DR failover exercise fails because the DRS configuration does not match the production change applied two weeks earlier (a cumulative-impact failure).

Risk 2, Integrity-loss risk. The risk that the BCMS does not work the same way after the change (RTO/RPO no longer met, contact tree no longer current, plan no longer executable, supplier no longer able to inherit continuity). Mitigation: integrity test per change; cascade to Clause 6.2 objectives re-validation; cascade to Clause 8.5 exercise programme update. Indian-context example: a cloud migration reduces RPO from 15 minutes to 2 hours because the new replication architecture was not validated against the BIA-derived RPO tolerance.

Risk 3, Transition-disruption risk. The risk that the change execution itself causes an operational disruption (a planned failover that takes the production system down for longer than the planned window; a supplier swap that introduces a service-quality gap). Mitigation: change-window planning; parallel-run period; operational risk assessment as part of the CIA. Indian-context example: a planned DRS migration at a payments bank causes a 90-minute outage because the cutover was not rehearsed with a dress-rehearsal exercise.

Risk 4, Regulatory-exposure risk. The risk that the change introduces a regulatory compliance gap (a process change that affects CERT-In 6-hour reporting capability; a system change that affects DPDP Section 8(5) availability; a supplier change that affects RBI MD Outsourcing compliance). Mitigation: regulatory-impact analysis as part of the CIA (mandatory for Category-B and Category-G changes); legal review; regulator-notification consideration. Indian-context example: a cloud migration that moves personal data outside India without the BCM team noticing, a Section 8(5) and Section 8(6) DPDP exposure.

Risk 5, Cumulative-impact risk. The risk that the accumulation of small changes exceeds the BCMS's tolerance even though each individual change was below threshold. Mitigation: quarterly cumulative-impact review; cluster detection in the change register; pattern analysis. Indian-context example: 12 small changes to the core-banking-system contact tree over six months, each individually below the CIA threshold, cumulatively leaving the contact tree 40% out of date.

Risk 6, Rollback-failure risk. The risk that the rollback plan does not work when invoked (the rollback was never tested; the rollback dependencies have changed; the rollback window is too short). Mitigation: rollback-test as part of the integrity test; rollback rehearsal for consequential changes; rollback decision-point in the deployment runbook. Indian-context example: a Category-G change at an insurance company is rolled back after the integrity test fails, but the rollback does not fully revert the configuration because the pre-change backup was incomplete, leaving the BCMS in an undefined state.

Risk 7, Emergency-change debt risk. The risk that emergency changes accumulate without retro-review, leaving the BCMS in a state that no one fully understands. Mitigation: retro-review SLA (e.g., 7 days for Category-C emergency, 14 days for Category-G emergency); CAB tracking of the retro-review backlog; escalation to BCM Steering Committee if the backlog grows. Indian-context example: a ransomware incident drives 18 emergency changes over a 72-hour period; six months later, only three have been retro-reviewed, leaving 15 unreviewed changes whose cumulative impact on the BCMS is unknown.

The change-risk treatment options

The Clause 6.1 risk-treatment options apply to change-related risks:

Mitigate, the default treatment for change-risk; reduce the likelihood or impact through the CIA, the deployment runbook, the integrity test, the parallel run, the staged deployment, the rollback plan. Most change-risk is mitigated through the MOC workflow itself.

Accept, the treatment for low-likelihood low-impact risks where mitigation is disproportionate; the acceptance is documented in the CIA and approved at the appropriate authority level.

Transfer, the treatment for risks that can be transferred to a third party (insurance, vendor warranty, contractual indemnity). The RBI MD Outsourcing of IT Services recognises transfer but does not allow it to absolve the RE of regulatory responsibility.

Avoid, the treatment for risks that cannot be adequately mitigated; the change is rejected or deferred. The avoid decision is a legitimate MOC outcome and should not be stigmatised; a MOC system that never avoids may be approving changes it should not.

The change-risk KPIs

The change-risk KPIs (see Section 12) include: deployment-failure rate; integrity-test failure rate; transition-disruption incident count; regulatory-exposure events (audit findings, regulator interactions); cumulative-impact findings per quarterly review; rollback-invocation rate; rollback-success rate; emergency-change debt (count of unreviewed retro-changes). These KPIs are tracked on the BCM dashboard and reviewed at the Clause 9.3 management review.

The change-risk appetite

The Clause 5.2 policy and the Clause 6.1 charter define the organisation's risk appetite; the change-risk appetite is a sub-set. A typical Indian growing-company change-risk appetite: zero tolerance for unmanaged Category-A/B/F changes; zero tolerance for emergency-change debt beyond 14 days; ≤5% deployment-failure rate for Category-C/D/E changes; ≤2% integrity-test failure rate for consequential changes; ≤1 transition-disruption incident per quarter; zero regulator-exposure events. The appetite is approved by top management and reviewed at the Clause 9.3 management review.

Audit and Compliance Checklist

The 6.3 audit checklist is structured around the eight-stage MOC workflow and the seven change categories. Each question lists the expected evidence and the typical red flags. The certification auditor (Stage 1, Stage 2, surveillance) and the internal auditor (Clause 9.2) will sample across these questions.

The policy and procedure layer

1. Is there a board-approved BCMS Change Management Policy? Evidence: the Policy document, the approval minute, the communication record. Red flag: no Policy, or a Policy that pre-dates the last 12 months of regulatory change.

2. Does the Policy operationalise Clause 6.3? Evidence: the Policy references ISO 22301:2019 Clause 6.3, lists the seven categories, defines the authority matrix, defines the emergency-change path. Red flag: a generic "we manage changes" Policy with no operational content.

3. Is there an MOC Procedure that documents the eight-stage workflow? Evidence: the Procedure document with the eight stages, the role assignments, the evidence requirements. Red flag: a Procedure that lists five stages, or that copies the ITSM change process verbatim.

4. Are roles and authorities defined and exercised? Evidence: the authority matrix; a sample of changes with the approver matching the matrix. Red flag: every change approved by the BCM Manager; Category-A changes with no top-management approval.

5. Is the MOC Procedure integrated with the Clause 6.1 risk-management process? Evidence: the change-risk register, the risk-treatment records in the CIA. Red flag: no change-risk register; CIAs with no risk-assessment section.

The register and the workflow

6. Is there a BCMS Change Register that is the single source of truth? Evidence: the register, the version control, the access control per Clause 7.5. Red flag: multiple versions of the register; an "official" register and an "actual" register.

7. Is the register alive (entries added, updated, escalated, closed continuously)? Evidence: the entry dates across the look-back period; the status distribution; the update frequency. Red flag: a burst of entries in the two weeks before the audit; a register with zero entries in the last quarter.

8. Does the register cover all seven categories? Evidence: the category distribution; the proportion of Category-A/B/F changes (the highest-consequence). Red flag: a register dominated by Category-C and Category-E with no Category-A/B/F/G entries (suggests the highest-consequence changes are bypassing the MOC).

9. Does every consequential change have a CIA? Evidence: the CIA document, the depth-tier match to the category. Red flag: routine CIAs for Category-A/B changes; full CIAs for Category-E routine changes (overkill suggests confusion).

10. Does the register trace each change to its trigger? Evidence: the related-CR/risk/objective/BIA-activity/audit-finding/incident column populated. Red flag: changes with no trigger recorded (suggests the MOC is producing changes without context).

The eight stages, sampling questions

11. Stage 1 (Request): show me a Change Request and walk me through it. Evidence: the CR with all minimum elements (ID, requester, date, category, purpose, scope, window, resources, related items). Red flag: CRs with no purpose statement; CRs with no category.

12. Stage 2 (Impact Assessment): show me a CIA and walk me through the five planning dimensions. Evidence: the CIA document with all five dimensions covered. Red flag: CIAs with the integrity-test dimension blank; CIAs with no resource estimate.

13. Stage 2 (consequences): does the CIA cover the seven sub-dimensions? Evidence: the consequences section with integrity, dependencies, interested parties, legal/regulatory, operational-during-transition, financial, strategic-alignment. Red flag: CIAs that cover only financial and operational dimensions.

14. Stage 3 (Decision): show me an approval record and the approver's authority. Evidence: the decision record, the approver's authority verification. Red flag: decisions with no rationale; decisions by unauthorised approvers.

15. Stage 3 (CAB): does the CAB meet on a published cadence? Evidence: the CAB charter, the CAB minutes, the cadence record. Red flag: a CAB that has not met in 90 days; CAB minutes with no decisions.

16. Stage 4 (Scheduling): show me the Forward Schedule of Changes. Evidence: the FSC, the blackout-window compliance, the dependency-sequencing record. Red flag: no FSC; multiple consequential changes stacked in a single window.

17. Stage 5 (Communication): show me a communication record for a consequential change. Evidence: the communication plan, the communication record, the audience reach. Red flag: changes deployed without communication; communication to the wrong audience.

18. Stage 6 (Execution): show me a deployment record with witness countersignature. Evidence: the deployment runbook, the deployment record, the witness countersignature for consequential changes. Red flag: deployment records with no witness; deviations from the runbook with no decision record.

19. Stage 7 (Validation): show me a validation record with success criteria, evidence and decision. Evidence: the integrity-test plan, the validation record, the success-criteria evaluation, the decision. Red flag: changes marked "validated" with no underlying validation record; integrity tests with no success criteria.

20. Stage 7 (patterns): does the integrity test use a recognised pattern (documented test, parallel run, exercise, internal-audit sample, regulator-reporting dry run)? Evidence: the pattern reference, the pattern application. Red flag: integrity tests that consist only of "the implementer confirmed it works".

21. Stage 8 (Post-Change Review): show me a post-change review record with lessons captured. Evidence: the lessons-captured record, the follow-up CRs raised, the escalation record for major changes. Red flag: changes closed without post-change review; the same mistakes recurring across changes.

The emergency-change and retro-review discipline

22. Is there a documented emergency-change path? Evidence: the MOC Procedure section on emergency changes; the incident-commander authority; the retro-review SLA. Red flag: no emergency path; emergency changes treated as exceptions rather than as a defined path.

23. Are emergency changes retro-reviewed within the SLA? Evidence: the retro-review log; the SLA-compliance rate. Red flag: emergency-change debt (unreviewed retro-changes) accumulating beyond 14 days.

The integration discipline

24. Are Clause 6.2 objectives re-validated when changes affect underlying capability? Evidence: the BC Objectives Update Log entries triggered by changes; the re-validation record. Red flag: changes to recovery capability with no corresponding objective re-validation.

25. Are Clause 7.5 documents updated as part of the change? Evidence: the document-update record per change; the version-control record. Red flag: BCMS documents that pre-date the changes affecting them.

26. Are Clause 9.2 audit findings and Clause 10.1 corrective actions routed through the MOC? Evidence: the integration of the audit/corrective-action pipeline with the change register. Red flag: audit findings and corrective actions executed without going through the MOC.

The auditor's interview set

The auditor will interview role-holders to test the live discipline. Typical interviews:

• Top management: "Tell me about the last Category-A or Category-B change you approved. What was the purpose, what was the impact assessment, what was the validation?" Red flag: top management cannot name a Category-A/B change they approved (suggests the authority matrix is not exercised).

• BCM Manager: "Walk me through your MOC workflow. Show me the last change in each category." Red flag: the BCM Manager cannot produce a Category-A/B/F change.

• Change Advisory Board member: "When did the CAB last meet? Walk me through the last consequential change you approved." Red flag: the CAB has not met in 90 days.

• Internal Audit: "When did you last audit the MOC system? What did you find?" Red flag: Internal Audit has not audited MOC; or has audited and found nothing (suspicious, every MOC has findings).

• Objective Owner (a function head): "Tell me about the last change that affected one of your objectives. How did you know the objective still held after the change?" Red flag: the Objective Owner cannot recall such a change.

• Validator (an internal-audit or BCM team member): "Walk me through the last integrity test you conducted. What was the success criterion, what was the evidence, what was the decision?" Red flag: the validator conflates "the change was deployed" with "the integrity test passed".

Metrics and KPIs

The 6.3 KPI set is structured around four families: workflow-volume KPIs (what is flowing through the MOC), workflow-quality KPIs (how well the MOC is working), outcome KPIs (what the MOC is producing), and integration KPIs (how the MOC connects to the rest of the BCMS).

Workflow-volume KPIs

KPI-1, Changes per quarter, by category. Definition: count of CRs submitted per quarter, broken down by category (A/B/C/D/E/F/G). Target: 5 to 20 changes per quarter for a growing company (50 to 250 staff); 20 to 50 for mid-market (250 to 2,000); 50 to 200 for enterprise. The category distribution matters more than the absolute count, a healthy distribution has all seven categories represented, with Category-C (corrective) and Category-E (BIA/strategy/plan) typically the highest-volume. Frequency: quarterly. Audience: BCM Steering Committee.

KPI-2, In-flight changes. Definition: count of CRs in any active stage (assessed, approved, scheduled, in execution, in validation, in post-review). Target: 5 to 15 in-flight for a growing company (50 to 250 staff); 15 to 50 for a mid-market (250 to 2,000 staff) organisation; 50+ for an enterprise. Frequency: weekly (BCM Manager review), monthly (CAB portfolio review).

KPI-3, Forward Schedule of Changes use. Definition: percentage of the next-30-day FSC windows that are filled. Target: 30% to 70% (low suggests under-use of the MOC; high suggests the BCMS is changing too fast). Frequency: monthly.

Workflow-quality KPIs

KPI-4, Change lead time. Definition: median calendar days from CR submission to change closure, by category. Target: 5 to 15 days for Category-E routine; 15 to 30 days for Category-C; 30 to 90 days for Category-D/G; 90 to 180 days for Category-A/B/F. The lead time matters because excessive lead time drives requesters to bypass the MOC. Frequency: monthly.

KPI-5, Validation rate. Definition: percentage of consequential changes with a documented validation record (integrity test passed, evidence on file). Target: 100%. Frequency: monthly. Red flag: below 95%.

KPI-6, Rollback rate. Definition: percentage of deployed changes that were rolled back. Target: 0% to 5% (some rollback is healthy, it shows the integrity test is working; zero rollback is suspicious; high rollback suggests CIA quality issues). Frequency: monthly.

KPI-7, Rollback-success rate. Definition: percentage of rollback invocations that succeeded (the rollback worked as planned). Target: 100%. Frequency: monthly. Red flag: any rollback failure (a failed rollback is a serious nonconformity because it leaves the BCMS in an undefined state).

KPI-8, Retro-review rate. Definition: percentage of emergency changes retro-reviewed within the SLA (7 days for Category-C, 14 days for Category-G). Target: 100%. Frequency: monthly.

KPI-9, Emergency-change debt. Definition: count of unreviewed retro-changes at month-end. Target: zero. Frequency: monthly.

Outcome KPIs

KPI-10, Change-induced incident rate. Definition: count of incidents (Clause 8.4) where the root cause was a change. Target: zero per quarter; trend downward. Frequency: quarterly. Red flag: any change-induced incident (the integrity test should have caught the issue).

KPI-11, Change-induced audit finding rate. Definition: count of Clause 9.2 audit findings where the root cause was a change (typically a change that did not go through the MOC). Target: zero per audit. Frequency: per audit cycle.

KPI-12, Cumulative-impact findings per quarterly review. Definition: count of clusters flagged by the quarterly cumulative-impact review. Target: trend downward as the MOC matures (clusters identified late suggest earlier CIA gaps). Frequency: quarterly.

KPI-13, Change ROI realised. Definition: the realised value (revenue gain, cost saving, risk reduction, audit-cost avoidance) of Category-D improvement changes, tracked per change and aggregated annually. Target: positive ROI on the Category-D portfolio per year. Frequency: annual (per the Clause 9.3 management review).

Integration KPIs

KPI-14, Objective-revalidation rate. Definition: percentage of changes that triggered a Clause 6.2 objective re-validation, where the re-validation was completed within 14 days. Target: 100%. Frequency: monthly.

KPI-15, Document-update lag. Definition: median days from change closure to corresponding Clause 7.5 document update. Target: ≤7 days. Frequency: monthly. Red flag: documents that pre-date the changes affecting them.

The dashboard layout

The 6.3 KPI dashboard is a one-page view (for top management) and a multi-tab view (for the BCM Manager and the CAB). The top-management view shows: changes per quarter (KPI-1) with category distribution; validation rate (KPI-5); rollback rate (KPI-6); change-induced incident rate (KPI-10); change ROI realised (KPI-13); cumulative-impact findings (KPI-12). The BCM Manager view adds: in-flight changes (KPI-2); lead time (KPI-4); rollback-success rate (KPI-7); retro-review rate (KPI-8); emergency-change debt (KPI-9); FSC use (KPI-3); audit-finding rate (KPI-11); integration KPIs (KPI-14, KPI-15).

The dashboard is reviewed at the BCM Steering Committee (quarterly), the CAB portfolio review (monthly), and the Clause 9.3 management review (annual). The trends matter more than the absolute values, a healthy MOC system shows the quality KPIs trending up, the failure KPIs trending down, and the integration KPIs at 100%.

Common Pitfalls and Audit Failures

The 6.3 audit findings in the Indian growing-company segment cluster around six failure patterns. Each is named, explained, and accompanied by the fix.

Pitfall 1, The empty register

The pattern. The change register is empty or has fewer than five entries. The BCMS in operation has clearly evolved since certification (the BIA has new dates, the contact tree has new names, the runbook has new content) but no change records exist.

The root cause. The MOC was set up for the certification audit but never operationally embedded. Changes happen but bypass the MOC because "the BCM procedure is too slow" or "the change is too small to log".

The fix. Run a 90-minute back-fill workshop (the quick-win in Section 1). Surface every change the BCMS has absorbed in the last 12 months. Classify, retro-assess, retro-approve, retro-validate. Then enforce the MOC going forward, every consequential change without exception.

Pitfall 2, The single-approver register

The pattern. Every change is approved by the BCM Manager. No top-management approval for Category-A/B changes; no CAB; no authority matrix.

The root cause. The BCM Manager was given the BCMS as a one-person job; top management treated the BCMS as a tick-box exercise; the MOC Procedure was written but never resourced with a functioning CAB.

The fix. Constitute the CAB with a written charter. Have top management approve the authority matrix. Re-route Category-A/B changes through top management. Re-issue the MOC Procedure with the authority matrix enforced.

Pitfall 3, The validation vacuum

The pattern. Changes are deployed and closed without an integrity test. The "validated" status in the register is unsupported by any validation record. The auditor's sample of "validated" changes finds zero underlying tests.

The root cause. The MOC Procedure lists the integrity test as a stage but does not enforce it; the BCM Manager marks changes "validated" as a clerical step; the integrity-test pattern library does not exist.

The fix. Make the integrity test a gating control, no closure without a validation record. Build the integrity-test pattern library (documented test, parallel run, exercise, internal-audit sample, regulator-reporting dry run). Sample-validate at every Clause 9.2 internal audit.

Pitfall 4, The ITSM-confusion register

The pattern. The change register is a copy of the ITSM/ITIL change-management system, with every operational IT change (server patches, password rotations, network config changes) logged as a BCMS change. The register is overwhelming in volume (hundreds of entries per month) and lacking in BCMS substance.

The root cause. The MOC Procedure confused Clause 6.3 (BCMS changes) with Clause 8.1 (operational changes) and with the ITSM/ITIL process. The BCM team did not push back when IT operations routed everything through the BCMS MOC.

The fix. Re-draw the boundary (Section 4.2). Move operational IT changes back to the ITSM process. Keep only the BCMS-relevant changes in the 6.3 register. For changes that touch both (a cloud migration), route through both processes with a shared ticket.

Pitfall 5, The emergency-change debt

The pattern. The register shows a tail of emergency changes (issued during incidents or under expedited authority) that have never been retro-reviewed. The tail grows over time. Six months later, the BCMS contains 15 unreviewed emergency changes whose cumulative impact is unknown.

The root cause. The emergency-change path was defined but the retro-review SLA was not enforced. The CAB did not track the retro-review backlog. The BCM Manager did not escalate the debt.

The fix. Enforce the retro-review SLA (7 days for Category-C, 14 days for Category-G). Track the debt at every CAB meeting. Escalate to the BCM Steering Committee if the debt grows. Conduct a debt-clearance campaign if the debt has accumulated.

Pitfall 6, The siloed MOC

The pattern. The 6.3 MOC system operates in isolation from the rest of the BCMS. Changes do not trigger Clause 6.2 objective re-validations; Clause 7.5 documents are not updated; Clause 8.5 exercises do not test the changed components; Clause 9.2 audits do not sample the MOC; Clause 10.1 corrective actions bypass the MOC.

The root cause. The MOC was built as a standalone system rather than as the change-control valve of the BCMS. The integration touchpoints were not designed in.

The fix. Map the integration touchpoints (Section 1, "What you must produce", item k). Wire each touchpoint explicitly into the MOC Procedure. Sample-test the integration at every Clause 9.2 audit.

Pitfall 7, The frozen register

The pattern. The register has entries but they are all between two and three years old. The BCMS documentation has the same dates. Nothing has been changed since certification, not because the BCMS is perfect but because the MOC has been bypassed for two years.

The root cause. The MOC was an audit-passing exercise; once certification was achieved, the BCM Manager stopped maintaining it. New changes bypassed the MOC because "the system is certified now".

The fix. Treat the frozen register as evidence of unmanaged drift. Conduct a full BCMS re-baseline (re-validate the BIA, strategy, plans, contact tree, exercise programme against current operational reality). Open a remediation programme under Clause 10.1 corrective action.

Illustrative Scenario 1: Failure, Northstar Cooperative Bank (Illustrative)

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

Disclaimer: The following is an illustrative scenario. Northstar Cooperative Bank is a fictional composite; the events, characters and figures are representative of patterns seen in the Indian urban-cooperative-banking sector and are not a report of any specific real company. The case is drawn from publicly documented patterns in RBI enforcement actions, CERT-In incident trends, and BCMS-audit findings.

The company and the BCMS

Northstar Cooperative Bank (NCB) is a Mumbai-based urban cooperative bank with 740 staff, ₹4,200 crore in deposits, 38 branches across Maharashtra and Gujarat, and a core-banking-system (CBS) hosted on-premise at the Mumbai DC with a DRS in Pune. ISO 22301:2019 certified in 2022 after an RBI-driven push for UCB cyber/BCP maturity (the RBI Complete Cyber Security Framework for UCBs, 31 December 2019). The BCMS scope covers the CBS, the digital-banking channels (mobile, internet, UPI), the branch operations, the ATM/POS switch, and the treasury operations.

NCB's BCM Manager (Rahul Sharma, an IT-trained deputy general manager) reports to the CTO; the BCM Steering Committee meets quarterly; the board Risk/IT Committee (constituted under SEBI LODR Reg. 21-equivalent for cooperative banks) receives a half-yearly BCM report. The 6.3 system at certification consisted of a 22-page MOC Procedure, a spreadsheet change register, and a CAB charter, all clean at the Stage 2 audit in mid-2022.

The drift (2022 to 2025)

Between mid-2022 and late 2025, NCB absorbed at least 16 consequential BCMS changes without going through the MOC. The drift was the textbook 6.3 failure pattern.

Change 1 (Category-G, October 2022): CBS replication architecture upgrade. The Pune DRS replication was upgraded from asynchronous to near-synchronous to improve RPO. No CR was raised. The BIA was not updated; the RPO objective in the Clause 6.2 register was not re-validated; the recovery runbook was rewritten informally by the storage team; no integrity test (failover exercise) was conducted post-change. The change was discovered in a 2024 internal audit (Clause 9.2), by which time the operational reality was 18 months ahead of the documented reality.

Change 2 (Category-F, March 2023): CTO transition. The CTO transitioned to a new CIO (Priya Sharma, hired from a private bank). The BCM reporting line was redrawn from CTO to COO without a CR. The new CIO was not onboarded into the CAB; the BCM Steering Committee did not meet for two quarters during the transition. The authority matrix in the MOC Procedure was not updated; Category-G changes for the next six months were approved by the same individuals as before, but they no longer held the named roles.

Change 3 (Category-B, April 2023): RBI Master Direction on Outsourcing of IT Services. The RBI MD (10 April 2023) imposed new change-notification and consent requirements on material outsourced-IT changes. NCB's CBS is partially outsourced (the CBS vendor provides L3 support and patch management). The compliance team assessed the applicability but did not raise a Category-B CR through the BCMS MOC; the BCMS documentation was not updated to reflect the new notification workflow; no integrity test (mock-notification exercise) was conducted.

Change 4 (Category-E, June 2023): BIA revision deferred. The annual BIA revision was scheduled for June 2023 but deferred due to "operational pressures" (the CTO transition). When the BIA was finally revised in March 2024, the discovery phase found that the Mumbai DC power-failure scenario, identified as a top-three risk in 2022, had been mitigated in late 2022 by an infrastructure change (an additional UPS string) that no one in the BCM team had been told about.

Change 5 (Category-B, August 2023): DPDP Act 2023 enactment. The DPDP Act (11 August 2023) introduced a Section 8(5) availability duty and a Section 8(6) breach-notification duty for NCB as a Data Fiduciary ( depositor data is personal data). The compliance team produced a high-level DPDP readiness assessment but did not raise a Category-B CR through the BCMS MOC; the BCMS was not updated to operationalise the availability duty; the breach-notification procedure was not revised to align with the DPDP Section 8(6) timeline.

Changes 6 to 16 (Category-E and Category-G, 2023 to 2025): Sixteen smaller changes accumulated, supplier swaps (ATM switching vendor, the SMS gateway provider, the cloud-storage vendor for archived statements); CBS patches; contact-tree updates; branch closures and openings; new digital-banking features (a UPI Lite rollout, a RuPay credit-on-UPI feature); each individually below the CIA threshold, cumulatively leaving the BCMS 30 to 40 percent out of date with operational reality.

The trigger, the October 2025 incident

On 14 October 2025, a fire-suppression system discharge at the Mumbai DC (a Category-5 FM-200 gas release triggered by a false smoke-alarm signal) took the CBS down for 4 hours 20 minutes during business hours. The failover to the Pune DRS was invoked, and failed.

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

First, the failover procedure in the BCM documentation was the pre-2022 version, it described the asynchronous replication architecture, not the near-synchronous architecture actually in place (Change 1). The failover failed because the documented procedure was wrong.

Second, the BCM team that invoked the failover did not include the storage engineer who had implemented the Change-1 upgrade, that engineer had left NCB in 2024 (Change 2 cascade), and the knowledge was lost (no deputy cross-training, a Clause 6.2 risk-treatment objective that had also been bypassed).

Third, the CBS vendor (whose L3 support was needed to authorise the failover) was not notified per the RBI MD Outsourcing change-notification workflow (Change 3), causing a 90-minute delay in vendor engagement.

Fourth, the BIA's 4-hour MTPD for the CBS (Clause 8.2) had been re-affirmed in March 2024 without anyone noticing that the Mumbai DC power-and-environmental risk had been partially mitigated but not the fire-suppression risk, the BIA revision missed the gap because the change had not been surfaced to the BCM team (Change 4).

Fifth, the customer-communication procedure (invoked under DPDP Section 8(6) because depositor data was potentially exposed by the disrupted controls) was the pre-DPDP version (Change 5 not operationalised); the communication went out 6 hours after the incident began, well inside the DPDP 72-hour window but well outside NCB's own internal 2-hour customer-communication commitment.

Sixth, the cumulative impact of the 16 smaller changes (Changes 6 to 16) was that the contact tree was 40% out of date, the runbook referenced supplier contracts that had been swapped, and the branch-fallback procedure referenced branch locations that had been closed.

The consequences

The immediate financial impact was a 4-hour-20-minute CBS outage, a 90-minute vendor-engagement delay, an estimated ₹14 crore in foregone transaction revenue (deposits, withdrawals, UPI, ATM), and an estimated ₹8 crore in operational recovery costs (overtime, vendor emergency fees, customer-compensation provisioning).

The regulatory consequences were more severe. The RBI was notified per the Cyber Security Framework (2 June 2016) 2-to-6-hour incident-reporting timeline, the notification went at 5.5 hours, late. CERT-In was notified per the Directions (28 April 2022) 6-hour timeline, the notification went at 7 hours, late. The DPDP breach-notification to the Data Protection Board was sent within the 72-hour window, but the customer-communication delay (6 hours vs NCB's 2-hour internal commitment) drew customer and media criticism.

The RBI supervisory team visited NCB within 14 days. The visit examined the BCMS in detail. The finding: NCB's BCMS had drifted from its certified state to the point where the recovery procedures could not be executed; this was a Clause 6.3 failure, the MOC system had been bypassed for 16 consequential changes over 36 months. The RBI monetary penalty (₹3 crore under the Banking Regulation Act) was modest; the structural penalty was a written undertaking requiring NCB to (a) commission an external BCM audit (the cost: ₹1.8 crore plus 4 FTE-months of internal effort); (b) remediate the BCMS under RBI supervision over 12 months; (c) report monthly to the RBI on remediation progress. The digital-banking-channel growth was capped at 5% year-on-year for the remediation period, a substantial commercial constraint.

Lessons specific to 6.3

The Northstar failure is a textbook 6.3 collapse. Every Clause 8.x technical artefact (BIA, strategy, plans, exercises) failed because the 6.3 MOC had failed. The lesson is that 6.3 is the upstream cause of BCMS operational fidelity, get it wrong and the downstream artefacts degrade silently until the BCMS does not work when activated; get it right and the downstream artefacts stay synchronised with operational reality.

The specific correctives: enforce the MOC on every consequential change without exception; constitute the CAB with a real charter and a real meeting cadence; require top-management approval for Category-A/B/F changes; build the integrity-test pattern library and make validation a gating control; integrate with Clause 6.2 objective re-validation, Clause 7.5 document updates, Clause 8.5 exercise programme; run quarterly cumulative-impact reviews; track emergency-change debt; escalate the frozen register as a red flag.

A working 6.3 system would have surfaced the Change-1 replication upgrade as a CR, triggered a BIA re-validation (catching the MTPD-vs-architecture mismatch), triggered a Clause 6.2 RPO-objective re-validation, triggered a recovery-runbook update and a failover-exercise integrity test, and the October 2025 incident would have been a 30-minute managed failover rather than a 4-hour-20-minute public outage.

Illustrative Scenario 2: Success, Sahyadri Specialty Chemicals (Illustrative, with ROI)

Disclaimer: The following is an illustrative scenario. Sahyadri Specialty Chemicals is a fictional composite; the events, characters and figures are representative of patterns seen in the Indian specialty-chemicals manufacturing sector and are not a report of any specific real company.

The company and the BCMS

Sahyadri Specialty Chemicals Pvt. Ltd. is a Pune-headquartered specialty-chemicals manufacturer with 920 staff, ₹680 crore annual revenue, operating two manufacturing sites (Roha in Maharashtra's Raigad district, and Dahej in Gujarat's PCPIR, the Petroleum, Chemicals and Petrochemicals Investment Region) serving pharmaceutical, agrochemical and performance-materials customers globally. ISO 22301:2019 certified since 2020, with a BCMS scope covering the manufacturing operations, the OT/ICS (distributed control systems, batch-management systems), the ERP and quality-management systems, the supply-chain operations, and the customer-technical-service function.

The BCM Manager (Anjali Deshpande, a chemical engineer with a BCMI-certified CBCI qualification) reports solid-line to the COO and dotted-line to the CEO; the BCM Steering Committee meets quarterly; the board Risk/IT Committee (Sahyadri is privately held but has voluntarily constituted a Risk Committee given its MAH, Major Accident Hazard, status under the NDMA Chemical Disasters Guidelines 2007) receives a half-yearly BCM report.

The 6.3 system

Sahyadri's 6.3 system was rebuilt in 2023 after a 2023 RBI-style regulator interaction (the Maharashtra Directorate of Industrial Safety and the Chief Controller of Explosives conducted a joint inspection following a peer-facility incident in Vapi) flagged that the BCMS documentation did not match the operational reality, three process-safety changes and two OT-system upgrades had been made since the last BIA revision without going through any formal change process.

The rebuild produced the eight-stage MOC workflow described in Section 7 of this guide.

The Policy was approved by top management in February 2023, with the seven categories, the authority matrix, the emergency-change path and the integrity-test patterns. The MOC Procedure was issued in March 2023. The CAB was constituted in April 2023 with the COO as chair, the BCM Manager as secretary, and the CTO, the Head of Manufacturing, the Head of EHS (Environment, Health and Safety), the Head of Supply Chain, and the Head of Quality as standing members; the Head of HR joined for Category-F changes; the Head of Procurement joined for Category-G changes. The CAB met weekly (30 minutes) for routine changes and monthly (120 minutes) for portfolio review.

The 6.3 portfolio ran at 64 changes in 2023, 72 in 2024, and 58 in the first three quarters of 2025. The category distribution was healthy: 3 Category-A (a scope expansion to add a new warehousing partner; a policy revision; a top-management sponsorship change), 8 Category-B (NDMA-driven, DPDP-driven, and Maharashtra-state-driven regulatory changes), 21 Category-C (corrective actions from audit findings, exercise findings, near-misses), 11 Category-D (improvements, the GRC-platform BCM-module migration, the introduction of quantitative BIA dimensions, the AI-assisted cumulative-impact-detection pilot), 19 Category-E (BIA, strategy, plan, procedure revisions, including a major BIA revision after the Dahej PCPIR earthquake-risk re-assessment), 4 Category-F (the CTO transition, two senior-leader changes, a manufacturing-head transition), 13 Category-G (OT-system upgrades, a supplier swap of the tank-container logistics provider, the cloud migration of the quality-management system, two emergency-changes during the June 2024 Roha site flooding).

The illustrative change, Change CR-2025-031 (Dahej OT upgrade)

To make the system concrete, consider CR-2025-031: a Category-G major change to upgrade the Dahej site's distributed control system (DCS) from the vendor's legacy version (end-of-support in 2026) to the current version, with a 9-month implementation window, an approved budget of ₹4.8 crore, and an integrity test consisting of a parallel-run of the legacy and new DCS for 60 days, a tabletop exercise with the manufacturing and EHS teams, a full-failover test in a sandbox environment, and a regulator-reporting dry-run with the Chief Controller of Explosives.

The cascade links for this change: Clause 4.1 (context), the vendor's end-of-support announcement triggered the change (a technological-context issue); Clause 4.2 (interested parties), the customer technical-service function needed to be informed because some customers track the DCS version as a process-reproducibility factor; Clause 5.1 (leadership), top management (CEO and COO) approved the change at the BCM Steering Committee; Clause 5.3 (roles), the RACI named the Head of Manufacturing as the requester (because the DCS supports the manufacturing process), the BCM Manager as the assessor, the BCM Steering Committee as the approver, the vendor plus the internal OT team as the implementers, the EHS Lead plus Internal Audit as the validators, the BCM Manager as the communicator, and the BCM Manager as the reviewer; Clause 6.1 (risks), the change-risk register flagged the deployment-failure risk (mitigated by the parallel-run), the integrity-loss risk (mitigated by the tabletop and full-failover), the transition-disruption risk (mitigated by the 60-day parallel-run), the regulatory-exposure risk (mitigated by the Chief Controller of Explosives engagement), the cumulative-impact risk (assessed at the next quarterly review), and the rollback-failure risk (mitigated by the rollback rehearsal and the legacy DCS retained during the parallel run); Clause 6.2 (objectives), the change triggered a re-validation of the manufacturing-RTO objective for Dahej (the original objective was based on the legacy DCS recovery characteristics); Clause 7.5 (documents), the BIA, the strategy, the plans, the contact tree and the runbooks for Dahej were updated as part of the change; Clause 8.2 (BIA), the BIA's MTPD and MBCO for the Dahej manufacturing activity were re-affirmed through a stakeholder workshop; Clause 8.5 (exercise programme), a Category-F DAhej-specific exercise was added to the 2026 calendar; NDMA Chemical Disasters Guidelines 2007, the on-site emergency plan was updated; the off-site mutual-aid arrangements were re-synchronised; the District Disaster Management Authority was engaged as a stakeholder.

The integrity test for CR-2025-031 was the most consequential single artefact. The test plan: parallel-run for 60 days (legacy and new DCS running side-by-side, with batch outcomes compared); a tabletop exercise with the manufacturing and EHS teams at day 30 of the parallel run; a full-failover test in the sandbox at day 45; a regulator-reporting dry-run with the Chief Controller of Explosives at day 60; success criteria = (a) batch outcomes within ±0.5% across the two DCSs; (b) tabletop exercise confirmed role-clarity and decision-tree currency; (c) full-failover test confirmed the new DCS could be recovered within the manufacturing RTO; (d) regulator-reporting dry-run confirmed the new DCS's alarm-and-trip log met the Chief Controller of Explosives's expectations.

The integrity test was executed between August and October 2025. The parallel-run revealed a batch-outcome drift of 0.3%, within tolerance but worth investigating; the root cause was a PID-loop tuning difference between the legacy and new DCSs, corrected by re-tuning. The tabletop exercise revealed two role-clarity gaps (the EHS Lead's decision-authority in a soft-shutdown was ambiguous; the shift-manager's authority to invoke the rollback was unclear), corrected by procedure revisions. The full-failover test achieved an RTO of 38 minutes (the manufacturing RTO objective is 60 minutes, a 22-minute margin). The regulator-reporting dry-run was acknowledged by the Chief Controller of Explosives with two minor recommendations (alarm-priority colour-coding; trip-event log retention period).

The post-change review at the November 2025 BCM Steering Committee concluded: change delivered against purpose; MOC process quality high (CIA accurate, integrity test sufficient, resource estimates within 8% of actual); no incidents or near-misses; two follow-up CRs raised (a PID-loop tuning review for the Roha site; an update to the Dahej exercise programme to incorporate the new alarm-priority colour-coding); cumulative-impact update, the change does not affect other in-flight changes.

The test, Cyclonic storm (June 2024)

Sixteen months before CR-2025-031's integrity test, in June 2024, a cyclonic storm flooded the Roha site (the older of Sahyadri's two manufacturing sites). The site lost grid power for 48 hours, lost telecom connectivity for 24 hours, and was inaccessible to non-resident staff for 36 hours. The site's emergency diesel generators sustained operations at 70% throughput for the duration; the DCS failover to a backup panel worked as designed; no product was lost; no safety event occurred.

The 6.3 system responded as designed. The storm itself was a Clause 8.4 incident, but the BCMS's ability to respond was the cumulative result of the MOC discipline. The two emergency changes invoked during the storm (a manual-mode fallback for the DCS; a temporary logistics rerouting) were executed under the incident commander's authority and retro-reviewed at the 19 July 2024 CAB meeting, both within the 14-day retro-review SLA. The lessons captured from the storm fed three Category-C corrective changes (an enhanced flood-response procedure; a generator-fuel-resilience upgrade; a DCS-manual-mode training programme for shift managers) and one Category-D improvement change (the AI-assisted cumulative-impact-detection pilot, which would later flag the Dahej-DCS-upgrade cumulative-impact pattern in 2025).

The ROI

The cumulative ROI of the 6.3 system over the 2023-2025 period was substantial.

Customer retention and growth. Two pharmaceutical customers (together representing ₹62 crore of annual revenue) had been considering dual-sourcing their specialty-chemicals supply to reduce single-site risk; the demonstrated Roha flood response and the Dahej DCS-upgrade integrity-test record retained both. One of them expanded the contract from ₹38 crore to ₹54 crore annually, citing Sahyadri's demonstrated operational resilience and change-management discipline as the deciding factor. New revenue: ₹16 crore per year.

Insurance premium reduction. The business-interruption and control-of-risk insurance renewal in Q1 2026 came in 28% lower than the prior year, reflecting the broker's assessment of the demonstrated change-management and recovery capability. Saving: approximately ₹1.4 crore per year.

Regulator and customer audit cost reduction. The customer-audit and regulator-inspection calendar for 2024 and 2025 produced zero findings requiring remediation on Sahyadri's BCMS or change-management discipline (down from 6 findings in 2022 and 4 in 2023). The cost avoidance: approximately ₹85 lakh.

ISO 22301 surveillance audit. The 2025 surveillance audit produced zero major nonconformities and one minor on documentation formatting; the certification body's report cited the 6.3 system as a strength of the BCMS and specifically called out the CR-2025-031 integrity test as exemplary practice.

Speed of recovery. The Roha flood response was 48 hours of generator-sustained operation with MBCO exceeded (70% throughput) plus 12 hours of repatriation, substantially less than the industry norm of 5 to 7 days of full outage for a comparable event. The foregone-revenue avoidance: approximately ₹9 crore.

Vendor negotiation use. The DCS upgrade (CR-2025-031) was negotiated with the vendor against the backdrop of a well-documented MOC system. The vendor offered a 12% discount on the upgrade licence and a 24-month extended warranty (versus the standard 12 months), citing Sahyadri's disciplined change-management as a lower support-risk profile. Saving: approximately ₹55 lakh on licence + an estimated ₹30 lakh on warranty value.

Total realised value over 24 months: ₹16 cr new revenue + ₹1.4 cr insurance saving + ₹0.85 cr audit-cost avoidance + ₹9 cr foregone-revenue avoidance + ₹0.85 cr vendor saving = ₹28.1 crore against the cumulative 6.3 investment (the BCM Manager FTE, the CAB time, the GRC-platform BCM module, the integrity-test costs across all 194 changes) of approximately ₹2.4 crore. ROI: approximately 11.7x over 24 months. The 6.3 programme was the highest-ROI control discipline the BCMS maintained in the period.

Why 6.3 was the cause of success

Every element of the Sahyadri success traces back to a 6.3 move. The Roha flood response capability was a CR-2023-018 corrective change output (the flood-response procedure revised after a peer-facility near-miss). The Dahej DCS upgrade integrity was a CR-2025-031 full-CIA output (the parallel-run, the tabletop, the full-failover, the regulator dry-run). The customer retention was a Stage 5 communication output (the customers knew about the changes and the integrity-test results). The insurance premium reduction was a KPI-13 (change ROI realised) output. The vendor negotiation use was a Stage 8 post-change-review output (the lessons captured on the MOC process quality were shareable with the vendor).

The lesson is that 6.3 is the highest-use clause in ISO 22301 for organisations willing to invest in it as a change-control valve rather than a documentation artefact. The Sahyadri pattern is replicable across Indian sectors with high physical-asset exposure, manufacturing, pharmaceuticals, chemicals, BFSI with physical DCs, logistics, where operational-reality drift is the dominant BCMS-degradation mode and where demonstrated change-management discipline is increasingly a commercial differentiator.

Multi-Framework Mapping

The 6.3 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.3 obligation maps to the Common Criteria and the Availability criteria. CC3.2 (the entity identifies risks) intersects via the change-risk register. CC8.1 (the entity authorises, designs, develops, configures, standardsises, documents, verifies, implements, and maintains controls) is the direct mapping, ISO 22301 6.3 MOC IS the SOC 2 CC8.1 control for BCMS changes. CC8.2 (the entity detects changes to controls) intersects via the change-register monitoring. The Availability criteria (A), specifically A1.1 (capacity, environmental protections, backup and recovery), A1.2 (recovery infrastructure), A1.3 (recovery testing), are operationalised through the integrity-test patterns applied to changes affecting recovery capability. The mapping is bidirectional, an ISO 22301 6.3 evidence set produces strong SOC 2 change-management and recovery-testing evidence.

How the mapping is used in an integrated audit

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

For organisations responding to sector regulators (RBI, SEBI, IRDAI, CERT-In, DPDP, NDMA), the 6.3 evidence set is the single most reusable artefact. The same change register, with appropriate tagging, satisfies the RBI MD change-management chapter, the SEBI CSCRF Protect-domain change-management expectation, the IRDAI board-overseen change-management control, the CERT-In log-integrity-through-changes expectation, the DPDP availability-through-changes duty, and the NDMA industrial-emergency-plan revision expectation. The toolkit's regulatory crosswalk (document 17) provides the clause-level mapping.

Implementation Roadmap

The 6.3 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 MOC system, convene top management, agree the principles, the seven categories, the authority matrix, the cadence and the roles; draft the Policy and the MOC Procedure for approval. Week 2: constitute the Change Advisory Board with a written charter; convene the first CAB meeting (even with no changes yet, to set the cadence). Week 3: open the BCMS Change Register; design the CIA template (three depth tiers); design the integrity-test pattern library. Week 4: define the integration touchpoints, Clause 6.1 (risk), Clause 6.2 (objectives), Clause 7.5 (documents), Clause 8.1 (operational change), Clause 8.5 (exercises), Clause 9.2 (audit), Clause 9.3 (management review), Clause 10.1 (corrective action).

Milestones at Day 30: Policy and Procedure approved; CAB chartered; register open; CIA template and integrity-test pattern library defined; integration touchpoints mapped.

Days 31-60, Back-fill and the first live changes

Days 31-45: run the back-fill workshop, surface every consequential change the BCMS has absorbed in the last 12 months; classify each into one of the seven categories; conduct retro-CIA on any high-consequence ones; conduct retro-validation where the integrity-test evidence is missing; populate the register with the back-fill. Days 46-60: process the first live changes through the MOC; calibrate the CIA depth tiers; calibrate the integrity-test patterns; refine the authority matrix in light of live experience.

Milestones at Day 60: register back-filled (typically 30 to 80 retro-changes for an Indian growing company); first live changes processed end-to-end through the eight stages; CIA and integrity-test patterns calibrated.

Days 61-90, Integration and the first management-review input

Days 61-75: wire the integration touchpoints, every consequential change now triggers Clause 6.2 objective re-validation where applicable, Clause 7.5 document updates, Clause 8.5 exercise-programme updates where the change affects a tested capability. Days 76-90: stand up the KPI dashboard; wire the integration with Clause 9.1 monitoring and Clause 9.3 management review; run the first BCM Steering Committee review of the change portfolio.

Milestones at Day 90: integration live; KPI dashboard live; first Steering Committee review of the change portfolio complete; integration with 9.1 and 9.3 wired.

Days 91-365, Living the system

Days 91-365: run the weekly CAB reviews, the monthly portfolio reviews, the quarterly Steering Committee reviews and the annual top-management review at 9.3; respond to event triggers (incidents, audit findings, regulatory shifts, BIA updates, exercise outcomes) with appropriate change CRs; populate the lessons-captured log; advance at least one methodological improvement per Clause 10.2 (e.g., the AI-assisted cumulative-impact-detection pilot).

Milestones at Day 365: first full cycle complete; change portfolio reviewed at 9.3; first-year performance report produced; year-2 MOC Procedure refinement 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 change-risk dimensions; extension of the MOC to cover ISO 27001 6.3 and ISO 9001 6.3 (integrated management system); introduction of AI augmentation (Layer 4) for CIA drafting and integrity-test selection; benchmarking against sector peers.

Resource plan (indicative, INR)

For a 50-to-250-staff Indian growing company: 0.3 to 0.7 FTE BCM Manager effort (internal) on MOC; ₹3 to ₹8 lakh of external facilitation for the first cycle (Policy, Procedure, CAB charter, back-fill workshop); ₹0.5 to ₹2 lakh for the KPI dashboard (spreadsheet-based at Layer 1); zero to ₹3 lakh for the CAB members' review time. For a 250-to-2,000-staff growing organisation: 0.7 to 1.5 FTE BCM Manager effort; ₹8 to ₹25 lakh external facilitation; ₹10 to ₹30 lakh GRC platform implementation (Layer 2); ₹2 to ₹8 lakh ongoing platform subscription. For a 2,000+ enterprise: scale proportionally with a 4-to-6-month implementation horizon.

FAQ

Q1. Does every operational change have to go through the BCMS MOC? No. Day-to-day operational changes, a server patch, a password rotation, a runbook micro-edit, are Clause 8.1 operational-planning-and-control events, not Clause 6.3 BCMS-change events. The 6.3 scope is changes to the BCMS itself (the system), not changes within the BCMS scope (the operations). The demarcation test: does this change alter the BCMS's design, objectives, capability or dependencies? If yes, it is a 6.3 change; if no, it is an 8.1 change.

Q2. Should the BCMS MOC be the same as the ITSM/ITIL change process? No, but they should integrate. The two systems overlap (especially for Category-G changes) but they have different scopes (BCMS vs IT services), different stakeholders (BCM Steering Committee vs CAB), and different validation criteria (BCMS integrity vs service availability). For most Indian growing companies, integrating the two, a single change ticket that triggers both ITSM and BCMS workflows where applicable, is more efficient than running them in parallel; but integration is a choice, not a requirement.

Q3. How many changes should we expect per year? Typically 20 to 80 per year for an Indian growing company; 60 to 200 for a mid-market (250 to 2,000 staff) organisation; 200+ for an enterprise. The standard does not prescribe a number. A BCMS that processes zero changes in a year is suspicious (suggests the MOC is bypassed); a BCMS that processes 500 changes a year is also suspicious (suggests operational changes are being routed through the BCMS MOC unnecessarily).

Q4. Does every change need a full CIA? No. The depth of the CIA must be proportionate to the consequence of the change. A Category-A scope change requires a full CIA with seven-dimension analysis; a Category-E contact-tree update may require only a one-line purpose, a one-line integrity test, and a register entry. The proportionality rule is part of the MOC Procedure, not an optional shortcut.

Q5. What if a change fails validation? Roll it back. A clean rollback, the change failed validation, was rolled back, the failure analysed, the lessons captured, is conformant. A register with zero rollbacks is suspicious; a register with thoughtful rollbacks and documented lessons is healthy.

Q6. Can the BCM Manager approve every change? No. The BCM Manager is the methodology custodian, not the universal approver. The authority matrix delegates approval by category: top management for Category-A/B; the BCM Steering Committee for Category-C/D/E and major Category-G; the BCM Manager under delegated authority for routine Category-D/E/G. A register where every change is approved by the BCM Manager fails the authority-matrix test.

Q7. How do we handle emergency changes during a disruption? The MOC Procedure defines an emergency-change path. The incident commander authorises the change; the BCM team validates it as soon as the incident is stabilised; the CAB retro-reviews it at the next meeting within the SLA (typically 7 days for Category-C, 14 days for Category-G). The 6.3 audit trail is preserved through retro-documentation.

Q8. Do we need a software-hosted register? No. A spreadsheet is conformant. A GRC-platform BCM module 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 obligations intersect with 6.3? Section 8(5) availability duty must survive every BCMS change touching a personal-data-bearing system, a change that breaks availability is a statutory breach. Section 8(6) breach-notification duty, an uncontrolled change that causes a personal-data breach is a reportable event. The CIA must include a regulatory-impact dimension for any change touching personal data. For Significant Data Fiduciaries, the DPDP Rules 2025 add DPIA-update and DPO-engagement obligations on changes affecting personal-data processing.

Q10. How do we operationalise the RBI MD IT Governance change-management chapter? The MOC Procedure is the operational form. For every consequential IT/BCMS change: a CR with segregation of duties between requester, approver and implementer; a CIA with risk assessment; CAB approval; a test evidence record; a rollback plan; a validation record. The RBI MD expects a formal change-management process, your MOC Procedure IS that process. Document the mapping in the regulatory crosswalk (toolkit document 17).

Q11. How do we integrate 6.3 with Clause 9.3 management review? The change portfolio (volume, category distribution, KPI trends, lessons captured, ROI realised) 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 MOC Procedure refinements, on authority-matrix updates, and on the year-ahead MOC priorities.

Q12. Can the same change ticket cover an ITSM/ITIL change and a BCMS change? Yes, and for integrated changes (e.g., a cloud migration that is both an IT operational change and a BCMS change) this is the most efficient pattern. The ticket includes the ITSM workflow (operational deployment) and the BCMS MOC workflow (consequential BCMS updates), with shared evidence (deployment record, validation record) where applicable.

Q13. How does the 6.3 system relate to enterprise change management? The 6.3 system is the BCMS-specific instance of the broader enterprise change-management discipline. The enterprise change-management system may include HR org-changes, procurement changes, financial-process changes; the 6.3 system is the BCMS subset. The two should align (a Category-F organisational change at the enterprise level triggers a BCMS MOC CR if it affects BCMS roles or capabilities) but they are not the same artefact.

Q14. How do we handle supplier-initiated changes? A supplier that changes its own infrastructure, processes or sub-contractors in a way that affects the BCMS is a Category-G change. The supplier's contract must require advance notification (the RBI MD Outsourcing of IT Services requires this for material outsourced-IT changes); the BCM team assesses the impact and decides whether the change is acceptable, requires countermeasures, or triggers a supplier-swap consideration.

Q15. What is the single biggest mistake Indian growing companies make on 6.3? The empty or frozen register, a register produced for the certification audit and never maintained, while the BCMS drifts operationally. The fix is the back-fill workshop, the live MOC discipline, and the integration touchpoints wired into the rest of the BCMS.

Industry-Specific Requirements

The 6.3 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.3. For banks and NBFCs (RBI MD IT Governance, 7 Nov 2023, eff 1 Apr 2024), the MOC must include the formal change-management chapter, segregation of duties, test evidence, rollback plans, CAB approval. For UCBs (RBI Complete Cyber Security Framework, 31 Dec 2019), the change-management discipline is graded by tier. For payment system operators (RBI cyber resilience framework), change-management covers the payment ecosystem. For MIIs and SEBI-regulated REs (SEBI CSCRF, 20 Aug 2024; SEBI MII BCP-DR, 22 Mar 2021), the MOC includes the blackout-window discipline (no production changes during trading/settlement hours), the board-notable Category-A/B change requirement, and the secure-SDLC expectations for in-house-built systems. For insurers (IRDAI Information and Cyber Security Guidelines, 24 Apr 2023), the MOC is board-overseen, with annual compliance reporting.

The BFSI 6.3 portfolio typically runs 40 to 100 changes per year for a mid-market (250 to 2,000 staff) NBFC, 80 to 200 for a mid-sized bank, and 200+ for a large bank or MII. Category-B (regulatory) changes dominate the high-consequence portfolio, the SEBI CSCRF, the RBI MD IT Governance, the RBI MD Outsourcing, the DPDP Act, and the DPDP Rules each drove multi-year Category-B change programmes across Indian BFSI. Category-G (technological/supplier) is the second-largest category, driven by cloud migrations, core-system upgrades, and the consolidating fintech supplier ecosystem.

Healthcare

Healthcare 6.3 is dominated by patient-safety-driven change control, every change to a clinical system must be assessed for patient-safety impact. The AIIMS Delhi November 2022 ransomware incident is the illustrative scenario of what happens when a healthcare BCMS absorbs technology changes without going through the MOC (the e-Hospital architecture had been changed without the BCMS being updated). For Indian healthcare providers, the MOC must include a patient-safety dimension in the CIA for every change touching a clinical system; a clinical-validation integrity test for every consequential change (typically involving a senior clinician sign-off); a manual-mode-fallback test for every change touching a clinical workflow.

The DPDP Act 2023 applies fully to healthcare Data Fiduciaries (patient data is personal data); every change touching patient data must preserve Section 8(5) availability. The Clinical Establishments (Registration and Regulation) Act 2010 and state-level clinical-establishment rules add sector-specific change-notification expectations.

IT / ITeS and SaaS

IT/ITeS and SaaS 6.3 is dominated by customer-contractual and supplier-ecosystem changes, the BCMS exists in large part to satisfy customer BCM mandates and tender requirements. The MOC must handle customer-flow-down changes (a customer's BCM audit finding that drives a change in the SaaS's BCMS); technology changes (cloud provider changes, framework updates); and supplier changes (sub-processor changes that must be communicated to customers per DPDP and per customer contract).

For SaaS providers serving EU customers, DORA Article 9(4)(e) change management is a customer-flow-down expectation that must appear in the MOC. For SaaS providers handling personal data, DPDP Section 8(5) availability must survive every change. The portfolio typically runs 40 to 100 changes per year for a mid-market (250 to 2,000 staff) SaaS firm.

Manufacturing

Manufacturing 6.3 is dominated by production-continuity and process-safety changes, the LG Polymers Vizag styrene gas leak (7 May 2020) is the illustrative scenario of what happens when an industrial operator absorbs process changes without going through the BCMS MOC (the M6 tank storage pattern had been changed during the COVID lockdown without the on-site emergency plan being updated). For Indian manufacturers, the MOC must include a process-safety dimension in the CIA for every change touching a MAH process; an OT-system integrity test for every change touching the OT/ICS environment; a regulator-notification consideration for every change touching a NDMA-scheduled process.

The NDMA Disaster Management Act 2005 and the NDMA Chemical Disasters Guidelines 2007 apply to chemical, petrochemical and pharma manufacturers; the MOC must include on-site emergency plan revisions, off-site mutual-aid re-synchronisation, and District DMP integration. Companies Act 2013 Section 134(3)(n) board risk-oversight applies to the highest-consequence changes.

Government and public sector

Government and public sector 6.3 is dominated by citizen-service continuity changes, the digital India stack (UPI, Aadhaar, DigiLocker, GSTN, e-Hospital, various state-level citizen-service portals) has explicit or implicit change-management expectations. 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.

For government departments, the MOC must include a citizen-communication dimension in the CIA for every change touching a citizen-facing service; a regulator-notification consideration for every change touching a CERT-In-reportable system; a multi-stakeholder engagement plan for every change touching inter-departmental arrangements.

Cross-industry themes

Three themes cut across industries. Climate (per ISO 22301:2019 Amendment 1:2024) generates Category-A/B changes for coastal, flood-prone or water-stressed locations, climate-driven extreme-weather recovery capability must be added to the BCMS through the MOC. DPDP Act 2023 generates availability-preservation and breach-notification considerations for every change touching personal data (essentially every sector). Cross-border regulatory flow-down (DORA, APRA CPS 230, MAS TRM, HKMA OR-2) generates Category-B changes for Indian organisations serving overseas customers in regulated sectors.

Maturity Model

The 6.3 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 (no MOC; drift)

The 6.3 system at L1 is a Policy and Procedure produced for the certification audit and never operationally embedded. The change register is empty or frozen. The CAB does not meet. The BCM Manager marks the system conformant for the surveillance audit without operational evidence. The BCMS in operation has drifted from the BCMS in documentation through months of uncontrolled changes. The auditor will issue a major nonconformity.

Audit posture: major nonconformity likely; surveillance audit risk high. Indicative INR to reach L2: 5 to 12 lakh rupees of internal effort plus 6 to 15 lakh of external facilitation (including the back-fill workshop).

Level 2, Managed (basic conformity)

At L2 the 6.3 system meets the minimum certification requirements. There is a board-approved Policy, a documented MOC Procedure, a functioning register, a constituted CAB, a CIA template, an integrity-test pattern library, named MOC roles, and a quarterly review cadence. The integration with Clause 6.1 risk, Clause 6.2 objectives re-validation, Clause 7.5 documents, 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 CIA depth, on integrity-test discipline, and on integration touchpoints. Indicative INR to reach L3: 8 to 20 lakh rupees of internal effort plus 10 to 25 lakh of external advisory for CIA depth advancement, integrity-test pattern library expansion, and full integration.

Level 3, Defined (living MOC)

At L3 the 6.3 system is genuinely living. The register is updated continuously; the CAB meets weekly for routine changes and monthly for portfolio review; event-triggered changes fire on incidents, audit findings, regulatory shifts, BIA updates, exercise outcomes, and corrective actions. The CIA depth tiers are calibrated and applied proportionately. The integrity-test pattern library covers all five patterns (documented test, parallel run, exercise, internal-audit sample, regulator-reporting dry run). The integration with Clause 6.2, Clause 7.5, Clause 8.5, Clause 9.2 and Clause 10.1 is bidirectional. The change-related KPIs (lead time, validation rate, retro rate, incident-correlation) are tracked and trended. The post-change-review lessons feed back into the MOC Procedure refinement.

Audit posture: strong conformity; the 6.3 system is a strength, not a vulnerability. Indicative INR to reach L4: 15 to 35 lakh rupees of internal effort plus 15 to 40 lakh for GRC platform adoption (Layer 2), quantitative change-risk dimensions, and AI-assisted cumulative-impact detection pilot.

Level 4, Quantitatively managed (integrated MOC)

At L4 the 6.3 system is integrated with the enterprise change-management system, the ISMS MOC (ISO 27001 6.3 and Annex A 8.32), the QMS change-management (ISO 9001 6.3), the OHSMS change-management (ISO 45001), the supplier-management tool, the audit-management tool and the GRC platform. Quantitative change-risk dimensions are applied to high-value changes. The change portfolio has clear ROI tracking; realised benefits are reported to top management. The board Risk Committee receives the change portfolio with trends and benchmarks. AI augmentation (Layer 4) is in pilot for CIA drafting, integrity-test selection, cumulative-impact detection, and lessons capture.

Audit posture: zero nonconformities expected; the 6.3 system is a documented strength of the BCMS. Indicative INR to reach L5: 25 to 60 lakh rupees of internal effort plus 25 to 75 lakh for full AI augmentation, integrated-dashboards advancement, and benchmarking against sector peers.

Level 5, Optimising (industry-leading)

At L5 the 6.3 system is at the leading edge. The methodology has been published (in anonymised form) in industry forums. The change portfolio produces predictive indicators that drive the Clause 8.5 exercise programme, the Clause 6.1 risk re-assessment cycle, and the Clause 6.2 objective re-validation cycle. The 6.3 evidence set is used actively in customer tenders, regulator interactions and board risk-reporting. The board Risk Committee has credited the 6.3 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.3 system is benchmarked by peers. Indicative INR to maintain L5: ongoing 10 to 25 lakh per year of internal effort plus 10 to 22 lakh of external advisory for horizon-scanning, methodology refresh, and AI-model tuning.

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), 6.1 (risk), 6.2 (objectives), 8 (operation), 9 (evaluation) and 10 (improvement), a high-maturity 6.3 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 Policy, the MOC workflow, the CIA, the integrity-test pattern library, the integration touchpoints, the change-related KPIs, 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.3 landscape over the 2025-2027 horizon.

Trend 1, AI-augmented MOC. AI augmentation is moving from leading-edge to mainstream for MOC systems. Use cases include AI-assisted CIA drafting (the system proposes a CIA based on the CR and historical patterns), AI-assisted integrity-test selection (the system recommends the validation pattern based on the change category and historical pass/fail patterns), AI-assisted cumulative-impact detection (the system scans the register and flags clusters), AI-assisted regulatory-impact analysis (the system scans regulatory updates and flags change CRs that may have regulatory implications), and AI-assisted lessons capture (the system mines post-change reviews for patterns). The opportunity is highest for L3 and above organisations; the investment is increasingly affordable for the mid-market (250 to 2,000 staff) by 2026-2027.

Trend 2, Climate as a Category-A/B change driver. ISO 22301:2019 Amendment 1:2024 added climate-related risk as an explicit Clause 4.1 context consideration; the natural 6.3 consequence is that climate-driven BCMS changes are an emerging category. Indian organisations in coastal, flood-prone or water-stressed locations (Mumbai, Chennai, Kolkata, coastal Andhra, the Bengaluru water-stress corridor) are particularly exposed. The MOC system should expect climate-driven Category-A/B changes to grow in volume and consequence over 2025-2027.

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 that includes change-management as a control. The 6.3 system is the natural locus for this convergence; a well-built 6.3 satisfies multiple regimes simultaneously. The cross-framework mapping in Section 16 is the practical tool.

Trend 4, DPDP operationalisation. The DPDP Rules 2025 finalisation introduces operational 6.3 considerations: every change touching personal data must preserve Section 8(5) availability; every change causing a personal-data breach is Section 8(6)-reportable; for Significant Data Fiduciaries, changes trigger DPIA-update and DPO-engagement obligations. The MOC Procedure must include a DPDP-impact dimension in the CIA for every change touching personal data.

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 + ISO 45001) and genuinely integrated management systems. The 6.3 clauses of all four standards can be jointly implemented with a single MOC 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.3 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 change-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.3 system the single integration point for multi-regulator compliance. Third, predictive integrity testing (AI that predicts which changes are at elevated risk of failure based on patterns and current conditions) will move from leading-edge to mainstream, with affordable AI-assisted integrity-test selection reaching the mid-market (250 to 2,000 staff) segment.

The 6.3 system built today should be designed to absorb these shifts, through the Policy's annual review, the event-trigger update protocol, and the maturity-advancement plan. A 6.3 system built as a living MOC (L3 and above) will absorb them naturally; a 6.3 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. (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.
• 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.3 (changes to the ISMS) and Annex A control 8.32 (change management).
• ISO 9001:2015 Quality management systems, Requirements, Clause 6.3 (planning of changes).
• ISO 14001:2015 Environmental management systems, Requirements with guidance for use, Clause 6.3.
• ISO 45001:2018 Occupational health and safety management systems, Requirements with guidance for use, Clause 6.3 and Clause 8.1.3 (change management).

NIST, FFIEC, FEMA

• NIST SP 800-34 Rev 1 Contingency Planning Guide for Federal Information Systems. May 2010. (Step 7, plan maintenance, is the structural analogue of 6.3.)
• 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.IM, recovery improvement).
• FFIEC IT Examination Handbook, Business Continuity Management Booklet. November 2019 (OCC Bulletin 2019-57; FRB SR 19-13; FDIC FIL-19071). Governance principle and post-change testing principle.
• FEMA Federal Continuity Directives FCD-1 (17 January 2017) and FCD-2 (13 June 2017) under PPD-40, reconstitution and plan maintenance.

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 9(4)(e) change management; Article 28 third-party change arrangements; Article 30 exit strategies.
• UK Civil Contingencies Act 2004, c.36.
• MAS Technology Risk Management Guidelines. Monetary Authority of Singapore, 18 January 2021. Change-management section.
• APRA Prudential Standard CPS 230 Operational Risk Management. Effective 1 July 2025. Paragraph 45 BCP updates; paragraph 59 APRA notification of new/changed critical-operation arrangements (≤ 20 business days).
• HKMA Supervisory Policy Manual TM-G-2 Business Continuity Planning (revised 31 May 2022) and OR-2 Operational Resilience (31 May 2022).

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; change-management chapter.
• Reserve Bank of India. Cyber Security Framework in Banks. 2 June 2016. DBS.CO/OC.No.114/33.01.001/2015-16. Change management as a cyber-resilience control.
• Reserve Bank of India. Master Direction, Outsourcing of Information Technology Services. 10 April 2023. RBI portal id 12376. Material-change notification; RE consent for major changes.
• Reserve Bank of India. Complete Cyber Security Framework for Primary (Urban) Cooperative Banks, A Graded Approach. 31 December 2019.
• 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. Board-notable BCP/DR changes; blackout windows.
• Insurance Regulatory and Development Authority of India. Information and Cyber Security Guidelines, 2023. 24 April 2023. Board-overseen change management; 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. Log integrity through changes; NTP-sync through changes; KYC integrity through changes.
• 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

• ISO 22313:2020, the most useful practitioner elaboration of Clause 6.3.
• The BCI practitioner guidance (31 October 2023), the professional-practice framework for BCM, including change-management as a management-layer practice.
• The DRI professional-practice framework (10 practices, living framework, free at drii.org), including the management-of-change practice.
• BCI Horizon Scan 2025 ("Complex and Interconnected Risk"), the single most-citable BCM industry dataset on change-induced incidents and emerging risks.
• ISO 31000:2018, risk management applied to changes.

Internal references

• Singahi ISO 22301 series, companion guides on Clauses 4 (context, scope, BCMS), 5 (leadership, policy, roles), 6.1 (risks and opportunities), 6.2 (BC objectives), 7 (resources, competence, awareness, communication, documented information), 8 (BIA, strategy, plans, exercises, evaluation), 9 (monitoring, internal audit, management review), 10 (corrective action, continual improvement).
• Singahi ISO 27001 series, Clause 6.3 and Annex A control 8.32 parallels; especially valuable for organisations running integrated ISMS + BCMS.
• Singahi ISO 9001 series, Clause 6.3 (planning of changes) parallels; for integrated QMS + BCMS.