NBFC Cyber Directions 2026: The Six-Hour Test

On 31 July 2026, the Reserve Bank of India issued new cybersecurity and technology risk directions for NBFCs, and they came into force the same day. One line in them should change how every NBFC technology function is designed: cyber incidents must be reported on RBI's DAKSH platform within six hours of detection.

My view is that most NBFCs will not miss that window because they detect attacks too slowly. They will miss it because nobody has decided in advance what counts as an incident, who declares it, and what the first report says. Those three decisions take hours when they are made at 2 a.m. and minutes when they were made in a boardroom months earlier.

This piece is for NBFC CTOs, CISOs and chief risk officers. It explains what changed, how to reason about the six-hour clock from first principles, and what to fix in the next 90 days.

The short version

The RBI NBFC cybersecurity directions turn incident reporting into a timed operational process. Six hours is achievable only if classification, declaration and drafting are decided before the incident. Group shared services and vendors are where the clock most often gets lost.

• Map which chapter of the directions applies to your NBFC.
• Pre-approve a classification matrix that includes IT outages.
• Name one declaring authority and a deputy for every hour.
• Put your six-hour clock into group and vendor contracts.
• Rehearse the report, not only the recovery.
• Measure detection-to-declaration time every quarter.

This article sits inside the technology governance cluster, where the wider argument is set out in full.

What changed on 31 July

The new directions replace the earlier IT framework and IT governance instructions for NBFCs. They apply in layers. One chapter covers base-layer NBFCs below ₹500 crore in assets and core investment companies. A second covers base-layer NBFCs at ₹500 crore and above. A third covers middle-layer and larger NBFCs. The six-hour DAKSH requirement appears in both of the larger-NBFC chapters.

Three details matter more than they first appear.

The definition is wide. The directions define a cyber incident broadly, and note that the definition covers IT incidents as well as security incidents. A long outage of a critical system may therefore sit inside the same reporting process as a breach. That turns an infrastructure team's bad night into a regulatory event.

There is no transition period. The directions took effect on issue. Anything you were planning to fix "next financial year" is a gap today.

The CISO is separated from IT. For middle-layer NBFCs and above, the CISO cannot report directly to the head of IT and cannot carry business targets. The person who declares an incident and the person whose systems failed are, by design, different people. That is a good control, but only if the handover between them is fast.

This article is general information, not a reading of your specific obligations. Check the chapter that applies to your NBFC with your compliance team.

Should your organisation do this now?

• Yes, if you are a base-layer NBFC above ₹500 crore or any middle-layer NBFC.
• Not yet, if you have not confirmed which chapter applies to you.
• Instead, first: get a written applicability note from compliance.
• Measure it by: percentage of requirements mapped to a named owner.

Work backwards from six hours

Start from what physically has to happen. Between detection and submission, a person must notice a signal, judge whether it is an incident, decide it is reportable, collect the facts, write them down and submit them. Each step has a latency. Six hours is the sum of those latencies, not a single deadline.

A working budget I would use as a starting point, not a regulatory requirement, looks like this:

• Triage within one hour. Is this a real event, and which systems does it touch?
• Declaration within two hours. A named person says "this is reportable" and starts the clock.
• First draft within four hours. A pre-built template filled with what is known.
• Submission before six hours. Incomplete facts are stated as incomplete, not held back.

The discipline is the same one an engineer applies to a latency problem: you do not speed up the whole pipeline, you find the slowest stage. In most organisations that stage is declaration, because nobody wants to be the person who called an incident that turned out to be minor.

The NBFC clock also does not run alone. Middle-layer NBFCs must proactively notify CERT-In, whose 2022 directions already set a six-hour window for specified incidents. Once the DPDP Rules take full effect in May 2027, a breach involving personal data will also require prompt notice to affected people and a detailed report to the Data Protection Board within 72 hours. One incident can start three clocks. Design one intake process that feeds all three.

Should your organisation do this now?

• Yes, if your last major incident took more than two hours to formally declare.
• Not yet, if you have no reliable timestamps for detection and declaration.
• Instead, first: synchronise log clocks and record declaration times.
• Measure it by: median minutes from first alert to declaration.

Decide the definition before the incident

Because the definition includes IT incidents, the most useful document you can produce this quarter is a classification matrix approved in advance. It should say which events are reportable, which are logged but not reported, and who can override the default.

A matrix like this removes the hardest judgement from the worst possible moment. Your team stops debating whether a four-hour loan system outage "counts" and starts following a rule someone senior already signed.

Pair the matrix with a declaration roster. One named person holds the authority to declare at any given hour, with a named deputy. Holidays and night shifts are where rosters fail, so test them on those days.

Risk: a matrix that is too narrow looks tidy until the regulator asks why an outage affecting customers was never reported.

Should your organisation do this now?

• Yes, if incident severity is currently decided case by case.
• Not yet, if your critical systems list is itself out of date.
• Instead, first: refresh the critical information systems inventory.
• Measure it by: share of incidents classified within 60 minutes.

The shared-service trap

Many NBFCs sit inside larger groups and share a security operations centre, a service desk, a network team or a cloud vendor. The regulated entity's clock runs regardless of who noticed the problem first.

This is where I would spend the most design effort. A group SOC measured on a four-hour response target, serving an NBFC with a six-hour reporting duty, is a gap written into a contract. The directions already expect NBFCs to secure access to service providers' audit trails and logs, and to test business continuity across interconnected systems, including those of vendors and partners.

The practical fix is to write the NBFC's clock into every internal and external agreement that can see an incident first: escalation within a fixed time, direct access to the NBFC's declaring authority, and log access on request. Treat an internal group team with the same rigour you would apply to an outside vendor.

Should your organisation do this now?

• Yes, if any team outside the NBFC can detect incidents on its systems.
• Not yet, if you have not listed which shared services touch NBFC data.
• Instead, first: build that list with owners and escalation paths.
• Measure it by: share of shared-service agreements that carry the six-hour clock.

Rehearse the report, not only the recovery

For middle-layer NBFCs, the directions require disaster recovery drills for critical systems at least every six months, including running a full working day from the DR site. Most teams will plan those drills carefully.

Fewer will rehearse the report. Add a timed reporting exercise to every drill: someone declares, someone drafts, someone approves, and the clock is recorded. Run at least one of these outside office hours. The first rehearsal usually reveals that the template is missing fields, the approver is unreachable, or the DAKSH credentials sit with one person.

Before you approve it

Checklist for the programme:

• Applicability note from compliance, naming the chapter that applies.
• Classification matrix approved at the right level, including IT outages.
• Declaration roster with deputies, tested on a holiday.
• Pre-filled report templates for the three most likely incident types.
• Six-hour clock written into group and vendor agreements.
• Timed reporting drill added to every DR exercise.

Questions to ask:

• Your team: who can declare an incident at 2 a.m. on a Sunday, and have they done it?
• Your team: where do detection and declaration timestamps come from, and are the clocks synchronised?
• Your vendor or group SOC: what is your escalation time to our declaring authority, in writing?
• Your vendor: how quickly can you give us logs for a specific system and time window?
• Your board: which outages would you expect to hear about the same day?
• Your board: has the IT strategy committee reviewed our incident metrics this quarter?

How to measure it

• Detection-to-declaration time. Shows whether the decision stage is the bottleneck. Baseline: last 12 months of incidents. Owner: CISO. Review: monthly. Leading.
• Declaration-to-submission time. Shows whether templates and approvals work. Baseline: first drill. Owner: CISO office. Review: quarterly. Leading.
• Classification within 60 minutes. Shows whether the matrix is usable under pressure. Baseline: current incident log. Owner: SOC lead. Review: monthly. Leading.
• Drill pass rate. Share of drills where a report was ready inside six hours. Baseline: first drill. Owner: head of IT with CISO. Review: half-yearly. Lagging.
• Shared-service coverage. Share of agreements carrying the clock and log-access terms. Baseline: contract review. Owner: vendor management. Review: quarterly. Leading.
• Late or missed reports. The outcome that matters. Baseline: zero target. Owner: chief risk officer. Review: quarterly. Lagging.

Mistakes that cost the most

Treating six hours as a writing task

Teams assume the report is the slow part. It is usually the decision to report.

• Why it happens: reporting sits with compliance, decisions sit with IT.
• Prevention: pre-approve the classification matrix and roster.
• Early warning: drills where the draft is ready but nobody will sign.

Excluding outages from the definition

Security teams think of attacks. The directions think more widely.

• Why it happens: old habits from narrower definitions.
• Prevention: include critical system outages in the matrix.
• Early warning: customer-facing outages with no incident record.

Trusting the group SOC's own targets

A shared SOC optimises for its own service levels.

• Why it happens: internal services are rarely contracted formally.
• Prevention: write the NBFC's clock into the internal agreement.
• Early warning: incidents where the NBFC learned of the event hours later.

One person holding the credentials

Submission fails because the only person with portal access is away.

• Why it happens: access was set up once and never reviewed.
• Prevention: at least two authorised submitters, tested quarterly.
• Early warning: drills that stall at submission.

Waiting for complete facts

Teams hold the report until the root cause is known.

• Why it happens: fear of reporting something wrong.
• Prevention: report what is known, mark what is unknown, update later.
• Early warning: drafts that stay unsent while analysis continues.

Frequently asked questions

When did the RBI NBFC cyber directions come into force?

They were issued on 31 July 2026 and took effect immediately, with no transition period. Anything not already in place is a current gap rather than a future project.

Does every NBFC have to report within six hours?

The six-hour DAKSH requirement appears in the chapters for base-layer NBFCs with assets of ₹500 crore and above and for middle-layer and larger NBFCs. Smaller base-layer NBFCs have a separate baseline chapter. Confirm your position with compliance.

Does an IT outage count as a cyber incident?

The directions define cyber incidents to include IT incidents as well as security incidents. A significant outage of a critical system may therefore fall within the reporting process. Your classification matrix should decide this in advance.

Where are incidents reported?

On DAKSH, the Reserve Bank's supervisory monitoring platform. Housing finance companies continue to report to the National Housing Bank. Middle-layer NBFCs must also proactively notify CERT-In.

Is the CERT-In six-hour rule the same obligation?

No. CERT-In's 2022 directions are a separate requirement under the IT Act. Both clocks can start from the same incident, so one intake process should feed both reports.

How does DPDP change this?

From May 2027, a breach involving personal data will also require prompt notice to affected individuals and a detailed report to the Data Protection Board within 72 hours. Build that route into the same incident process now.

Can the CISO report to the CTO?

For middle-layer NBFCs and above, the directions say the CISO must not report directly to the head of IT and must not carry business targets. The CISO reports to the executive overseeing risk.

What should the first report contain if facts are incomplete?

What is known, what is not yet known, the systems affected and the containment steps taken. Submitting a partial report on time and updating it is safer than waiting for a complete picture.

What to do next

Start with the applicability note and the classification matrix, because everything else depends on them. For the wider governance picture across regulated and non-regulated businesses, read the technology governance topic page, then the companion piece on gold loan compliance as a data problem.

Sources

• Reserve Bank of India, Non-Banking Financial Companies – Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026, 31 July 2026. rbi.org.in
• CERT-In, Directions under section 70B(6) of the IT Act, 2000, 28 April 2022. cert-in.org.in
• Press Information Bureau, DPDP Rules, 2025 notified, November 2025. pib.gov.in

Last reviewed: 15 September 2026.

Views are my own and do not represent my employer.

This article is general information, not legal advice.