BCP/DR Posture Assessment: Meeting RBI and SEBI RC.1–RC.4 Without 3 Months of Consultancy

Introduction

Most regulated entities have a BCP document. The gap is not documentation — it is operationalisation. An untested BCP is not a plan; it is a fiction. SEBI and RBI both require evidence of actual test execution, and inspectors have become increasingly specific about what that evidence must contain.

The RC domain of SEBI CSCRF (Respond and Recover) is not optional, and its sub-categories RC.1 through RC.4 represent a structured cascade: you cannot meaningfully satisfy RC.4 (annual full DR test) without first completing RC.2 (BIA with RTO/RPO) and RC.3 (operational DR site). The 1.7 average maturity score reflects exactly this failure mode — entities either have a document that hasn't been reviewed, or a DR site that hasn't been tested, or RTO/RPO values that were never justified by a BIA.

This article gives you the methodology to close all four sub-categories, understand what RBI DPSC requires in parallel, and structure the evidence pack that satisfies both regulators without engaging a consultancy for three months.

What RC.1–RC.4 Actually Require

The four sub-categories are sequential in intent. Each builds on the prior one. Inspectors evaluate them as a chain, not a checklist.

A common misconception is that RC.4 can be satisfied with a tabletop exercise. It cannot. A tabletop tests awareness — it does not test systems. SEBI inspectors will ask for actual failover logs, not facilitation notes.

RBI DPSC Resiliency Requirements

While SEBI CSCRF governs market infrastructure participants, brokers, and listed entities, RBI DPSC governs banks and payment system operators — and the resiliency requirements are specific and quantified. If your organisation falls under both regulators, DPSC requirements generally set the stricter floor.

• 99.5% availability for core payment processing systems, calculated monthly per payment channel
• 4-hour RTO for ATM processing infrastructure
• Same-day recovery for RTGS and NEFT critical payment rails
• Quarterly DR drills for internet banking and mobile banking platforms
• Communication to RBI within 2 hours of any outage exceeding 30 minutes on regulated payment channels

Industry RTO/RPO Benchmarks

The values below represent the regulatory floor, not aspirational targets. Your BIA may justify stricter targets based on financial impact calculation. Where your current RTO/RPO exceed these thresholds, you are by definition non-compliant with the applicable regulatory requirement.

BIA Methodology: The Foundation SEBI Checks First

The BIA document is what SEBI inspectors review before evaluating anything else in the RC domain. Without a credible BIA, your RTO/RPO values have no defensible basis and your DR test results cannot be validated against targets. A SEBI-compliant BIA must cover four elements:

The 9 RC Failures That Appear in Every SEBI Inspection

Across inspection findings published by SEBI and practitioner-reported outcomes, nine gaps appear with consistent frequency. These are the items inspectors check directly — not derived from a maturity model but from observed enforcement patterns.

1. 01
   BCP Document Never Tested The most common RC finding. An untested BCP is treated as effectively non-existent. Inspectors request the most recent DR test report as their first evidence request in the RC domain. If none exists, RC.4 is automatically scored 0.
2. 02
   DR Site Not Truly Operational "Warm standby" sites without live workload in the past 12 months are not considered operational. Inspectors request the last DR test report to verify that systems at the DR site were actually activated. A site agreement alone does not satisfy RC.3.
3. 03
   RTO/RPO Set Arbitrarily RTO/RPO values chosen without a BIA have no regulatory standing. When inspectors ask how the 4-hour RTO was derived and the answer is "IT team judgment," RC.2 fails. The BIA financial impact calculation is what creates the defensible basis.
4. 04
   Last DR Test Was 18+ Months Ago RC.4 explicitly requires annual testing. A test gap exceeding 18 months is treated as a major finding regardless of how comprehensive the prior test was. Organisations often complete a DR test once and consider the obligation satisfied indefinitely.
5. 05
   Tabletop Test Only — No Actual Failover A tabletop exercise is a Level 1 awareness activity. It does not prove that systems can actually recover within the stated RTO. Inspectors specifically ask whether actual failover was performed and whether RTO was measured against BIA targets during the exercise.
6. 06
   Third-Party Systems Excluded from DR Scope DR testing that covers internal infrastructure but excludes the core banking system hosted by a vendor, or cloud SaaS used for critical operations, is materially incomplete. If the process is critical, its entire dependency chain — including vendor-hosted components — must be in scope.
7. 07
   No Regulator Communication Plan No documented procedure for notifying RBI, SEBI, or CERT-In during an outage. The RBI 2-hour reporting obligation requires a pre-defined escalation path with named contacts and draft notification templates. An improvised response during an incident will not meet the timeline.
8. 08
   Recovery Runbooks Outdated Runbooks not updated after infrastructure changes are a systemic risk. If the organisation migrated CBS to a new version 18 months ago and the DR runbooks still reference the prior architecture, the DR test may fail operationally even when the DR site is functional.
9. 09
   No Post-Test Lessons Learned Tests completed but undocumented do not satisfy RC.4. A post-test report listing what worked, what failed, actual measured RTO vs. BIA target, identified deficiencies, and a deficiency closure register with dates is a mandatory component of the evidence pack. Without it, the test is treated as anecdotal.

The 3-Tier DR Test Evidence SEBI Accepts

SEBI does not define a single prescribed test format, but inspection outcomes reveal a clear hierarchy of what constitutes acceptable evidence for RC.4. The tier you need depends on your regulated entity category.

Building the Evidence Pack

The evidence pack for RC.1–RC.4 should be structured as a single dossier with four sections, one per sub-category. Each section should open with the requirement, followed by the evidence artefacts, followed by a self-assessment maturity score with justification.

For RC.1: Board-approved BCP with approval date, and meeting minutes from the most recent annual review. The minutes must show that BCP was a named agenda item, not merely referenced in passing.

For RC.2: The BIA report with all four elements (process inventory, dependency maps, financial impact calculations, RTO/RPO sign-off matrix). The sign-off matrix should show process name, agreed RTO, agreed RPO, IT owner, business owner, and approval date.

For RC.3: DR site agreement or infrastructure confirmation letter, a current asset inventory of DR-hosted systems, and the last connectivity test report with date, systems tested, and pass/fail outcome.

For RC.4: The full test package — test plan, execution log with timestamps and named participants, post-test report with deficiency register, and evidence of closure for any deficiencies raised in prior tests. If deficiencies remain open, the register must show target closure dates and current status.