ISO 22301 Clause 8.6: Evaluation of Business Continuity Documentation and Capabilities

Quick Reference (60 Seconds)

The single sentence to remember: documentation and capabilities decay the moment they are written, Clause 8.6 is the discipline that keeps them honest. A BIA that was correct in January is wrong by July if the organisation has launched a new product, migrated a workload to a new cloud region, lost a key recovery engineer, or been acquired. Clause 8.6 is the clause that catches that decay before a disruption does, and the clause that turns every real outage into a learning loop rather than a recurring failure.

What the Standard Actually Requires

Figure · Process

What Clause 8.6 asks you to do

ISO 22301 Clause 8.6 asks organizations to evaluate whether the continuity documentation and capabilities remain suitable, adequate, and effective, especially after disruptions and significant change. In practical terms, the clause requires an organisation to develop a disciplined habit of looking at its own BC arrangements, the BIA, the risk assessment, the strategies, the plans, the procedures, the people, the facilities, the technology, the supplier relationships, and asking, with evidence, whether they still match reality and still work.

What the clause requires in substance

Read alongside ISO 22313:2020 (the companion guidance) and ISO 22300:2021 (vocabulary), the requirement breaks into seven interlocking obligations:

1. Evaluation of documentation. The organisation must periodically and triggered-ly evaluate every piece of BC documented information produced under Clauses 8.2 through 8.5, the BIA, the risk assessment, the continuity strategies, the response structure, the plans and procedures, the exercise programme, the contact trees, the communications matrices, the RTO/RPO/MBCO values, the supplier inventory. "Evaluate" here means a structured judgement against three criteria: is it suitable (does it address the right problem?), is it adequate (is it sufficient in scope and depth?), and is it effective (does it actually produce the intended outcome when used?).

2. Evaluation of capabilities. Documentation is necessary but not sufficient. The organisation must also evaluate the capabilities that the documentation assumes, the people who must execute the plans (are they still in role? trained? aware?), the facilities the plans rely on (alternate work sites, DR sites, crisis rooms, still available, still fit for purpose?), the technology (replication links, backup systems, failover mechanisms, still working, still meeting RTO/RPO?), and the suppliers (still contracted? still meeting their own BC SLAs? still solvent?).

3. Scheduled evaluation. A defined, recurring cadence, typically annual for full documentation review, quarterly for contact-list and critical-capability currency, and after every exercise (Clause 8.5) for the plans that were exercised. The cadence must be risk-based: tier-1 prioritised activities (per the BIA) warrant more frequent evaluation than tier-3 activities.

4. Triggered evaluation after disruptions. This is the clause's signature requirement. After any real disruption that invoked BC arrangements, or a near-miss that should have, the organisation must conduct a post-incident review (PIR): reconstruct the timeline, identify what worked and what failed, determine root causes, capture lessons, and translate them into corrective actions under Clause 10.1. The PIR is not optional; it is the mechanism by which a disruption becomes a learning event rather than a recurring failure.

5. Triggered evaluation after significant change. The organisation must evaluate its BC documentation and capabilities whenever a significant change occurs that could render them obsolete. Significant changes include: mergers, acquisitions, divestitures, or major restructures; new products, services, or markets; new or decommissioned technology platforms; site openings or closures; new or changed regulation (e.g., DPDP Rules taking effect, DORA applying to an EU-serving entity, SEBI CSCRF reclassifying the firm); major threat-landscape shifts (a new ransomware strain, a geopolitical event, a supply-chain compromise in a vendor the firm uses); key-person departures; and findings from exercises or audits that invalidate assumptions.

6. Outputs that feed improvement. Evaluation findings are not filed and forgotten. They must flow into Clause 10.1 (corrective action) for nonconformities, Clause 10.2 (continual improvement) for opportunities, and Clause 9.3 (management review) for the top-management lens. The closed loop, evaluate, find, correct, re-evaluate, is the heart of the BCMS PDCA cycle.

7. Evidence of evaluation. The organisation must retain documented evidence that evaluations were conducted, who conducted them, what was found, and what was done about it. This evidence, evaluation reports, PIR reports, change-triggered review logs, corrective-action tickets, is what a certification auditor and a regulator will request.

What the clause does NOT require

This demarcation matters because over-scoping an evaluation programme burns money and creates bureaucratic drag:

• It does not require a full re-BIA on every cycle. A scheduled evaluation may confirm that the existing BIA remains valid; a triggered evaluation after significant change may require a targeted re-BIA of only the affected activities. The clause asks for a judgement about suitability, adequacy, and effectiveness, not a mandatory re-do.
• It does not require the evaluation to be performed by an independent party. Internal audit (Clause 9.2) is the independent function; Clause 8.6 evaluation is an operational management activity, typically led by the BCM with activity owners. Independence is valuable for PIRs of major incidents but is not a clause requirement.
• It does not require every plan to be evaluated on the same cadence. A risk-based, tiered cadence, tier-1 activities quarterly, tier-2 semi-annually, tier-3 annually, is both compliant and pragmatic.
• It does not require a specific evaluation methodology. ISO 22313:2020 gives structural guidance; the organisation chooses the method (checklist-driven review, peer review, facilitated PIR workshop, technical capability test). What matters is that the evaluation is structured, evidence-based, and recorded.
• It does not require evaluations to find that everything is fine. A well-conducted evaluation that surfaces a broken capability is a successful evaluation; the nonconformity arises only if the finding is not corrected (Clause 10.1).

What auditors actually check

A certification auditor (and a regulator like RBI, SEBI, or IRDAI) will look for the following concrete evidence that Clause 8.6 is alive in the organisation:

• An evaluation schedule, a documented calendar showing when each BC artefact (BIA, risk assessment, strategies, plans, contact lists) and each capability (people, facilities, technology, suppliers) will be reviewed, at what frequency, and by whom.
• Evaluation records, completed reviews for the period under audit, with dates, reviewers, scope, findings, and disposition (valid / update required / re-do required).
• A post-incident review process, a documented PIR procedure, PIR reports for any disruptions that occurred during the audit period, and evidence that PIR findings became corrective actions.
• A change-triggered review log, evidence that significant organisational, operational, regulatory, or threat-landscape changes triggered an evaluation, and what it concluded.
• The link to Clause 10.1, corrective-action tickets traceable from 8.6 findings, with status, owner, and closure evidence.
• The link to Clause 9.3, management review minutes that reference 8.6 evaluation outputs as an input.
• Currency spot-checks, the auditor will pick a plan, open it, and check the contact list, the RTO value, and the last review date. Stale contact names, RTO values that predate a known system change, or review dates older than the stated cadence are immediate findings.

The most common Clause 8.6 finding in the Indian context is not that evaluations were never done, it is that evaluations were done but their findings were not converted into corrective action, so the same gap appears in the next disruption. This is the "DBS recurrence" pattern: repeated outages because the post-incident review identified the root cause but the corrective-action loop did not close. The auditor will trace findings forward to closure; open findings older than the stated correction timeframe are a nonconformity.

Why This Control Matters

The business risk of decay

Business continuity documentation and capabilities are not static assets; they are perishable. A contact tree corrodes the day someone leaves the company. A BIA becomes inaccurate the day a new product launches. A DR strategy becomes obsolete the day the primary system is re-platformed. A recovery capability erodes the day the one engineer who knew the failover procedure moves to a new team. The half-life of BC accuracy, in a typical growing company, is shorter than the annual review cycle most organisations nominally follow. Clause 8.6 exists because without a disciplined evaluation habit, the organisation's BC arrangements become a literature of past assumptions, and the next disruption exposes the gap in real time, under stress, with customers and regulators watching.

The financial consequence of decay is not theoretical. When a real disruption strikes an organisation whose plans have silently drifted, three costs compound: the direct loss of revenue or production during the extended outage; the cost of improvised recovery (emergency procurement, manual workarounds at scale, crisis consulting fees); and the regulatory and reputational cost of failing to meet a stated RTO or a mandatory notification timeline. In the Indian BFSI context, where RBI has demonstrated willingness to bar a bank from launching new digital products for repeated outages (the HDFC Bank action of 2 December 2020), the cost of decay is measured not just in rupees but in lost strategic optionality, a year or more of product freeze.

The Indian regulatory context

Indian regulators have, over the past five years, progressively hardened their expectation that organisations will evaluate, and demonstrably learn from, their continuity arrangements. The pattern is consistent across sectors:

• RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices (7 November 2023, effective 1 April 2024) consolidates and strengthens the expectation that banks and NBFCs maintain board-approved BCP/DR, conduct periodic reviews, and perform post-incident analysis. The Master Direction treats repeated digital outages as a governance failure, not an IT-ops issue, which is precisely the Clause 8.6 frame: if the same failure recurs, the evaluation-and-corrective-action loop is broken, and that is a board-level concern.
• SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) (CIR/2024/113, 20 August 2024) structures the entire resilience regime around six operational functions, Identify, Protect, Detect, Respond, Recover, and Learn. The "Learn" function is, in substance, Clause 8.6's post-incident review and capability-currency evaluation, codified as a regulatory expectation for every SEBI-regulated entity, graded across five categories. CSCRF requires lessons-logged, post-incident analysis, and feedback into controls.
• SEBI BCP/DR for Market Infrastructure Institutions (CIR/2021/33, 22 March 2021) requires MIIs to maintain a document-review cadence, conduct live/parallel DR drills, and, critically, to review and update BCP/DR documents based on drill findings and incident experience. This is 8.6 made explicit for exchanges, clearing corporations, and depositories.
• IRDAI Information and Cyber Security Guidelines 2023 (24 April 2023) require insurers to conduct DR drills, report annually to IRDAI within 90 days of financial year-end, and have the Board's Risk/IT committee oversee BCP/DR. The annual compliance certificate is, in effect, a management assertion that the evaluation cycle has been completed.
• CERT-In Directions (20(3)/2022-CERT-In, 28 April 2022) mandate incident reporting within 6 hours and 180-day log retention. The 6-hour clock presupposes a tested incident-response capability; the post-incident cooperation duty presupposes a structured PIR process. An organisation that cannot produce a PIR for a reportable incident is non-compliant with CERT-In, not just ISO 22301.
• DPDP Act 2023 (Act 22/2023), Section 8(5) imposes a statutory duty to protect the availability of personal data; Section 8(6) and the Schedule impose breach-notification duties with penalties up to ₹250 crore for inadequate safeguards and ₹200 crore for failure to notify. A post-breach PIR is now not just good practice but the evidentiary foundation for demonstrating that safeguards were "adequate", the absence of a PIR process weakens the defence against a Data Protection Board penalty.
• Companies Act 2013, Section 134(3)(n) requires the Board's Report to include a statement on risk management policy, including risks that "may threaten the existence of the company itself." Stale BC documentation that fails to reflect a material change in the company's risk profile is, in substance, a Section 134(3)(n) disclosure failure, the board is attesting to a risk posture that the documentation does not support.

The cost of non-compliance with examples

The Indian regulatory record provides concrete cost anchors for the failure to evaluate and learn:

• HDFC Bank (2020): Repeated digital outages (November 2018, December 2019, and the 21–22 November 2020 data-centre power failure that took net banking and cards dark for roughly half a day) led RBI on 2 December 2020 to bar HDFC from launching new digital products and issuing fresh credit cards, pending an external IT audit. The ban was partially lifted only around August 2021 (roughly 8 months) and fully lifted around March 2022 (roughly 15 months). The episode is the canonical Indian example of a broken Clause 8.6 loop: the same failure mode recurred across three years because post-incident evaluations did not drive corrective action to root cause, and the regulator had to force the loop closed. The cost was not just the direct outage impact but 15 months of strategic freeze in India's most competitive banking segment.
• DBS Singapore (2023): While not Indian, this is the most-cited regional cautionary tale for 8.6. Recurring digital-banking disruptions, including a 6.5-hour outage in May 2023 and a November 2023 access-control failure, led the Monetary Authority of Singapore to impose a six-month pause on non-essential IT changes (November 2023 to May 2024) and apply an approximately 1.8x multiplier on operational-risk capital. The recurrence pattern, the same availability problems repeating because the evaluation loop did not close, is the precise failure mode Clause 8.6 is designed to prevent.
• SpiceJet (2022): After multiple in-flight snags, the DGCA on 27 July 2022 ordered SpiceJet to operate at 50% of approved Summer Schedule flights for 8 weeks (extended to 29 October 2022) for failing to establish "safe, efficient and reliable air services." This is a Clause 8.6/9.2 hybrid: chronic under-resourcing of asset integrity is itself a continuity failure, and the regulatory escalation (capacity cap) is the cost of not evaluating and correcting the capability decay before the regulator intervened.

Why growing companies are especially exposed

Growing companies, the 250-to-2,000-employee firms that are Singahi's audience, face a structural mismatch between the rate of organisational change and the maturity of their evaluation discipline. A company adding 30% headcount year-on-year, entering new markets, shipping new products, and migrating workloads to cloud has a BC-documentation half-life measured in weeks, not quarters. Yet most growing companies either (a) have no scheduled evaluation cadence at all, relying on the annual audit to surface gaps, or (b) have a nominal annual review that no one actually performs because the BCM is also doing four other jobs. The result is the same: the BIA on file describes a company that no longer exists, and the next disruption is the first time the gap is discovered.

Clause 8.6 is, for this audience, the single highest-use clause to get right. It costs relatively little, evaluation is a people-and-process discipline, not a capital expenditure, and it prevents the most expensive failure mode in BCM: the discovery, mid-outage, that the plan describes a different company.

Scope and Applicability

What is in scope

Clause 8.6 applies to the full set of operational BC arrangements established under Clause 8, evaluated as both documentation and capabilities:

Documentation scope (the "what it says" layer):

• The Business Impact Analysis (Clause 8.2), prioritised activities, MTPD/RTO/RPO/MBCO values, impact-over-time matrices, dependency maps.
• The risk assessment (Clause 8.2), disruption risks, likelihood/impact ratings, treatment decisions.
• The continuity strategies and solutions (Clause 8.3), selected strategies per prioritised activity, resource allocations, supplier arrangements.
• The response structure (Clause 8.4), crisis management team composition, activation thresholds, decision authorities.
• The plans and procedures (Clause 8.4), incident response plan, IT DR plan, work-area recovery plan, communications plan, occupant evacuation plan, supplier-failover plan, manual-workaround procedures.
• The exercise programme (Clause 8.5), exercise calendar, scenario library, after-action reports.
• Supporting documented information, contact trees, call cascade matrices, vendor inventory with BC SLAs, recovery runbooks, RACI charts.

Capability scope (the "what it can do" layer):

• People capability, BC team members, crisis management team, deputies, activity owners, recovery engineers; their currency of training, awareness, and rehearsal.
• Facility capability, alternate work sites, DR sites, crisis management rooms, fallback sites; their availability, capacity, currency of configuration, and tested readiness.
• Technology capability, replication links, backup systems, failover mechanisms, crisis-communication platforms, incident-management tooling; their operational status, currency of testing, and achievement of stated RTO/RPO.
• Supplier capability, critical suppliers' BC arrangements, their tested recovery SLAs, their financial viability, and the contractual right to audit.

What is out of scope (and where it sits instead)

• Management-system-level evaluation (the BCMS as a whole, policy, objectives, management commitment) sits in Clause 9.3 (management review) and Clause 9.2 (internal audit). Clause 8.6 evaluates the operational BC arrangements, not the management system.
• Ongoing performance monitoring (KPI dashboards, RTO achievement trends, incident counts) sits in Clause 9.1. Clause 8.6 uses 9.1 data as an input to evaluation, but 9.1 is the measurement layer and 8.6 is the judgement layer.
• Independent conformance audit sits in Clause 9.2. Clause 8.6 evaluation is a management activity; 9.2 is the independent check on whether 8.6 (and everything else) is working.
• Exercising and testing sits in Clause 8.5. The distinction is subtle but important: 8.5 is the activity of exercising plans; 8.6 is the evaluation of whether the plans and capabilities are still suitable, adequate, and effective, using 8.5 exercise outputs as one input among several.

Applicability by organisation size

Applicability by industry (summary; detailed in Section 21)

• BFSI (banks, NBFCs, insurers, MIIs, PSOs): The most regulated sector for 8.6. RBI, SEBI, and IRDAI all require post-incident review, document-review cadence, and board oversight. The cost of a broken 8.6 loop is regulatory action (product freeze, capital multiplier, capacity cap).
• Healthcare: Patient-safety consequence; evaluation must include clinical-manual-fallback currency. AIIMS Delhi 2022 ransomware is the cautionary anchor, primary and backup servers encrypted, e-Hospital down 6–15 days, paper revert, a case where capability evaluation would have caught the untested backup.
• IT/ITeS and SaaS: Client-contract-driven; evaluation must cover client-facing SLAs and the supplier's own BC commitments. DORA applies if serving EU financial entities.
• Manufacturing (especially pharma/chemical): Production-stoppage consequence; OT/IT segmentation evaluation, LG Polymers-grade industrial-disaster review.
• Government and public sector: NDMA Disaster Management Plan template; evaluation tied to the DMP review cycle.

Key Definitions and Terminology

The three evaluation criteria

Clause 8.6 evaluates against three criteria, suitable, adequate, effective, that come straight from ISO management-system vocabulary (they recur in Clauses 9.3 and 10.2). Understanding the distinction is essential because each criterion asks a different question and requires different evidence:

• Suitable (the "right problem" test): Does the documentation or capability address the actual continuity problem the organisation faces? A BIA that analyses a 2019 product mix when the company has since launched three new revenue lines is not suitable. A DR strategy that assumes a mainframe the organisation decommissioned last year is not suitable. Suitability is about alignment with current reality.
• Adequate (the "enough" test): Is the documentation or capability sufficient in scope, depth, and resourcing to meet the continuity objective? A plan that covers the primary site but not the alternate site is not adequate. A contact tree that reaches 70% of staff is not adequate. A DR drill that tests failover but not failback is not adequate. Adequacy is about completeness and sufficiency.
• Effective (the "it works" test): Does the documentation or capability actually produce the intended outcome when invoked? A plan that meets RTO in the drill but not in the real outage (because the drill used synthetic data and the real event hit peak load) is not effective. A backup that is restorable in the lab but took 14 hours in the real ransomware is not effective. Effectiveness is about demonstrated outcome.

Core BCM terms (Clause 8.6 lens)

• Post-Incident Review (PIR): The structured evaluation conducted after a real disruption or near-miss. Also called after-action review, post-mortem, or lessons-learned review. The PIR reconstructs the timeline, identifies what worked and what failed, determines root causes, captures lessons, and translates them into corrective actions. The PIR is the signature triggered-evaluation event under Clause 8.6.
• Hotwash: A rapid, informal debrief conducted immediately (typically within 24–72 hours) after a disruption or exercise, while memory is fresh. The hotwash feeds the formal PIR.
• Significant change: A change in the organisation's context, operations, technology, regulatory environment, or threat landscape that could render existing BC documentation or capabilities obsolete. The organisation defines what counts as "significant" in its evaluation procedure; typical triggers include M&A, new products/markets, platform changes, site changes, regulatory changes, major incidents (own or industry), exercise findings, and key-person departures.
• Capability currency: The degree to which the people, facilities, technology, and suppliers assumed by the BC plans are still in place, still functional, and still able to deliver the stated recovery objectives. Currency is the day-to-day measure of effectiveness between formal evaluations.
• Documentation currency: The degree to which the BC documented information reflects the current organisation, current products, current systems, current people, current contacts, current RTO/RPO values, current threats.
• Corrective action: The action taken to eliminate the root cause of a nonconformity identified through evaluation, audit, or incident, to prevent recurrence. Governed by Clause 10.1. The closed loop from evaluation finding to corrective-action closure is the measure of a working 8.6 programme.
• Lessons learned: The generalised insights extracted from a PIR or evaluation that are applicable beyond the specific incident, the difference between "fix this one backup" (corrective action) and "our backup-test cadence is inadequate for tier-1 systems" (lesson learned, which drives a programme-level change).
• Near-miss: An event that could have caused a disruption but did not, either because it was caught in time or because of luck. Near-misses are evaluation triggers under 8.6; treating them as free lessons is a hallmark of a mature programme.

Terminology variance across frameworks

Different frameworks use overlapping labels for the Clause 8.6 concept, and the cross-framework mapping in Section 16 reconciles them precisely. The key variances:

• "Post-incident review" (ISO 22301, NIST CSF RC.IM) ≈ "lessons learned" (NIST SP 800-34 step 7, ISO 27001 A.5.30) ≈ "Learn" function (SEBI CSCRF) ≈ "learning and evolving" (DORA Art 13) ≈ "post-incident analysis" (CERT-In cooperation duty).
• "Suitable, adequate, effective" (ISO 22301 8.6, 9.3, 10.2) ≈ "continuing suitability, adequacy, and effectiveness" (ISO 27001 Clause 9.3), the same three-criterion test, applied at different levels (8.6 = operational BC arrangements; 9.3 = the whole BCMS).
• MTPD vs MAO: Maximum Tolerable Period of Disruption (ISO 22301:2019 / ISO/TS 22318:2021 preferred label) = Maximum Acceptable Outage (older BCM terminology and ISO 22301:2012 legacy). Present both neutrally; the evaluation checks whether the value is still valid regardless of label.

Relationship to Other Clauses

Clause 8.6 sits at the intersection of Clause 8 (Operational) and Clause 9 (Performance Evaluation), and it is the most commonly confused clause in the standard. The distinction table below is the single most important reference for an implementer and an auditor.

The Clause 8.6 vs 8.5 / 9.1 / 9.2 / 9.3 / 10.1 distinction

The upstream inputs to Clause 8.6

Clause 8.6 does not operate in isolation; it consumes the outputs of nearly every other clause:

• Clause 4.1 (Context): Internal and external issues define what "significant change" means for this organisation.
• Clause 4.2 (Interested parties): Stakeholder expectations (regulators, customers, insurers) define what "suitable" means, a regulator's expectation raises the bar.
• Clause 6.1 (Risks and opportunities): The risk register is an evaluation input; new risks trigger re-evaluation.
• Clause 7.5 (Documented information): The document-control framework is what makes evaluation traceable, version history, review dates, approval records.
• Clause 8.2 (BIA and risk assessment): The primary documentation being evaluated. If the BIA is stale, every downstream plan is stale.
• Clause 8.3 (Strategies): The strategies being evaluated for continued suitability (does the selected strategy still meet the RTO/RPO, given cost and risk changes?).
• Clause 8.4 (Plans): The plans being evaluated for currency and completeness.
• Clause 8.5 (Exercises): Exercise after-action reports are the richest single source of evaluation evidence, they reveal what actually happens when the plan is invoked.
• Clause 9.1 (Monitoring): Performance data, RTO achievement trends, incident response times, drill pass rates, is the quantitative backbone of evaluation.

The downstream destinations of Clause 8.6 findings

• Clause 10.1 (Corrective action): Every nonconformity found in evaluation becomes a corrective-action record with root-cause analysis, action plan, owner, deadline, and closure verification.
• Clause 10.2 (Continual improvement): Opportunities found in evaluation (not just failures) feed the improvement pipeline.
• Clause 9.3 (Management review): The 8.6 evaluation summary is a mandatory input to management review; it tells top management whether the operational BC arrangements are still fit for purpose.
• Clause 7.5 (Documented information): Updated documentation, revised plans, refreshed contact lists, re-baselined RTO values, is the visible output of a working 8.6 loop.
• Regulatory reporting: For regulated entities, 8.6 outputs feed compliance returns (RBI, SEBI, IRDAI), breach notifications (DPDP, CERT-In), and board reporting (Companies Act §134(3)(n)).

Cross-framework structural relationships

Clause 8.6 maps to the "learn" or "improve" layer of every major resilience framework. The detailed mapping is in Section 16; the structural relationships are:

• ISO 27001: A.5.30 ICT readiness for business continuity (the evaluation of ICT readiness) and the ISO 27001 Clause 9.1/9.3 management-review cycle. ISO 22301 8.6 is broader (all BC arrangements, not just ICT).
• NIST CSF 2.0: The Recover function's RC.IM (Recovery Improvement) category, "lessons learned from incidents are incorporated into recovery plans and processes."
• NIST SP 800-34 Rev 1: Step 7 of the seven-step contingency planning process, "Plan maintenance", which is the scheduled-review and update cycle.
• DORA (EU): Article 13 "Learning and evolving", the post-incident review and improvement obligation for ICT-related incidents.
• APRA CPS 230: Paragraphs 43–46, annual business-continuity exercise and internal-audit review of the BCP.
• SEBI CSCRF: The "Learn" operational function, post-incident analysis, lessons-logged, feedback into controls.
• FFIEC BCM Booklet: The "testing" and "governance" themes, evaluation of test results and board oversight of BCM effectiveness.

Detailed Implementation Guidance

This section is the operational core of the guide. It is structured as a phased implementation, tiered by maturity, with worked procedures for each of the three evaluation modes: scheduled, triggered (post-disruption), and triggered (post-change).

Phase 1, Establish the evaluation framework (months 1–3)

Step 1.1, Define the evaluation scope and inventory. Before evaluating anything, the BCM must know what exists. Build a BC documentation and capability inventory, a single register listing every BC artefact (BIA, risk assessment, strategies, plans, procedures, contact trees, exercise AARs) and every capability category (people, facilities, technology, suppliers) with its owner, last-review date, and next-review date. This inventory is itself the master schedule for Clause 8.6 and is the first artefact an auditor will request. For a mid-market (250–2,000) firm, expect 30–80 line items in the inventory.

Step 1.2, Define the evaluation cadence by tier. Risk-base the cadence to the BIA tier of the activity each artefact supports:

Document this cadence in the Evaluation Procedure (toolkit doc 02). For regulated entities (RBI/SEBI/IRDAI), the cadence must meet or exceed the regulator's minimum, RBI expects at least annual BCP/DR review; SEBI MII BCP/DR (CIR/2021/33) expects document review after every drill and at defined intervals.

Step 1.3, Define "significant change" triggers. The organisation must define, in its Evaluation Procedure, what counts as a significant change that triggers an out-of-cycle evaluation. Recommended trigger list (adapt to context):

• Organisational: merger, acquisition, divestiture, major restructuring, leadership change in BC roles.
• Operational: new product/service launch, new market entry, new technology platform, platform decommission, site opening/closure, major process re-engineering.
• Regulatory: new or changed regulation (DPDP Rules taking effect, DORA applying, SEBI CSCRF reclassification, RBI Master Direction update), regulatory enforcement action against the organisation or a peer.
• Threat: major incident at the organisation, major incident at a peer or in the supply chain, new threat intelligence materially changing the risk profile, exercise finding that invalidates an assumption.
• People: departure of a key BC role-holder (BCM, crisis management team lead, recovery engineer), team restructuring affecting BC responsibilities.
• Supplier: critical supplier change of control, supplier BC failure, supplier contract renegotiation.

Step 1.4, Establish the PIR procedure. Document the post-incident review procedure (toolkit doc 08). The PIR must specify: trigger criteria (what events require a PIR), timeline (hotwash within 48–72 hours; formal PIR within 2–4 weeks), composition (facilitator, activity owners, independent observer for major incidents), structure (timeline reconstruction, what-worked/what-failed, root-cause analysis, lessons, corrective actions), and the link to Clause 10.1. For regulated entities, the PIR timeline must align with regulatory reporting, a CERT-In 6-hour report and a DPDP 72-hour breach notification are upstream of the PIR, but the PIR must feed any follow-up regulatory submission.

Step 1.5, Establish the corrective-action linkage. Evaluation findings must flow into a corrective-action log (governed by Clause 10.1) with: unique ID, source (scheduled review / PIR / change-triggered), description, root cause, action plan, owner, target date, status, closure evidence, and verification. The BCM reviews this log monthly; open actions older than their target date escalate to the sponsor. The closed loop, finding to closure to re-evaluation, is what auditors trace.

Phase 2, Scheduled evaluation (ongoing, from month 3)

Step 2.1, Documentation evaluation checklist. For each artefact in the inventory, run the documentation evaluation checklist (toolkit doc 03). The checklist tests the three criteria:

• Suitability: Does the artefact address the current organisation? (Has the product mix changed? Have systems been added/decommissioned? Have regulations changed?) Compare the artefact's scope against the current organisational scope (Clause 4.3).
• Adequacy: Is the artefact complete? (Does the BIA cover all prioritised activities? Does the plan cover activation, response, recovery, and reconstitution? Does the contact tree reach 100% of required personnel?) Check against the BIA's prioritised-activity list.
• Effectiveness: Has the artefact been demonstrated to work? (Was the plan exercised in the last cycle? Did the exercise meet its objectives? Was the RTO achieved?) Pull the latest exercise AAR (Clause 8.5) and the latest 9.1 performance data.

Record the evaluation outcome: Valid (no change needed), Update required (minor refresh, contact list, RTO value, owner name), Re-do required (major rework, re-BIA needed, strategy change), or Retire (artefact no longer needed).

Step 2.2, Capability evaluation checklist. For each capability category, run the capability evaluation (toolkit doc 09):

• People capability: Are all BC role-holders still in post? (Cross-check against HR data.) Are deputies designated and aware? Have they been trained in the last 12 months? Have they participated in an exercise or real activation in the last 12 months? For each "no," raise a finding.
• Facility capability: Are alternate work sites and DR sites still under contract? Have they been visited/inspected in the last 12 months? Is the capacity still adequate for the current headcount? Is the configuration current (for DR sites, does the hardware/software match the primary)?
• Technology capability: Are replication links operational? (Pull the last 30 days of replication status.) Are backups restorable? (Pull the last restore-test results.) Do failover mechanisms work? (Pull the last failover-test results.) Is the crisis-communication platform functional and reaching current contacts?
• Supplier capability: Are critical suppliers still contracted? Have their BC SLAs been tested? (Pull the last supplier-BC test evidence.) Are they financially viable? (Check for any supplier distress signals.) Have there been any supplier-side incidents affecting the organisation?

Step 2.3, Record and report. Produce an Evaluation Summary per cycle (quarterly for tier-1, etc.) covering: scope evaluated, findings by category and severity, corrective actions raised, actions closed, open actions ageing, trends (is the documentation getting more or less current?). Distribute to the BCM sponsor and, for regulated entities, to the board Risk/IT Committee quarterly.

Phase 3, Triggered evaluation: post-disruption (the PIR)

The PIR is the highest-stakes evaluation event. Conduct it as follows:

Step 3.1, Hotwash (within 48–72 hours). Convene the response team and key participants while memory is fresh. Run a structured debrief: timeline reconstruction (what happened, when), what worked (what plan elements functioned as designed), what did not work (what failed, was missing, or was wrong), and immediate lessons. Capture raw notes; do not wait for analysis. The hotwash is not the PIR, it is the input to the PIR.

Step 3.2, Formal PIR (within 2–4 weeks). Convene the PIR workshop, facilitated (ideally by someone who did not lead the response, for major incidents). Structure:

1. Timeline reconstruction: Build the complete incident timeline from logs, comms records, and participant accounts. Identify decision points, delays, and uncertainties.
2. Plan-vs-actual comparison: Walk through the BC plan as it was supposed to execute. Where did actual diverge from plan? Why?
3. What worked: Document the plan elements, capabilities, and decisions that functioned well. (This is not just for morale, it identifies what to preserve.)
4. What failed: Document the plan elements, capabilities, and decisions that failed, were missing, or were wrong. Be specific and evidence-based.
5. Root-cause analysis: For each failure, determine the root cause (not just the symptom). Use a structured method, the "five whys," fishbone, or fault-tree analysis. The root cause is what the corrective action must address.
6. Lessons learned: Generalise from the specific findings. What does this incident tell us about our overall BC posture that we should change?
7. Corrective actions: For each root cause, define a corrective action with owner, target date, and closure criteria. Log in the corrective-action system (Clause 10.1).
8. Documentation updates: Identify which BC documents need updating (contact lists, RTO values, procedures, strategies). Assign owners and dates.
9. Regulatory follow-up: If the incident was reportable (CERT-In, RBI, SEBI, IRDAI, DPDP), ensure the PIR findings inform any follow-up regulatory submission.

Step 3.3, PIR report. Produce the PIR report (toolkit doc 08 template) and distribute per the classification and distribution list. For major incidents, the PIR report goes to the board Risk/IT Committee and, for regulated entities, may be requested by the regulator.

Step 3.4, Corrective-action tracking. Track every PIR corrective action to closure in the corrective-action log. The BCM reviews PIR actions monthly; open PIR actions older than 90 days escalate. The single most common 8.6 failure is PIR actions that are raised but never closed, the DBS recurrence pattern. An auditor will trace every PIR action forward to closure; an open PIR action with no progress is a nonconformity.

Phase 4, Triggered evaluation: post-significant-change

When a significant change occurs (per the defined triggers), the BCM conducts a change-triggered evaluation:

Step 4.1, Assess the change's impact on BC arrangements. For each change, ask: which prioritised activities are affected? Which BC documents are now potentially stale? Which capabilities are affected (people, facilities, technology, suppliers)? What is the risk if we do not update?

Step 4.2, Scope the evaluation. Based on the impact assessment, scope the evaluation, full re-BIA of affected activities, targeted review of specific plans, or confirmation that existing arrangements remain valid. Not every change requires a full re-do; the evaluation is a judgement, and the judgement may be "still valid, document the review."

Step 4.3, Conduct the evaluation and update. Run the scoped evaluation, update the affected documentation and capabilities, and record the change-triggered review in the evaluation log with: change description, date, scope evaluated, outcome, documents updated, capability actions taken.

Step 4.4, Communicate. Notify affected stakeholders, activity owners, BC team members, suppliers, regulators (if the change is itself reportable), of the updated arrangements. A common failure is updating the plan but not telling the people who must execute it.

Phase 5, Continuous improvement of the evaluation programme itself (ongoing)

The evaluation programme is itself subject to evaluation: is it producing useful findings? Are evaluations being completed on schedule? Are corrective actions closing? Use the metrics in Section 12 to assess the programme's health, and review the programme annually in management review (Clause 9.3). A programme that finds nothing wrong year after year is not a successful programme, it is a programme that has lost the ability to see.

Tiered guidance by maturity

For L1 organisations (ad hoc, no scheduled evaluation): Start with the inventory (Step 1.1) and a single quarterly review of tier-1 plans. Establish the PIR procedure and run a PIR for the last disruption (even if months ago, reconstruct it). The goal is to move from "we evaluate when forced" to "we evaluate on a schedule."

For L2 organisations (scheduled, but weak corrective-action loop): Focus on the 8.6→10.1 link. Audit the corrective-action log: how many findings are open? How old? The goal is to move from "we evaluate" to "we close the loop."

For L3 organisations (scheduled + triggered, closed loop): Focus on the quality of evaluation, root-cause depth, lessons generalisation, predictive capability currency (what will break next?). Integrate with 9.1 monitoring data for evidence-led evaluation. The goal is to move from "we close the loop" to "we anticipate."

For L4–L5 organisations (continuous, predictive): Focus on ecosystem evaluation, supplier BC, industry threat intelligence, regulatory horizon scanning, and feeding lessons back into design (Clause 8.3 strategy selection). The goal is resilience by design, not resilience by review.

Tools, Technologies, and Solutions

Clause 8.6 is primarily a people-and-process discipline, but tooling amplifies its effectiveness, particularly for the inventory, the corrective-action log, and the evidence trail. This section describes the tool categories a growing company should consider, with indicative INR cost ranges. No vendor names are used; the categories are described by function, and the evaluation criteria in toolkit doc 14 help a buyer select a specific product.

Tool categories for Clause 8.6

Category 1, BCM / GRC platforms (enterprise IRM suite or growing GRC SaaS). These platforms host the BC documentation inventory, the evaluation schedule, the corrective-action log, and the evidence repository in a single system. For a mid-market (250–2,000) firm, a growing GRC SaaS or BCM-specialist SaaS is the typical fit; for a large enterprise (2,000+), an enterprise IRM suite integrated with risk management and audit. Indicative INR cost: ₹15–60 lakh per year for a growing SaaS; ₹1–4 crore per year for an enterprise suite. Key capabilities to look for: documented-information version control, scheduled-review workflows, corrective-action tracking with escalation, evidence attachments, and dashboards for board reporting. The platform should integrate with the ITSM platform (for incident records that feed PIRs) and the collaboration platform (for response-team coordination).

Category 2, Incident management and PIR tooling (ITSM platform or incident-response platform). The PIR depends on a clean incident timeline, which in turn depends on the incident-management tooling used during the response. An ITSM platform (the system of record for IT incidents) or a dedicated incident-response platform (for cyber incidents) provides the timestamped log of detection, response, escalation, and resolution. For PIR purposes, the tool must support: timeline export, participant logging, decision recording, and post-incident action tracking. Indicative INR cost: ₹6–30 lakh per year for a mid-market ITSM or IR platform.

Category 3, Crisis-communication and notification platforms (crisis-notification platform). For the capability-currency evaluation of the communications tree, a crisis-notification platform that can test reachability (without a real activation) is valuable. These platforms send automated check-in messages to the response team and contact tree, measure response rates and times, and flag stale contacts. Indicative INR cost: ₹3–15 lakh per year for a mid-market platform.

Category 4, Backup and DR management tooling (backup-management platform or DR-orchestration platform). For the technology-capability evaluation, the tooling that manages backups and DR replication provides the evidence, replication status, restore-test results, failover-test results, RTO/RPO achievement. A backup-management platform with reporting and a DR-orchestration platform with test-automation are the relevant categories. Indicative INR cost: included in the backup/DR infrastructure cost (typically ₹20–80 lakh for a mid-market deployment).

Category 5, Documentation and collaboration (collaboration platform or document-management system). The BC documentation itself lives in a document-management system or collaboration platform with version control, access control, and review-reminder workflows. For evaluation purposes, the key capability is version history, the auditor wants to see that the plan was reviewed on date X, by person Y, and what changed. Indicative INR cost: ₹1–8 lakh per year for a mid-market collaboration platform with document management.

Category 6, Analytics and dashboarding (BI tool or GRC dashboard). For the 9.1 monitoring data that feeds 8.6 evaluation, a business-intelligence tool or the GRC platform's built-in dashboard provides the trends, RTO achievement over time, incident counts, corrective-action closure rates, documentation-currency percentages. Indicative INR cost: ₹4–20 lakh per year for a mid-market BI tool.

Build vs buy for the evaluation programme

For most growing companies, the evaluation programme does not require a dedicated tool, it can be run on a collaboration platform (for documentation and the inventory) plus the ITSM platform (for the corrective-action log) plus a spreadsheet (for the evaluation schedule and summary). The case for a dedicated BCM/GRC platform emerges when: the documentation inventory exceeds ~50 artefacts; the corrective-action log exceeds ~100 open items; the organisation is regulated and needs demonstrable, auditable evidence trails; or the evaluation programme spans multiple sites or business units. The case for building (rather than buying) is weak unless the organisation has a bespoke BCM methodology that no commercial platform supports.

Tool selection criteria (detailed in toolkit doc 14)

The tool-comparison matrix in the toolkit evaluates categories against: documentation inventory and version control, evaluation scheduling and workflow, corrective-action tracking, evidence repository, PIR support, capability-currency monitoring, dashboards and reporting, integration with ITSM and collaboration, regulatory reporting support, deployment model (SaaS vs on-premises), India data-residency, and total cost of ownership. For a mid-market (250–2,000) regulated firm, the recommended stack is: a growing GRC SaaS or BCM-specialist SaaS for the core programme, the existing ITSM platform for incident-to-PIR linkage, a crisis-notification platform for contact-tree testing, and the existing backup/DR tooling for technology-capability evidence.

India-specific tooling considerations

• Data residency: RBI Master Direction on Outsourcing of IT Services (10 April 2023) and DPDP Act 2023 impose data-locality expectations. If the evaluation evidence (which may include incident details, contact data, system architecture) is sensitive, the tooling should support India data residency or on-premises deployment.
• Regulatory reporting: For BFSI, the tool should support the compliance-return formats required by RBI/SEBI/IRDAI. Generic international GRC platforms may require configuration to produce India-specific reports.
• Cost discipline: For a growing company, the total cost of a BCM/GRC platform (₹15–60 lakh per year) must be justified against the maturity gain. A pragmatic path is to start with collaboration-platform + spreadsheet + ITSM, and migrate to a dedicated platform when the inventory and corrective-action volume justify it (typically at the L3 maturity level).

Policy and Procedure Templates

This section provides ready-to-customise excerpts from the toolkit. The full policy template is toolkit doc 01 and the full procedure is toolkit doc 02. Sample policy "shall" clauses are the organisation's own drafting (not the standard's text) and are encouraged.

Evaluation policy, sample "shall" clauses (excerpt)

The following are sample policy clauses an organisation might adopt. They are the organisation's own language, drafted to operationalise Clause 8.6, not a reproduction of the standard's text.

• "The Organisation shall maintain a documented inventory of all business continuity documentation and capabilities, including the owner, last-review date, and next-review date of each item."
• "The Organisation shall evaluate the suitability, adequacy, and effectiveness of business continuity documentation and capabilities on a risk-based cadence: at minimum quarterly for tier-1 prioritised activities, semi-annually for tier-2, and annually for tier-3."
• "The Organisation shall conduct a post-incident review after any disruption that invoked business continuity arrangements, and after any near-miss that could have. The post-incident review shall be initiated within 72 hours and completed within 4 weeks, and shall produce corrective actions logged under the corrective-action procedure."
• "The Organisation shall conduct a change-triggered evaluation of affected business continuity documentation and capabilities whenever a significant change occurs, as defined in the Evaluation Procedure."
• "The Organisation shall track all evaluation findings as corrective actions to closure, with monthly review by the BCM and quarterly escalation of open actions to the BCM Sponsor and, for regulated activities, the board Risk/IT Committee."
• "The Organisation shall retain evaluation records, evaluation reports, post-incident review reports, change-triggered review logs, and corrective-action records, for a minimum of [5] years, or longer where regulation requires."

Evaluation procedure, the seven-step operating method (excerpt)

The full procedure is toolkit doc 02. The seven steps are:

1. Maintain the inventory, the BC documentation and capability register, kept current by the BCM.
2. Schedule evaluations, per the tiered cadence; quarterly/semi-annual/annual calendar published and tracked.
3. Conduct scheduled evaluations, documentation and capability checklists per artefact; outcome recorded.
4. Conduct triggered evaluations (PIR), after disruptions and near-misses; hotwash + formal PIR + corrective actions.
5. Conduct triggered evaluations (change), after significant changes; impact assessment + scoped evaluation + updates.
6. Log and track corrective actions, every finding to the corrective-action log; monthly review; escalation.
7. Report and review, quarterly evaluation summary to sponsor/board; annual programme review in management review (Clause 9.3).

PIR procedure, the eight-element structure (excerpt)

The full PIR playbook is toolkit doc 08. The eight elements are: (1) PIR initiation and scoping; (2) timeline reconstruction; (3) plan-vs-actual comparison; (4) what worked; (5) what failed; (6) root-cause analysis; (7) lessons learned; (8) corrective actions and documentation updates. Each element has a template section in the PIR report.

Documentation-currency review checklist (excerpt)

The full checklist is toolkit doc 03. The currency review checks, for each artefact:

• Is the review date within the stated cadence?
• Does the scope match the current organisational scope (Clause 4.3)?
• Are the contact names and numbers current? (Cross-check against HR/Active Directory.)
• Are the RTO/RPO/MBCO values still valid? (Cross-check against the BIA and recent exercise results.)
• Are the referenced systems and suppliers still current? (Cross-check against the application/supplier inventory.)
• Has the artefact been exercised in the last cycle? (Cross-check against the exercise AAR.)
• Are there open corrective actions against this artefact? (Cross-check against the corrective-action log.)

Risk Assessment and Treatment

Clause 8.6 is itself a risk-treatment control, it reduces the risk of BC decay. But the evaluation programme also has its own risks that must be assessed and treated. This section frames the 8.6 risk register.

The 8.6 risk register

Risk treatment priorities for growing companies

For a mid-market (250–2,000) firm building its 8.6 programme, the highest-priority treatments are: (1) establish the inventory and scheduled cadence (treats the documentation-decay risk); (2) fix the corrective-action loop (treats the recurrence risk); (3) establish the change-trigger process (treats the obsolescence risk); and (4) implement automated capability-currency monitoring for tier-1 systems (treats the silent-erosion risk). These four treatments address ~80% of the 8.6 risk for ~20% of the effort.

The risk of over-evaluation

A less obvious risk is over-evaluation, a programme so heavy that the BCM spends all their time reviewing and none improving. Symptoms: evaluation cycles that take longer than the interval between them; corrective-action backlogs that grow faster than they close; activity owners who treat evaluation as bureaucracy rather than learning. Treatment: risk-base the cadence ruthlessly (do not evaluate tier-3 plans quarterly); batch evaluations to reduce administrative overhead; and use automated monitoring (9.1 data) to replace manual review where possible. The goal is a programme that finds real things and fixes them, not a programme that produces a large volume of review records.

Audit and Compliance Checklist

This section provides 28 audit questions covering the full scope of Clause 8.6. Each question lists the expected evidence and the red flag that indicates a finding. The full audit-evidence checklist is toolkit doc 04.

Evaluation framework (questions 1–6)

1. Is there a documented inventory of all BC documentation and capabilities? Expected: a register listing every artefact and capability with owner, last-review date, next-review date. Red flag: no inventory, or inventory that does not match the actual document set.
2. Is the evaluation cadence defined by tier and documented? Expected: a procedure specifying quarterly/semi-annual/annual cadence mapped to BIA tiers. Red flag: a single "annual review" for everything, or no documented cadence.
3. Are "significant change" triggers defined? Expected: a trigger list in the evaluation procedure. Red flag: no trigger list, or triggers so vague they cannot be operationalised.
4. Is the PIR procedure documented? Expected: a PIR playbook specifying trigger criteria, timeline, composition, structure, and corrective-action linkage. Red flag: no PIR procedure, or a procedure that does not link to corrective action.
5. Are evaluation responsibilities assigned (RACI)? Expected: a RACI matrix for evaluation activities. Red flag: the BCM is the only name on every row.
6. Is the evaluation programme approved by management and (for regulated entities) overseen by the board Risk/IT Committee? Expected: approval minutes; quarterly board reporting. Red flag: no management approval, or no board oversight for regulated activities.

Scheduled evaluation (questions 7–12)

7. Were scheduled evaluations completed on time for the audit period? Expected: evaluation records with dates matching the cadence. Red flag: evaluations skipped or delayed beyond the cadence.
8. Did each evaluation record the three-criteria judgement (suitable, adequate, effective)? Expected: evaluation records with explicit judgements and evidence. Red flag: records that say "reviewed, no change" with no evidence.
9. Were evaluation outcomes (valid / update / re-do / retire) recorded and acted on? Expected: outcome records with follow-up actions. Red flag: outcomes recorded but no follow-up.
10. Were contact lists checked for currency? Expected: contact-list review records cross-checked against HR data. Red flag: contacts in the plan who have left the organisation.
11. Were RTO/RPO/MBCO values validated against recent exercise results? Expected: cross-reference between evaluation records and exercise AARs. Red flag: RTO values that have not been tested or that were missed in the last exercise.
12. Were capability evaluations (people, facilities, technology, suppliers) completed? Expected: capability evaluation records per category. Red flag: documentation evaluated but capabilities not.

Post-incident review (questions 13–18)

13. Was a PIR conducted for every disruption in the audit period? Expected: PIR reports for each reportable incident. Red flag: incidents with no PIR, or PIRs missing for some incidents.
14. Was the PIR initiated within the stated timeline (typically 72 hours for hotwash, 4 weeks for formal PIR)? Expected: PIR records with dates. Red flag: PIRs initiated months after the incident.
15. Did the PIR include root-cause analysis? Expected: PIR reports with documented root causes (not just symptoms). Red flag: PIRs that list failures but no root causes.
16. Were PIR findings converted to corrective actions? Expected: corrective-action records traceable from PIR findings. Red flag: PIR reports with no corrective actions logged.
17. Were PIR corrective actions tracked to closure? Expected: closure evidence in the corrective-action log. Red flag: open PIR actions with no closure, or actions older than 90 days with no escalation.
18. For reportable incidents, did the PIR inform regulatory follow-up? Expected: PIR findings referenced in regulatory submissions. Red flag: regulatory submissions that do not reflect PIR findings.

Change-triggered evaluation (questions 19–22)

19. Were significant changes in the audit period evaluated for BC impact? Expected: change-triggered review records. Red flag: known changes (M&A, new product, new platform) with no corresponding evaluation.
20. Did the change-trigger process fire for the changes that occurred? Expected: evidence that the BCM was notified of significant changes. Red flag: the BCM learned of changes after the fact.
21. Were affected documents updated following change-triggered evaluation? Expected: document version history showing updates post-change. Red flag: changes occurred but documents not updated.
22. Were affected stakeholders notified of updated arrangements? Expected: communication records. Red flag: documents updated but response team not informed.

Corrective action and improvement (questions 23–26)

23. Is there a corrective-action log for 8.6 findings? Expected: a log with unique IDs, sources, owners, dates, status. Red flag: no log, or findings tracked informally.
24. Are corrective actions reviewed monthly and escalated when overdue? Expected: monthly review minutes; escalation records. Red flag: no monthly review, or overdue actions not escalated.
25. Are closed corrective actions verified for effectiveness? Expected: closure verification records. Red flag: actions marked "closed" with no verification that the fix worked.
26. Do evaluation outputs feed management review (Clause 9.3)? Expected: management review minutes referencing 8.6 evaluation summary. Red flag: 9.3 minutes with no 8.6 input.

Evidence and records (questions 27–28)

27. Are evaluation records retained per the stated retention period? Expected: records accessible for the audit period and beyond. Red flag: records missing or destroyed.
28. Are evaluation records sufficient to demonstrate the programme to an external auditor/regulator? Expected: a complete, organised evidence pack. Red flag: the BCM must reconstruct evidence on demand.

Metrics and KPIs

This section defines 14 KPIs for the Clause 8.6 evaluation programme, organised into process metrics, outcome metrics, and improvement metrics. The full KPI dashboard is toolkit doc 11.

Process metrics (is the programme running?)

Outcome metrics (is the programme finding and fixing things?)

Improvement metrics (is the programme getting better?)

Dashboard sample

A quarterly 8.6 dashboard for the board Risk/IT Committee would show: schedule adherence (KPI 1), documentation-currency percentage (KPI 2), PIR completion and timeliness (KPIs 4–5), corrective-action closure rate and aging (KPIs 8–9), repeat-finding rate (KPI 10), and a narrative summary of the top 3 findings and their disposition. For regulated entities, this dashboard aligns with the quarterly compliance reporting expected by RBI/SEBI/IRDAI.

The "zero findings" red flag

A special note on KPI 7: an evaluation programme that finds nothing wrong, cycle after cycle, is not a success, it is a failure of perception. If findings drop to zero, the evaluation has lost the ability to see. The BCM should treat zero findings as a trigger to review the evaluation method, not as a cause for celebration. Mature programmes expect a steady flow of low- and medium-severity findings; the absence of findings indicates either that the programme has become a rubber stamp or that the organisation has stopped changing (which is itself a finding).

Common Pitfalls / Audit Failures

This section names the recurring anti-patterns that cause Clause 8.6 to fail audit or, worse, to fail in a real disruption. Each is named, described, and given its treatment.

"The annual review that never happens"

The most common pitfall: the evaluation procedure states an annual review, the audit record shows the review was "completed," but no one actually did it. The contact list is a year stale, the RTO value predates a system migration, and the plan references a supplier contract that expired. The auditor's spot-check exposes it immediately. Treatment: move from annual to tiered quarterly for tier-1; use automated contact-tree testing; require evidence (not just a checkbox) for each review item.

"The PIR that produced no corrective actions"

The PIR was held, the report was written, but the corrective-action log is empty or the actions were never tracked. This is the DBS recurrence pattern: the same failure mode repeats because the loop did not close. The auditor traces PIR findings forward to closure; open PIR actions with no progress are a nonconformity. Treatment: mandate that every PIR finding becomes a corrective-action record; review PIR actions monthly; escalate overdue PIR actions to the sponsor.

"The change that did not trigger"

The organisation underwent a significant change, an acquisition, a new platform, a new regulation, but the BCM was not in the approval workflow, and the BC documentation was not updated. The next disruption reveals that the plan describes the pre-change organisation. Treatment: put the BCM on the change-approval workflow for changes that meet the "significant" criteria; run a quarterly horizon scan of organisational changes; make change-triggered evaluation a mandatory sign-off for major projects.

"The capability that was assumed but not tested"

The plan assumes the DR site is ready, the replication is working, and the backup is restorable, but no one checked. The replication has been failing silently for weeks, the DR site hardware is two generations behind the primary, and the backup restore was last tested two years ago. The real outage discovers the gap. Treatment: automated capability-currency monitoring for tier-1; quarterly restore and failover tests; DR-site configuration drift checks.

"The checkbox evaluation"

The evaluation is completed on time, every time, but it always concludes "no change required." This is the evaluation that has lost the ability to see, it is a ritual, not a judgement. The auditor will notice that the findings count is zero across multiple cycles. Treatment: quality review of evaluations by an independent party; rotate evaluators; treat zero findings as a red flag (KPI 7).

"The key-person documentation trap"

The BC plan and the recovery runbooks live in the head of one engineer. When that engineer leaves, the capability leaves with them, and the documentation is too thin to reconstruct it. Treatment: deputy designation for all tier-1 BC roles; documented runbooks (not just "call X"); cross-training; key-person risk explicitly assessed in the BIA.

"The supplier BC assumption"

The plan assumes the critical supplier can recover, but the supplier's BC has never been tested, the contract has no BC clause, and the supplier's own financial distress is not monitored. When the supplier fails, the organisation's recovery fails. Treatment: BC clauses in all critical supplier contracts; right to audit; annual supplier-BC test; supplier financial-viability monitoring; exit/transition plans for critical suppliers.

"The regulatory drift"

The evaluation programme was designed two years ago against the then-current regulations. Since then, DPDP Rules have taken effect, SEBI CSCRF has been issued, and the RBI Master Direction has been updated, but the evaluation programme has not been updated to reflect the new regulatory baseline. The organisation is non-compliant without knowing it. Treatment: annual legal/compliance review of the evaluation programme; regulatory horizon scanning; alignment of evaluation cadence to regulatory minimums.

"The PIR that blamed the tool"

A common PIR failure mode: the root cause is attributed to "the tool failed" or "human error" without deeper analysis. The tool failed because it was misconfigured; the human erred because the procedure was unclear. Without root-cause depth, the corrective action is superficial ("retrain the operator") and the failure recurs. Treatment: mandate a structured root-cause method (five whys, fishbone) in the PIR; require root-cause depth before accepting a corrective action.

"The evaluation that did not feed management review"

The 8.6 evaluation summary is produced but never presented to top management in Clause 9.3 management review. The board is unaware of the BC posture, and strategic decisions are made without continuity input. Treatment: mandate 8.6 evaluation summary as a standing input to 9.3; the BCM presents at management review, not just submits a written report.

Illustrative Scenario 1: Failure

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

Illustrative scenario. The following composite scenario is drawn from publicly documented patterns in the Indian BFSI sector (notably the HDFC Bank RBI action of 2 December 2020 and the DBS Singapore MAS action of 2023). It is illustrative and does not represent any single named organisation's full facts; the regulatory anchors are real and primary-sourced.

The organisation

A mid-market Indian private bank (call it "Meridian Bank"), roughly 4,000 employees, with a digital-first retail strategy: net banking, mobile app, UPI, and cards accounting for ~70% of customer transactions. Meridian had a documented BCMS, a board-approved BCP/DR policy, a BIA, an IT DR plan, and an annual DR drill, on paper, a compliant L2 programme.

The pattern

Over 18 months, Meridian suffered three significant digital outages:

• Outage 1 (Month 1): A data-centre power fluctuation caused the core banking switch to fail over; failover took 90 minutes (target RTO: 30 minutes). Net banking and UPI were dark for ~2 hours. A PIR was conducted; root cause was attributed to "UPS transfer delay"; corrective action: "tune UPS settings." The action was logged but not assigned a closure date.
• Outage 2 (Month 9): A botched change to the card-switching platform caused a 4-hour card outage. A PIR was conducted; root cause attributed to "insufficient change testing"; corrective action: "strengthen change management." The action was logged but the change-management process was not actually revised.
• Outage 3 (Month 18): A storage array failure on the core banking system took net banking, mobile, and UPI dark for ~6 hours. Failover to the DR site failed initially because the DR site's storage configuration had drifted from the primary (the replication link had been failing intermittently for 6 weeks; no one had evaluated the capability). A PIR was conducted; root cause attributed to "storage vendor issue."

What Clause 8.6 would have caught

The 8.6 failures were not in the PIRs, Meridian held PIRs. The failures were in the loop:

1. Corrective actions were raised but not closed. Outage 1's "tune UPS settings" was never verified; Outage 2's "strengthen change management" was never implemented. The corrective-action log had three open actions with no closure evidence. This is the DBS recurrence pattern: the loop that did not close.
2. Capability was not evaluated between incidents. The DR site storage drift and the failing replication link were not discovered because no capability evaluation was conducted, only documentation was reviewed, and the documentation (the DR plan) still said "replication: active." The plan was suitable and adequate on paper; it was not effective in reality.
3. Significant changes did not trigger evaluation. Between Outage 1 and Outage 3, Meridian migrated its card-switching platform to a new version and expanded its UPI infrastructure, both significant changes. Neither triggered a change-triggered evaluation of the affected BC plans.
4. The PIRs did not find root cause. Each PIR attributed the failure to a proximate cause ("UPS," "change," "vendor") without deeper analysis. The deeper root cause, that Meridian's evaluation-and-corrective-action loop was broken, was never identified, so the same failure mode recurred.

The regulatory consequence

After Outage 3, RBI invoked supervisory action: Meridian was barred from launching new digital products and issuing fresh credit cards, pending an external IT audit. The ban lasted roughly 9 months, during which Meridian lost an estimated ₹180–250 crore in foregone digital-banking revenue (illustrative figure based on the bank's digital transaction volume and margin) and, more strategically, lost a full product cycle to competitors. The external IT audit found, among other things, that Meridian's Clause 8.6 evaluation programme existed on paper but did not produce closed-loop corrective action, precisely the failure this guide describes.

Lessons

• A PIR that does not produce closed corrective actions is worse than no PIR, it creates the illusion of learning.
• Documentation evaluation without capability evaluation is half a programme; the plan that says "replication: active" is worthless if the replication is failing.
• Significant changes must trigger evaluation; without a change-trigger process, the BC documentation drifts silently.
• Root-cause depth matters; "human error" and "tool failure" are symptoms, not causes.
• The regulator treats repeated outages as a governance failure (board-level), not an IT-ops issue. The board Risk/IT Committee should have been tracking the corrective-action closure rate (KPI 8) and the repeat-finding rate (KPI 10), both were flashing red, and neither was reported.

Illustrative Scenario 2: Success

Illustrative scenario. The following composite scenario is drawn from publicly documented resilience patterns in the Indian IT/ITeS and SaaS sector (notably the Cognizant Chennai 2015 flood response and the broader post-incident-review discipline of mature Indian SaaS firms). It is illustrative; the ROI figures are realistic estimates for a firm of this size and are not a claim about any single named organisation.

The organisation

A growing Indian SaaS company (call it "Northstar SaaS"), roughly 1,200 employees, providing a B2B analytics platform to financial-services clients in India and the EU. Northstar is DPDP-applicable, ISO 27001 certified, ISO 22301 pursuing, and, because it serves EU financial clients, DORA-relevant as an ICT third-party service provider.

The near-miss that triggered the programme

In Month 0, Northstar suffered a near-miss: a ransomware strain (delivered via a compromised software-supply-chain update, similar to the Kaseya/SolarWinds pattern) reached one development environment. Detection caught it before it reached production; no customer data was affected; no regulatory report was required. But the BCM, Priya Sharma, recognised that the near-miss had exposed three gaps: (1) the incident-response plan had not been invoked for a supply-chain scenario; (2) the backup-restore capability for the affected environment had not been tested in 14 months; (3) the contact tree for the crisis management team had two stale entries (people who had left Northstar in the last quarter).

The 8.6 programme Priya built

Priya treated the near-miss as a free lesson and built a Clause 8.6 programme over the following 12 months, with a budget of approximately ₹35–45 lakh (one full-time BCM analyst at ₹18–22 lakh per year, plus tooling and training at ₹15–20 lakh, plus an external PIR facilitator retainer at ₹4–6 lakh). The programme had four pillars:

1. Tiered scheduled evaluation. Northstar's 22 prioritised activities (from the BIA) were tiered: 7 tier-1 (customer-facing, RTO ≤ 2 hours), 9 tier-2 (RTO 2–8 hours), 6 tier-3 (RTO > 8 hours). Tier-1 documentation and capabilities evaluated quarterly; tier-2 semi-annually; tier-3 annually. The evaluation used a standardised checklist (toolkit doc 03) and produced an evaluation summary per cycle.
2. Triggered PIR discipline. Every disruption and every near-miss triggered a PIR within 72 hours (hotwash) and 4 weeks (formal PIR). Priya engaged an external facilitator for tier-1 PIRs to ensure independence and root-cause depth. Every PIR finding became a corrective-action record with owner, target date, and closure criteria.
3. Change-triggered evaluation. Priya joined the change-advisory board for significant changes. Every new product launch, platform migration, and regulatory change (DPDP Rules, DORA onboarding) triggered a scoped evaluation. The change-trigger process caught, for example, that a planned migration of the analytics platform to a new cloud region invalidated the DR strategy, the strategy was updated before the migration, not after a disruption.
4. Automated capability-currency monitoring. For tier-1 systems, Northstar implemented automated monitoring of replication status, daily restore-tests of sample backups, and a monthly failover-test of the DR environment. The monitoring fed the 9.1 dashboard, which Priya used as the quantitative backbone of the 8.6 evaluation, she no longer had to ask "is replication working?"; the dashboard told her.

The real disruption

In Month 14, Northstar suffered a real disruption: a cloud-region outage (the kind of event that has affected major cloud providers globally) took the primary production environment down. The DR failover, which had been tested monthly, executed in 38 minutes (target RTO: 2 hours). The contact tree, tested quarterly via the crisis-notification platform, reached 100% of the crisis management team within 8 minutes. The communications plan, refreshed in the last quarterly evaluation, notified affected clients within 30 minutes and the regulator (CERT-In, as a precautionary notification) within 4 hours. No customer data was lost (RPO: 0, achieved via synchronous replication). Total outage duration for customers: 38 minutes.

The PIR and the ROI

The PIR (conducted within 2 weeks) found three minor issues: the failback procedure took longer than expected (90 minutes vs a 60-minute target); the client comms template had a stale regulatory-reference; and one deputy crisis-management-team role was unclear on decision authority. All three became corrective actions, closed within 60 days, and verified.

The ROI of the 8.6 programme, measured over 18 months:

• Avoided outage cost: The Month 14 disruption, had it lasted 6 hours (a reasonable counterfactual without the tested DR failover), would have cost Northstar an estimated ₹90–120 lakh in service credits, SLA penalties, and churn risk (based on the client-contract SLA terms and the revenue concentration in the affected region). The actual cost, with a 38-minute outage, was negligible. Avoided cost: ~₹90–120 lakh from a single incident, more than twice the annual programme cost.
• Avoided regulatory penalty: As a DORA-relevant ICT third-party service provider and a DPDP data fiduciary, Northstar's ability to demonstrate a working PIR and a tested recovery capability was material to its regulatory posture. The 8.6 programme reduced the risk of a DPDP penalty (up to ₹250 crore for inadequate safeguards) and supported DORA Art 13 "learning and evolving" compliance.
• Client-contract wins: Two EU financial-services clients, in their vendor due-diligence, specifically requested evidence of the post-incident-review process and the capability-currency monitoring. Northstar's 8.6 evidence pack was a differentiator; both contracts were won, worth a combined ₹8–12 crore in annual revenue.
• Insurance premium reduction: Northstar's cyber-insurance renewal, supported by the 8.6 evidence, came in approximately 12–15% below the prior premium, a saving of roughly ₹8–12 lakh per year.
• Internal capability: The programme built a cadre of activity owners who understood their BC roles, a corrective-action discipline that had closed 47 of 52 findings within target, and a management-review rhythm that gave the leadership team confidence in the continuity posture.

Lessons

• A near-miss is a free PIR; treat it as such. The Month 0 near-miss, costlessly examined, built the programme that paid for itself in Month 14.
• Capability-currency monitoring (automated, not manual) is the single highest-use 8.6 investment for a SaaS firm.
• The change-trigger process catches obsolescence before the disruption does.
• The 8.6 evidence pack is a commercial asset, it wins regulated clients and reduces insurance cost.
• The ROI of 8.6 is dominated by the avoided cost of a single disruption; the programme does not need to prevent many outages to pay for itself.

Multi-Framework Mapping

This section maps Clause 8.6 to the equivalent or adjacent requirements in the major global and Indian resilience frameworks. The mapping uses real control numbers and is the basis for the regulatory-mapping toolkit doc 17.

ISO 22301:2019 Clause 8.6 ↔ ISO/IEC 27001:2022

ISO 22301:2019 Clause 8.6 ↔ NIST CSF 2.0 and NIST SP 800-34

ISO 22301:2019 Clause 8.6 ↔ SOC 2

ISO 22301:2019 Clause 8.6 ↔ DORA (EU)

ISO 22301:2019 Clause 8.6 ↔ APRA CPS 230 (Australia)

ISO 22301:2019 Clause 8.6 ↔ Indian regulators

The cross-framework insight

Clause 8.6 is the clause that every major framework converges on, under different labels: "Learn" (SEBI CSCRF), "learning and evolving" (DORA Art 13), "Recovery Improvement" (NIST CSF RC.IM), "Plan maintenance" (NIST SP 800-34 Step 7), and the post-incident review expectations of RBI, IRDAI, CERT-In, and DPDP. An organisation that builds a strong 8.6 programme is simultaneously satisfying the "learn" layer of every framework it maps to, which is why 8.6 is among the highest-use clauses for multi-framework organisations.

Implementation Roadmap

This section provides a 30/90/180/365-day roadmap for a growing company moving from L1 to L3, with the Year 2 and Year 3 horizon to L4–L5. The full roadmap is toolkit doc 05.

Days 1–30, Establish the baseline

• Day 1–7: Build the BC documentation and capability inventory (toolkit doc 03). List every artefact and capability with owner, last-review date, next-review date.
• Day 8–14: Define the evaluation cadence by tier (quarterly/semi-annual/annual mapped to BIA tiers). Draft the Evaluation Procedure (toolkit doc 02).
• Day 15–21: Define "significant change" triggers. Draft the PIR procedure (toolkit doc 08). Obtain sponsor approval.
• Day 22–30: Conduct the first currency spot-check: pull the top 3 tier-1 plans and check contact lists, RTO values, last-review dates. Log the first findings.

Day 30 milestone: Inventory complete; procedure drafted; first findings logged.

Days 31–90, Run the first cycle and fix the loop

• Day 31–45: Conduct the first quarterly evaluation of all tier-1 documentation. Use the checklist (toolkit doc 03). Record outcomes.
• Day 46–60: Conduct the first tier-1 capability evaluation (people, facilities, technology, suppliers). Pull replication status, restore-test results, contact-tree test.
• Day 61–75: Establish the corrective-action log. Log all findings from the first cycle. Assign owners and target dates.
• Day 76–90: Run a retrospective PIR for the last real disruption (even if months old, reconstruct it). Test the PIR procedure.

Day 90 milestone: First quarterly cycle complete; corrective-action log live; PIR procedure tested.

Days 91–180, Extend coverage and close the loop

• Day 91–120: Conduct the first semi-annual evaluation of tier-2 documentation and capabilities.
• Day 121–150: Implement the change-trigger process: join the change-advisory board; run the first horizon scan.
• Day 151–180: Close the first wave of corrective actions; verify closures. Produce the first quarterly evaluation summary for the sponsor.

Day 180 milestone: Tier-1 and tier-2 coverage; change-trigger process live; first management report delivered.

Days 181–365, Mature the programme

• Day 181–240: Conduct the first annual evaluation of tier-3 documentation and capabilities. Full inventory now covered.
• Day 241–300: Implement automated capability-currency monitoring for tier-1 systems (replication status, restore tests, failover tests). Integrate with 9.1 dashboard.
• Day 301–365: Annual programme review. Self-assess against the L1–L5 maturity model (Section 22). Feed the 8.6 evaluation summary into management review (Clause 9.3).

Day 365 milestone: Full inventory coverage; automated monitoring for tier-1; first 9.3 input delivered; L2/L3 maturity.

Year 2, To L4

• Quarterly tier-1, semi-annual tier-2, annual tier-3 cycles embedded.
• PIR discipline: every disruption and near-miss; external facilitator for tier-1 PIRs.
• Change-trigger process: 100% of significant changes evaluated.
• Corrective-action closure rate ≥ 85% (KPI 8).
• Predictive evaluation: use trend data to anticipate capability decay.
• Ecosystem evaluation: supplier BC tests; industry threat-intelligence integration.

Year 3, To L5

• Continuous capability-currency monitoring for all tier-1 and tier-2 capabilities.
• Lessons-learned implementation rate ≥ 70% (KPI 13).
• Evaluation feeds design: 8.6 findings drive Clause 8.3 strategy changes.
• Regulator-witnessed exercises and PIRs for regulated activities.
• The programme is self-improving: the evaluation of the evaluation programme is itself rigorous.

Resourcing and budget (mid-market, 250–2,000)

For a regulated growing firm, this cost is modest against the avoided cost of a single regulatory action (the HDFC-style 9–15 month product freeze) or a single extended outage (the Northstar-style ₹90–120 lakh counterfactual).

FAQ

Q1. How is Clause 8.6 different from Clause 8.5 (Exercise Programme)? Clause 8.5 is the activity of exercising plans, running tabletops, drills, simulations, failovers. Clause 8.6 is the judgement that the plans and capabilities are still suitable, adequate, and effective. Exercise after-action reports (an 8.5 output) are a primary input to 8.6 evaluation, but 8.6 also uses real-incident PIRs, change-triggered reviews, performance monitoring data (9.1), and scheduled documentation/capability reviews. 8.5 asks "did the exercise work?"; 8.6 asks "are our plans and capabilities still valid?"

Q2. How is Clause 8.6 different from Clause 9.1 (Monitoring and Measurement)? Clause 9.1 is the ongoing measurement of BCMS performance, the dashboard of RTO achievement, incident counts, drill pass rates. Clause 8.6 is the interpretation of that data (and other evidence) into a judgement about whether the operational BC arrangements are still fit for purpose. 9.1 is the measurement layer; 8.6 is the judgement layer. 9.1 tells you RTO was missed in 3 of 10 incidents; 8.6 asks why and what to do about it.

Q3. How is Clause 8.6 different from Clause 9.2 (Internal Audit)? Clause 9.2 is an independent conformance audit of the whole BCMS, conducted by internal audit at planned intervals. Clause 8.6 is an operational management activity, led by the BCM with activity owners, that evaluates the operational BC arrangements. 9.2 audits whether 8.6 (and everything else) is working; 8.6 is one of the things being audited. Independence is required for 9.2; it is valuable but not required for 8.6.

Q4. How is Clause 8.6 different from Clause 9.3 (Management Review)? Clause 9.3 is the top-management review of the BCMS as a whole, its continuing suitability, adequacy, and effectiveness. Clause 8.6 evaluates the operational BC arrangements (the BIA, strategies, plans, capabilities) and feeds its findings up to 9.3 as a mandatory input. 8.6 is the operational layer; 9.3 is the strategic layer. Both use the same three-criteria test (suitable, adequate, effective) but at different scopes.

Q5. How is Clause 8.6 different from Clause 10.1 (Corrective Action)? Clause 10.1 is the process of reacting to nonconformities, dealing with consequences, and correcting root causes. Clause 8.6 is the evaluation that finds the nonconformities. 8.6 findings become 10.1 corrective actions; the closed loop, evaluate, find, correct, re-evaluate, is the PDCA heart. An 8.6 finding with no corresponding 10.1 corrective action is a broken loop.

Q6. Do we need to do a full re-BIA every year? No. The scheduled evaluation may conclude that the existing BIA remains valid, the judgement is "suitable, adequate, effective: yes." A full re-BIA is required when the evaluation (scheduled or triggered) finds that the BIA no longer reflects the organisation, typically after a significant change (M&A, new product line, new platform). The clause asks for a judgement, not a mandatory re-do.

Q7. What counts as a "significant change" that triggers evaluation? The organisation defines this in its evaluation procedure. Typical triggers: M&A, divestiture, major restructuring; new product/service/market; new or decommissioned technology platform; site opening/closure; new or changed regulation; major incident (own or industry); exercise finding that invalidates an assumption; key-person departure; critical supplier change. The key is that the BCM is notified when these occur, the change-trigger process must be wired into the organisation's change-management workflow.

Q8. How soon after a disruption must we do a PIR? Best practice: hotwash within 48–72 hours (while memory is fresh); formal PIR within 2–4 weeks. For regulated entities, the PIR timeline must align with regulatory reporting, CERT-In's 6-hour report and DPDP's 72-hour breach notification are upstream of the PIR, but the PIR must inform any follow-up regulatory submission. The PIR is not complete until its findings are corrective actions in the log.

Q9. Our last PIR found only minor issues. Is that a problem? Not necessarily, if the incident was minor. But if your evaluation programme consistently finds nothing, cycle after cycle, that is a red flag (KPI 7). A programme that finds nothing has either lost the ability to see or the organisation has stopped changing. Both are findings. Review the evaluation method; rotate evaluators; bring in an independent observer.

Q10. Do we need a dedicated tool for Clause 8.6? Not initially. A collaboration platform (for documentation and the inventory) plus the ITSM platform (for the corrective-action log) plus a spreadsheet (for the evaluation schedule) is sufficient for L1–L2. The case for a dedicated BCM/GRC platform emerges at L3, when the inventory exceeds ~50 artefacts, the corrective-action log exceeds ~100 open items, or the organisation is regulated and needs demonstrable evidence trails.

Q11. How does Clause 8.6 help with DPDP compliance? The DPDP Act 2023 §8(5) imposes a duty to protect the availability of personal data; §8(6) imposes breach-notification duties with penalties up to ₹250 crore for inadequate safeguards. A post-breach PIR is the evidentiary foundation for demonstrating that safeguards were "adequate", the absence of a PIR process weakens the defence against a Data Protection Board penalty. The 8.6 evaluation also confirms that the breach-notification capability (contact tree, notification templates, regulator relationships) is current.

Q12. How does Clause 8.6 help with RBI/SEBI/IRDAI compliance? RBI's Master Direction on IT Governance (7 Nov 2023) expects periodic BCP/DR review and post-incident analysis; SEBI CSCRF's "Learn" function expects post-incident learning; IRDAI's 2023 guidelines expect annual compliance reporting and DR drill review. A strong 8.6 programme satisfies all of these simultaneously, the evaluation summary, PIR reports, and corrective-action log are the evidence regulators request.

Q13. Who should chair a PIR? For minor incidents, the BCM. For major incidents (tier-1, regulated, or with board visibility), an independent facilitator, someone who did not lead the response. Independence is not a clause requirement for 8.6 (it is for 9.2 internal audit), but it materially improves PIR quality by removing the incentive to defend decisions.

Q14. What is the most common Clause 8.6 audit finding? Stale contact lists. The auditor opens a plan, checks the contact tree, and finds names of people who have left the organisation. It is the most visible, most embarrassing, and most easily prevented finding, a quarterly contact-list check (cross-referenced to HR data) eliminates it.

Q15. Can we combine the 8.6 evaluation with the 9.3 management review? No, they are different clauses with different scopes and different audiences. But the 8.6 evaluation summary is a mandatory input to 9.3, so they are sequential: 8.6 produces the evaluation, 9.3 consumes it. Running them as a single activity conflates operational judgement with strategic review and weakens both.

Industry-Specific Requirements

BFSI (banks, NBFCs, insurers, MIIs, PSOs)

The most regulated sector for Clause 8.6. The evaluation programme must align with:

• RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices (7 Nov 2023, eff 1 Apr 2024): board-approved BCP/DR; periodic review; post-incident analysis; the MD treats repeated outages as governance failure. The 8.6 evaluation summary must reach the board Risk/IT Committee quarterly.
• RBI Cyber Security Framework in Banks (2 Jun 2016): CCMP, incident reporting within 2–6 hours, drills. The PIR must align with the RBI incident-reporting timeline.
• SEBI CSCRF (20 Aug 2024): the "Learn" function (post-incident analysis, lessons-logged, feedback into controls) is 8.6 in regulatory form. SEBI-regulated entities must demonstrate the PIR discipline and the corrective-action loop.
• SEBI BCP/DR for MIIs (22 Mar 2021): document review cadence; post-drill review; RTO ≤ 2 hours for critical systems. MIIs must evaluate after every drill and update documents based on findings.
• IRDAI Information & Cyber Security Guidelines 2023 (24 Apr 2023): annual compliance reporting within 90 days of FY-end; DR drill review. Insurers' 8.6 evaluation feeds the annual compliance certificate.
• CERT-In Directions (28 Apr 2022): 6-hour incident report; post-incident cooperation. The PIR is the evidentiary backbone for CERT-In cooperation.

BFSI-specific 8.6 emphasis: the corrective-action closure rate (KPI 8) and the repeat-finding rate (KPI 10) must be board-reported; the HDFC pattern (repeated outages → regulatory action) is the cautionary anchor; capability-currency monitoring for payment and core-banking systems is non-negotiable; the evaluation must cover the concentration risk of critical third-party providers (payment switches, NPCI dependencies, cloud providers).

Healthcare

Patient-safety consequence. The AIIMS Delhi ransomware (23 Nov 2022), primary and backup servers encrypted, e-Hospital down 6–15 days, OPD/admissions/billing/labs reverted to paper, NIA cyberterrorism probe, is the canonical 8.6 failure anchor: a capability (tested backup, clinical manual fallback) that was assumed but not evaluated, and was discovered missing mid-incident. Healthcare 8.6 emphasis:

• Clinical-manual-fallback capability must be evaluated for currency (are the paper forms available? are staff trained on the manual workflow?).
• Backup-restoration capability for clinical systems must be tested (not just replication status, actual restore to a test environment).
• Medical-device dependencies (IoMT) must be in the capability inventory and evaluated for BC.
• The PIR for a healthcare disruption must include a patient-safety impact assessment.
• IRDAI applies to health insurers; DPDP applies to health data (Sensitive Personal Data under DPDP).

IT/ITeS and SaaS

Client-contract-driven. The 8.6 programme must cover:

• Client-facing SLAs and the supplier's own BC commitments (the client contract's BC/DR clauses are evaluation inputs).
• DORA applicability if serving EU financial entities (Art 13 "learning and evolving" is the 8.6 equivalent; TLPT findings under Art 26 are high-value inputs).
• Software-supply-chain risk (the SolarWinds/Kaseya pattern), evaluation must cover the integrity of vendor updates and the segmentation of "trusted vendor" systems.
• The Cognizant Chennai 2015 success (closed delivery centres, invoked BCP, relocated staff, reaffirmed ≥$12.41bn guidance) is the positive anchor, a tested capability that worked under real stress.
• Multi-tenant SaaS DR capability: failover and failback tested; tenant-isolation in the DR environment validated.

Manufacturing (especially pharma/chemical)

Production-stoppage consequence. The LG Polymers Vizag styrene gas leak (7 May 2020; 12–13 fatalities; NGT ₹50 cr interim penalty; plant permanently closed) is the catastrophic 8.6 failure anchor, a capability (safety systems, emergency response) that was not evaluated and not maintained. Manufacturing 8.6 emphasis:

• OT/IT segmentation capability evaluated for currency.
• Industrial-disaster response capability (on-site and off-site emergency plans) evaluated per NDMA Chemical Disaster Guidelines 2007.
• Production-line RTO/MBCO values validated against supplier and raw-material continuity.
• The Maruti Suzuki Manesar violence (18 Jul 2012; ~₹1,400 cr lockout loss) is the anchor for workplace-violence/industrial-relations as a BC scenario, the evaluation must cover the people-safety and mutual-aid capabilities.

Government and public sector

NDMA Disaster Management Plan template. The 8.6 evaluation aligns with the DMP review cycle:

• The NDMA Guidelines for Preparation of DMPs (2014) provide the canonical DMP template (Prevention/Mitigation/Preparedness/Response/Relief/Recovery & Reconstruction/Capacity Building); the evaluation checks the DMP against current organisational and threat reality.
• The Disaster Management Act 2005 (Section 35/37/40) casts duties on ministries/departments; the evaluation evidences compliance.
• For CPSEs and PSUs, the 8.6 evaluation feeds the annual DMP review and the NDMA compliance reporting.

Maturity Model

The maturity model below assesses the Clause 8.6 evaluation programme on five levels, with indicative INR investment estimates for a mid-market (250–2,000) firm. The full self-assessment is toolkit doc 12.

Level 1, Ad hoc / Reactive

• Evaluation posture: No scheduled evaluation. PIRs conducted only when the regulator asks or after a major incident forces it. No inventory. No corrective-action log.
• Documentation currency: Unknown. Plans are whatever was last written; contact lists are stale.
• Capability currency: Unknown. Replication, backups, DR sites assumed working.
• Typical findings: Stale contacts; untested backups; plans that describe a previous organisation.
• Indicative investment: ₹0–3 lakh per year (essentially unfunded; ad hoc effort only).
• Regulatory exposure: High. A regulator examination would find multiple nonconformities.

Level 2, Scheduled but weak loop

• Evaluation posture: Annual documentation review exists on paper. PIRs conducted after major incidents but findings not consistently tracked. Inventory exists but is incomplete.
• Documentation currency: Reviewed annually, but reviews may be checkbox exercises. Contact lists refreshed annually (not quarterly).
• Capability currency: Reviewed annually, but not between reviews. Replication/backup status checked manually, infrequently.
• Typical findings: PIR actions open with no closure; capabilities that drifted between reviews; changes that did not trigger evaluation.
• Indicative investment: ₹8–18 lakh per year (part-time BCM effort; basic tooling, spreadsheet + collaboration platform).
• Regulatory exposure: Medium. The programme exists but the loop is weak; recurrence risk is the primary concern.

Level 3, Scheduled + triggered, closed loop

• Evaluation posture: Tiered scheduled cadence (quarterly/semi-annual/annual). PIRs for every disruption and near-miss. Change-trigger process live. Corrective-action log with monthly review and escalation.
• Documentation currency: Tier-1 quarterly; contact lists tested quarterly. Currency percentage ≥ 90%.
• Capability currency: Tier-1 quarterly; replication/backup/failover tested quarterly. Some automated monitoring.
• Typical findings: Fewer stale-document findings; more capability findings (because they are now looked for); corrective-action closure rate ≥ 85%.
• Indicative investment: ₹40–80 lakh per year (1 FTE BCM analyst; growing GRC SaaS; crisis-notification platform; external PIR facilitator).
• Regulatory exposure: Low. The programme is demonstrable; the loop closes.

Level 4, Predictive and ecosystem-aware

• Evaluation posture: Continuous capability-currency monitoring for tier-1 and tier-2. Predictive evaluation (trend data anticipates decay). Ecosystem evaluation (supplier BC tested; industry threat intelligence integrated).
• Documentation currency: Currency percentage ≥ 95% for tier-1; near-real-time contact-list currency via automated testing.
• Capability currency: Automated monitoring with alerting; drift detected before it becomes a finding.
• Typical findings: Predictive findings (what will break next); ecosystem findings (supplier weaknesses); lessons generalised into design changes.
• Indicative investment: ₹80–150 lakh per year (BCM team of 2–3; enterprise or mid-market GRC platform with integration; automated capability monitoring; supplier-BC testing programme).
• Regulatory exposure: Very low. The programme anticipates and prevents.

Level 5, Resilience by design

• Evaluation posture: The evaluation programme is self-improving. 8.6 findings drive Clause 8.3 strategy changes (resilience by design). Regulator-witnessed exercises and PIRs. The programme is a competitive differentiator (client due-diligence asset).
• Documentation currency: Near-100% for all tiers.
• Capability currency: Continuous, automated, with chaos-engineering-style proactive failure injection.
• Typical findings: Design-level findings (architecture changes to eliminate failure modes); strategic findings (new risk landscapes).
• Indicative investment: ₹150–300 lakh+ per year (mature BCM function; enterprise IRM suite; chaos engineering; TLPT-grade exercises; ecosystem-wide evaluation).
• Regulatory exposure: Minimal. The programme sets the regulatory bar.

Maturity advancement guidance

• L1 → L2: Build the inventory; establish the annual review; create the corrective-action log. The hardest step, moving from "we evaluate when forced" to "we evaluate on a schedule."
• L2 → L3: Fix the loop (corrective-action closure); add the PIR discipline; add the change-trigger process; tier the cadence. The step that prevents the HDFC/DBS recurrence pattern.
• L3 → L4: Add automated capability-currency monitoring; add predictive evaluation; add ecosystem evaluation. The step that moves from reactive to anticipatory.
• L4 → L5: Drive design changes from findings; regulator-witnessed programme; competitive differentiation. The step that makes resilience a strategic asset.

Emerging Trends

Regulatory convergence on the "Learn" function

The most significant trend is the convergence of Indian and global regulators on the Clause 8.6 concept, under different labels. SEBI CSCRF's "Learn" function (2024), DORA's Article 13 "Learning and evolving" (2025), APRA CPS 230's annual exercise and internal-audit review (2025), and the RBI Master Direction's post-incident expectations (2024) all codify the 8.6 discipline as a regulatory minimum. An organisation that builds a strong 8.6 programme is simultaneously satisfying the "learn" layer of every framework it maps to, and the regulatory bar is rising. Expect the next RBI/SEBI/IRDAI cycle to tighten the expectation further, particularly on corrective-action closure evidence and PIR timeliness.

DPDP and the PIR as legal evidence

The DPDP Act 2023 and the DPDP Rules 2025 transform the post-breach PIR from a good-practice artefact into legal evidence. A Data Protection Board proceeding assessing a ₹250-crore penalty for "inadequate safeguards" will ask: what was your post-breach review? What did it find? What did you do about it? An organisation that cannot produce a PIR, or whose PIR found the gap but did not correct it, is in a materially weaker legal position. The 8.6 PIR is now a component of the DPDP defence, not just a BCM discipline.

Software-supply-chain compromise as an evaluation trigger

The SolarWinds SUNBURST (2020), Kaseya VSA (2021), and CDK Global (2024) incidents established that software-supply-chain compromise is a recurring BC disruption mode. For 8.6, this means the evaluation programme must treat vendor software updates as a capability to be evaluated, build-pipeline integrity, signed updates, segmentation of vendor-administered tooling, and SBOM (software bill of materials) currency. The change-trigger process must fire when a vendor discloses a supply-chain incident, even if the organisation's own systems are not yet affected.

AI and the automation of evaluation

Artificial intelligence is beginning to automate parts of the 8.6 evaluation: contact-list currency checks against HR data; documentation-drift detection (comparing plan content against current system inventories); replication-status trending and anomaly detection; even draft PIR timelines from incident logs. For a growing company, the pragmatic path is to start with the deterministic automations (contact-list cross-check, replication-status alerting) and adopt AI-assisted PIR drafting as the tooling matures. The human judgement, the "suitable, adequate, effective" assessment, remains with the BCM; AI amplifies the evidence-gathering.

Operational resilience beyond BC

The broader trend, visible in DORA, APRA CPS 230, HKMA OR-2, and the UK operational-resilience regime, is a shift from "continuity of operations" (recover from disruption) to "operational resilience" (remain within tolerance through disruption). For Clause 8.6, this means the evaluation is increasingly judged not on "did you recover?" but on "did you stay within tolerance?", the APRA CPS 230 paragraph 38 triple (maximum disruption period, maximum data loss, minimum service levels). The evaluation programme should begin to frame its findings in tolerance terms, not just recovery terms, to align with this trajectory.

Climate change and Amendment 1:2024

ISO 22301:2019 Amendment 1:2024 added climate-change considerations to Clauses 4.1 and 4.2 (context and interested parties). For Clause 8.6, this means the evaluation programme must consider whether BC documentation and capabilities reflect climate-change-driven disruption scenarios, extreme heat (a growing concern for Indian data-centre and manufacturing operations), flooding (Chennai 2015, Kerala 2018 patterns), and supply-chain climate exposure. The change-trigger process should fire when climate-risk assessments are updated, and the evaluation should confirm that strategies and plans account for the amplified frequency and severity of climate events.

Concentration risk and ecosystem evaluation

The CrowdStrike 2024 global outage (a single-vendor content-update failure disabling ~8.5M Windows devices) and the Change Healthcare 2024 ransomware (a single-vendor near-monopoly disrupting the US healthcare payments system) established that concentration risk is a systemic BC issue. For 8.6, this means the evaluation programme must assess concentration, in technology vendors, in cloud providers, in payment rails, in critical suppliers, and evaluate whether the organisation's continuity capabilities account for the simultaneous failure of a concentrated dependency. Ecosystem evaluation (supplier BC, industry-wide dependencies) is moving from L4 maturity to L3 expectation.

References and Further Reading

The standard and companion guidance

• ISO 22301:2019 + Amendment 1:2024, Security and resilience, Business continuity management systems, Requirements (the standard; paraphrased, never reproduced).
• ISO 22313:2020, Security and resilience, Business continuity management systems, Guidance on the use of ISO 22301 (companion guidance per clause).
• ISO 22300:2021, Security and resilience, Vocabulary (RTO/RPO/MTPD/MBCO definitions; note: 22300:2018 is withdrawn).
• ISO/TS 22317:2021, Guidelines for business impact analysis (the BIA methodology).
• ISO/TS 22331:2018, Guidelines for business continuity strategy.
• ISO/TS 22318:2021, Guidelines for supply chain continuity.
• ISO/TS 22330, Guidelines for people aspects of BC.
• ISO 22316, Guidelines for organizational resilience.

Indian regulators and instruments

• RBI Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (7 Nov 2023, eff 1 Apr 2024), rbi.org.in.
• RBI Cyber Security Framework in Banks (2 Jun 2016), rbi.org.in.
• RBI Master Direction on Outsourcing of Information Technology Services (10 Apr 2023), rbi.org.in.
• SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities (SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 Aug 2024), sebi.gov.in.
• SEBI Guidelines for BCP and DR of Market Infrastructure Institutions (SEBI/HO/MRD1/DTCS/CIR/P/2021/33, 22 Mar 2021), sebi.gov.in.
• IRDAI Information and Cyber Security Guidelines, 2023 (24 Apr 2023), irdai.gov.in.
• CERT-In Directions under Section 70B(6) of the IT Act, 2000 (No. 20(3)/2022-CERT-In, 28 Apr 2022), cert-in.org.in.
• Digital Personal Data Protection Act, 2023 (Act 22/2023) + DPDP Rules 2025, meity.gov.in.
• Disaster Management Act, 2005 + NDMA Guidelines, ndma.gov.in.
• Companies Act, 2013 (Section 134(3)(n), Section 177), mca.gov.in.
• Information Technology Act, 2000 (Sections 43, 65, 66, 70, 70A, 70B), indiacode.nic.in.

Global frameworks

• NIST SP 800-34 Rev 1, Contingency Planning Guide for Federal Information Systems (May 2010), nist.gov.
• NIST SP 800-160 Vol 1 + Vol 2 Rev 1, Systems Security Engineering / Cyber Resilience, nist.gov.
• NIST Cybersecurity Framework 2.0 (26 Feb 2024), Recover function (RC.RP, RC.CO, RC.IM), nist.gov.
• FEMA FCD-1 (17 Jan 2017) + FCD-2 (13 Jun 2017), Continuity of Operations, fema.gov.
• FFIEC IT Examination Handbook, Business Continuity Management Booklet (Nov 2019), ffiec.gov.
• DORA, Regulation (EU) 2022/2554 (14 Dec 2022; applies 17 Jan 2025), eur-lex.europa.eu. Article 13 (Learning and evolving); Article 11(5) (BIA); Article 11(6) (yearly BCP testing); Article 26 (TLPT).
• APRA CPS 230, Operational Risk Management (eff 1 Jul 2025), apra.gov.au. Paragraphs 34–46 (business continuity); paragraph 38 (tolerance levels); paragraph 43 (annual exercise); paragraph 46 (internal audit review).
• MAS TRM Guidelines (18 Jan 2021) + MAS Guidelines on Business Continuity Management, mas.gov.sg.
• HKMA Supervisory Policy Manual TM-G-2 (31 May 2022) + OR-2 (31 May 2022), hkma.gov.hk.

Practitioner bodies and data

• DRI professional-practice framework (10 practices, living framework, free at drii.org), a practitioner body's professional-practice framework.
• BCI Horizon Scan 2025 ("Complex and Interconnected Risk") and BCI Horizon Scan 2024, thebci.org. Industry survey datasets on BCM risk trends.

Incident anchors (primary-sourced)

• AIIMS Delhi ransomware (23 Nov 2022), peer-reviewed illustrative scenario, Indian Journal of Medical Informatics; thehindu.com; NIA probe.
• HDFC Bank RBI action (2 Dec 2020), RBI order; finextra.com; livemint.com. Partial lift ~Aug 2021; full lift ~Mar 2022.
• DBS Singapore MAS action (2023), mas.gov.sg (six-month IT-change pause); reuters.com.
• Cognizant Maze ransomware (18–20 Apr 2020), SEC 10-Q/K (ctsh-20201231); ciodive.com; ~$50–70M Q2 2020 impact.
• Cognizant Chennai floods response (Dec 2015), news.cognizant.com; reaffirmed ≥$12.41bn FY2015 guidance.
• LG Polymers Vizag styrene gas leak (7 May 2020), NGT Order (OA 73/2020, ₹50 cr interim); greentribunal.gov.in; thehindu.com.
• Go First insolvency (filed 2 May 2023), NCLT; ₹597 cr refund liability (31 Jul 2023 disclosure); thehindu.com; reuters.com.
• SpiceJet DGCA action (27 Jul 2022), 50% capacity cap; indiatoday.in; thehindu.com.
• Mumbai power grid blackout (12 Oct 2020), WRPC report; Recorded Future/RedEcho attribution (contested); Maharashtra vs Union positions.
• CrowdStrike global IT outage (19 Jul 2024), crowdstrike.com preliminary report; Microsoft estimate ~8.5M devices; Parametrix ~$5.4B Fortune 500 estimate.
• Maersk NotPetya (27 Jun 2017), ~$200–300M disclosed cost; wired.com; cnbc.com.
• Change Healthcare ransomware (21 Feb 2024), unitedhealthgroup.com Q3 2024; aha.org; ~100M individuals' PHI.
• Tokyo Stock Exchange full-day halt (1 Oct 2020), reuters.com; jpx.co.jp.
• Knight Capital $440M loss (1 Aug 2012), dealbook.nytimes.com.
• Infosys McCamish Systems LockBit (~29 Oct 2023), ~6M individuals affected; ~$17.5M class-action settlement.

Certification bodies and audit framework

• ISO/IEC 17021-1:2015 + IAF Mandatory Documents, the rule-set governing all ISO 22301 audits (note: no BCMS-specific IAF MD exists; IAF MD 6 is GHG).
• Accredited certification bodies: BSI Group, DNV, SGS, TÜV, Bureau Veritas, Intertek, NQA. (Note: "BSI" the certification body is distinct from the German BSI, bsi.bund.de, which is the federal cyber-security authority.)

This guide paraphrases ISO 22301:2019 Clause 8.6 throughout. ISO 22301 Clause 8.6 asks organizations to evaluate whether the continuity documentation and capabilities remain suitable, adequate, and effective, especially after disruptions and significant change. The standard's official clause text is copyrighted and is not reproduced in this guide or the accompanying toolkit. Sample policy and procedure "shall" clauses in the toolkit are the author's own drafting, operationalising the requirement; they are not the standard's text.