ISO 22301 Clause 5.3: Roles, Responsibilities and Authorities

Quick Reference (60 Seconds)

If you only read one thing: Clause 5.3 is where the BCMS stops being a programme owned by one overstretched manager and becomes a system run by named, competent, authorised, communicating people. A 5.3-conformant BCMS is one in which every continuity role has a named human owner and deputy, every BCMS activity has a single Accountable owner, every authority needed during disruption has been pre-delegated in writing, the people inside the roles and the people around them know who owns what, and BCMS performance flows back up to top management on a cadence. The certification auditor will examine this distinction ruthlessly, and so will a regulator after a real disruption, when an incident strikes, the first question is always "who is in charge here?" Get 5.3 wrong and however strong the BIA, strategy, and plans, the response will collapse on the day. Get it right and every other clause becomes executable because the human infrastructure is in place.

What the Standard Actually Requires

The paraphrased requirement

ISO 22301 Clause 5.3 asks organizations to assign and communicate who is responsible and accountable for the BCMS and for reporting its performance. Three verbs do the work in that paraphrase. The organisation must assign specific BCM roles and authorities to specific, named people, not to departments, not to job-titles-in-the-abstract, not to "the leadership team". The organisation must communicate those assignments so that the people inside the roles, and the people who interact with them, know who owns what, and so that an outsider (auditor, regulator, customer, insurer) can trace any BCMS activity to a named human owner. And the organisation must ensure that BCMS performance is reported to top management, closing the accountability loop that Clause 5.1 opens.

ISO 22301:2019 Clause 5.3 is short, most of the requirement is captured in a small number of sentences. The depth lives not in the clause text but in the architectural decisions an organisation must make to satisfy it. The standard requires the role architecture to do three jobs at once. First, the role architecture is the execution mechanism, every other clause in the standard depends on named humans to do the work: Clause 4 context is owned by a person, Clause 8.2 BIA is run by a person, Clause 8.4 plans are activated by a person, Clause 9.3 management review is chaired by a person. 5.3 is what makes every other clause executable. Second, the role architecture is the accountability mechanism, when something goes wrong (a missed BIA review, a failed exercise, an incident that breached MTPD), the standard expects the organisation to be able to identify who owns the response and who reports to top management. Third, the role architecture is the authority mechanism, during a disruption, decisions must be made in minutes by people who know they have the authority to make them; that authority must be pre-delegated in writing, not negotiated in the moment.

What must be assigned

The clause requires three things to be assigned. The first is roles and responsibilities, the BCMS work itself, spanning Clauses 4 through 10. The second is authorities, the decision rights that role holders need to do their work, particularly during disruption when normal approval cycles are too slow. The third is the reporting obligation, the duty of the assigned role holders to report BCMS performance to top management. Each of these three assignments needs its own artefact: a RACI matrix for responsibilities, an authority-and-decision-rights matrix for authorities, and a reporting package and cadence for the reporting obligation.

The standard's deliberate use of both responsibility and accountability is important. A responsible role does the work; an accountable role owns the outcome and signs off. The cardinal rule of RACI, exactly one Accountable per activity, exists precisely because accountability cannot be shared without diluting it. The standard's phrasing makes clear that every BCMS activity must have a single accountable owner; activities with shared accountability are activities without accountability in audit terms.

What "communicate" means

The communication obligation is structural, not cosmetic. The standard requires role assignments to be communicated to at least four audiences. The first audience is the role holders themselves, every person holding a BCM role must know what their role is, what their authorities are, what their deputies and reporting lines are, and what their reporting obligations are. The second audience is the wider workforce, every employee and contractor must know the BCM structure well enough to know who to call, who commands a disruption, and how their own day-job connects to continuity. The third audience is interested parties (Clause 4.2), regulators, key customers, suppliers, insurers, and where relevant emergency services must know who to engage with on BCM matters. The fourth audience is top management, the reporting obligation is itself a form of communication, structured and cadenced rather than ad-hoc.

Communication takes many forms in a 5.3-conformant BCMS: the BCM org chart on the intranet, role-on-a-page cards, induction briefings, awareness programme content (Clause 7.3), the BCM Steering Committee minutes, the Crisis Management Team contact tree, the role descriptions embedded in HR systems, the regulator-mandated officer appointments notified to the relevant regulator. The test is whether an informed outsider, or a newly appointed role holder, could understand the BCM role architecture and their own place in it within fifteen minutes of looking.

What "reporting its performance" means

The reporting-to-top-management obligation is the clause's most under-appreciated load-bearing requirement. It is what closes the accountability loop opened by Clause 5.1 and substantiated by 5.3's role assignments. Top management (the same top management that Clause 5.1 charges with leadership and commitment) cannot lead what it cannot see; the reporting obligation is what makes the BCMS visible at the top of the house.

The reporting obligation has two modes. The routine mode is the cadenced report, typically quarterly to the executive committee, half-yearly or annually to the board Risk Management Committee, and at least annually as a formal input to the Clause 9.3 management review. The routine report covers BCMS performance metrics (Clause 9.1), exercise and test results (Clause 8.5), audit findings (Clause 9.2), incident summaries and corrective action status (Clause 10.1), and the health of the role architecture itself (vacancies, deputy readiness, succession gaps). The escalation mode is the real-time report during a disruption, top management is informed within minutes of incident declaration, kept informed at a cadence appropriate to the incident's severity, and engaged personally for any incident that crosses defined escalation thresholds (regulator-reportable, customer-visible, safety-related, above defined financial or operational impact).

The Indian regulatory overlay strengthens the reporting obligation significantly. RBI's Master Direction on IT Governance (7 November 2023) requires board-level oversight of IT service continuity; SEBI CSCRF (20 August 2024) requires the board to oversee the cyber resilience framework; IRDAI's Information and Cyber Security Guidelines (24 April 2023) place explicit BCP/DR oversight on the board's Risk or IT committee; the Companies Act 2013 Section 134(3)(n) requires the board's report to address risks that may threaten the existence of the company. A 5.3-conformant reporting package satisfies all four regulators at once when designed well.

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

Clause 5.3 is widely misread as "produce an org chart", download a template, drop in names, sign it. That misreading produces the single most common 5.3 nonconformity in the Indian small-and-growing-company segment. Being explicit about what 5.3 does not require protects against two failure modes: under-investing (treating the role architecture as a chart) and over-reaching (treating it as the entire governance manual).

• 5.3 does not require a specific organisational structure. ISO 22301 does not mandate a BCM Steering Committee, a board Risk Committee, a separate Crisis Management Team, or any particular named forum. The standard requires roles, responsibilities and authorities to be assigned; the shape of those assignments is the organisation's choice. Most well-formed Indian BCMSs have all three forums, but that is leading practice, not standardised mandate.
• 5.3 does not require a specific number of BCM roles. The eight-role minimum in Section 7 of this guide is Singahi's practitioner view, not the standard's requirement. The standard requires whatever roles the organisation's context (Clause 4.1), interested-party needs (4.2), scope (4.3), BIA outputs (8.2), and strategy (8.3) make necessary. A 50-person SaaS startup needs fewer roles than a 50,000-person bank.
• 5.3 does not require every role to be a full-time position. The BCM Manager role is sometimes full-time in large regulated entities; in most growing companies it is a part-time hat worn by an existing executive (often the COO, Head of Operations, or CIO). The standard requires the role to be assigned and competent; whether it is full-time is a resourcing decision (Clause 7.1).
• 5.3 does not require the BCM Manager to report to a specific executive. Reporting line is the organisation's choice. The audit-relevant test is whether the BCM Manager has direct access to top management, particularly during disruption. Dotted-line to the CEO and solid-line to the COO is common; solid-line three levels down from the CEO with no escalation path is a red flag.
• 5.3 does not require every role assignment to be a formal HR appointment. The BCM role is a functional assignment layered on top of an existing job. The same person can hold the Head of Operations title and the Crisis / Incident Commander role; they are different assignments with different authorities. What the standard requires is that the BCM assignment is documented, communicated, and competent.
• 5.3 does not require the BCM Steering Committee to approve every BCMS change. Authority levels are the organisation's choice. The standard requires authorities to be assigned; whether a particular change needs committee approval or BCM Manager approval is a delegation decision documented in the authority matrix.
• 5.3 does not require the board to approve role assignments. Top management assignment is required. For SEBI LODR Reg. 21 listed entities, RBI-regulated banks, and IRDAI-regulated insurers, board-committee noting is additionally required by sectoral regulation; for most growing companies, CEO/MD noting suffices.
• 5.3 does not require variable-pay linkage to BCM role performance. Pay linkage is a leading-practice signal of L4 to L5 maturity, not a standard requirement.
• 5.3 does not require the BCM Manager to be internally hired. External BCM consultants can support, but the accountable role holders must be organisation people, the standard expects the organisation to own its BCMS, not to outsource accountability. Consultants can be Responsible; they cannot be Accountable.
• 5.3 does not require a separate "BCM Manual." Many Indian firms maintain a BCMS Manual that bundles the policy (Clause 5.2), the role catalogue, the scope statement, and the process map; this is permitted but not required. The role catalogue can stand alone as a set of artefacts.

Why This Control Matters

The business risk

When a disruption strikes, the single largest determinant of outcome is not the technical quality of the recovery solution, it is whether named, competent, authorised people are available to execute the plan within the first minutes. Every major Indian incident of the last decade that turned from a contained event into a public crisis shares a 5.3 failure mode. The October 2020 Mumbai grid blackout, the November 2020 HDFC digital outage that drew the RBI's ban on new digital products, the November 2022 AIIMS Delhi ransomware, the September 2024 Jio data-centre fire that took a national carrier dark for hours, each of those incidents put the same three questions under a public spotlight: who was in charge, who could authorise what, and who owed top management and the regulator an account of what was happening.

The business risk of weak 5.3 implementation is concentrated in three failure modes. The first is decision paralysis, when no one is sure who has the authority to declare an incident, activate the BC plan, switch to manual fallback, or talk to the media, the response stalls while people phone each other. In a 2-hour RTO scenario, a 30-minute decision-paralysis delay consumes a quarter of the recovery budget. The second is concentration of accountability, when the BCM Manager is the Accountable owner for fifty activities, the BCM Manager becomes the single point of failure; if they are on leave, on a flight, or among the affected, the BCMS stalls. The third is information starvation of top management, when the reporting obligation is treated as a year-end slide deck rather than a real-time loop, the CEO and the board learn about a disruption from a reporter's call rather than from their own BCMS, and the regulator learns from social media rather than from the CERT-In PoC.

The Indian regulatory context

The Indian regulatory environment has, over the last decade, transformed 5.3 from a documentation requirement into a regulatory expectation with named, accountable officers. The transformation has happened across every major sector regulator.

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 the board to oversee IT governance, the senior management to implement it, and named functionaries, CISO, Head IT, Information Security Officer, to execute it. The RBI Cyber Security Framework (2 June 2016) requires a board-approved cyber security policy, an organisational framework for cyber resilience, and a Cyber Crisis Management Plan (CCMP). The repeated HDFC outages and the November 2020 RBI action demonstrated that the RBI treats unclear roles and accountability as a board-level governance failure, not an IT operations issue.

For SEBI-regulated entities, the Cybersecurity and Cyber Resilience Framework (SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024) defines five cyber resilience goals across six operational functions including Governance, and requires every RE to appoint a CISO, a nodal officer, and a defined organisational structure for cyber resilience. The SEBI MII BCP-DR circular (22 March 2021) requires Market Infrastructure Institutions to define roles and reporting lines for BCP activation. For SEBI LODR Reg. 21 listed companies, the Risk Management Committee must include members with an understanding of cyber, operations, and continuity risk, a structural role assignment at the board level.

For insurers, the IRDAI Information and Cyber Security Guidelines (24 April 2023) require a board-approved Information and Cyber Security Policy including BCP/DR, a CISO reporting directly to the senior management, and explicit BCP/DR oversight by the board's Risk or IT committee. The role catalogue must name these functionaries.

CERT-In Directions (20(3)/2022-CERT-In, 28 April 2022) require every service provider, intermediary, data centre, body corporate, and government organisation operating ICT in India to appoint a Point of Contact for CERT-In liaison, a regulator-mandated BCM role that must be in the catalogue, with a deputy, and with the authority to make the 6-hour incident report.

The DPDP Act 2023 (Act 22 of 2023) and the DPDP Rules 2025 require Significant Data Fiduciaries to appoint a Data Protection Officer (DPO), and the wider DPDP framework requires every Data Fiduciary to maintain the availability of personal data (Section 8(5)), a continuity obligation with an implicit role architecture underneath it. The DPO and the BCM Manager must coordinate because every personal-data breach is simultaneously a continuity event, a regulator-reportable event, and an individual-rights event.

The Companies Act 2013 Section 134(3)(n) requires the board's report to address risk management policy including risks that may threaten the existence of the company, a structural obligation that requires a board Risk Committee (Section 177 and SEBI LODR Reg. 21) to oversee BCM. The board's accountability flows through 5.3.

The Disaster Management Act 2005 casts duties on every Ministry, Department, and (by extension) operating entity in India, and Section 51 to 60 create penalties for non-compliance with DM authority directions during a disaster, directly relevant to crisis-command role clarity.

The cost of non-compliance

The cost of weak 5.3 implementation is rarely a direct ISO 22301 certification failure. It shows up as regulatory penalties, incident amplification, insurance friction, customer churn, and audit-cycle drag.

The HDFC case is the most-cited Indian example: the November 2020 outage drew a 2 December 2020 RBI order barring HDFC from new digital products and fresh credit cards; the ban was partially lifted only in August 2021 (~8 months) and fully lifted in March 2022 (~15 months). The cost was not the fine; it was the multi-quarter revenue impact of being unable to launch new digital products in the most aggressive digital-banking market in the world. The post-mortem made clear that the RBI viewed the repeated outages as evidence of a governance and accountability failure, a 5.3-grade failure, not merely an IT operations issue.

For growing companies, the most common cost is the Stage 1 major nonconformity. ISO 22301 certification audits are staged: Stage 1 is a documentation and readiness review; Stage 2 is the conformity audit. A 5.3 major nonconformity at Stage 1 (typically: no documented authority matrix, no deputy assignments, no reporting cadence to top management) delays the Stage 2 audit by 8 to 16 weeks while the organisation remediates, with consultant and internal-effort costs of 4 to 12 lakh rupees for a mid-market (250 to 2,000 staff) firm. The Stage 1-to-Stage-2 delay is the single most common source of cost overrun in ISO 22301 certification programmes in the Indian small-and-growing-company segment, and 5.3 is one of the top three clauses where Stage 1 majors are issued.

The opportunity

A strong 5.3 implementation compounds. It makes every other clause cheaper to implement because the human infrastructure is in place. It makes the BCMS exercise programme (Clause 8.5) productive because exercises test real role holders in real scenarios. It makes the management review (Clause 9.3) substantive because the reporting package is structured. It reduces regulator friction because the CISO, CERT-In PoC, DPO, and BCM Manager are named, contactable, and authorised to engage. It reduces cyber-insurance premia because the underwriter can see the governance structure. It improves customer trust because the security questionnaire gets a clear answer to "who runs your BCM programme?". And it reduces the time-to-recovery in a real incident because the people in the roles have rehearsed them.

Section 15 of this guide quantifies these benefits for an illustrative mid-sized Indian cooperative bank that invested approximately 22 lakh rupees in a 5.3-led BCMS rebuild and recovered the investment in regulatory-fine avoidance, lower insurance premia, and a Stage 1-to-Stage 2 cycle that ran to plan instead of stalling for a quarter.

Scope and Applicability

By organisation size

Growing companies (50 to 250 staff). The minimum viable 5.3 implementation is the eight-role architecture in Section 7, Executive Sponsor (usually the CEO or COO), BCM Manager (a part-time role, often held by the COO or Head of Operations), Crisis / Incident Commander (sometimes the same person as the BCM Manager, sometimes a separate role given to a senior operations executive), and five or six Response and Recovery Team Leads covering IT DR, Communications, People and Facilities, Supplier Coordination, and Customer Coordination. The BCM Steering Committee is typically a quarterly forum of the senior leadership team with BCM as a standing agenda item rather than a separate committee. The reporting package to top management is typically quarterly. The deputy and succession plan covers the Incident Commander and the BCM Manager at minimum. Total effort: 3 to 6 weeks of BCM Manager time for the first cycle, less than 1.5 lakh rupees of internal effort.

Mid-market (250 to 2,000 staff). The eight-role minimum expands to a twelve-to-fifteen-role architecture, with separate people typically filling the BCM Manager and Incident Commander roles, dedicated Response Team Leads for each major business function, a named Compliance / Legal lead, a named HR lead for people continuity, and a Company Secretary responsible for board noting. The BCM Steering Committee becomes a standalone forum chaired by the COO or an Executive Director, meeting monthly. The reporting package is monthly to the executive committee, quarterly to the board Risk Committee. Deputy and succession plans cover every named BCM role. Total effort: 6 to 10 weeks for the first cycle, 4 to 8 lakh rupees of internal effort plus external consultant support.

Multi-entity enterprise (2,000-plus staff). The role architecture includes group, business-unit, and site-level role assignments; a Group BCM Manager, BU BCM Coordinators, site Incident Commanders; a Group Crisis Management Team chaired by a Group Executive, BU crisis teams, site teams; integration with the group CISO, CERT-In PoC, DPO, and Compliance Officer; a board-level Risk Committee that receives quarterly BCM reporting; and a formal succession plan for every BCM role down to BU level. Total effort: 3 to 6 months for the first cycle, integrated with group governance taxonomy, multi-jurisdiction officer roles, and the group crisis-management standard.

By industry

Banking, financial services, and insurance (BFSI). The most regulator-heavy implementation. The role catalogue must integrate the RBI-mandated CISO, the SEBI-mandated CISO and nodal officer (for SEBI-regulated entities), the IRDAI-mandated CISO and board-committee oversight (for insurers), the CERT-In PoC, and, for Significant Data Fiduciaries, the DPDP DPO. The Crisis Management Team must include the Treasurer (for liquidity continuity), the Head of Customer Operations (for depositor / policyholder / investor communication), and the Compliance Officer (for regulator reporting). The reporting package to top management must satisfy the board oversight expectations of RBI MD IT Governance, SEBI CSCRF, IRDAI ICS, and the Companies Act. The authority matrix must pre-delegate the power to invoke the CCMP (RBI Cyber Security Framework, 2 June 2016), to make the 6-hour CERT-In report, and to engage the RBI / SEBI / IRDAI relationship manager.

Healthcare. The role catalogue must integrate the Medical Superintendent or Clinical Lead (because continuity decisions in a hospital are clinical decisions, the AIIMS Delhi ransomware taught the sector that an IT outage is a patient-safety event). The Crisis Management Team must include the Medical Superintendent, the Nursing Supervisor, the Head of Facilities (for power, oxygen, water continuity), the IT Head, the Head of Pharmacy, and the Head of Medical Records. The authority matrix must pre-delegate the power to switch to paper-based clinical workflows, to divert patients to peer hospitals, and to engage the District Health Authority. The reporting package to top management must include clinical-impact metrics, not just IT metrics. The DPDP overlay is significant because healthcare data is sensitive personal data under DPDP.

IT / ITeS and SaaS. The role catalogue must include the Head of Site Operations for each delivery site (because Chennai 2015 taught the sector that site access disruption is the dominant scenario), the Head of Customer Success (because customer communication during a SaaS outage is the dominant reputational risk), the Head of Engineering (because manual fallback and degraded-mode operation require engineering authority), and the Head of People (because employee safety and work-from-anywhere activation are first-class continuity actions). For SaaS firms serving EU financial-sector customers, the DORA overlay adds the ICT third-party incident notification role. The authority matrix must pre-delegate the power to declare a major incident under DORA Article 19, to invoke the status-page communication, and to engage the customer's incident-response lead.

Manufacturing. The role catalogue must include the Plant Manager for each site (because a plant-level disruption is the dominant scenario), the Head of EHS (because industrial-continuity decisions are safety decisions, the LG Polymers Vizag styrene gas leak in May 2020 taught the sector that an unmanaged process upset can kill), the Head of Supply Chain (because raw-material and component continuity drives production continuity), and the Head of Maintenance (because asset availability is the business, the Go First insolvency and the Pratt and Whitney PW1100G engine failures taught the aviation manufacturing sector that a single supplier can ground a fleet). For chemical and Major Accident Hazard (MAH) units, the NDMA Guidelines on Chemical Disasters (2007) require named on-site and off-site emergency plan role holders, these must be integrated with the BCM role architecture, not parallel-tracked. The authority matrix must pre-delegate the power to evacuate, to shut down a process, to engage mutual-aid partners, and to communicate with the District Disaster Management Authority.

Government and public sector. The role catalogue must align with the NDMA Disaster Management Plan template (Prevention / Mitigation / Preparedness / Response / Relief / Recovery / Capacity Building), and the Crisis Management Team must integrate with the District / State Disaster Management Authority structure. The authority matrix must respect the Section 51 to 60 penalty structure of the DM Act 2005. For Critical Information Infrastructure operators, the role catalogue must include the NCIIPC liaison (under IT Act 2000 Section 70A). The reporting package must satisfy the Ministry / Department accountability structure under DM Act Section 35 and 37.

Key Definitions and Terminology

The following definitions are paraphrased and operationalised for Clause 5.3, the precise normative definitions live in ISO 22300:2021 (vocabulary) and are not reproduced here.

Role. A defined BCM function with a specific mandate, set of responsibilities, set of authorities, and reporting obligations. A role is assigned to a person; the person is the role holder. The same person can hold multiple roles (e.g. Head of Operations and Crisis / Incident Commander); each role is a separate assignment with separate authorities. Roles persist across people; the BCM Manager role exists whether or not a specific person currently fills it.

Responsibility. The work a role holder is expected to do, the activities, decisions, and reports associated with the role. Responsibilities are operational; they live in the RACI matrix as R (Responsible) or C (Consulted). Multiple roles can share responsibility for an activity (multiple R); only one role can be accountable.

Accountability. Ownership of the outcome of an activity. The accountable role holder signs off, takes the blame if the activity fails, and gets the credit if it succeeds. Accountability lives in the RACI matrix as A (Accountable). The cardinal rule: exactly one A per activity. The standard's deliberate use of both terms makes this distinction load-bearing for 5.3 audits.

Authority. The decision rights a role holder needs to discharge their responsibilities, the power to spend, to commit resources, to declare, to activate, to communicate externally, to evacuate, to switch operational modes, to stand down. Authorities are pre-delegated in writing in the authority-and-decision-rights matrix; they are not negotiated during a disruption. The Authority matrix is the single most under-developed artefact in Indian BCMS implementations.

Top management. The person or group of people who direct and control the organisation at the highest level. In an Indian context this typically means the CEO/MD, the Executive Committee, and, for regulated or listed entities, the Board of Directors and its committees (particularly the Risk Management Committee under SEBI LODR Reg. 21 and the Audit Committee under Companies Act Section 177). Clause 5.3's reporting obligation runs to top management.

BCM Manager / BCM Lead. The role responsible for the day-to-day management of the BCMS, maintaining the policy (Clause 5.2), the role catalogue, the BIA, the strategy, the plans, the exercise programme, the audit and management review inputs. The BCM Manager is the operational owner of the BCMS but is not necessarily the Incident Commander during a disruption.

Crisis / Incident Commander. The role with the authority to declare an incident, activate the BC plan, command the response, and stand down. In a well-formed BCMS the Incident Commander role is held by a senior operational executive (often the COO or a senior business head), distinct from the BCM Manager (who is the architect of the response, not necessarily the commander). The distinction matters because the BCM Manager may need to be available to support rather than to command; conflating the two roles concentrates accountability and creates key-person risk.

BCM Steering Committee. The cross-functional governance forum that oversees the BCMS between management reviews. Membership typically includes the Executive Sponsor (chair), the BCM Manager (secretary), the CIO/CTO, the COO or Head of Operations, the Head of HR, the Head of Compliance / Legal, the Head of Communications, and, for regulated entities, the CISO, the DPO, and the Company Secretary. The Committee meets on a defined cadence (monthly or quarterly) and reports to top management.

Crisis Management Team (CMT). The team that assembles during a disruption to command the response. Membership includes the Incident Commander (chair), the BCM Manager (advisory), the Response Team Leads (IT DR, Communications, People and Facilities, Supplier and Customer Coordination), the Compliance Officer (regulator reporting), and, for escalated incidents, the Executive Sponsor. The CMT is activated by defined triggers; it is not a standing forum.

Response Team Lead. A role responsible for a specific response workstream during disruption, IT DR (restoring systems), Communications (internal and external messaging), People and Facilities (employee safety, work-area recovery, site evacuation), Supplier Coordination (invoking supplier BCPs, alternate suppliers), Customer Coordination (customer-facing comms, SLA management). Each Response Team Lead has deputies and a defined reporting cadence to the Incident Commander.

Recovery Team Lead. A role responsible for the recovery-and-resumption workstream after the immediate response, restoring full operations, returning from manual fallback to normal, capturing lessons learned, executing corrective actions. In smaller organisations the Response Team Leads double as Recovery Team Leads; in larger organisations the roles separate.

Deputy. A role holder designated to discharge the role in the absence, escalation, or unavailability of the primary role holder. Every BCM role must have at least one deputy; deputy readiness is a leading indicator of 5.3 maturity.

Successor. A role holder designated to take over a BCM role on a planned or unplanned vacancy. Succession planning is distinct from deputy assignment: the deputy holds the role temporarily; the successor holds it permanently.

RACI matrix. A two-dimensional table mapping activities (rows) to roles (columns) with cell values R (Responsible), A (Accountable), C (Consulted), I (Informed). The RACI matrix is the primary 5.3 artefact for the responsibility assignment. Every BCMS activity has exactly one A.

Authority-and-decision-rights matrix. A table mapping specific decisions (declare an incident, activate the BC plan, spend emergency funds, talk to regulators, talk to media, evacuate, switch to manual fallback, stand down) to the role holders authorised to make them, with the limits and the escalation paths. The authority matrix is the primary 5.3 artefact for the authority assignment.

Regulator-mandated officer. A BCM role that an Indian regulator explicitly requires the organisation to appoint, CISO (RBI / SEBI / IRDAI), CERT-In Point of Contact (CERT-In Directions 2022), DPDP Data Protection Officer (DPDP Act 2023 for Significant Data Fiduciaries), Nodal Officer (SEBI CSCRF), Compliance Officer (SEBI / IRDAI), Information Officer (IT Act 2000). The 5.3 role catalogue must name these functionaries and integrate them with the BCM role architecture rather than parallel-track them.

Relationship to Other Clauses and Frameworks

Within ISO 22301

Clause 5.3 is the central nervous system of the BCMS. Every other clause depends on named role holders to execute it. The relationships run in both directions.

5.1 Leadership and Commitment is the upstream clause. 5.1 requires top management to lead the BCMS; 5.3 operationalises that leadership by naming the role holders through whom leadership is exercised. A 5.1 failure (top management not visible, not engaged, not resourcing) typically shows up as a 5.3 failure (no named sponsor, no BCM Steering Committee, no reporting cadence). The two clauses are audited together because the evidence overlaps.

5.2 Policy is the parallel clause. The policy (5.2) is what the role holders (5.3) execute; the role catalogue is what makes the policy operational. The policy commits the organisation to maintain the BCMS; the role architecture is the human infrastructure that discharges that commitment. The two artefacts should be version-locked, when the policy changes, the role catalogue is reviewed.

4.1, 4.2, 4.3 Context, Interested Parties, Scope are the upstream inputs. The role catalogue must reflect the organisation's context (which roles are needed depends on what the organisation does), its interested parties (regulator-mandated officer roles depend on who is regulating), and its scope (multi-site organisations need site-level role assignments).

6.1, 6.2, 6.3 Planning are the downstream consumers. Risk treatment actions (6.1) are owned by named roles; BC objectives (6.2) cascade to role owners; BCMS changes (6.3) are authorised by named roles.

7.1 Resources, 7.2 Competence, 7.3 Awareness, 7.4 Communication, 7.5 Documented Information are the support infrastructure for 5.3. Roles are resourced (7.1); role holders are competent (7.2); the workforce is aware of the role architecture (7.3); role assignments are communicated (7.4) and documented (7.5). The awareness programme (7.3) carries 5.3 to the workforce; the Documented Information controls (7.5) govern the role catalogue.

8.1 through 8.6 are the operational processes the roles run. Operational planning (8.1) is owned by the BCM Manager; the BIA (8.2) is run by the BCM Manager with activity owners; strategy (8.3) is approved by the BCM Steering Committee; plans (8.4) are activated by the Incident Commander; exercises (8.5) test the role holders; evaluation (8.6) reviews role-holder performance.

9.1 Monitoring, 9.2 Internal Audit, 9.3 Management Review are the performance-evaluation loop. 9.1 produces the metrics that 5.3's reporting obligation carries to top management; 9.2 independently tests role assignments; 9.3 is the formal destination of the reporting obligation, where top management reviews the role architecture.

10.1 Nonconformity and Corrective Action, 10.2 Continual Improvement are the improvement loop. Nonconformities are assigned to role owners; corrective actions are owned by role holders; continual improvement is driven by the BCM Manager with Executive Sponsor oversight.

To other ISO management-system standards

ISO 22301:2019 Clause 5.3 is structurally aligned to the corresponding clause in every ISO management-system standard that uses the Harmonized Structure: ISO/IEC 27001:2022 Clause 5.3 (organizational roles, responsibilities and authorities), ISO 9001:2015 Clause 5.3 (organizational roles, responsibilities and authorities), ISO 14001:2015 Clause 5.3, ISO 45001:2018 Clause 5.3, ISO/IEC 20000-1 Clause 5.3, and ISO 55001 Clause 5.3. The clause number, the assignment-communication-reporting structure, and the top-management accountability are common across all of them.

For Indian organisations running multiple management systems, this alignment is an opportunity. The BCM role catalogue (5.3) can share appointments with the ISMS role catalogue (ISO 27001 5.3), the CISO is often the same person, the BCM Steering Committee often doubles as the ISMS Steering Committee at the management-review level, and the reporting package to top management can combine BCM, ISMS, and QMS metrics into a single resilience dashboard. The audit-ready artefacts (RACI, authority matrix, reporting package) are largely transferable.

ISO 22313:2020 (the guidance on the use of ISO 22301) Section 5.3 expands on the clause with implementation guidance on role assignment, deputy and succession planning, and the integration with regulator-mandated roles. ISO 22313 is the first port of call for an organisation asking "how do I do this practically?".

To Indian regulations

The 5.3 implementation is the primary site of integration between the BCMS and the Indian regulatory environment. The role catalogue is where the regulator-mandated officer roles land.

RBI Master Direction IT Governance (7 November 2023, effective 1 April 2024). Requires the board to oversee IT governance; senior management to implement it; named functionaries (CISO, Head IT, Information Security Officer) to execute. The role catalogue must name these functionaries. The reporting package to top management must satisfy the board's IT governance oversight duty.

RBI Cyber Security Framework (2 June 2016). Requires a board-approved cyber security policy, an organisational framework for cyber resilience, a Cyber Crisis Management Plan (CCMP). The Incident Commander role is the operational lead for CCMP activation; the CISO is the architect.

SEBI CSCRF (20 August 2024). Requires every RE to appoint a CISO and a nodal officer; the organisational structure for cyber resilience must be defined. The BCM role catalogue must integrate the CISO and nodal officer.

SEBI MII BCP-DR (22 March 2021). Requires MIIs to define roles and reporting lines for BCP activation. For MIIs (stock exchanges, clearing corporations, depositories), the role catalogue is regulator-grade: the BC plan activation chain must be unambiguous and tested.

IRDAI Information and Cyber Security Guidelines (24 April 2023). Requires a board-approved Information and Cyber Security Policy including BCP/DR, a CISO reporting directly to senior management, and explicit BCP/DR oversight by the board's Risk or IT committee. The role catalogue must name the CISO and define the reporting line; the board committee noting must be in the reporting package.

CERT-In Directions (28 April 2022). Requires every in-scope entity to appoint a Point of Contact for CERT-In liaison. The PoC is a regulator-mandated BCM role; the authority matrix must give the PoC the power to make the 6-hour incident report.

DPDP Act 2023 and DPDP Rules 2025. Requires Significant Data Fiduciaries to appoint a Data Protection Officer; every Data Fiduciary must maintain personal-data availability (Section 8(5)) and report breaches (Section 8(6)). The DPO coordinates with the BCM Manager because every personal-data breach is a continuity event.

Companies Act 2013 Section 134(3)(n) and Section 177; SEBI LODR Regulation 21. Require board oversight of risk management; listed companies must have a Risk Management Committee covering cyber, operations, and continuity risk. The reporting package to top management is the vehicle through which the board discharges this duty.

Disaster Management Act 2005. Casts duties on every Ministry, Department, and operating entity; Section 51 to 60 create penalties for non-compliance with DM authority directions during a disaster. The Incident Commander role is the operational interface with the District / State Disaster Management Authority; the authority matrix must give the Incident Commander the power to engage.

To global frameworks

NIST SP 800-34 Rev 1 (May 2010). Step 1 of the seven-step contingency planning process is the contingency planning policy statement, which establishes roles. NIST's contingency-planning model is system-centric (per information system) whereas ISO 22301 is organisation-centric (per prioritised activity); the role assignments differ accordingly, NIST expects an ISCP Coordinator per system; ISO 22301 expects a BCM Manager across the BCMS.

NIST CSF 2.0 (26 February 2024). The Govern function (GV.OC, GV.RM, GV.RR, GV.PO, GV.OV) explicitly addresses roles, responsibilities, and authorities, GV.RR is "Roles, responsibilities, and authorities are established, communicated, understood, and enforced". A 5.3-conformant role catalogue satisfies GV.RR-01 through GV.RR-04 directly.

FFIEC BCM Booklet (November 2019). The accountability principle requires the board and senior management to establish roles, assign responsibilities, and delegate authority for BCM. The booklet is structurally aligned to ISO 22301 Clauses 5 through 8.

DORA (Regulation (EU) 2022/2554, applicable from 17 January 2025). Article 5(3) requires the management body to define, approve, oversee, and be accountable for the implementation of the ICT risk management framework; management body members receive specific training. Article 11(7) requires a crisis communication function; Article 12 requires backup policies and restoration roles. For Indian firms serving EU financial-sector customers, the DORA overlay adds specific role and authority requirements to the BCM catalogue.

APRA CPS 230 (effective 1 July 2025). Paragraphs 20 to 23 are the strongest global parallel to ISO 22301 5.3: the board is ultimately accountable for operational risk including business continuity and service provider management; senior managers are allocated specific responsibilities; the board approves the BCP and tolerance levels. An Indian firm with Australian operations can satisfy APRA CPS 230 paragraphs 20 to 23 with the same role catalogue that satisfies ISO 22301 5.3.

MAS TRM Guidelines (18 January 2021). Section 8 (Technology Risk Management Framework) requires the board and senior management to establish clear roles and responsibilities for technology risk management including BCM. The MAS overlay is most relevant for Indian firms with Singapore operations or MAS-regulated customers.

HKMA TM-G-2 (31 May 2022) and OR-2 (31 May 2022). TM-G-2 requires the Authorized Institution's senior management to establish clear roles for BCP; OR-2 requires board accountability for operational resilience including the identification of Important Business Services and impact tolerances. The HKMA overlay is most relevant for Indian firms with Hong Kong operations.

Detailed Implementation Guidance, The Eight Role Moves

Figure · Process

What Clause 5.3 asks you to do

The 5.3 implementation decomposes into eight moves. Each is necessary; together they are sufficient. The moves are sequenced for a growing company building the role architecture for the first time; organisations with an existing BCMS can run them as a refresh cycle.

Move 1, Build the BCM role catalogue

The role catalogue is the master list of every BCM role the organisation assigns. It is the foundation artefact of 5.3; the RACI matrix, the authority matrix, and the reporting package all derive from it.

The catalogue is built top-down, starting with the executive layer and working down to the operational layer. The minimum viable role set for a growing company is eight roles.

Role 1: Executive Sponsor. The member of top management who holds ultimate accountability for the BCMS. Typically the CEO, MD, or COO. The Sponsor's name appears on the BC policy (Clause 5.2); the Sponsor chairs the BCM Steering Committee; the Sponsor receives the escalation-mode reports during incidents. The Sponsor cannot be delegated, only the operational work is delegated. Time commitment: 8 to 12 hours per quarter plus incident-driven time.

Role 2: BCM Manager / BCM Lead. The operational owner of the BCMS. Drafts and maintains the policy (Clause 5.2), the role catalogue, the BIA, the strategy, the plans, the exercise programme, the audit and management review inputs. Reports to the Executive Sponsor. May or may not be the Incident Commander (typically not, in organisations of more than 250 staff). Time commitment: 1 to 2 days per week in a part-time role; full-time in regulated mid-market (250 to 2,000 staff) and enterprise implementations.

Role 3: BCM Steering Committee Chair. The chair of the cross-functional governance forum. In most growing companies this is the Executive Sponsor; in mid-market (250 to 2,000 staff) and enterprise implementations it is often a separate Executive Director or the COO, with the Sponsor attending. The Chair sets the agenda, makes the go/no-go decisions on strategy and spend, and signs off the reporting package to top management.

Role 4: Crisis / Incident Commander. The role with the authority to declare an incident, activate the BC plan, command the response, and stand down. Typically a senior operational executive, the COO, a senior business head, or the Head of Operations. Distinct from the BCM Manager. The Incident Commander holds the response-phase authority; the BCM Manager supports. Time commitment: zero in steady state; intense during disruption and exercises.

Roles 5 to 8: Response and Recovery Team Leads. Five core workstreams typically need leads: IT DR (restoring systems and data), Communications (internal, external, regulator, media), People and Facilities (employee safety, work-area recovery, site evacuation, access), Supplier and Customer Coordination (invoking supplier BCPs, alternate suppliers, customer comms, SLA management), and Compliance and Reporting (regulator reporting, DPO/CISO coordination, audit-trail of decisions). In smaller organisations one person may lead two workstreams; in larger organisations each workstream has multiple leads per business unit or site.

The catalogue is documented in the BCM Role Descriptions toolkit document (toolkit 16). Each role has a description covering mandate, responsibilities, authorities, reporting line, deputy, competence requirement, time commitment, and KPIs.

For Indian regulated entities, the catalogue adds the regulator-mandated roles: CISO, CERT-In PoC, DPO (for SDFs), Nodal Officer (for SEBI REs), Compliance Officer, Information Officer. These roles are often held by the same people who hold the BCM roles (the CISO is often the BCM Steering Committee member; the Compliance Officer is often the regulator-reporting Response Team Lead); the catalogue makes the dual-hat explicit.

Move 2, Assign named individuals and deputies

Every role in the catalogue must be assigned to a named individual today, not to a job title in the abstract, not to a department. "The Head of Operations is the Incident Commander" is a 5.3 nonconformity if the Head of Operations is not named in the artefact; "Priya Sharma, Head of Operations, is the Incident Commander" is the 5.3-conformant formulation.

Every role must also have at least one deputy. The deputy holds the role when the primary is on leave, on travel, in another incident, or otherwise unavailable. Deputy readiness, the deputy's ability to actually discharge the role, is a leading indicator of 5.3 maturity. A deputy who has never been exercised in the role is a deputy in name only.

For senior roles (Incident Commander, BCM Manager, Response Team Leads), the catalogue also names a successor, the person who would take over the role on a planned or unplanned vacancy. Succession planning is a leading-practice signal of L4 to L5 maturity; it is not a baseline requirement but it is increasingly expected by regulators (RBI MD IT Governance and SEBI CSCRF both expect key-person risk to be managed).

The assignment is documented in the BCM Role Descriptions toolkit document and visualised in the BCM Org Chart (a one-page graphic on the intranet showing the BCM structure with named individuals).

Move 3, Build the authority-and-decision-rights matrix

The authority matrix is the primary 5.3 artefact for the authority assignment, and it is the single most under-developed artefact in Indian BCMS implementations. The matrix maps specific decisions to the role holders authorised to make them, with limits and escalation paths.

The minimum decision set covers eight decisions, each of which has caused real Indian incidents to escalate when authority was unclear.

Decision 1: Declare an incident. Who has the authority to declare that an event has crossed the threshold from operational issue to BC incident? Typically the Incident Commander, with input from the BCM Manager and the relevant Response Team Lead. Declaration triggers the BC plan activation, the CMT assembly, and the reporting clock.

Decision 2: Activate the BC plan. Who has the authority to invoke the BC plan, including the work-area recovery, the alternate site, the manual fallback procedures? Typically the Incident Commander, with the BCM Manager's support. Activation commits resources and may be publicly visible.

Decision 3: Spend emergency funds. Who has the authority to commit spend above the normal approval limit during an incident, to engage an external IR retainer, to commission a forensics firm, to provision emergency cloud capacity, to book emergency travel, to retain legal counsel? Typically the Incident Commander up to a defined limit (e.g. 25 lakh rupees), with the Executive Sponsor or the CFO above that limit. Pre-delegation of emergency spend authority is critical because finance approval cycles are too slow for a 2-hour RTO.

Decision 4: Talk to the regulator. Who has the authority to engage the RBI, SEBI, IRDAI, CERT-In, the DPDP Board, the District Disaster Management Authority? The 6-hour CERT-In clock under CERT-In Directions 28 April 2022; the 72-hour DPDP breach clock; the 2-to-6-hour RBI clock; the 6-hour SEBI RE clock, all require pre-named, pre-authorised role holders. Typically the Compliance Officer or the CERT-In PoC makes the report; the BCM Manager and the Incident Commander support. For SEBI MIIs, the responsibility matrix is regulator-defined.

Decision 5: Talk to the media. Who has the authority to make public statements about an incident? Typically a single named spokesperson (often the Head of Communications or the CEO); all other role holders are pre-instructed to refer. Uncoordinated media engagement during an incident is a textbook amplifier of reputational damage.

Decision 6: Evacuate or close a site. Who has the authority to order evacuation of a facility, closure of a site, or relocation of staff? Typically the site Incident Commander or the Head of Facilities, with the Executive Sponsor informed. For chemical and MAH units, the NDMA Guidelines on Chemical Disasters (2007) define this authority chain explicitly.

Decision 7: Switch to manual or degraded-mode operations. Who has the authority to switch the organisation from normal operations to manual fallback (paper-based clinical workflows in a hospital, manual check-in at an airport, manual order processing in an e-commerce firm)? This decision has business consequences, manual mode is slower, costlier, and error-prone, and requires operational authority. Typically the relevant Response Team Lead with Incident Commander concurrence.

Decision 8: Stand down. Who has the authority to declare the incident closed, return to normal operations, and trigger the post-incident review? Typically the Incident Commander, with the BCM Manager's concurrence and the Executive Sponsor's noting. Stand-down triggers the Clause 8.6 evaluation and the Clause 10.1 corrective-action workflow.

The matrix is documented in the BCM Authority and Decision-Rights Matrix toolkit document (toolkit 13, RACI, includes the authority sub-matrix). Each decision has a primary authority holder, a limit (spend cap, scope cap), an escalation path, and a documentation requirement (every exercise of authority is logged for the post-incident review).

Move 4, Charter the BCM Steering Committee

The BCM Steering Committee is the cross-functional governance forum that oversees the BCMS between management reviews. The Committee is chartered by the Executive Sponsor; the BCM Manager is the secretary.

The charter covers six elements. Mandate, what the Committee is responsible for (oversight of the BCMS, approval of strategy and plans, sign-off of the reporting package to top management, decision on resource allocations). Membership, who sits on the Committee (Executive Sponsor as chair; BCM Manager as secretary; CIO/CTO; COO or Head of Operations; Head of HR; Head of Compliance / Legal; Head of Communications; for regulated entities the CISO, the DPO, and the Company Secretary). Cadence, how often it meets (monthly in mid-market (250 to 2,000 staff) and enterprise; quarterly in growing companies). Decision rights, what the Committee can decide versus what it escalates (typically: approves strategy, plans, exercise schedule, audit responses; escalates spend above a defined limit, scope changes, regulator-facing positions). Escalation rules, how issues move up to top management and down to operational teams. Reporting, what the Committee reports to top management (the reporting package; see Move 6).

The charter is documented in the BCM Steering Committee Charter toolkit document (embedded in toolkit 16, the role descriptions). A well-chartered Committee meets its cadence, has quorum, takes minutes, and reports on time; an under-chartered Committee is the classic 5.3 audit failure ("the Committee exists on paper but has not met in nine months").

Move 5, Charter the Crisis Management Team

The Crisis Management Team is the team that assembles during a disruption to command the response. The CMT is chartered by the BCM Steering Committee; the Incident Commander is the chair; the BCM Manager is the advisory.

The charter covers activation triggers, command structure, comms protocol, and stand-down. Activation triggers are the events that assemble the CMT, typically any incident that crosses a defined severity threshold (regulator-reportable, customer-visible, safety-related, above a defined operational or financial impact). The triggers are pre-defined; the Incident Commander has the authority to activate without further approval.

Command structure is the CMT in session: Incident Commander (chair), BCM Manager (advisory), Response Team Leads (IT DR, Communications, People and Facilities, Supplier and Customer Coordination, Compliance and Reporting), and, for escalated incidents, the Executive Sponsor. The command structure is documented in the CMT charter and visualised in the BCM Org Chart.

Communications protocol covers the cadence of internal CMT updates (typically 30-minute syncs during active incident), the cadence of workforce updates, the cadence of top-management reports, the cadence of customer and supplier comms, and the cadence of regulator reports. The protocol references the authority matrix for who speaks on which channel.

Stand-down is the formal closure of the CMT session, return to normal operations, trigger the Clause 8.6 evaluation, trigger the Clause 10.1 corrective-action workflow, schedule the post-incident review.

The CMT charter is exercised at least annually (Clause 8.5); an unexercised CMT is a textbook 5.3 / 8.5 combined failure mode.

Move 6, Build the reporting-to-top-management package

The reporting package is the artefact that discharges 5.3's reporting-its-performance obligation. It has two modes: routine and escalation. Both must be designed and documented.

The routine reporting package covers content, cadence, format, and destination. Content spans BCMS performance metrics (Clause 9.1, exercise pass rates, RTO/RPO actuals versus targets, plan-activation times, training-completion rates), audit findings (Clause 9.2, open and closed findings, ageing, repeat findings), incident summaries (Clause 10.1, count by severity, corrective actions, root-cause themes), exercise results (Clause 8.5, exercises completed, lessons learned, role-holder performance), and the health of the role architecture itself (vacancies, deputy readiness, succession gaps, lapsed assignments). Cadence is typically monthly to the executive committee, quarterly to the board Risk Management Committee (for LODR-listed entities), and at least annually as a formal input to the Clause 9.3 management review. Format is a standing dashboard plus narrative commentary. Destination is the Executive Sponsor, the executive committee, and, for regulated entities, the board Risk Committee.

The escalation reporting mode covers the real-time flow during disruption. Within minutes of incident declaration, top management is informed by a defined channel (phone, then email summary). For incidents crossing defined thresholds (regulator-reportable, customer-visible, safety-related, above defined financial or operational impact), the Executive Sponsor is engaged personally, the board Risk Committee Chair is notified, and the cadence of updates is defined (typically hourly during active incident). The escalation thresholds are pre-defined; the reporting cadence is pre-defined; the channels are pre-defined, none of this is negotiated during the incident.

The reporting package is documented in the Metrics and KPI Dashboard toolkit document (toolkit 11) and the Roles Communication Plan toolkit document (toolkit 15). A well-designed reporting package satisfies RBI MD IT Governance, SEBI CSCRF, IRDAI ICS, the Companies Act Section 134(3)(n) board duty, and Clause 9.3 management review in one instrument, the BCM Manager does not produce five reports for five audiences; the BCM Manager produces one reporting package that satisfies all five.

Move 7, Communicate the role architecture

The communication obligation in 5.3 is structural, not cosmetic. The role architecture must be communicated to four audiences using the artefacts below.

To the role holders themselves, through the role descriptions (toolkit 16), the BCM Steering Committee charter (toolkit 16), the CMT charter (toolkit 16), and an induction briefing when a role is first assigned or refreshed. The role holder signs an acknowledgement that they understand the role, the authorities, the reporting obligations, and the deputy assignment. The acknowledgement is filed in the role catalogue.

To the wider workforce, through the BCM Org Chart on the intranet, role-on-a-page cards, the awareness programme content (Clause 7.3), the BC plan's contact tree (who to call by role), and the induction programme for new joiners. The test is that every employee knows who their site Incident Commander is and how to reach them.

To interested parties, through the customer trust portal (BCM Manager named, CISO named for security questionnaires), the vendor portal (BCM Manager named for supplier-engagement purposes), the regulator notifications (CERT-In PoC named to CERT-In, CISO named to the regulator), and the insurer's underwriting file (BCM structure for premium assessment).

To top management, through the routine and escalation reporting packages (Move 6).

The communication artefacts are documented in the Roles Communication Plan toolkit document (toolkit 15). A well-communicated role architecture is invisible, nobody in the organisation wonders who runs BCM; it is obvious because the artefacts are everywhere. A poorly-communicated role architecture produces the symptom that is the 5.3 audit red flag: nobody below the BCM Manager can name the Incident Commander.

Move 8, Build the deputy and succession plan

The deputy and succession plan is what makes the role architecture resilient to the absence, resignation, escalation, or post-incident exhaustion of role holders. It is the 5.3 contribution to people continuity (which ISO/TS 22330 addresses in more detail).

Deputy assignment is the immediate layer. Every BCM role has at least one deputy; the deputy holds the role in the primary's absence. Deputy readiness is built through exercises (Clause 8.5) where the deputy holds the role in a simulation, through shadowing during real incidents, and through structured handovers. A deputy who has never held the role in an exercise is a deputy in name only.

Successor assignment is the medium-term layer. Every senior BCM role (Incident Commander, BCM Manager, Response Team Leads) has a named successor, the person who would take over the role on a planned or unplanned vacancy. Successor readiness is built through longer-form development, typically 6 to 18 months of structured exposure, training (Clause 7.2), and progressive responsibility. Succession planning is a leading-practice signal of L4 to L5 maturity.

Cross-training is the team-level layer. Every BCM role's responsibilities are documented well enough that a competent person from a related role can fill in if both primary and deputy are unavailable. Cross-training is what makes the role architecture survive a mass-impact event (pandemic, mass food poisoning, site evacuation) that takes out multiple role holders at once.

The deputy and succession plan is documented in the BCM Role Descriptions toolkit document (toolkit 16), with deputy and successor named for every role. The plan is exercised annually through a "missing persons" drill, a tabletop where primary role holders are absent and deputies hold the response.

Sequencing, dependencies, and time

The eight moves are sequenced for a first-cycle implementation. Moves 1 and 2 (catalogue and assignment) come first because everything else references them. Move 3 (authority matrix) follows because it is the next most under-developed artefact and it is the one that most directly affects response performance. Moves 4 and 5 (Steering Committee and CMT charters) come next because they formalise the governance forums that the catalogue and the authority matrix populate. Move 6 (reporting package) is built once the forums exist. Move 7 (communication) is the dissemination of the catalogue, the matrix, the charters, and the reporting package. Move 8 (deputy and succession) is the resilience layer that makes the architecture survive.

A growing company can complete Moves 1 through 5 in 3 to 6 weeks of BCM Manager time; Moves 6 and 7 in another 2 to 3 weeks; Move 8 as an ongoing programme. Mid-market implementations take 6 to 10 weeks for Moves 1 through 7 and treat Move 8 as a 6-month deputy-readiness build. Enterprise implementations run 3 to 6 months for the full cycle and treat deputy readiness and succession as continuous HR-aligned programmes.

Tools, Technologies, and Solutions

The 5.3 implementation runs mostly on documents, meetings, and people, but a tool stack amplifies the BCM Manager's capacity and produces audit-trail evidence that a document-only approach cannot. The Indian market offers a useful range from free to enterprise. The tool categories below are described in category-level terms; specific vendor selection is the organisation's choice.

The tool categories that matter for 5.3

GRC / BCM platforms. A Governance, Risk and Compliance platform with a BCM module is the most consequential 5.3 investment for mid-market (250 to 2,000 staff) and enterprise. The platform holds the BCM role catalogue, the RACI matrix, the authority matrix, the reporting dashboards, the policy repository, the BIA repository, the exercise schedule, the audit findings, and the corrective-action log. The key 5.3 features are: role-based access control that mirrors the BCM role catalogue; workflow automation that routes approvals to named role holders; dashboard authoring for the reporting package; and an evidence-export function that produces the audit pack in a single click. Platforms in this category typically price per-user-per-month; expect mid-market (250 to 2,000 staff) implementations in the range of 1,500 to 4,500 rupees per user per month, with annual commitment and Indian rupee invoicing increasingly common. For Indian banks, the RBI's expectation that the board oversee IT governance has driven strong adoption of GRC platforms in the regulated segment.

Org-chart and role-visualisation tools. A lighter-weight alternative for growing companies, a tool that produces the BCM org chart, the deputy and succession visualisation, and the contact tree. Some HR information systems include this functionality natively; standalone tools specialise in it. Pricing is typically per-employee-per-month, with entry plans under 200 rupees per employee per month.

Incident-management and mass-notification platforms. A platform that, on incident declaration, assembles the CMT (calls the role holders), captures the incident log, drives the communications protocol, and produces the post-incident report. The 5.3-relevant features are: pre-configured activation chains (call the Incident Commander, then the CMT, then the executive sponsor by defined order); role-based notification templates; integrated conference bridge or chat; and an immutable incident log for post-incident review. Pricing is typically per-user-per-month or per-incident; expect entry plans in the range of 500 to 1,500 rupees per user per month for the mass-notification category.

Collaboration and document-control platforms. A document-controlled intranet or team workspace (often built on a standard enterprise productivity suite) that hosts the role catalogue, the authority matrix, the BCM Steering Committee minutes, the reporting package, and the BC plan. The 5.3-relevant features are: version control with approval workflow (Clause 7.5 documented information); role-based access; co-authoring for the role catalogue and the reporting package; and integration with the GRC platform. For Indian growing companies this is typically an extension of the existing productivity suite at no additional licence cost.

Awareness and training platforms. A learning management system that delivers BCM role training (Clause 7.2 competence), awareness content (Clause 7.3 awareness), and assessment. The 5.3-relevant features are: role-specific learning paths; acknowledgement capture (the role-holder signature); and certification tracking for regulator-mandated roles (CISO, CERT-In PoC, DPO). Pricing is typically per-learner-per-month; expect entry plans under 150 rupees per learner per month.

Status-page and customer-comms platforms. For SaaS firms and customer-facing digital businesses, a status-page platform that lets the Communications Response Team Lead publish incident updates to customers and the public. The 5.3-relevant feature is the pre-authorised workflow, the Communications Lead has the authority to publish without further approval within defined severity tiers.

Build versus buy by maturity level

L1 / L2 (ad-hoc / compliance-only). Documents in a productivity suite, an intranet page for the BCM org chart, an email distribution list for the CMT activation. Total cost: less than 50,000 rupees per year. Adequate for organisations below ~100 staff with limited regulatory exposure.

L3 (managed). Add a structured BCM module (often part of a broader GRC or ISMS platform) for the role catalogue, RACI, authority matrix, and reporting package; add a mass-notification tool; add role-specific learning paths in the LMS. Total cost: 2 to 6 lakh rupees per year for a mid-market (250 to 2,000 staff) firm. The single most-valuable addition at this level is the GRC platform, it converts the role architecture from documents into a managed system.

L4 / L5 (optimised). Full GRC platform with BCM, ISMS, operational-risk, and compliance modules sharing a common role catalogue; integrated incident management with mass notification; real-time executive dashboard; deputy-readiness analytics; integration with the HR system for succession planning. Total cost: 8 to 25 lakh rupees per year for an enterprise implementation. At this level, the 5.3 artefacts are machine-enforced, the GRC platform will not let an approval proceed without the named accountable role holder signing off.

Implementation notes

Three implementation notes apply regardless of the tool choice. First, the role catalogue is master data, it should live in one system (typically the HR system or the GRC platform) and propagate to others; multiple unsynchronised copies of the catalogue are a 5.3 audit failure waiting to happen. Second, the reporting dashboard should be reproducible, the BCM Manager should be able to generate the reporting package in minutes, not weeks; if the reporting cycle takes more than a day of preparation, the tool architecture is wrong. Third, the audit-trail must be immutable, every exercise of authority, every role-assignment change, every reporting-cycle emission must be logged with a timestamp and an author; this is the evidence the certification auditor and the regulator will demand.

Policy and Procedure Templates

The 5.3 artefacts translate into a set of templates that the BCM Manager authors, the Executive Sponsor signs, and the BCM Steering Committee reviews. The full templates are in the toolkit; the structure and intent of each is described below.

The BCM Roles, Responsibilities and Authorities Policy

The policy is the apex 5.3 artefact. It establishes the role architecture, assigns accountability, and binds the organisation. Sample "shall" clauses (Singahi's drafting, the standard's own clause text is not reproduced) include:

• "The organisation shall maintain a BCM role catalogue naming every BCM role, the named individual holding each role, the deputy, and the successor where applicable."
• "The Executive Sponsor shall be a member of top management and shall not delegate accountability for the BCMS."
• "Every BCMS activity shall have exactly one Accountable role owner documented in the BCM RACI matrix."
• "Every BCM role shall have at least one deputy. Deputy readiness shall be exercised at least annually."
• "The organisation shall maintain an authority-and-decision-rights matrix pre-delegating the powers required to declare an incident, activate the BC plan, spend emergency funds, communicate with regulators and media, evacuate or close a site, switch to manual or degraded-mode operations, and stand down."
• "The BCM Manager shall report BCMS performance to top management on a defined cadence and through defined escalation triggers."
• "The BCM Steering Committee shall meet at least quarterly; the Crisis Management Team shall be activated by defined triggers and shall be exercised at least annually."
• "Regulator-mandated officer roles, CISO, CERT-In Point of Contact, DPDP Data Protection Officer where applicable, SEBI nodal officer where applicable, shall be named in the BCM role catalogue and integrated with the BCM role architecture."
• "Role assignments shall be reviewed at least annually and on event triggers including major incident, reorganisation, regulatory change, audit nonconformity, and role-holder change."

The policy is signed by the Executive Sponsor; for SEBI LODR Reg. 21 listed entities, it is noted by the board Risk Management Committee; for RBI-regulated banks, it is noted by the board's IT or Risk committee.

The BCM Role Assignment and Communication Procedure

The procedure operationalises the policy. It defines how roles are assigned (selection criteria, approval chain, acknowledgement record), how they are communicated (induction briefing, intranet publication, awareness programme), how they are reviewed (calendar cadence, event triggers, change management), and how they are revoked (resignation, reassignment, removal). The procedure is the operating instruction for the BCM Manager.

The BCM Authority and Decision-Rights Matrix

The matrix is described in Move 3 above. It is the most operationally consequential 5.3 artefact because it determines what happens in the first minutes of an incident. The matrix is reviewed annually and after every incident where authority was unclear or contested.

The BCM Steering Committee Charter

The charter is described in Move 4 above. It is reviewed annually and on any change to the committee's mandate, membership, or reporting line.

The Crisis Management Team Charter

The charter is described in Move 5 above. It is exercised at least annually (Clause 8.5) and reviewed after every activation.

The Reporting-to-Top-Management Package Specification

The specification defines the routine and escalation modes (Move 6). It is reviewed annually and on any change to the regulator-reporting landscape.

The Deputy and Succession Plan

The plan is described in Move 8 above. It is reviewed annually and on any role-holder change.

Risk Assessment and Treatment

The 5.3 implementation is itself subject to risk assessment and treatment under Clause 6.1. The BCM Manager assesses the risks to the role architecture and treats them. The standard risk catalogue for 5.3 implementations is below.

Risk R1, Key-person concentration. A single role holder is Accountable for an excessive number of BCMS activities; the role holder becomes the single point of failure. Likelihood: high in growing companies. Impact: high, the BCMS stalls if the role holder is unavailable. Treatment: enforce the one-Accountable-per-activity rule; redistribute accountabilities; develop deputies.

Risk R2, Deputy un-readiness. Deputies are named on paper but have never held the role in an exercise or a real incident. Likelihood: very high. Impact: high, when the primary is unavailable, the deputy cannot discharge the role. Treatment: schedule deputy exercises; track deputy-readiness as a KPI; build cross-training across the team.

Risk R3, Authority ambiguity. The authority matrix is silent on a decision that an incident requires (e.g. who can engage an external forensics firm at 3 am). Likelihood: high. Impact: medium to high, decision paralysis during the incident. Treatment: red-team the authority matrix against scenario libraries; add the missing decisions; pre-delegate with limits.

Risk R4, Reporting starvation of top management. The routine reporting package is late, incomplete, or not produced; the escalation mode is not triggered when it should be; top management learns of incidents from the media. Likelihood: medium to high. Impact: very high, regulator and reputational consequences. Treatment: automate the routine dashboard; pre-define escalation thresholds; test the escalation chain.

Risk R5, Role-holder competence gap. A role holder lacks the competence (knowledge, skill, experience) to discharge the role, for example, a non-technical Incident Commander who cannot interpret a recovery-time estimate. Likelihood: medium. Impact: medium to high, degraded response. Treatment: competence assessment under Clause 7.2; role-specific training; pairing of technical and business role holders.

Risk R6, Communication failure. The workforce does not know who holds the BCM roles; an employee with critical information during an incident cannot find the role holder. Likelihood: high. Impact: medium. Treatment: BCM org chart on the intranet; role-on-a-page cards; awareness programme; contact tree in the BC plan.

Risk R7, Lapsed role assignments. The role catalogue is out of date, a named role holder left the organisation six months ago and was never replaced in the catalogue. Likelihood: high. Impact: medium, confusion during activation. Treatment: calendar review of the catalogue; HR-trigger-based update on role-holder departure; spot-check at every BCM Steering Committee meeting.

Risk R8, Regulator-mandated role gaps. A regulator-mandated officer role (CISO, CERT-In PoC, DPO, nodal officer) is unfilled or is held by a person without the authority or access the role requires. Likelihood: medium. Impact: high, direct regulatory non-compliance. Treatment: track regulator-mandated role fill-rates as a KPI; report gaps to the BCM Steering Committee; escalate to top management.

Risk R9, Committee dysfunction. The BCM Steering Committee does not meet, does not have quorum, does not take minutes, or does not act on its decisions. Likelihood: medium to high. Impact: medium, governance theatre. Treatment: charter enforcement; minute-taking; decision-tracking; escalation to the Executive Sponsor.

Risk R10, Culture-of-one. The BCM is "the BCM Manager's job", top management is not engaged, the role architecture is not exercised, the reporting package is ignored. Likelihood: very high in growing companies. Impact: very high, the BCMS fails when it is needed. Treatment: visible Executive Sponsor engagement; management review (Clause 9.3) that actually reviews; corrective-action (Clause 10.1) that actually corrects.

Each risk has an owner (typically the BCM Manager), a treatment plan, a treatment deadline, and a residual-risk assessment. The risk register is reviewed at every BCM Steering Committee meeting and reported in the routine reporting package.

Audit and Compliance Checklist

The certification auditor (and the internal auditor under Clause 9.2) tests 5.3 through a combination of document review, interview, and observation. The checklist below has 28 questions covering the eight implementation moves, with the evidence expected and the red flags.

Document review, the artefacts

1. Is there a BCM role catalogue listing every BCM role? Expected evidence: the catalogue document. Red flag: no catalogue exists; only an org chart exists.
2. Does the catalogue name the individual holding each role? Expected evidence: catalogue with named individuals. Red flag: catalogue names job titles or departments only.
3. Does the catalogue list a deputy for every role? Expected evidence: catalogue with deputy column populated for every role. Red flag: deputies listed for senior roles only or for none.
4. Does the catalogue list a successor for senior roles? Expected evidence: catalogue with successor column populated for Incident Commander, BCM Manager, Response Team Leads. Red flag: no successor column at all (L1/L2 maturity).
5. Is there a BCM RACI matrix covering the BCMS activities of Clauses 4 through 10? Expected evidence: the RACI document. Red flag: no RACI; or a RACI with multiple A's per activity; or a RACI with no A's.
6. Is there an authority-and-decision-rights matrix? Expected evidence: the matrix document. Red flag: no matrix; or a matrix that does not cover the eight minimum decisions.
7. Is there a BCM Steering Committee charter? Expected evidence: the charter document with mandate, membership, cadence, decision rights, escalation, reporting. Red flag: no charter; or a charter that does not specify decision rights.
8. Is there a Crisis Management Team charter? Expected evidence: the charter document with activation triggers, command structure, comms protocol, stand-down. Red flag: no charter; or a charter without activation triggers.
9. Is there a reporting-to-top-management package specification? Expected evidence: the specification document with routine and escalation modes. Red flag: no specification; or a specification without escalation thresholds.
10. Is there a deputy and succession plan? Expected evidence: the plan document. Red flag: no plan; or a plan with no readiness-build programme.
11. Is there a BCM Roles, Responsibilities and Authorities Policy? Expected evidence: the policy, signed by the Executive Sponsor. Red flag: no policy; or a policy unsigned; or a policy with the standard's verbatim text reproduced.
12. Are the regulator-mandated officer roles (CISO, CERT-In PoC, DPO where applicable, nodal officer where applicable) named in the catalogue? Expected evidence: catalogue entries for these roles. Red flag: regulator-mandated roles absent from the catalogue or parallel-tracked outside it.

Interview, the role holders

13. Can the Executive Sponsor describe their accountability for the BCMS? Expected evidence: clear articulation. Red flag: "the BCM Manager handles all that".
14. Can the BCM Manager describe the eight implementation moves and the artefacts? Expected evidence: clear articulation. Red flag: "we have an org chart".
15. Can the Incident Commander describe the activation triggers and their authorities? Expected evidence: clear articulation, including emergency-spend limit and regulator-engagement authority. Red flag: confusion about who can declare an incident or activate the plan.
16. Can the CERT-In PoC describe the 6-hour reporting clock and the channels? Expected evidence: clear articulation. Red flag: "I think it is 24 hours".
17. Can the CISO describe their reporting line and the cyber-resilience authority delegated to them? Expected evidence: clear articulation. Red flag: reporting line unclear; no formal authority delegation.
18. Can a sample of Response Team Leads describe their deputy and the deputy's readiness? Expected evidence: clear articulation, including last exercise where deputy held the role. Red flag: "I have a deputy but they have not done it yet".
19. Can a sample of non-BCM employees name the Incident Commander and how to reach them? Expected evidence: a majority can. Red flag: fewer than half can; the role architecture is not communicated.

Observation, the evidence of operation

20. Has the BCM Steering Committee met on its defined cadence in the last 12 months? Expected evidence: minutes. Red flag: no minutes; or fewer meetings than the charter requires.
21. Has the CMT been activated (in a real incident or a simulation) in the last 12 months? Expected evidence: activation record; post-incident report. Red flag: no activations; CMT has never assembled.
22. Has the routine reporting package been produced on its defined cadence in the last 12 months? Expected evidence: dashboard history. Red flag: no dashboard; or gaps in the cadence.
23. Has the escalation reporting mode been triggered when it should have been? Expected evidence: escalation records correlated with incident records. Red flag: incidents occurred that crossed escalation thresholds but no escalation was triggered.
24. Has the deputy-readiness exercise been run in the last 12 months? Expected evidence: exercise report. Red flag: no such exercise.
25. Has the role catalogue been reviewed on calendar cadence and on event triggers? Expected evidence: review records. Red flag: catalogue is more than 12 months old; or event triggers occurred (reorganisation, role-holder departure) with no review.
26. Has the authority matrix been reviewed and updated in the last 12 months? Expected evidence: review record; version history. Red flag: matrix unchanged for years.
27. Are the role-holder acknowledgements on file? Expected evidence: signed acknowledgements. Red flag: no acknowledgements; or stale acknowledgements.
28. Has the internal audit (Clause 9.2) tested the role architecture independently? Expected evidence: internal audit report. Red flag: no audit; or audit that did not test 5.3.

Audit nonconformity patterns

The most common 5.3 nonconformities in the Indian small-and-growing-company segment are: (a) no authority matrix; (b) no deputy assignments; (c) no reporting cadence to top management; (d) lapsed role assignments; (e) regulator-mandated roles parallel-tracked outside the BCM role catalogue; (f) BCM Steering Committee that exists on paper but has not met; (g) CMT that has never been activated. Each of these is a major nonconformity at Stage 1 if it represents a systemic gap; each is a minor nonconformity if it is a gap in an otherwise conformant implementation.

Metrics and KPIs

The 5.3 KPI set covers process health, outcome health, and integration health. The fifteen KPIs below are the working set; the BCM Manager selects ten to twelve for the routine reporting package.

Process-health KPIs

KPI 1, Role-catalogue completeness. Percentage of BCM roles with a named primary, a named deputy, and (for senior roles) a named successor. Target: 100%. Cadence: monthly. Formula: (roles with named primary AND deputy AND successor where applicable) / (total roles in catalogue). This is the foundational 5.3 KPI.

KPI 2, Role-catalogue currency. Percentage of role assignments reviewed in the last 12 months. Target: 95%+. Cadence: monthly. Formula: (roles reviewed in last 12 months) / (total roles). Lapsed assignments are the most common audit finding.

KPI 3, RACI coverage. Percentage of BCMS activities (across Clauses 4 to 10) with exactly one Accountable owner in the RACI matrix. Target: 100%. Cadence: quarterly. Formula: (activities with exactly one A) / (total activities).

KPI 4, Authority-matrix coverage. Percentage of the eight minimum decisions (declare an incident, activate the BC plan, spend emergency funds, talk to the regulator, talk to media, evacuate or close a site, switch to manual fallback, stand down) with a named primary authority and a documented escalation path. Target: 100%. Cadence: quarterly.

KPI 5, BCM Steering Committee cadence adherence. Percentage of scheduled Committee meetings held with quorum and minutes. Target: 100%. Cadence: quarterly.

KPI 6, Reporting-package on-time delivery. Percentage of routine reporting packages delivered to top management on the defined cadence. Target: 100%. Cadence: matches the reporting cadence.

Outcome-health KPIs

KPI 7, CMT activation time. Time from incident declaration to CMT quorum. Target: under 30 minutes for severity-1 incidents. Cadence: per activation; reported in the routine package.

KPI 8, Deputy-readiness index. Percentage of deputies who have held the role in an exercise or real incident in the last 12 months. Target: 80%+. Cadence: half-yearly. This is the leading indicator of role-architecture resilience.

KPI 9, Workforce role awareness. Percentage of a sample of employees who can name the Incident Commander and how to reach them. Target: 75%+. Cadence: annual survey. This is the communication-effectiveness KPI.

KPI 10, Authority exercised without escalation ambiguity. Percentage of authority exercises (in real incidents or simulations) where the authority holder was correctly identified and engaged without ambiguity. Target: 95%+. Cadence: per activation; reviewed in post-incident report.

KPI 11, Top-management awareness of incidents. Percentage of incidents crossing escalation thresholds for which top management was informed within the defined target time. Target: 100%. Cadence: per incident; reported in the routine package. This KPI directly tests the reporting obligation.

Integration-health KPIs

KPI 12, Regulator-mandated role fill-rate. Percentage of regulator-mandated officer roles (CISO, CERT-In PoC, DPO where applicable, nodal officer where applicable) that are filled by a named, competent, authorised individual at the measurement date. Target: 100%. Cadence: monthly. This KPI is critical for regulated entities.

KPI 13, Regulator-reporting timeliness. Percentage of regulator reports (CERT-In 6-hour, DPDP 72-hour, RBI 2-to-6-hour, SEBI RE 6-hour, IRDAI per the clock) made within the deadline in the last 12 months. Target: 100%. Cadence: per report; reported in the routine package.

KPI 14, Role-holder competence certification. Percentage of role holders who have completed role-specific training and assessment. Target: 95%+. Cadence: half-yearly. This KPI integrates with Clause 7.2 competence.

KPI 15, Corrective-action closure on role-architecture findings. Percentage of internal-audit and exercise findings against the role architecture that are closed within the agreed deadline. Target: 90%+. Cadence: quarterly. This KPI integrates with Clause 10.1 corrective action.

Dashboard design

The reporting package dashboard typically presents the fifteen KPIs in three sections (process, outcome, integration) with trend arrows, target lines, and a narrative commentary. The BCM Manager produces the dashboard on the reporting cadence; the Executive Sponsor signs off; the BCM Steering Committee reviews; top management receives. A well-designed dashboard tells the story of the role architecture's health in one page.

Common Pitfalls and Audit Failures

The 5.3 implementation traps are well-known because they recur across the Indian small-and-growing-company segment. The ten most common pitfalls below are named, described, and paired with their characteristic audit failure.

Pitfall 1, "The BCM is my job." A single BCM Manager holds the entire role architecture in their head and laptop; top management has not engaged; the Steering Committee has not met; the reporting package is produced only when the auditor asks. Audit failure: major nonconformity on 5.1 (leadership), 5.3 (assignment), and 9.3 (management review) simultaneously.

Pitfall 2, "Org chart as RACI." The organisation produces a BCM org chart but no RACI matrix and no authority matrix. The auditor cannot tell which role is Accountable for which activity; the organisation cannot tell who has emergency-spend authority. Audit failure: major nonconformity on 5.3.

Pitfall 3, "Departments as role holders." The catalogue lists "IT" or "Operations" as the role holder; no named individual is identified. Audit failure: major nonconformity on 5.3. The standard requires roles to be assigned to people, not departments.

Pitfall 4, "Deputy in name only." Deputies are listed on paper but have never been exercised. Audit failure: typically a minor nonconformity on 5.3 with a finding under Clause 8.5 (exercises).

Pitfall 5, "Reporting that is a slide deck once a year." The reporting obligation is treated as a year-end presentation; no routine dashboard; no escalation mode. Audit failure: typically a major nonconformity on 5.3 read together with Clause 9.3.

Pitfall 6, "Regulator-mandated roles parallel-tracked." The CISO and CERT-In PoC exist in compliance artefacts but are not in the BCM role catalogue; the BCM Steering Committee does not include them; the reporting package does not cover them. Audit failure: typically a major nonconformity on 5.3 with regulatory non-compliance consequences.

Pitfall 7, "Steering Committee theatre." The Committee exists on paper but does not meet, or meets without quorum, or meets without minutes, or meets without decisions. Audit failure: minor to major nonconformity on 5.3 read together with Clause 9.3.

Pitfall 8, "Authority matrix not tested." The matrix exists but has never been exercised in a simulation; the first real incident surfaces decisions the matrix does not cover. Audit failure: typically a minor nonconformity on 5.3 with a finding under Clause 8.5.

Pitfall 9, "Catalogue is stale." The role catalogue is more than 12 months old; named individuals have left; reorganisations have not been reflected. Audit failure: typically a major nonconformity on 5.3.

Pitfall 10, "Verbatim standard text in the policy." The BC Roles Policy reproduces the standard's clause text verbatim, a copyright violation and an IP-and-sourcing failure, not a substantive 5.3 failure, but it triggers a rework cycle that delays certification. Treatment: paraphrase the standard's text; keep sample "shall" clauses of the organisation's own drafting.

Illustrative Scenario 1: Failure, Madhav Life Insurance (Illustrative)

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

Disclaimer: Madhav Life Insurance is a fictional Indian life insurer. The scenario is illustrative, drawn from patterns documented in the research base (HDFC RBI action 2020; Yes Bank moratorium 2020; AIIMS Delhi ransomware 2022; multiple IRDAI compliance failures). Any resemblance to a real insurer is coincidental.

The organisation

Madhav Life Insurance is a mid-sized Indian life insurer with annual premium income of approximately 4,200 crore rupees, 2,800 employees, and 7.5 million policyholders. The insurer holds an IRDAI registration and operates under the IRDAI Information and Cyber Security Guidelines (24 April 2023). Madhav's BCMS was certified to ISO 22301:2019 in 2023 with a clean Stage 2 audit. The certificate was, however, the high-water mark of the implementation.

The pre-incident state

Madhav's 5.3 implementation was a textbook Pitfall 1, Pitfall 5, and Pitfall 6 combined. The BCM Manager (Anil Verma, a capable but under-resourced former operations manager) held the role in a part-time capacity alongside his day job as Head of Policy Administration. The BCM Steering Committee had not met in nine months. The CISO (Sneha Patel) sat on the Steering Committee in principle but was not in the BCM role catalogue; she ran cyber in parallel. The CERT-In PoC was the Head of IT Operations, who had not been formally trained for the role and did not have a named deputy. The Incident Commander was the COO (Rajesh Nair), who had not been exercised in the role since certification. The authority matrix existed but did not cover the decision to engage an external forensics firm; the escalation thresholds for top-management notification were not defined.

The reporting package was produced annually as a slide deck for the board's Risk Committee. The most recent deck, eight months old, reported that all KPIs were green; in fact, the deputy-readiness KPI had never been measured, and the role-catalogue currency was 41 percent (the catalogue had not been refreshed since certification).

The incident

On 14 March, a Tuesday at 02:17 IST, Madhav's policy administration system began returning errors. By 04:00 the system was unresponsive; the on-call IT team identified ransomware. By 06:00 the IT Lead had escalated to the Head of IT Operations (the untrained CERT-In PoC), who escalated to the COO (the un-exercised Incident Commander) at 06:45.

The next eight hours exposed every gap in the 5.3 implementation. The Incident Commander did not have the authority to engage an external forensics firm; the matrix required Executive Sponsor approval; the Executive Sponsor (the CEO, Mira Kapoor) was in a board meeting until noon. The CERT-In 6-hour clock started at 02:17; the CERT-In PoC did not begin drafting the report until 09:00; the report was filed at 14:30, almost five hours late. The IRDAI clock and the policyholder-comm clock were not on anyone's agenda. The BCM Manager (Anil) arrived at the office at 08:30 to find the CMT assembling without a chair (the COO was on a call with the cyber-insurer's panel lawyer); the CMT lacked a scribe; the incident log was being kept on a whiteboard that was photographed and emailed intermittently.

The CISO (Sneha) was looped in at 10:00 by a phone call from a former colleague at another insurer who had seen chatter about Madhav on a dark-web monitoring feed. She had not been on the CMT distribution list.

By 18:00 the policy administration system was partially restored from backups; by 22 March (eight days later) it was fully restored. The post-incident review identified 14,000 policyholders whose personal data was exfiltrated; the DPDP 72-hour clock had been missed by six days.

The consequences

IRDAI issued a show-cause notice on 19 April; the insurer's cyber-insurer contested coverage on the basis of the late CERT-In and DPDP reports; the policyholder-comm delay produced a class-action complaint filed in the National Consumer Disputes Redressal Commission; the board's Risk Committee commissioned an independent review that produced a 96-page report cataloguing the 5.3 failure modes.

The ISO 22301 certificate survived the incident only because the surveillance audit was eight months away; the insurer used the window to remediate aggressively. The remediation included appointing a full-time BCM Manager (replacing Anil, who moved into a BIA role), restructuring the Steering Committee with the CISO as a voting member, redrawing the authority matrix with the eight minimum decisions plus the forensics-engagement decision, building the reporting dashboard, running a CMT simulation, and refreshing the role catalogue.

The total cost of the incident to Madhav, IRDAI penalty, cyber-insurer recovery gap, policyholder-comm remediation, legal fees, BCM remediation, and the lost management time, was estimated internally at 28 to 34 crore rupees, against a BCM annual budget of approximately 1.4 crore rupees.

Lessons for 5.3

The lessons map directly to the eight implementation moves. Move 1 (catalogue) had been done but not maintained. Move 3 (authority matrix) had not been red-teamed. Move 4 (Steering Committee) had atrophied. Move 5 (CMT) had not been exercised. Move 6 (reporting) had been treated as a year-end slide deck. Move 7 (communication) had not been refreshed. Move 8 (deputy and succession) had been done on paper only.

The single most-loadbearing lesson: a 5.3 implementation that exists for the certification audit but is not operated, exercised, refreshed, and reported is worse than no implementation, it creates a false confidence that the role architecture exists when in fact it does not. The Madhav failure was not a failure of intent; it was a failure of operation.

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

Disclaimer: Sahyadri Sahakari Bank is a fictional Indian urban cooperative bank. The scenario is illustrative, drawn from patterns documented in the research base (HDFC RBI action 2020; RBI Complete Cyber Security Framework for UCBs 2019; multiple UCB corrective-action programmes). Any resemblance to a real cooperative bank is coincidental.

The organisation

Sahyadri Sahakari Bank is a multi-branch urban cooperative bank in Maharashtra with total deposits of approximately 6,800 crore rupees, 1,400 employees, 42 branches, and a digital banking platform serving 1.1 million customers. The bank falls under the RBI Complete Cyber Security Framework for Primary (Urban) Cooperative Banks (31 December 2019) and the RBI Master Direction IT Governance (7 November 2023, effective 1 April 2024). Following a 2024 RBI inspection that flagged BCM weaknesses, the bank's board commissioned a 5.3-led BCMS rebuild.

The intervention

The BCM Manager (a senior operations manager, Sunita Kulkarni, who had been wearing the role part-time) was seconded full-time to lead the rebuild. Sunita ran the eight implementation moves over a 14-week programme.

Move 1 (catalogue) produced a 14-role BCM role architecture (eight minimum plus six regulator-mandated and UCB-specific roles). Move 2 (assignment) named the individuals and the deputies for every role, including a separate Incident Commander (the General Manager Operations, who was not the BCM Manager) and a separate BCM Steering Committee Chair (the CEO, distinct from the Sponsor who was the Chairman of the board). Move 3 (authority matrix) was red-teamed against a scenario library of 18 UCB-relevant scenarios; the red team identified three decisions the matrix did not cover (engaging the RBI relationship manager; activating the reciprocal-aid arrangement with a peer UCB; switching the ATM network to graceful-degraded mode) and they were added. Move 4 (Steering Committee charter) established monthly meetings with the CISO (a voting member), the DPO-equivalent (the bank's compliance lead for DPDP), and the Company Secretary. Move 5 (CMT charter) was exercised twice during the rebuild, a tabletop in week 8 and a simulation in week 13.

Move 6 (reporting package) was where the bank made its most consequential design choice. Sunita consolidated four reporting obligations, the board's IT governance oversight under the RBI MD, the Risk Committee's cyber resilience oversight under the RBI UCB framework, the Audit Committee's internal-financial-controls duty under Companies Act Section 177, and the Clause 9.3 management review under ISO 22301, into a single monthly dashboard. The dashboard carried fifteen KPIs (the set in Section 12 of this guide) plus the bank's RTO/RPO actuals, regulator-reporting timeliness, and deputy-readiness index. The same instrument went to four audiences with different cuts.

Move 7 (communication) produced a BCM org chart on the intranet, role-on-a-page cards for every branch manager, an induction module for new joiners, and a quarterly awareness refresh. Move 8 (deputy and succession) named deputies for every role and built a 12-month deputy-readiness programme that paired each deputy with their primary for an exercise within the year.

The total investment over the 14-week programme was approximately 22 lakh rupees, 9 lakh in external consultant support, 7 lakh in internal effort (Sunita's full-time secondment plus the BCM Steering Committee's time), 4 lakh in a lightweight GRC platform annual subscription, and 2 lakh in exercise costs (tabletop facilitation, simulation materials, branch-staff overtime).

The incident

On 11 November, a Monday at 11:08 IST, the bank's digital banking platform began returning 5xx errors. By 11:20 the platform was unresponsive. The IT Lead (the deputy CMT member for IT DR) declared an incident at 11:14 under the authority matrix. The Incident Commander (the GM Operations, in his first real activation) confirmed the declaration at 11:18 and activated the BC plan at 11:22.

The CMT assembled (in a virtual room) at 11:34, sixteen minutes from declaration, well inside the 30-minute target. The BCM Manager (Sunita) joined as advisory. The CISO joined with the IT DR lead's update. The Compliance Officer (also the CERT-In PoC's deputy) began drafting the CERT-In report at 11:40; the report was filed at 14:50, one hour and twenty-seven minutes inside the 6-hour clock from the 08:08 discovery window (the platform had been degrading since the previous night; the IT team reconstructed the timeline). The RBI relationship manager was briefed at 12:30 with the Incident Commander's authority. The customer-comm team published a status update at 11:45; updates followed every 30 minutes until stand-down.

The Executive Sponsor (the Chairman of the board) was briefed at 11:50, within the 30-minute escalation threshold. The board's Risk Committee Chair was briefed at 12:10. The CEO (Steering Committee Chair) chaired the midday CMT sync.

The platform was restored at 19:30 from the disaster-recovery site. The post-incident review (Clause 8.6) ran on 14 November; the corrective-action register (Clause 10.1) was updated; the BCM Steering Committee reviewed at its 25 November meeting; the December reporting package to top management included the incident, the response, the lessons, the corrective actions, and the KPI movements.

The ROI

The intervention cost 22 lakh rupees. The avoided costs over the following twelve months were substantial.

Regulator-fine avoidance. The RBI inspection in the following cycle produced a clean rating on BCM and IT governance, a meaningful improvement from the 2024 findings. Comparable UCB failures had drawn RBI penalties in the range of 50 lakh to 2 crore rupees in the prior 18 months; the clean rating avoided that exposure. Conservative value: 50 lakh rupees.

Cyber-insurance premium reduction. The bank's cyber-insurer, on renewal, reduced the premium by 18 percent on the strength of the documented BCM role architecture, the tested CMT, and the reporting package. The bank's annual cyber-insurance premium was approximately 55 lakh rupees; the reduction saved approximately 10 lakh rupees per year.

Stage 1-to-Stage 2 cycle ran to plan. The bank's parallel ISO 22301 recertification audit (it had been certified in 2022) cleared Stage 1 without majors on 5.3, avoiding the typical 8-to-16-week Stage 2 delay that follows a Stage 1 major. The avoided cost, consultant and internal-effort to remediate plus the value of the four-month earlier certification, was estimated internally at 12 lakh rupees.

Incident-response performance. The 11 November incident was handled with a 16-minute CMT activation time, a 1-hour-27-minute CERT-In margin, and a 19:30 restoration, all inside plan. The reputational consequence (measured by the bank's customer-satisfaction survey and its deposit retention) was negligible. Comparable UCB platform outages in the prior 24 months had produced double-digit deposit attrition in the affected customer segments; the avoided deposit attrition was estimated at 8 to 14 crore rupees of deposits, with a margin contribution of approximately 14 to 24 lakh rupees per year on a continuing basis.

Total quantified benefit over 12 months: 86 lakh to 1.04 crore rupees, against a 22 lakh rupee investment, a 4-to-5x return in the first year, with continuing benefits in subsequent years.

Lessons for 5.3

Sahyadri's success was not about the artefacts, every artefact the bank produced is producible by any BCM Manager with a weekend and a template. The success was about operating the role architecture: naming people, exercising them, reporting on cadence, refreshing after every change. The single most-loadbearing lesson: a 5.3 implementation that is operated produces compounding returns in regulator relations, insurance economics, audit-cycle efficiency, and incident-response performance. The artefacts are the price of entry; the operation is the value.

Multi-Framework Mapping

The 5.3 implementation maps cleanly to the corresponding requirements in every major BCM, ISMS, and operational-resilience framework. The crosswalk below uses real clause and article numbers from the cited instruments. The cells with a clause or article number are direct cross-references; the cells with a name only are methodological analogues.

ISO and adjacent management-system standards

NIST (US)

US financial-sector and supervisory

EU, DORA

UK, Civil Contingencies Act and Government Resilience Framework

Singapore, MAS TRM Guidelines

Australia, APRA CPS 230

Hong Kong, HKMA Supervisory Policy Manual

The integrated crosswalk

A 5.3-conformant role catalogue satisfies the corresponding requirement across every framework in this section. The integrated reporting package satisfies the board-oversight obligations of RBI MD IT Governance, SEBI CSCRF, IRDAI ICS, DORA Article 5, APRA CPS 230 paragraphs 20 to 23, the Companies Act Section 134(3)(n), and SEBI LODR Reg. 21. For an Indian growing company with multi-jurisdiction operations or multi-regulator exposure, the BCM Manager produces one role catalogue and one reporting package that satisfy all of them, the canonical efficiency gain of integrated management-system implementation.

Implementation Roadmap

The roadmap below is the practical sequenced plan for a first-cycle 5.3 implementation by a growing company (50 to 2,000 staff). It is built around the eight implementation moves and the toolkit documents.

Days 0 to 30, Foundation

Week 1 to 2. The Executive Sponsor names the BCM Manager (Move 1 partial) and charters the BCM rebuild programme. The BCM Manager reads the BCMS policy (Clause 5.2), the scope (Clause 4.3), the BIA outputs (Clause 8.2) if they exist, and any prior role assignments. The BCM Manager drafts the eight-role minimum catalogue using the BCM Role Descriptions toolkit document (toolkit 16).

Week 3 to 4. The Executive Sponsor and the BCM Manager run a half-day role-assignment workshop with the heads of IT, HR, Operations, Compliance, and Communications. The workshop assigns named individuals and deputies to each role (Move 2). The output is the first complete role catalogue.

Day 30 milestone. The role catalogue exists with named individuals and deputies. The Executive Sponsor has signed off. The catalogue is published on the intranet.

Days 31 to 60, Authority and governance

Week 5 to 6. The BCM Manager drafts the authority-and-decision-rights matrix (Move 3) using the eight minimum decisions plus any sector-specific decisions. The matrix is red-teamed with the Incident Commander and the Response Team Leads; missing decisions are added.

Week 7. The BCM Manager drafts the BCM Steering Committee charter (Move 4) and the Crisis Management Team charter (Move 5). The Executive Sponsor signs both. The first BCM Steering Committee meeting is scheduled.

Week 8. The first BCM Steering Committee meeting is held. The Committee reviews and approves the role catalogue, the authority matrix, and its own charter.

Day 60 milestone. The authority matrix, the Steering Committee charter, and the CMT charter exist. The Steering Committee has met. The CMT is constituted.

Days 61 to 120, Reporting and communication

Week 9 to 11. The BCM Manager designs the reporting-to-top-management package (Move 6) using the fifteen KPIs in Section 12 of this guide. The dashboard is built in the GRC platform or in a structured document. The first routine reporting package is produced for the next executive committee meeting.

Week 12 to 14. The BCM Manager builds the communication artefacts (Move 7): the BCM org chart on the intranet, the role-on-a-page cards, the contact tree, the induction briefing for role holders. Role-holder acknowledgements are captured.

Week 15 to 16. The BCM Manager and HR launch the deputy-readiness programme (Move 8). Each deputy is paired with their primary; the year's exercise schedule (Clause 8.5) is built around deputy exercise.

Day 120 milestone. The reporting package is in production. The role architecture is communicated. The deputy programme is running.

Days 121 to 180, Exercise and review

Week 17 to 22. The BCM Manager runs the first CMT tabletop exercise (Clause 8.5) using a scenario drawn from the organisation's BIA or risk register. The exercise tests the role architecture, the authority matrix, the CMT charter, the reporting escalation, and the deputies. The post-exercise report identifies gaps.

Week 23 to 24. The BCM Manager updates the role catalogue, the authority matrix, the CMT charter, and the reporting package on the exercise findings. The corrective-action log (Clause 10.1) is opened. The second BCM Steering Committee meeting reviews.

Week 25 to 26. The first routine reporting package that includes exercise results and corrective actions goes to top management. The internal audit (Clause 9.2) tests the role architecture independently.

Day 180 milestone. The role architecture has been exercised, reviewed, updated, and reported. The 5.3 implementation is operational, not just documented.

Beyond 180 days

The implementation continues as an operating cycle. The BCM Steering Committee meets on cadence. The CMT is exercised at least annually (Clause 8.5). The reporting package goes on cadence. The role catalogue is reviewed on calendar cadence and on event triggers (reorganisation, role-holder change, regulator change, audit nonconformity, major incident). The deputy-readiness programme builds progressively. The authority matrix is red-teamed annually. The CMT is activated in real incidents as they occur.

The Year-2 implementation typically deepens the role architecture (more Response Team Leads per business unit, site-level Incident Commanders for multi-site organisations, integration with the group CISO for enterprise implementations) and tightens the KPI set. Year-3 implementations focus on resilience (cross-training, succession depth, integration with enterprise risk management).

FAQ

Q1. Does Clause 5.3 require a BCM Steering Committee? No. ISO 22301 does not mandate a Steering Committee. The standard requires roles, responsibilities, and authorities to be assigned. Most well-formed Indian BCMSs have a Steering Committee because it is a practical way to oversee the BCMS between management reviews, but it is leading practice, not a standardised mandate. The BCM Steering Committee charter is in Move 4 of this guide.

Q2. Can the BCM Manager also be the Incident Commander? Yes, in smaller organisations it is common. In growing companies below 250 staff, the same person often holds both roles. In organisations above 250 staff, the roles typically separate because (a) the BCM Manager may need to be available as advisory during the response rather than as commander, and (b) separating the roles reduces key-person concentration. The Madhav illustrative scenario (Section 14) shows the failure mode when both roles are overloaded.

Q3. Do we need to have a separate Crisis Management Team from the BCM Steering Committee? In most cases, yes. The Steering Committee is the standing governance forum that oversees the BCMS between incidents; the CMT is the team that assembles during a disruption. Membership overlaps (the BCM Manager is on both; the Executive Sponsor is on both) but the mandates are different. Conflating them produces a Steering Committee that tries to command incidents and a CMT that tries to set strategy, both poorly.

Q4. What is the minimum number of BCM roles for a 50-person company? The eight-role minimum in Section 7 of this guide is practical for most growing companies. In a 50-person company, the same individuals will hold multiple roles (the Head of Operations may be both the BCM Manager and the Incident Commander; the Head of People may be both the People-and-Facilities Lead and the Supplier-Coordination Lead). The role catalogue makes the dual-hat assignments explicit.

Q5. How often should the role catalogue be reviewed? At least annually on a calendar cadence, and on event triggers, reorganisation, role-holder departure, role-holder appointment, regulator change, audit nonconformity, major incident, post-exercise finding. Lapsed role assignments are the most common 5.3 audit finding.

Q6. Does the CISO have to report to the BCM Manager? No. The CISO and the BCM Manager are typically peers; both report into the executive layer. The integration is through the BCM Steering Committee (where the CISO is a voting member) and through the reporting package (which the BCM Manager assembles and the CISO contributes to). For RBI-regulated banks, the RBI MD IT Governance (7 November 2023) requires the CISO to have direct access to the board / board committee; this is independent of the BCM reporting line.

Q7. Do we need to run a CMT exercise every year? Yes, under Clause 8.5, the exercise programme must exercise the BCMS at planned intervals. The CMT activation is a 5.3 load-bearing artefact; an unexercised CMT is a combined 5.3 / 8.5 audit finding. For SEBI MIIs (under SEBI BCP-DR circular 22 March 2021) and for RBI-regulated banks, the cadence is regulator-defined.

Q8. How do we handle the CERT-In Point of Contact role? The CERT-In PoC is a regulator-mandated BCM role under CERT-In Directions (28 April 2022). The PoC must be named, must have a deputy, must have the authority to make the 6-hour report, and must be reachable to CERT-In on the channels CERT-In specifies. The PoC sits in the BCM role catalogue (not parallel-tracked) and is part of the CMT for cyber incidents. The PoC must keep the 180-day log retention and the NTP-clock-sync obligations in scope.

Q9. Does our DPDP Data Protection Officer sit in the BCM role catalogue? For Significant Data Fiduciaries under the DPDP Act 2023, the DPO is a regulator-mandated role that should sit in the BCM role catalogue. The DPO coordinates with the BCM Manager because every personal-data breach is a continuity event (Section 8(5) availability), a breach-notification event (Section 8(6)), and an individual-rights event. For non-SDF Data Fiduciaries, a DPO is not mandated, but the breach-notification obligation under Section 8(6) still requires a named role holder, often the CISO or the Compliance Officer.

Q10. Can we use consultants for the BCM Manager role? Consultants can support the BCM Manager as Responsible parties, drafting the artefacts, facilitating the exercises, preparing the reporting package. They cannot be Accountable. The BCM Manager accountability must sit with an organisation person because the standard requires the organisation to own its BCMS. A common arrangement is an internal BCM Manager supported by an external consultant for the first cycle.

Q11. How do we demonstrate to an auditor that the role architecture is operated, not just documented? Four evidence types: (a) Steering Committee minutes showing the role architecture was reviewed; (b) exercise reports showing the role holders were tested; (c) the reporting package history showing the role architecture was reported on cadence; (d) the role catalogue version history showing the role architecture was refreshed. A 5.3 audit is not just about the artefacts; it is about the evidence of operation.

Q12. Does our board need to approve the role catalogue? For SEBI LODR Reg. 21 listed entities, the Risk Management Committee must oversee continuity risk; the role catalogue is typically noted at the RMC. For RBI-regulated banks, the board's IT or Risk committee notes the catalogue. For IRDAI-regulated insurers, the board's Risk or IT committee notes the catalogue. For most growing companies, the CEO/MD noting suffices. The audit-relevant test is that top management has engaged with the catalogue, not the specific forum.

Q13. What if our organisation restructures during the year? A reorganisation is an event trigger for role-catalogue review. The BCM Manager refreshes the catalogue within 30 days of the reorganisation, re-confirms role-holder acknowledgements, updates the authority matrix, and reports the change to the next BCM Steering Committee meeting. Lapsed catalogue = a major 5.3 finding.

Q14. Should BCM role performance be linked to variable pay? Pay linkage is a leading-practice signal of L4 to L5 maturity, not a standard requirement. Some Indian regulated entities (banks, insurers) do link BCM role performance to variable pay for senior role holders. For growing companies, the typical starting point is to include BCM role responsibilities in the role-holder's job description and performance review, without a separate variable-pay component.

Q15. How does 5.3 relate to Clause 7.2 (Competence)? 5.3 assigns the roles; 7.2 ensures the people in the roles are competent. The two clauses are operationally inseparable, a role assigned to an incompetent person is a 5.3-and-7.2 combined failure. The role descriptions (toolkit 16) include the competence requirements; the BCM Manager and HR jointly maintain the competence assessment; the reporting package includes the role-holder competence certification KPI.

Industry-Specific Requirements

The 5.3 implementation adapts to the industry. The five sectors below cover most Indian implementations.

Banking, financial services, and insurance (BFSI)

The most regulator-heavy implementation. The role catalogue integrates the CISO (RBI Cyber Security Framework 2 June 2016 for banks; SEBI CSCRF 20 August 2024 for REs; IRDAI ICS 24 April 2023 for insurers), the CERT-In PoC, the DPDP DPO for Significant Data Fiduciaries, the SEBI nodal officer for REs, the Compliance Officer, and, for banks, the Treasurer (for liquidity continuity), the Head of Customer Operations (for depositor / policyholder / investor communication), and the Head of Branch Banking (for branch-network continuity). The BCM Steering Committee includes the CISO as a voting member and is noted by the board's IT or Risk committee. The reporting package satisfies RBI MD IT Governance, SEBI CSCRF, IRDAI ICS, the Companies Act Section 134(3)(n), and Clause 9.3 in one instrument. The authority matrix pre-delegates the power to invoke the CCMP, to make the 6-hour CERT-In report, to engage the RBI / SEBI / IRDAI relationship manager, and to activate the inter-bank liquidity continuity arrangements.

For UCBs (urban cooperative banks), the RBI Complete Cyber Security Framework (31 December 2019) sets a graded role expectation; smaller UCBs have a lighter control set, larger UCBs approach SCB parity. The Sahyadri illustrative scenario (Section 15) is illustrative for the UCB segment.

For payment system operators, the RBI Cyber Resilience and Digital Payment Security Controls Master Direction adds the PSO-specific roles, the Information Security Officer, the Head of Operations for the payment switch, the Fraud Risk Officer.

Healthcare

The role catalogue integrates the Medical Superintendent or Clinical Lead (because continuity decisions in a hospital are clinical decisions, the AIIMS Delhi ransomware 23 November 2022 taught the sector that an IT outage is a patient-safety event). The CMT includes the Medical Superintendent, the Nursing Supervisor, the Head of Facilities (for power, oxygen, water continuity), the IT Head, the Head of Pharmacy, the Head of Medical Records, and the Head of Patient Safety. The authority matrix pre-delegates the power to switch to paper-based clinical workflows, to divert patients to peer hospitals, to engage the District Health Authority, and to invoke the mutual-aid arrangements with neighbouring facilities. The reporting package includes clinical-impact metrics (diverted patients, delayed procedures, length-of-stay outliers), not just IT metrics.

For hospitals under the Clinical Establishments Act and state-level regulations, the role catalogue also names the Nodal Medical Officer and the Public Relations Officer for regulator engagement. The DPDP overlay is significant because health data is sensitive personal data under DPDP; the DPO-equivalent coordinates closely with the BCM Manager.

IT / ITeS and SaaS

The role catalogue integrates the Head of Site Operations for each delivery site (because Chennai 2015 taught the sector that site access disruption is the dominant scenario, Cognizant's reaffirmation of FY2015 guidance of at least 12.41 billion US dollars after invoking its BCP is the textbook success). The CMT includes the Head of Customer Success (because customer communication during a SaaS outage is the dominant reputational risk), the Head of Engineering (because manual fallback and degraded-mode operation require engineering authority), and the Head of People (because employee safety and work-from-anywhere activation are first-class continuity actions). The authority matrix pre-delegates the power to declare a major incident under DORA Article 19 (for firms serving EU financial-sector customers), to invoke the status-page communication, to engage the customer's incident-response lead, and to switch the production stack to degraded-mode operation.

For SaaS firms, the customer-comm Lead role is regulator-grade in importance, the SEBI CSCRF 6-hour clock, the DORA incident-notification clock, and the customer SLA penalties all converge on this role. For BPO / ITeS firms, the role catalogue includes the Voice Network Lead (because voice continuity is the product) and the Customer-Delivery Lead (because delivery continuity drives revenue continuity).

Manufacturing

The role catalogue integrates the Plant Manager for each site, the Head of Environment, Health and Safety (because industrial-continuity decisions are safety decisions, the LG Polymers Vizag styrene gas leak on 7 May 2020, with the NGT interim penalty of 50 crore rupees, taught the sector that an unmanaged process upset can kill), the Head of Supply Chain (because raw-material and component continuity drives production continuity, Go First's 2 May 2023 insolvency blamed on Pratt and Whitney PW1100G engine failures is the textbook supply-chain-driven continuity failure), and the Head of Maintenance (because asset availability is the business).

For chemical and Major Accident Hazard (MAH) units, the NDMA Guidelines on Chemical Disasters (2007) require named on-site and off-site emergency plan role holders; these must be integrated with the BCM role architecture, not parallel-tracked. The authority matrix pre-delegates the power to evacuate, to shut down a process, to engage mutual-aid partners, and to communicate with the District Disaster Management Authority. The CMT includes the District Magistrate's liaison for off-site emergency response.

For automotive and discrete manufacturing, the role catalogue includes the Head of Supplier Quality (because a single sub-tier supplier disruption can stop a line, the semiconductor shortages of 2021 to 2023 taught the sector that supplier-role coordination is BCM work). For pharma manufacturing, the role catalogue includes the Qualified Person for batch release (because continuity of batch release is a regulator-grade requirement, Sun Pharmaceutical's 2023 ransomware disclosure of revenue-hit risk is the textbook case).

Government and public sector

The role catalogue aligns with the NDMA Disaster Management Plan template (Prevention / Mitigation / Preparedness / Response / Relief / Recovery / Capacity Building). The CMT integrates with the District / State Disaster Management Authority structure; the Incident Commander role is the operational interface with the DDMA. For Critical Information Infrastructure operators (under IT Act 2000 Section 70A and NCIIPC), the role catalogue includes the NCIIPC liaison. The reporting package satisfies the Ministry / Department accountability structure under DM Act Section 35 and 37; the authority matrix respects the Section 51 to 60 penalty structure of the DM Act.

For Central and State PSUs, the role catalogue is typically integrated with the enterprise risk management framework under the Department of Public Enterprises guidelines. For municipal and urban-local-body implementations, the role catalogue integrates with the City Emergency Operations Centre.

Maturity Model

The 5.3 maturity model has five levels. Each level is described with the artefacts present, the operating behaviour, and an indicative Indian rupee investment range for a mid-market (250 to 2,000 staff) organisation.

Level 1, Ad-hoc / compliance-only

Artefacts. A BCM org chart that names departments instead of people. No RACI matrix. No authority matrix. No Steering Committee charter. No CMT charter. No reporting package. No deputy or succession plan. The BCM role is "the BCM Manager's job".

Operating behaviour. The BCMS is operated by one person; top management is not engaged; the Steering Committee does not exist or does not meet; incidents are responded to ad-hoc; reporting to top management is a year-end slide deck if it happens at all.

Investment range. Less than 1 lakh rupees per year. The investment is the BCM Manager's part-time effort and a productivity-suite folder of documents.

Audit outcome. Major nonconformity on 5.3 at Stage 1. Most growing companies in the Indian small-and-growing-company segment are at L1 when they start their ISO 22301 programme.

Level 2, Reactive / partial

Artefacts. A role catalogue that names individuals for senior roles but not for operational roles. A partial RACI matrix covering some clauses. An authority matrix that covers some decisions. A Steering Committee that meets irregularly. A CMT that has been activated at least once but not exercised. A reporting package produced for the certification audit but not on cadence.

Operating behaviour. The BCM Manager produces the artefacts when asked (for the audit, for the regulator, for the customer questionnaire); the artefacts are not operated between asks. Top management engages around audits and incidents.

Investment range. 1 to 3 lakh rupees per year for a mid-market (250 to 2,000 staff) firm, mostly in BCM Manager time and external consultant support for audit cycles.

Audit outcome. Typically passes Stage 1 with minors; produces majors at Stage 2 in the absence of evidence of operation. Most Indian mid-market (250 to 2,000 staff) firms plateau at L2.

Level 3, Managed

Artefacts. The full role catalogue with named individuals and deputies for every role. A complete RACI matrix across Clauses 4 to 10. The authority matrix covering the eight minimum decisions. A chartered Steering Committee meeting monthly. A chartered CMT exercised at least annually. A monthly routine reporting package and a defined escalation mode. A deputy-readiness programme.

Operating behaviour. The BCM Manager produces the reporting package on cadence. The Steering Committee meets and decides. The CMT is exercised annually. The role catalogue is refreshed on calendar and event triggers. Top management receives the package and engages.

Investment range. 5 to 12 lakh rupees per year for a mid-market (250 to 2,000 staff) firm, BCM Manager full-time or near-full-time, external consultant support for exercises, lightweight GRC platform subscription, training costs.

Audit outcome. Passes Stage 1 and Stage 2 cleanly. The certification is sustained through surveillance audits. This is the target maturity for most growing companies in regulated or customer-sensitive segments.

Level 4, Integrated

Artefacts. L3 artefacts plus: the role catalogue integrated with the GRC platform (machine-enforced role-based access, approval workflows); the authority matrix integrated with the incident-management platform; the reporting package as a real-time dashboard; the deputy-readiness programme with tracked KPIs; the regulator-mandated officer roles fully integrated (CISO, CERT-In PoC, DPO, nodal officer); the role architecture integrated with ISO 27001 (and ISO 9001 where applicable) sharing appointments.

Operating behaviour. The role architecture is operated as a system, not as a set of documents. The GRC platform enforces the role-based approvals. The CMT has been activated in a real incident in the last 12 months and the lessons are folded back into the role descriptions. Top management receives real-time dashboards. The deputy-readiness index is above 80 percent.

Investment range. 15 to 30 lakh rupees per year for a mid-market (250 to 2,000 staff) firm, full GRC platform, dedicated BCM Manager plus BCM analyst, regular exercise programme, integration with HR for succession planning.

Audit outcome. Passes Stage 1 and Stage 2 with no majors; surveillance audits produce opportunities-for-improvement rather than nonconformities. Typical maturity for regulated mid-market (250 to 2,000 staff) banks, insurers, and large SaaS firms.

Level 5, Optimised

Artefacts. L4 artefacts plus: the role architecture continuously improved through data-driven analysis (deputy-readiness analytics, succession-pipeline depth, authority-matrix red-team against scenario library); the reporting package integrated with enterprise risk management and with operational resilience programmes (UK FCA / PRA / CB operational-resilience model where applicable; APRA CPS 230 important-business-services tolerance model where applicable); cross-training across roles at scale; variable-pay linkage for senior BCM role holders.

Operating behaviour. The role architecture is a strategic asset. Top management uses the BCM reporting package as a primary input to strategic risk decisions. The CMT is exercised in multi-entity, multi-jurisdiction simulations. The role catalogue is integrated with the group HR system for enterprise-wide succession. Deputy readiness exceeds 90 percent. The corrective-action closure rate on role-architecture findings exceeds 90 percent.

Investment range. 30 to 60 lakh rupees per year for an enterprise implementation, typically multi-entity, multi-jurisdiction, with a group BCM function and BU coordinators.

Audit outcome. The organisation is regularly cited as a reference implementation by its certification body and its regulators. Typical maturity for large Indian banks, global Indian IT services firms, and major pharmaceutical manufacturers.

Maturity advancement

L1 to L2 is a documentation investment, produce the artefacts. L2 to L3 is an operating-model investment, operate the artefacts on cadence. L3 to L4 is a tooling and integration investment, machine-enforce the role architecture. L4 to L5 is a strategic-positioning investment, treat the role architecture as a strategic asset. Each transition is a 6-to-18-month programme; the BCM Manager and the Executive Sponsor co-own the transition.

Emerging Trends

The 5.3 implementation is evolving in response to four trends that BCM Managers in Indian growing companies should track.

Regulator convergence on operational resilience

The RBI, SEBI, and IRDAI are converging on an operational-resilience framing that goes beyond traditional BCM, Important Business Service identification, impact tolerance setting, severe-but-plausible scenario testing, and explicit board accountability. The SEBI CSCRF (20 August 2024) and the RBI MD IT Governance (7 November 2023) are the Indian expressions of the same global trend visible in the UK FCA / PRA / CB operational-resilience policy, the HKMA OR-2 module, the MAS Guidelines on Business Continuity Management, and APRA CPS 230 (effective 1 July 2025). For 5.3, the trend means the role architecture is increasingly expected to support tolerance-setting, scenario-testing, and board-reporting at a depth that goes beyond traditional BCM. BCM Managers should expect to extend the reporting package and the CMT exercise programme to cover tolerance-breaches (not just recovery times).

Climate-change adaptation in the role architecture

ISO 22301:2019 Amendment 1:2024 introduces climate-change adaptation into Clause 4.1 (context). For 5.3, the implication is that the role catalogue should include climate-related continuity roles, typically integrated into the People-and-Facilities Lead and the Site Operations Lead roles, with named deputies for site-evacuation scenarios driven by heatwave, flooding, cyclone, or air-quality events. The 2015 Chennai floods and the 2018 Kerala floods (which shut Cochin airport for approximately two weeks with an income loss of approximately 250 crore rupees) are the Indian precedent; the role architecture should accommodate similar events.

DORA and the ICT third-party overlay

DORA (Regulation (EU) 2022/2554, applicable from 17 January 2025) imposes specific role and authority requirements on the ICT third-party service providers that serve EU financial-sector customers, many of which are Indian IT and BPO firms. For 5.3, the implication is that Indian firms serving EU financial-sector customers should expect their role catalogue, their authority matrix, and their incident-reporting workflow to be examined by EU financial-sector customers as part of their DORA compliance. The integration point is the Supplier Coordination Lead role and the ICT-third-party-incident notification workflow.

Generative AI in the BCM role architecture

Generative AI is starting to play a role in the BCM function, drafting role descriptions, summarising incident logs, generating exercise scenarios, surfacing authority-matrix gaps, building reporting-package drafts. The 5.3 implication is twofold. First, AI can amplify the BCM Manager's capacity, particularly in L1-to-L2 and L2-to-L3 maturity advancement where the artefacts are being built. Second, AI cannot be Accountable, the cardinal rule of one-Accountable-per-activity is preserved; AI is a Responsible party supporting the human Accountable. BCM Managers should develop policies on AI use in the BCM function, including data-handling, model-choice, and human-review obligations, and should reflect AI-assisted activities in the RACI matrix.

References and Further Reading

The standard and companion guidance

• ISO 22301:2019, Security and resilience, Business continuity management systems, Requirements (ISO/TC 292). International Organization for Standardization.
• ISO 22301:2019/Amd 1:2024, Climate change adaptation integration.
• ISO 22313:2020, Guidance on the use of ISO 22301.
• ISO 22300:2021, Security and resilience, Vocabulary (3rd edition; verify whether a 2025 edition has published).
• ISO/TS 22317:2021, Guidelines for business impact analysis (2nd edition; 2015 edition withdrawn).
• ISO/TS 22318:2021, Guidelines for supply chain continuity (2nd edition; 2015 edition withdrawn).
• ISO/TS 22330, Guidelines for people aspects of business continuity.
• ISO/TS 22331:2018, Guidelines for business continuity strategy.
• ISO 22316:2017, Guidelines for organizational resilience.
• ISO/IEC 27001:2022, Information security management systems, Requirements (Clause 5.3).

Indian regulatory instruments (verified citations)

• Reserve Bank of India, Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (7 November 2023; effective 1 April 2024). RBI portal.
• Reserve Bank of India, Cyber Security Framework in Banks (2 June 2016). RBI portal.
• Reserve Bank of India, Complete Cyber Security Framework for Primary (Urban) Cooperative Banks, A Graded Approach (31 December 2019). RBI portal.
• Reserve Bank of India, Master Directions on Outsourcing of Information Technology Services (10 April 2023). RBI portal.
• Securities and Exchange Board of India, Cybersecurity and Cyber Resilience Framework for SEBI Regulated Entities (SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024). SEBI portal.
• Securities and Exchange Board of India, Guidelines for Business Continuity Plan and Disaster Recovery of Market Infrastructure Institutions (SEBI/HO/MRD1/DTCS/CIR/P/2021/33, 22 March 2021). SEBI portal.
• Insurance Regulatory and Development Authority of India, Information and Cyber Security Guidelines, 2023 (24 April 2023). IRDAI portal.
• Indian Computer Emergency Response Team, Directions under Section 70B(6) of the IT Act, 2000 (No. 20(3)/2022-CERT-In, 28 April 2022). CERT-In portal.
• Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023, enacted 11 August 2023). MeitY.
• Digital Personal Data Protection Rules, 2025 (draft 3 January 2025; final notification November 2025, confirm exact date against the MeitY gazette). MeitY.
• Disaster Management Act, 2005 (Act No. 53 of 2005, enacted 23 December 2005). NDMA portal.
• National Disaster Management Guidelines, Chemical Disasters (Industrial), 2007. NDMA portal.
• National Disaster Management Guidelines, Preparation of Disaster Management Plans (2014). NDMA portal.
• Companies Act, 2013, Sections 134(3)(n) and 177 (Act No. 18 of 2013). Ministry of Corporate Affairs.
• SEBI Listing Obligations and Disclosure Requirements (LODR) Regulations, 2015, Regulation 21 (Risk Management Committee). SEBI portal.
• Information Technology Act, 2000, Sections 43, 65, 66, 70, 70A, 70B, 72, 84A (Act No. 21 of 2000, as amended 2008). Indian Code portal.

Global frameworks and supervisory instruments

• NIST Special Publication 800-34 Rev 1, Contingency Planning Guide for Federal Information Systems (May 2010, updated 11/11/2010). NIST CSRC.
• NIST Cybersecurity Framework 2.0 (NIST.CSWP.29, 26 February 2024). NIST.
• NIST Special Publication 800-160 Vol 1 (November 2016) and Vol 2 Rev 1 (September 2021). NIST CSRC.
• FFIEC IT Examination Handbook, Business Continuity Management Booklet (November 2019). FFIEC; issued via OCC Bulletin 2019-57, Federal Reserve SR 19-13, FDIC FIL-19071-2019.
• Regulation (EU) 2022/2554, Digital Operational Resilience Act (DORA), OJ L 333, 27.12.2022, p. 1; applicable from 17 January 2025 (Article 64). EUR-Lex.
• Civil Contingencies Act 2004, c.36 (UK). legislation.gov.uk.
• UK Government Resilience Framework (December 2022). GOV.UK.
• Monetary Authority of Singapore, Technology Risk Management Guidelines (18 January 2021). MAS.
• Monetary Authority of Singapore, Guidelines on Business Continuity Management. MAS.
• Australian Prudential Regulation Authority, Prudential Standard CPS 230 Operational Risk Management (effective 1 July 2025). APRA; CPG 230 companion guidance.
• Hong Kong Monetary Authority, Supervisory Policy Manual TM-G-2 Business Continuity Planning (31 May 2022) and OR-2 Operational Resilience (31 May 2022). HKMA.

Incident and case anchors cited

• AIIMS Delhi ransomware (23 November 2022), peer-reviewed case in the Indian Journal of Internal Medicine; reporting in The Hindu.
• HDFC Bank repeated digital outages and RBI action (2018 to 2020; RBI ban 2 December 2020; partial lift August 2021; full lift March 2022), reporting in Livemint, Finextra; RBI order.
• Yes Bank RBI moratorium (5 to 18 March 2020), peer-reviewed case in the Yale Journal of Financial Commons; RBI order.
• Cognizant Maze ransomware (18 to 20 April 2020; SEC 10-Q/K disclosure of 50 to 70 million US dollars Q2 2020 impact), SEC filings.
• Cognizant Chennai 2015 flood response (Cognizant official statement reaffirming FY2015 revenue guidance of at least 12.41 billion US dollars), Cognizant newsroom.
• LG Polymers Visakhapatnam styrene gas leak (7 May 2020; NGT interim penalty 50 crore rupees under OA 73/2020; LG Chem relief package 730 crore rupees), National Green Tribunal; The Hindu; AIChE illustrative scenario.
• Sun Pharmaceutical ransomware (2023; revenue-hit and litigation-risk disclosure), Sun Pharma regulatory filing.
• Go First insolvency (filed 2 May 2023; refund liability 597 crore rupees to approximately 1.55 million passengers as of 31 July 2023 disclosure; Pratt and Whitney PW1100G engine failures cited), NCLT filings; Reuters; The Hindu.
• SpiceJet DGCA enhanced surveillance and 50 percent schedule cap (27 July 2022; extended to 29 October 2022), DGCA order; India Today; The Hindu.
• Jio data-centre fire and nationwide outage (17 September 2024; Cloudflare Radar measured Jio AS55836 traffic down up to 53 percent), Reuters; Cloudflare.
• Cochin International Airport Limited shut approximately two weeks during the 2018 Kerala floods; income loss approximately 250 crore rupees, CIAL disclosure; SDMA Kerala.
• IndiGo CrowdStrike-related outage (19 July 2024; 283 flights cancelled) versus Akasa Air zero-cancellation response, The Hindu.
• Cognizant-Chennai 2015 success contrast with CIAL-Kerala 2018 infrastructure failure.

The references list comprises the standards, regulations, and primary-source incident anchors used in this guide. The guide does not reproduce any copyrighted standard text; all standard requirements are paraphrased and attributed to "ISO 22301 Clause 5.3 asks organizations to …". The reference books used as inspiration during research are not named in this output, per the IP-and-sourcing rules that govern this series.