RBI Cybersecurity Directions 2026: What Changes for an NBFC on AWS?

On 31 July 2026 the RBI issued the Non-Banking Financial Companies – Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026. Paragraph 2 says they come into force with immediate effect. Paragraph 155 repeals the old IT framework. There is no transition window and no date to work back from.

So if you run an NBFC, or you are a fintech whose lending entity holds the licence, the RBI cybersecurity directions 2026 already apply to your AWS account. Whatever it does not do yet, it is not doing late. It is doing never, until you change it.

This is the direction read as a list of things an AWS account has to be able to do and prove.

Who do the RBI Cybersecurity Directions 2026 apply to?

The RBI issued seven directions on the same day, one per class of entity. This post is about the NBFC one.

Within the NBFC direction, the tier decides most of what follows:

• Chapter III — Base Layer NBFCs with assets below ₹500 crore, and core investment companies. Baseline requirements only.
• Chapter IV — Base Layer NBFCs with assets of ₹500 crore and above. Adds an IT strategy committee, an outsourcing policy and a board-approved BCP.
• Chapter V — Middle, Upper and Top Layer NBFCs. The full set: a CISO, VA/PT cadence, audit trails, DR drills, MFA for privileged users.

Two things caught us. The Chapter IV threshold is ₹500 crore, not the ₹2,500 crore we saw repeated in more than one summary; read the text, not the summary, because we nearly got this wrong ourselves.

The six-hour incident clock is in every chapter: paragraph 28 in Chapter IV, paragraph 141 in Chapter V.

What does "six hours of detection" mean when there are two regulators?

Paragraph 141: report cyber incidents to the RBI on the DAKSH platform within six hours of detection, and pro-actively notify CERT-In as well.

You already had a six-hour clock from CERT-In. We wrote about what it actually takes to report an incident in six hours; the report is the easy half, the detection and the evidence are the hard half. Now there are two clocks, from the same moment, to two portals, in two formats.

Your incident runbook needs a single step that fires both, owned by one named person, with the DAKSH login already provisioned and tested. We have watched a team lose forty minutes of a six-hour window finding out who had the credentials for a regulator's portal. The clock does not care.

What has to be logged, and who has to be able to read it?

Paragraphs 109 to 111 are broader than most accounts are set up for. Every system that can access or affect critical or sensitive information needs audit logging. The trails have to be detailed enough to serve as forensic evidence and support non-repudiation. And, paragraph 111, you have to regularly monitor them, not just keep them.

There is no retention period in the text. We looked. Your number comes from your own policy, from CERT-In's separate requirement of a rolling 180 days held within Indian jurisdiction.

On AWS the minimum that satisfies the wording is an organisation-level CloudTrail with data events on for the buckets and tables that hold customer data, delivered to a bucket with Object Lock in compliance mode so nobody, including you, can shorten history; CloudWatch Logs for the application layer; and a scheduled review that leaves a record of having happened. GuardDuty on its own is not "regularly monitoring the audit trails". It is a detector. The paragraph asks for a process.

Then paragraph 62, which sits in the outsourcing section but is really about your DevOps vendor. For technology outsourcing, the service provider must retain audit trails and logs for administrative activities, make them accessible to the NBFC on request, and the RBI must be able to get at them too. If an external team runs your account, its actions have to be logged as that team, on identities that are theirs. A shared admin user does not meet this and never did.

How often do you have to test, and on what?

Paragraph 121 gives Chapter V entities a fixed cadence: vulnerability assessment at least every six months and penetration testing at least every twelve, for critical systems and anything in the DMZ with a customer interface. Paragraph 124 adds the detail people miss: post-implementation testing is done on production, and if it must be done on test, the test environment has to match production in version and configuration, with the deviation documented and approved.

That last clause is a Terraform argument in disguise. The only honest way to say staging resembles production is if both were built from the same code with different variables. If staging was clicked together in 2023 and production has drifted since, you have two environments and a hope.

Paragraph 125 requires known vulnerabilities to be fixed in a time-bound way and the fix sustained, with a specific nod to the CVE database. An Inspector finding that reopens every time the AMI is rebuilt is what this paragraph is written against. The fix belongs in the image pipeline, not on the instance. And paragraph 126 says all of it applies equally to systems hosted in a cloud environment. Nobody gets to say the pen test was the cloud provider's job.

What does a half-yearly DR drill look like on AWS?

Paragraph 129: DR drills for critical systems at least half-yearly. Paragraph 131: the drill involves switching over to the DR site and running it as primary for at least a full working day, beginning-of-day to end-of-day. Paragraph 135: minimal RTO and a near-zero RPO for critical systems. Paragraph 136: if RPO is not zero, a documented method for reconciling the data you lost.

A Multi-AZ RDS instance is not a DR drill. The drill is a region failover, sustained for a business day, with real traffic. The first one will find things: a Lambda that hard-codes ap-south-1, a KMS key that was never replicated, a DNS TTL of 3,600 seconds, a secret that exists in only one region. Every one of those is better found on a planned Saturday.

Paragraph 133 also requires backups to be periodically restored. A backup that has never been restored is a file.

One concession. A Chapter III or IV entity needs a BCP tested annually, not the full Chapter V regime, and a second region for a company under ₹500 crore in assets is usually the wrong spend. Do the restore test and grow into the rest.

What does this mean for the vendor running your account?

Paragraphs 60 to 64 and 117 cover outsourcing and third parties, and we sell the thing they regulate, so weigh what follows accordingly.

The board stays responsible for outsourced operations. The contract has to give the NBFC continuous monitoring of the provider, access to all relevant books and records, the admin audit trails from paragraph 62, and RBI access within a reasonable time.

Turn that into questions for whoever runs your infrastructure, including us:

1. Does every engineer on your side act on a named identity in our account, with no shared credentials, and can you produce the trail for a given week on request?
2. Is the infrastructure in our repositories, as code, such that we could operate it if you left tomorrow?

The hire-or-partner question has one more variable now. Whichever way you go, the audit trail has to exist. An in-house engineer on a shared root account fails paragraph 62 exactly as badly as a vendor does.

What should you do in the next thirty days?

The direction is already in force, so "next quarter" is not a plan. In this order:

1. Work out which chapter you are in by asset size and write it at the top of your IT policy.
2. Confirm the DAKSH login exists, works, and is in the runbook next to the CERT-In step. Time the whole path once.
3. Check the CloudTrail bucket cannot be shortened: aws s3api get-object-lock-configuration --bucket <your-trail-bucket>. If that errors, Object Lock is off and your trail is only as durable as the next IAM mistake.
4. List every human and vendor identity with administrative access, and delete every shared one. That is paragraphs 62 and 114 in one afternoon.
5. If you are Chapter V, book the pen test. Twelve months from the last one is the deadline; if there was no last one, the deadline was 31 July.
6. Restore one production backup into a scratch account and record how long it took. That is your real RTO, and it is almost certainly not the one in the BCP.
7. Put the first DR drill in the calendar. The drill will tell you what the second region needs to be.

For the data residency side of the same account, where payment data leaves India without anyone deciding it should covers the part this direction does not.

The short version

Find your chapter. Wire DAKSH into the same runbook step as CERT-In. Make the audit trail immutable and every identity, yours and your vendor's, a named one. If you are Chapter V, book the pen test, restore a backup, and schedule a full-day DR drill before the auditor asks for the date of the last one.

None of it is exotic. All of it is already required.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.