Short answer: RBI’s Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, issued on 31 July 2026, require regulated entities to report cyber incidents to RBI on the DAKSH platform within six hours of detection, and to notify CERT-In as well. A bank can only meet that deadline for a vendor-side incident if the vendor tells it quickly and in a usable form. The Directions also set minimum cadences for vulnerability assessment, penetration testing and disaster recovery drills, and they keep the regulated entity accountable for technology risk it places with third parties. For risk teams the work is contractual and evidential: shorten vendor notification windows, and collect proof that vendor-run controls are actually tested.
This article is independent commentary, not legal advice. Requirement details come from the text of the Small Finance Banks version of the Directions as reproduced by a legal-update service, and from secondary summaries of the other versions. Paragraph numbers and thresholds can differ by entity type, so confirm them against the instrument that applies to you on the RBI website.
See how the Crest.Digital TPRM platform describes its vendor register, lifecycle view and compliance reporting.
Talk to the TeamWhat the 2026 Directions Require
According to a secondary summary, RBI issued seven parallel sets of Directions on 31 July 2026, one for each class of regulated entity: commercial banks, small finance banks, payments banks, urban co-operative banks, all-India financial institutions, non-banking financial companies and credit information companies. Each carries the same title and replaces that class’s earlier cyber and IT governance instructions. In the version we reviewed they came into force with immediate effect. The provisions most relevant to vendor oversight are below.
| Area | What the Directions say (version reviewed) | Why it reaches vendors |
|---|---|---|
| Incident reporting | Report cyber incidents on DAKSH within six hours of detection; notify CERT-In proactively | A vendor-side incident reaches the bank only when the vendor says so |
| Vulnerability assessment and testing | For critical systems and customer-facing DMZ systems: assessment at least every six months, penetration testing at least every 12 months | Vendor-hosted systems need current test evidence |
| Disaster recovery | Drills for critical systems at least half-yearly | Vendor-run recovery must be drilled, not assumed |
| Observation closure | Status of closure of assessment and testing observations goes to the IT Strategy Committee and the information security committee at least quarterly | Fixes owned by vendors need tracked closure dates |
| Third-party arrangements | Vendor risk assessment proportionate to materiality, including concentration and single-point-of-failure risk; the bank remains accountable; right to audit and RBI inspection access; data-location and personnel controls | Contracts and due diligence must carry these terms |
The governance layer matters too. In the version reviewed, the CISO reports to an executive overseeing risk management rather than to the head of IT, and reviews cyber risk preparedness with the board, its risk committee or the IT Strategy Committee at least quarterly. Open vendor incidents and overdue vendor findings are natural items for that agenda.
Two Rulebooks for Technology Vendors
The third-party provisions in the 2026 Directions apply only to IT and cybersecurity arrangements that are not already covered by RBI’s separate outsourcing directions, which a secondary summary dates to 28 November 2025. A bank’s technology vendor population therefore splits across two instruments, and the split decides which questions each vendor file must answer.
| Arrangement | Governing instrument | What to confirm |
|---|---|---|
| Outsourced service within RBI’s outsourcing directions | Managing Risks in Outsourcing Directions | Materiality assessment and agreement terms, covered in our RBI outsourcing guidelines article |
| IT or cybersecurity arrangement outside those directions | Third-party paragraphs of the 2026 Cybersecurity Directions | Vendor risk assessment, accountability, audit and RBI access, data location, vendor personnel controls |
| Third-party ATM switch application service providers (commercial banks) | Baseline controls in the commercial banks’ version | Contract clauses on incident notification and security baselines |
| Unclear cases | Compliance determination | Record the reasoning in the vendor register |
Compliance should record, vendor by vendor, which rulebook applies and why, and tie that decision to the tiering already used in vendor classification and tiering. Banks that also answer to other regimes can compare the approach in the financial-services outsourcing guide, DORA and the OCC’s third-party guidance. SEBI-regulated entities have a parallel framework, discussed in SEBI CSCRF and third-party risk.
Making the Six-Hour Clock Work Through a Vendor
The Directions require the bank to report within six hours of detection. The text we reviewed does not spell out how a vendor’s detection maps onto the bank’s own, so that interpretation belongs with legal and compliance. What is clear is that a notification clause written in days cannot support a duty measured in hours. Four contract and process changes close most of the gap.
Define the trigger and shorten the window
Define a notifiable incident, set the vendor’s deadline well inside six hours of its own detection, and name 24x7 contacts on both sides.
Agree the content of the notice
Specify the minimum fields: affected systems and data, time of detection, containment status and a named incident lead, so the bank can prepare its regulatory report from the notice.
Secure cooperation and access
Require forensic cooperation, log retention, the bank’s right to audit and inspection access for RBI, which the version reviewed lists among its third-party requirements.
Rehearse the path before an incident
Run a tabletop exercise that includes the highest-tier vendors and time how long a notice takes to reach the person who files the report.
Clause design is covered in more depth in contractual controls in TPRM, and the response side in managing vendor breaches.
The Evidence a Supervisor Can Ask For
Testing and recovery cadences are only defensible with dated evidence. For each vendor that hosts or operates a critical or customer-facing system, build an evidence calendar: the date and scope of the latest vulnerability assessment and penetration test, the status and closure dates of critical findings, the date and outcome of the latest recovery drill, and the vendor’s recovery targets. Which vendor-hosted systems fall under the testing provisions depends on architecture, so settle that with your technology and compliance teams first.
An independent report helps but does not replace this. A SOC 2 report describes controls over a defined period and scope; it does not show that a specific system was tested within the last six months. Recovery claims should be checked against the approach in vendor business continuity planning, and dates should be refreshed through continuous monitoring rather than an annual questionnaire.
Worked Example: A Hosted Analytics Vendor (Illustrative)
This is a hypothetical scenario, not a customer case study. A mid-sized lender uses a hosted customer-analytics platform. The contract gives the vendor 72 hours to notify security incidents. The vendor detects ransomware overnight and notifies the lender on the second day. By then the lender’s clock question is already unanswerable: nobody can show when the lender should reasonably have known, and the regulatory report is late or built on guesswork.
After the lender re-papers the contract with a short notification window, agreed notice fields and a 24x7 contact, the same event looks different. The duty officer receives a structured notice within hours of vendor detection and prepares the report from it. The lender can also show the supervisor the vendor’s last penetration test date, the closure status of its critical findings and the date of its last recovery drill, because those were collected on a calendar rather than reconstructed afterwards. Judgement calls on materiality and reporting remain with people; the contract and the evidence calendar make them possible within the time.
Where to Start
Start with an inventory of vendors that touch critical or customer-facing systems, and classify each under the right rulebook. Then amend notification and access clauses for the highest-tier vendors first, using contract renewals as the trigger, as described in reassessment at contract renewal. Finally, set up the evidence calendar and a quarterly view for the committees named above. For the wider discipline, see what third-party risk management is and the India-specific view in continuous vendor monitoring for BFSI in India.
Where the friction is chasing vendors for dated evidence, the Voice AI for GRC page describes phone-based follow-up and incident intake. For recurring control checks, the Agentic GRC page describes configurable monitoring agents.
Bring your critical-vendor list and see how a single register and lifecycle view could track notification terms, test dates and closure status.
Explore the TPRM PlatformFrequently Asked Questions
RBI issued Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, in separate versions for each class of regulated entity. A secondary summary lists commercial banks, small finance banks, payments banks, urban co-operative banks, all-India financial institutions, NBFCs and credit information companies. The versions we reviewed took effect immediately.
The reviewed versions require the regulated entity to report cyber incidents to RBI on the DAKSH platform within six hours of detection and to notify CERT-In as well. CERT-In has its own separate reporting expectations, so the two obligations should be built into one incident procedure.
No. According to the material reviewed, the outsourcing directions remain separate. The 2026 Directions’ third-party paragraphs cover IT and cybersecurity arrangements that fall outside the outsourcing directions, so many banks will apply both to different vendors.
The text we reviewed says the entity reports within six hours of detection but does not address vendor-side detection. Get a documented interpretation from legal and compliance. Whatever the answer, requiring vendors to notify well inside six hours of their own detection reduces the exposure.
Collect dated vulnerability assessment and penetration test summaries with scope, closure status of critical findings, recovery drill dates and outcomes, and recovery targets. Refresh them on a calendar tied to the testing cadences, and treat attestations such as SOC 2 reports as supporting inputs.