Meeting RBI Cyber Security Guidelines: VAPT and Risk Standards for BFSI

I. Introduction: The Regulatory Paradigm Shift

The shock of 31 July 2026

On 31 July 2026, the Reserve Bank of India repealed 628 supervisory circulars in a single stroke. The Cyber Security Framework in Banks, the 2016 circular that had anchored most Indian bank security programmes for a decade, was repealed along with the other 628 circulars.

In its place, the Department of Supervision issued 64 consolidated Master Directions across 11 entity categories. Cybersecurity did not get one replacement. It got seven parallel instruments issued the same day, sharing a single title, the Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026, with a separate Direction for each class of regulated entity.

They commenced on issuance. There was no transition window.

Seven weeks later, most compliance manuals in Indian BFSI still cite the repealed text. Policy documents, vendor questionnaires and internal audit scopes all reference circular numbers that no longer point to anything. None of that becomes non-compliant overnight, because the substance largely carried forward. It does mean that the document you hand to an inspector cites an instrument that they no longer supervise.

What this guide does

The RBI cyber security guidelines for BFSI are now entity-specific, which raises a question that did not exist before: which of the seven Directions actually binds you, and what does it demand that its siblings do not?

This guide answers that first, because everything else depends on it. It then covers testing cadence and evidence, the six-hour DAKSH clock and how it interacts with CERT-In, governance and resilience, vendor flow-down, and how RBI sits alongside SEBI, IRDAI and DPDP. It closes with a self-audit checklist and the gaps that get written up during inspection.

Paragraph references are given where they help. Verify them against the Direction text before relying on them in a submission.

II. The New Architecture: What Survived and Which Direction Applies to You?

Seven Directions now carry the RBI cybersecurity framework, one per entity class, and they are not identical. Two contain no red-teaming paragraph. One omits the rogue application takedown duty. One drafts vulnerability assessment and penetration testing differently from every sibling. Reading the wrong instrument produces a compliant-looking programme against the wrong obligations.

This section maps the seven and explains how obligations are tiered inside each.

The seven parallel instruments

The consolidation was presented as a restructuring rather than a rewrite, and RBI received 767 stakeholder comments on the April 2026 drafts, of which the accepted changes were largely clarity and accuracy corrections. That framing is broadly right for the 64 Directions as a whole. It understates what happened in the cyber instruments, where the drafting is materially tighter than the 2016 circular on testing, governance and auditor qualification.

The differences between siblings are the part that catches people. An organisation running a group structure with a bank, an NBFC and a payments arm is now reading three separate instruments with three different baselines. A head of security who assumes the commercial bank text applies group-wide will over-comply in some places and under-comply in others.

Proportionality and tiered obligations

Inside each instrument, obligations scale. What changed is the variable they scale on.

NBFCs are tiered by Scale-Based Regulation layer. A Base Layer NBFC below the ₹500 crore asset threshold carries a reduced chapter rather than the full baseline. The middle layer and above carry the complete set. The cybersecurity framework for NBFCs is therefore not a single standard, and an NBFC that crosses a layer boundary inherits a materially heavier obligation set in the same financial year.

UCBs tier by digital depth and payment-system interconnectedness. There are four levels, and asset size is not the deciding variable. A small co-operative bank that is a direct UPI member sits higher than its balance sheet suggests, because the tiering follows the risk its connectivity creates rather than its size.

Non-bank payment system operators sit outside this framework entirely. They remain under the Master Direction on Cyber Resilience and Digital Payment Security Controls issued in July 2024, with a phased calendar: large PSOs from 1 April 2025, medium from 1 April 2026, and small from 1 April 2028. If you are a PSO, that is your instrument.

Carve-outs worth knowing

Smaller entities receive genuine relief in several areas, but the relief is narrower than most assume. Reduced scope generally applies to advanced capabilities such as red teaming, threat hunting and continuous control validation. The core obligations- asset inventory, access control, logging, vulnerability management, incident reporting and board oversight- apply across the board, with differences of depth rather than of kind.

The practical first step for any BFSI compliance lead is short: identify your instrument, identify your tier within it, and map your existing policy set against that specific text rather than against the framework you have been working on since 2016.

III. RBI VAPT Mandates for Regulated Entities: Cadence, Scope, and Evidence

For commercial banks, the 2026 Directions set vulnerability assessment at every six months and penetration testing at every twelve months for critical systems and DMZ customer-facing infrastructure, with additional testing triggered by significant change. The wording differs across the seven instruments, so confirm the cadence in yours rather than assuming the bank text applies.

This section covers what must be tested, how often, and what evidence an inspector now expects.

Core testing cadence

The RBI VAPT guidelines for banks are more prescriptive than the 2016 circular, and the split between the two activities matters.

One caution that applies to every entity class. At least one of the seven Directions drafts the VA and PT obligation differently from its siblings, meaning that a group running multiple regulated entities cannot standardise on a single testing calendar without checking each instrument.

Change triggers are where most programmes underperform. The annual date is straightforward to diarise. The triggers require a standing list and an owner. At minimum:

• Major code deployment affecting authentication, authorisation or payment flows
• New or materially changed API integration, including partner and aggregator connections
• Architectural change, cloud migration, or a new region
• New customer-facing channel or application release
• Onboarding of a critical technology service provider
• Following any reportable security incident
• A CERT-In advisory or vulnerability note affecting technology you run

Without a written trigger list reviewed at release planning, “testing on significant change” remains a sentence in a policy that nobody applies.

Technical testing scope

The BFSI vulnerability assessment requirements now extend significantly beyond the perimeter scan that many programmes still conduct.

Customer-facing applications: Internet banking, mobile applications on both platforms, and any channel a customer authenticates into. Testing must be authenticated and cover multiple user roles, because severe findings can occur between two legitimate users rather than outside the login.

DMZ and internet-facing infrastructure: Edge appliances, reverse proxies, VPN concentrators and exposed management interfaces. Edge devices appear in the CISA Known Exploited Vulnerabilities catalogue with regularity, which makes patch currency here a live rather than theoretical concern.

Core banking and internal infrastructure: Segmentation validation, lateral movement from an assumed foothold, Active Directory and identity infrastructure, and privilege escalation paths are all critical areas of concern. This stage is where an incident becomes an event.

APIs: Treated separately from the applications that front them, because the interface hides nothing from a direct caller. Object-level authorisation, function-level authorisation and rate limiting per authenticated identity are the recurring failure categories, and no scanner evaluates them reliably.

Cloud configuration: IAM policy is scoped to least privilege, storage exposure, encryption at rest across databases and backups, key management, logging coverage, and data residency verified against actual region settings rather than stated intent. That last item catches Indian institutions regularly, and section V returns to it.

Production testing: The Directions push toward testing the environment that actually serves customers. A staging clone with sanitised data and a different configuration is not the same system, and inspectors increasingly challenge silent substitution during inspection.

The evidence trail

The evidence trail in this case is the largest practical shift, and it is where most programmes will feel the change.

A PDF report filed once a year no longer discharges the obligation. What inspectors now look for:

Remediation proof, not remediation intent: For every high and critical finding, evidence that the fix was deployed and independently verified. A ticket marked ‘resolved’ is not verified.

Closure validation by retest: The retest report, dated, confirms both that the original finding is closed and that the patch introduced nothing new.

Auditor qualification records: The Directions require the regulated entity to assess the qualification, expertise, credentials and competency of both the testing firm and the individual personnel it assigns, at every selection, appointment, engagement and renewal. Keep the assessment, not just the contract.

Quarterly closure reporting: A pack for the IT Strategy Committee and the Information Security Committee showing open findings by severity and age, with movement since the last quarter. Many banks did not produce this artefact before 2026, but they must now do so.

Risk acceptance documentation: Where a finding is accepted rather than fixed, a record must be kept naming the approver, the date, the compensating control, and the expiry date. Silence is no longer a defensible position on an open finding.

The direction of travel is from point-in-time attestation towards continuous demonstrable control, and the NBFC instrument goes furthest, inviting consideration of continuous auditing approaches for critical systems. Build the evidence as a by-product of operations rather than assembling it before an inspection, because reconstructed evidence never carries accurate dates, and inspectors notice.

IV. The Critical Six-Hour Clock: Detect, Comply, Report

Cyber incidents must be reported to RBI through the DAKSH portal within six hours of detection, followed by a detailed root cause analysis within 21 days. Most regulated entities simultaneously carry CERT-In’s six-hour obligation under Direction 20(3)/2022, to a different authority, on a trigger that does not match. Running both clocks is a runbook problem, not a technology problem.

This section covers each obligation and how to de-conflict them.

The DAKSH reporting mandate

The clock starts at detection, not at confirmation. That distinction is the single most misread element of the requirement, and it is where competent incident response teams fail a compliance obligation they never knew was running.

The sequence:

Within six hours of detection, the incident response team must submit an initial report through DAKSH that covers what was observed, the affected systems, the preliminary impact assessment, and the immediate containment action taken.

Within 21 days, a detailed root cause analysis must be completed, including the full timeline, the established attack path, the completed remediation, and the controls added to prevent recurrence.

The failure pattern is consistent, and it is never technical. Detection works. An analyst spots anomalous activity at 11 pm on a Saturday, escalates in a channel, and the team contains it overnight. On Monday, somebody asks when RBI was notified. Nobody, because the runbook ended at “escalate to the CISO”; the CISO was travelling, and no backup was named.

What resolves it takes an afternoon: a named primary and backup with 24-hour contact in the on-call rota, a pre-drafted DAKSH submission template mapped to your own alert taxonomy, and a documented decision rule agreed with legal about what constitutes detection.

Managing CERT-In in parallel

Two clocks, two authorities, two triggers that overlap but do not match.

A ransomware event affecting a core system triggers both. Targeted scanning of your network triggers CERT-In and may not meet the RBI threshold. An internal data exposure with no external actor may trigger RBI and not CERT-In’s categories.

Add a determination step at the top of the runbook. Before the containment write-up, before anything else: does this trigger RBI, CERT-In, both, or neither? That call must be made in minutes, because both clocks are already running.

Where personal data is involved, a third obligation may apply. The DPDP framework adds notification to the Data Protection Board and to affected data principals, on its own timeline, once the substantive provisions commence. Build the decision tree once rather than discovering it mid-incident.

Triage under time constraint

Six hours sounds generous until you have spent four of them establishing whether the alert is real.

Three practices make the difference. Report on the basis of what you know at the four-hour mark rather than waiting for a complete picture, because the obligation attaches to detection rather than to certainty. Keep the initial submission factual and avoid speculating on attribution or root cause, since the 21-day report exists for that. And log the moment of detection with a timestamp and the name of whoever noticed, because if the timeline is later questioned, that record is your evidence.

Test the path out of hours. A tabletop run at 3 pm on a Tuesday has not tested the thing that actually fails.

Need to Validate Your RBI VAPT Requirements?

Assess your applications, APIs, cloud, and infrastructure against the requirements applicable to your regulated entity.

Request an RBI-Aligned VAPT Assessment→

V. Governance, Resilience, and Third-Party Upstream Compliance

The 2026 Directions push accountability upward and outward. The CISO must sit outside the operational IT reporting line; the IT Strategy Committee carries defined composition and expertise requirements; disaster recovery must be proven by running the secondary site as primary; and obligations flow down contractually to technology vendors that RBI does not regulate directly.

This section covers each in turn.

Board-level accountability

CISO independence is now structural. The Directions require that the CISO does not report to the Head of IT. The reasoning is straightforward: an officer cannot credibly escalate a risk that delays delivery if their appraisal is written by the person responsible for delivery.

In practice, this requirement means a reporting line to the MD, CEO, a board committee or the Chief Risk Officer, with documented independence in appraisal and budget. Institutions that have satisfied this requirement on paper by adding a dotted line while leaving the solid line in IT should expect the question during inspection.

The IT Strategy Committee has composition and expertise requirements, including chair expertise thresholds, and must meet at a defined minimum frequency. It is not a standing item on an existing committee agenda.

The quarterly closure pack for the ITSC and the Information Security Committee is the artefact that most institutions did not produce before. Open findings by severity and age, movement since last quarter, overdue items with owners named, and risk acceptances with expiry dates. Build it as a standing report rather than assembling it before each meeting.

Modern resilience testing

The definition of “tested” tightened considerably.

Disaster recovery drills are at least half-yearly, and the drill must involve the DR site actually running as primary for a full business day. Failing over for an hour on a Sunday and failing back does not meet the standard, because it does not test what a real invocation tests: whether the secondary site sustains real transaction volume, real batch processing and real customer load.

Near-zero RPO for critical systems. Recovery point objectives are measured in minutes rather than hours, which for most institutions is an architecture decision about synchronous replication rather than a backup policy decision.

RTO and RPO defined by the business and evidenced by measured drill results, not by aspiration recorded in a BCP document.

The question that separates a real capability from a documented one: when did you last restore into a clean environment and verify the data, rather than confirming the backup job succeeded?

Upstream vendor risk

This scenario is where an Indian fintech compliance audit becomes unavoidable for firms that RBI does not regulate at all.

The regulated entity remains accountable for outsourced technology. It discharges that accountability through contract, which means the obligations arrive at the vendor’s door whether or not the vendor is named in any Direction. A fintech whose largest customer is a bank absorbs most of this framework through its master services agreement.

What flows down in practice:

• Right to audit, and in many cases a right to have RBI or its appointed auditor inspect
• Security testing evidence, at the cadence the regulated entity owes
• Incident notification fast enough for the bank to meet its own six-hour obligation, which in practice means notification within hours rather than days
• Data localisation warranties and evidence
• Business continuity and exit obligations, including data return or destruction with certification
• Sub-contractor restrictions and approval
• Concentration risk disclosure where the vendor serves multiple regulated entities

The clause that is most often missing is the incident clause. If your contract allows the vendor six hours to notify you, your own six hours have expired before you learn anything.

Cross-border data transfer and localisation

Cross-border data transfer compliance on the India side is governed by at least three instruments that do not align, and where they conflict, the most restrictive applies.

RBI payment data localisation: Circular DPSS.CO.OD.No.2785/06.08.005/2017-2018, dated 6 April 2018, requires payment system operators to store the entire end-to-end payment data only in systems located in India. Foreign processing is permitted for the foreign leg of a cross-border transaction, but the data must be deleted from foreign systems and brought back to India within 24 hours of payment processing. Sharing with foreign regulators requires prior RBI approval. Compliance is evidenced through a System Audit Report from a CERT-In empanelled auditor, alongside periodic certification signed at the CEO or MD level.

IRDAI: Policyholder, claims and underwriting data must be held in data centres located in India for insurers and intermediaries.

DPDP: The Act permits transfer except to countries that the Central Government restricts by notification, which is a negative-list approach rather than a localisation mandate. Note that MeitY has proposed bringing Significant Data Fiduciary cross-border restrictions into force earlier than the main timeline, so check the notified position.

Three practical failures recur. Backup and disaster recovery replication was configured to a foreign region years ago and never revisited. SaaS observability and logging platforms processing payment data outside India. And analytics pipelines are exporting transaction data for modelling.

Verify the actual region setting on every storage destination, including archives, snapshots and cold tiers. A localisation attestation that rests on a policy document rather than a configuration export is finding that it is waiting to be written.

VI. Interoperability: Balancing the Multi-Regulator Landscape

Large Indian financial groups sit under RBI, SEBI, IRDAI, CERT-In and the DPDP framework simultaneously. The obligations overlap heavily, which means one well-scoped assessment can evidence several of them, provided the control mapping is specified during scoping rather than retrofitted afterwards.

This section maps where they meet and where they diverge.

Cross-sector mapping

Where a bancassurance or capital markets arm sits

A bank with a capital markets division reads the Commercial Banks Direction for the bank and CSCRF for the SEBI-registered entity. They are separate obligations against separate legal entities, and an audit scoped to one does not discharge the other. The recurring inspection finding here is a group that ran a single enterprise-wide assessment and assumed it covered both.

The same applies to bancassurance. IRDAI’s requirements attach to the insurer, not to the distributing bank.

The overlap dividend

Scope one engagement to evidence several obligations rather than running separate audits per regulator. A single well-structured report can carry RBI closure-pack evidence, SEBI CSCRF control identifiers, ISO/IEC 27001 Annex A mapping and SOC 2 criteria simultaneously.

Two conditions make that work. Specify every applicable framework during scoping, because retrofitting a control mapping onto a delivered report is awkward and sometimes impossible. And index your evidence repository by control identifier rather than by regulator, so that one artefact can be produced against several obligations without duplication.

Organisations running separate audits for each regulator usually pay two or three times for overlapping work and produce four inconsistent versions of the same evidence.

Will Your VAPT Evidence Stand Up to Supervisory Review?

Get penetration testing, remediation validation, and retesting documented for your security and audit requirements.

Talk to a VAPT Expert→

VII. The BFSI Vulnerability Assessment and Compliance Checklist

Work through this checklist with your engineering, risk and compliance leads together. Each item is either evidenced or it is not, and an inspector asks for the evidence rather than the assertion.

Step-by-step self-audit protocol

1st Stage: Establish which instrument binds you

• Applicable Direction identified by entity class, and the correct text obtained
• Tier established within that instrument: NBFC Scale Based Regulation layer, UCB level, or PSO size band
• Group entities mapped separately, with a Direction identified for each regulated entity.
• Existing policy set mapped against the 2026 text, with references to repealed circulars listed for correction.
• Gap list produced against the new text rather than the 2016 framework

2nd Stage: Asset discovery and prioritisation

• Complete asset inventory covering applications, APIs, cloud accounts, third-party integrations and network infrastructure, with a named owner against each
• Inventory reconciled across four sources: gateway configuration, source repositories, passive traffic observation at the edge, and external reconnaissance including certificate transparency logs.
• Criticality classification applied, with customer-facing and payment-processing systems identified explicitly
• Data classification applied, with payment system data and personal data flagged for residency obligations
• Internet-facing attack surface enumerated, including forgotten staging hosts and deprecated API versions
• Legacy systems inventoried, with risk acceptance documented where they cannot be remediated.

3rd Stage: Scan and test frequency validation

• Vulnerability assessment cadence confirmed against your specific Direction, not the commercial bank text.
• Penetration testing cadence confirmed, with the annual date diarised and the engagement starting far enough ahead of it.
• Written change-trigger list, owned by a named person, reviewed at release planning
• Authenticated testing included, with at least two test accounts provisioned per user role.
• API testing scoped separately from the applications that front them
• Cloud configuration assessment included per provider
• Segmentation validation included
• Production testing agreed, with rules of engagement and halt conditions, or a documented rationale where staging is substituted.

4th Stage: Vendor selection and qualification

• Firm-level competency assessed and documented, at every selection and renewal.
• Individual assigned testers named, with certifications verified and written into the contract
• Where a Direction or another instrument names CERT-In empanelment, status verified against the live registry using the firm’s registered legal name, correct category and current validity dates
• Redacted sample report requested and read before signing
• Retesting included in scope, with the number of rounds stated
• Framework mapping specified up front, covering every regulator that applies to you
• Exclusions documented in writing

5th Stage: Evidence and closure

• Remediation proof retained for every high and critical finding
• Independent retest completed and dated
• Quarterly closure pack produced for the ITSC and the Information Security Committee
• Risk acceptances documented with approver, date, compensating control and expiry
• Evidence repository indexed by control identifier rather than by regulator
• DAKSH submissions and acknowledgements filed
• DR drill results recorded with achieved RTO and RPO against target

Common gaps identified during RBI inspections

The consistent theme is that these are ownership and evidence failures rather than control failures. The controls usually exist. Nobody owns the proof.

VIII. How Qualysec Accelerates RBI-Aligned Validation

Qualysec is a specialised penetration testing company working across web applications, APIs, cloud environments, mobile applications and infrastructure, with substantial delivery into Indian BFSI and fintech.

Hybrid testing mapped to the 2026 standards

Automation runs first and runs fast, clearing known CVEs, missing headers, TLS configuration and common misconfigurations so none of it consumes senior consultant hours. Certified consultants then spend the bulk of the engagement on the classes of tooling that structurally cannot reach: object-level and function-level authorisation across roles and tenants, business logic abuse in payment and lending flows, and attack paths assembled from findings that individually look unremarkable.

That distinction matters for a regulated entity, because the findings that become incidents are rarely the ones a scanner produces. On a recent engagement with a regulated financial platform preparing for a regulator submission, the application passed automated scanning with no critical authorisation finding. Our consultants opened two separately funded accounts and began substituting object identifiers between them by hand. The wallet endpoint accepted a transaction identifier as an API parameter and never verified the transaction belonged to the authenticated caller. Incrementing it returned another customer’s balance, transaction history and metadata, with sequential identifiers making the full customer base enumerable.

That was one of 18 findings in that engagement, alongside source code disclosure through unhandled stack traces, an open redirect usable for phishing from the client’s own domain, missing anti-CSRF protection on account settings, and session tokens that survived a password change.

Evidence built for supervisory review

Findings arrive mapped to the obligations you are evidencing rather than to a generic reference, so the report enters your closure pack directly instead of requiring translation. Each carries severity adjusted for your context, reproduction steps written for the engineer shipping the patch, business impact expressed in terms of what an attacker reaches, and remediation guidance. False positives are removed before delivery.

Reports are structured to satisfy 52-plus compliance frameworks, which means one engagement can serve RBI alongside SEBI CSCRF, ISO/IEC 27001 or SOC 2 where the mapping is specified during scoping.

On auditor qualification, the Directions require you to assess both the firm and the assigned personnel. We provide named consultants with verifiable certifications so that assessment is a document rather than a conversation. Qualysec holds CREST accreditation alongside ISO/IEC 27001:2022, ISO 9001:2015 and ISO 13485:2016, has delivered over 2,500 penetration test reports to 350-plus clients across 38 countries, and rates 4.9 across 31 verified reviews on Clutch.

Remediation verification within tight patch windows

Progress is visible live through the Qualysec Vulnerability Dashboard throughout the engagement, so you are not waiting on a report to learn what has been found. Your engineers get direct access to the consultant who found the issue, which is usually the difference between a three-day fix and a three-week one. Retesting is included as standard rather than invoiced separately, because a finding marked ‘closed’ without independent verification will not survive inspection.

One note on scope: this guide includes a section on interrogating vendors. Qualysec is a testing firm, not a managed security provider and not a regulatory advisory. There is no SOC, no round-the-clock monitoring, and no compliance consulting practice. This is built to find exploitable issues in your applications and infrastructure and prove they were fixed.

Found Gaps in Your RBI Cybersecurity Readiness?

Validate your vulnerabilities, remediation status, and testing evidence before they become inspection findings.

Schedule a VAPT Assessment→

IX. Frequently Asked Questions

Q1: Is the RBI Cyber Security Framework of 2016 still valid?

No. It was repealed on 31 July 2026, along with 627 other supervisory circulars, and replaced by seven entity-specific Directions issued under the title Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026. Those commenced immediately, with no transition window. Most of the substance carried forward, so a programme built to the 2016 framework is not suddenly non-compliant. Still, every citation in your policy set, audit scope, and vendor questionnaires now points to a repealed instrument.

Q2: Does RBI require quarterly VAPT?

No, and this claim appears on several vendor pages. For commercial banks, the cadence is at least a half-yearly vulnerability assessment and at least an annual penetration test for critical and DMZ customer-facing systems, plus testing triggered by significant change. Quarterly scanning of internet-facing systems is a SEBI CSCRF requirement, not an RBI one, which is likely where the confusion originates. Confirm the cadence in your own Direction, because the wording differs across the seven.

Q3: Do we need a CERT-In empanelled auditor to satisfy RBI VAPT requirements?

It depends on the obligation. Empanelment is specifically named for certain audits, notably the payment aggregator system audit and the data-localisation System Audit Report under the payment data storage circular. The 2026 Directions also incorporate CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines into the supervisory relationship with an empanelled auditor. Separately, and regardless of empanelment, the Directions require you to assess the qualifications, expertise, and competency of both the testing firm and each assigned tester at every selection and renewal. Those are two different obligations, and satisfying one does not satisfy the other.

Q4: What happens if we miss the six-hour DAKSH reporting deadline?

A missed deadline is a supervisory finding, and it compounds over time. It becomes part of the inspection record, it raises questions about the adequacy of your incident response governance, and it weakens your position on everything else the inspection examines. Remember also that the clock runs from detection rather than from confirmation, so an entity that spent a day establishing scope before reporting has already missed it. A detailed root cause analysis follows within 21 days, and the CERT-In six-hour obligation to a different authority runs in parallel.

Q5: Do the 2026 Directions apply to fintechs and technology vendors that RBI does not regulate?

Not directly, but the obligations arise by contract. A regulated entity remains accountable for outsourced technology and discharges that accountability through its vendor agreements. Hence, audit rights, testing evidence, incident notification timelines, localisation warranties and exit obligations flow down. A fintech whose largest customer is a bank absorbs most of this framework whether or not it appears in any Direction. In practice, the commercial consequence of being unable to evidence alignment is the loss of the contract or a delay in its execution.

Q6: Do we need to update policy documents that cite the repealed circulars?

Yes, and it is the most immediate action item. Internal policies, board papers, audit scopes, vendor questionnaires and customer security responses across Indian BFSI currently cite circular numbers that no longer resolve. Start with anything that leaves the building, meaning submissions to a regulator, responses to customer due diligence and contracts with technology vendors. Then work through internal policy. Map each old citation to the corresponding provision in your applicable 2026 Direction rather than doing a find-and-replace on the title, because the provisions did not all carry across in the same place.

X. Conclusion

Compliance under the 2026 Directions is not an annual event with a report at the end of it. The obligations run continuously: testing on a cadence and on change, incident reporting on a six-hour clock that can start at any hour, closure evidence produced quarterly for committees that now expect it, and a disaster recovery capability proven by actually running on it.

Three actions are worth taking this quarter rather than next.

Identify your instrument and your tier. Seven Directions exist, and the differences between them are real. A group structure needs a separate mapping per regulated entity, not one enterprise-wide assumption.

Re-base your documentation. Every citation pointing to a repealed circular needs mapping to the current text, starting with whatever reaches a regulator, a customer or a vendor.

Fix the ownership gaps before the control gaps. Most inspection findings are evidence failures rather than control failures. Name the owner of the six-hour clock. Move the CISO reporting line. Write the change-trigger list. None of that requires a budget.

If you are working toward an inspection or want to know whether your testing evidence would survive supervisory review, talk to our team about an assessment mapped to your specific Direction, or review a sample report first.