If your company sells software to an Indian bank, an NBFC, a payments bank or a credit information company, the rulebook underneath that relationship changed on 31 July 2026, and nobody was obliged to send you a note about it. The security questionnaire you filled in last quarter very likely cites a framework the Reserve Bank of India has since repealed.
This is written for the CTO or founding engineer at a company of roughly 10 to 40 people whose largest customer is regulated by the RBI. You are not the regulated entity. You will still absorb most of this, because a regulated entity discharges these obligations through the contracts it signs with you.
Most coverage of the change is written for the bank's compliance head. That framing is close to useless for a vendor. It describes duties you do not hold, and it skips the only two questions you need answered: which clauses show up in your next renewal, and what do you have to be able to show when they do.
Two different things happened on 31 July 2026
Conflating them is the most common error in the commentary so far, and it will make you sound wrong in a customer call.
The first is a housekeeping action with real teeth. The RBI's Department of Supervision repealed 628 circulars and replaced them with 64 consolidated Master Directions, spanning 11 categories of regulated entity and up to nine functional areas each. The repeal instrument is numbered RBI/DoS/2026-27/221, it took effect immediately, and the consolidated set is now the single official library for that department (SCC Online, CorpLawUpdates). If a questionnaire you answered cites a circular by number, there is a real chance that number no longer points at anything.
The second is substantive. On the same day the RBI issued a parallel set of Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026, one per class of regulated entity. They retire the 2016 Cyber Security Framework in Banks circular and fold a scattered patchwork into a single eight chapter rulebook, effective on issuance with no transition window (DSCI, MediaNama). That second one is the document that reaches you.
1. Cite the list, not the number
Secondary write-ups do not agree on how many Directions were issued. Some say six, others say seven. The ones that actually enumerate the classes list seven: commercial banks, small finance banks, payments banks, urban co-operative banks, all India financial institutions, NBFCs, and credit information companies (Risk Awareness, BitScore). The counts that say six appear without a list, and the class most often missing from them is all India financial institutions.
This matters more than pedantry. A vendor who quotes a wrong count in a security review has just told the reviewer they read a blog and not the instrument. Practitioner opinion: never carry the number at all. Carry the name of your customer's specific Direction, and take the authoritative list from the Department of Supervision's own Master Directions page on rbi.org.in rather than from anyone's summary, this one included.
Takeaway: before your next renewal, write down which single Direction governs each regulated customer you have. That one line of homework changes the whole conversation.
2. The six hour clock becomes your notification clause
The headline operational change is reporting speed. Cyber incidents must be reported to the RBI through the DAKSH platform within six hours of detection, alongside reporting to CERT-In where applicable (TaxGuru summary of the NBFC Directions). DAKSH is the RBI's supervisory platform, and naming it explicitly is new.
Your customer cannot meet a six hour clock if they learn about your incident on day three. So the clock does not stay with them. It arrives in your contract as a notification window measured in hours, and it will be shorter than six so they have room to file.
The trap is not the timer. It is the definition. Most vendor contracts say notify on a confirmed breach, which lets everyone argue for two days about whether it was confirmed. The Directions run on detection, not confirmation. Practitioner opinion: negotiate the trigger, not the duration. Agree in writing what counts as detection, who your named on call owner is, and which channel the notice goes to, then rehearse it once. A four hour clause you have practised is worth more than a twelve hour clause you have not.
Takeaway: put a written detection definition and one named owner into the contract before your customer's lawyer writes a worse one for you.
3. Source code escrow arrives in your contract
This is the clause most early stage vendors have never priced. The Directions expect critical vendored applications to be supported by source code availability, escrow arrangements where necessary, certification that the code is free of known vulnerabilities, and source code audits for critical applications where the regulated entity considers it appropriate (BitScore, Security Brigade).
Founders hear escrow and picture handing their source to a competitor. That is not what it is. Escrow is a third party agent holding a deposit that is released only on defined trigger events, usually your insolvency or a sustained failure to support. The commercial risk is small. The engineering risk is the one nobody checks: a deposit that does not build.
Practitioner opinion: if you agree to escrow, treat the deposit as a release artifact, not a zip file. It needs the build manifest, pinned dependency versions, and enough documentation that a competent engineer can rebuild it without you. An escrow deposit nobody has ever rebuilt is a compliance decoration, and the first time anyone finds out is the worst possible time.
Takeaway: get one escrow agent quote now so the clause is a number you already know, not a negotiation you stall.
4. Audit rights, regulatory access, and evidence, not promises
Regulated entities remain accountable for risks they outsource. The framework expects vendor due diligence, risk assessment, contractual controls, audit rights, regulatory access, supply chain risk management and ongoing compliance monitoring, which is the same posture the earlier IT outsourcing rules took and now sits alongside a cybersecurity rulebook with its own assurance chapter.
Two of those words are the ones that change your week. Audit rights means your customer can inspect you. Regulatory access means the RBI can reach you through them. A clause granting the regulator access to a vendor's premises, systems and records is standard in this space and is not something a lean team can quietly decline.
The shift under all of it is from promises to evidence. A questionnaire answer saying we follow best practice is now the weakest thing in the file. Practitioner opinion: the cheapest thing you can build this quarter is an evidence folder that a reviewer can read without you in the room. Current penetration test report, quarterly access review with dates, backup restore test with a result, incident log even if empty, and a one page architecture note.
Takeaway: assemble the evidence folder once and reuse it. It is the single highest leverage compliance asset a small vendor owns, and it is the same folder our security questionnaire playbook builds.
5. Secure development and freedom from known vulnerabilities
The 2026 Directions reach into territory the 2016 framework never formally covered: data governance, cryptography controls, secure software development, IPv6 readiness, teleworking security and cloud security (Security Brigade). Secure software development is the one that lands on the vendor, because your customer does not write your code.
A certification that an application is free of known vulnerabilities sounds impossible if you read it literally, and it is. Read it operationally instead. What a reviewer wants is proof that you know what is in your build and that you have a rule for acting on what you find. That is a software bill of materials per release, dependency and container scanning wired into the pipeline, and a written severity policy with timelines you actually meet.
Practitioner opinion: publish a severity SLA you can hit rather than one that sounds impressive. Critical in seven days that you meet beats critical in twenty four hours that you miss, because the second one turns every miss into a contractual breach you handed them yourself.
Takeaway: generate an SBOM in CI this month. It is a few lines of pipeline config and it answers a question that is about to be asked of you repeatedly.
6. Your cloud architecture is now their supervised risk
Cloud security is named in the framework's scope, and the practical effect is that your infrastructure choices stop being purely yours. Where your data sits, how keys are managed, who at your company can reach production, and what happens when your region has a bad day all become answerable questions inside your customer's supervisory perimeter.
The Directions also push concentration risk visibility, meaning your customer is expected to understand what breaks if one vendor goes down. You are that one vendor. Expect to be asked for a recovery time objective and a recovery point objective, in writing, with numbers you can defend rather than aspire to.
Practitioner opinion: state the honest number and the plan to improve it, in the same sentence. A vendor who says our RTO is four hours today, here is the work that takes it to one, reads as competent. A vendor who claims near zero and cannot show a restore test reads as a risk the reviewer now has to write up.
Takeaway: run one real restore test, write down the elapsed time, and use that number in every questionnaire until you improve it.
7. Not every customer carries the same weight
The Directions are tiered, and the tier decides how hard your customer will push. For NBFCs the tiering follows the Scale Based Regulation layers: reporting indicates that Chapter III binds Base Layer NBFCs below Rs 500 crore and core investment companies, Chapter IV binds Base Layer at Rs 500 crore and above, and Chapter V binds Middle Layer and above (BitScore). Urban co-operative banks are graded across four levels by digital depth and interconnectedness with payment systems.
The gap between tiers is large. Reporting on the smallest Base Layer NBFCs describes an obligation of a few paragraphs, without a mandated security operations centre or the vulnerability testing cadence that applies higher up. Above that, vulnerability assessment every six months and penetration testing every twelve months for critical and customer facing DMZ systems is described as the baseline. Red teaming is reported as not mandated in the NBFC and urban co-operative bank Directions.
Takeaway: tier your own customer list. A Middle Layer NBFC will send you the full clause set, a small Base Layer lender may not, and knowing which is which tells you where to spend first.
8. The outsourcing rules are a separate track
Do not fold these into the outsourcing rulebook. The Master Direction on Outsourcing of Information Technology Services, notification RBI/2023-24/102, came into force on 1 October 2023 and remains its own instrument (RBI text). It was then carried into a 2025 consolidation, with the NBFC outsourcing Directions of November 2025 giving existing contracts until 10 April 2026 to transition (Vinod Kothari Consultants).
So a vendor to an RBI regulated entity is now standing under two overlapping instruments: an outsourcing framework that governs the relationship, and a cybersecurity framework that governs the controls. They share vocabulary, which is exactly why teams merge them and then answer the wrong question in a review.
Our earlier implementation guide to the IT outsourcing Direction covers that first track in depth. Read it alongside this, and treat the 2026 cybersecurity Directions as the control layer sitting on top rather than a replacement for it.
Takeaway: keep two tabs in your evidence folder, one for outsourcing clauses and one for cybersecurity controls. Reviewers ask about them separately.
9. The overlap stack: CERT-In and DPDP
The six hour clock will feel familiar because CERT-In already runs one. Its 2022 directions, issued under section 70B(6) of the Information Technology Act, 2000, require specified cyber incidents to be reported within six hours of noticing them, along with log retention and clock synchronisation obligations (Trilegal). That one can apply to you directly, not only through your customer.
The Digital Personal Data Protection Act adds the third layer. A data processor carries no direct statutory duties under the Act; its obligations flow from the contract, while the fiduciary stays accountable for the processor's non compliance (King Stubb and Kasiva). That is precisely why your customer's data processing agreement is getting longer. Our DPDP guide for startups covers the processor side.
Practitioner opinion: build one control set and map it to three regimes, rather than three programmes. The overlap is high, and a single incident runbook that names the RBI six hour path, the CERT-In path and the DPDP notification path in one page covers most of what any reviewer will ask.
Takeaway: one runbook, three named paths, one rehearsal. That is a week of work, not a quarter.
10. What to do in the next two weeks
None of this requires a compliance function. It requires a short, ordered list. Identify which Direction governs each regulated customer. Read your current contracts for the notification trigger you already agreed to. Get one escrow quote. Turn on SBOM generation. Run a restore test and record the time. Write the incident runbook with the three paths named.
That sequence is deliberately ordered by cost. The first two are reading. The next two are configuration. Only the last two need a scheduled afternoon. A vendor who has done all six answers a security review from a folder instead of from memory, and reviewers can tell the difference immediately.
Takeaway: the work that makes you contract ready here is measured in days, and every item on the list is reusable across every regulated customer you sign next.
Summary: the clause, the reason, and what you need ready
| Clause you will see | What it requires of your customer | What you need ready |
|---|
| Incident notification window | Cyber incidents reported to the RBI through DAKSH within six hours of detection | A written detection definition, a named on call owner, and a rehearsed notice path |
| Source code escrow | Source code availability or escrow for critical vendored applications | An agent quote, a build manifest, and a deposit that actually rebuilds |
| Audit and inspection rights | Vendor due diligence, audit rights and regulatory access in contract | Current pen test, dated access reviews, and a named audit window |
| Freedom from known vulnerabilities | Certification and source code audit for critical applications | SBOM per release, pipeline scanning, and a severity SLA you meet |
| Cloud security and data governance | Cloud controls, cryptography and data governance brought in scope | Residency answers, key management note, and production access list |
| Concentration risk | Visibility into what breaks if a single vendor fails | Defensible RTO and RPO, a restore test result, and an exit plan |
Where to start, by stage
Pre-seed. Do the reading and nothing expensive. Know which Direction governs your one or two regulated customers, and fix the notification trigger in your contract language. Add SBOM generation because it is nearly free. Skip escrow until a customer asks in writing.
Seed. Build the evidence folder and run the restore test. Get the escrow quote so the clause stops being a blocker in a deal cycle. Write the incident runbook with the RBI, CERT-In and DPDP paths named, and rehearse it once with whoever is actually on call.
Series A. Formalise it. A named owner for regulated customer compliance, a scheduled access review, a vulnerability testing cadence that matches what your largest customer's tier carries, and a documented severity SLA. At this stage reviewers start asking who owns this, and a name is the answer that ends the thread.
The next questionnaire is the deadline
There is no filing you owe the RBI. The deadline is commercial: the next renewal or security review from a regulated customer, and those arrive without warning. Every item above is something you can hold up in that conversation instead of promising to follow up.
If you want a second pair of eyes on where your cloud and security posture stands against what these clauses will ask for, the free security checklist is the fastest place to start. It takes about twenty minutes and it produces the kind of written output a reviewer will accept.
About the author
Avinash S is the founder of MatrixGard, a fractional DevSecOps practice for early stage startups, funded or bootstrapped. He works with engineering teams that carry cloud, infrastructure and security responsibilities without a dedicated person to own them.
Methodology note
This post is based on the RBI's 31 July 2026 supervisory consolidation and the Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026, as reported by the sources linked inline, together with the primary text of the 2023 IT outsourcing Master Direction, the 2022 CERT-In directions and published analysis of processor duties under the DPDP Act. Where secondary sources disagree, in particular on whether six or seven entity specific Directions were issued, the disagreement is stated in the post rather than resolved silently, and readers are pointed at the RBI's own Master Directions library. Descriptions of chapter applicability and testing cadence reflect published summaries of the Directions and should be checked against the text of the specific Direction that governs your customer before you rely on them contractually. Statements of judgement are labelled as practitioner opinion. This is not legal advice.
