NBFC Cyber Incident Reporting in 6 Hours: DAKSH, CERT-In and Your Incident Response Playbook
RBI cyber incident reporting in 6 hours explained for NBFCs: DAKSH vs CERT-In, what counts as an incident, and an hour-by-hour response playbook you can use.
NBFC Cyber Incident Reporting in 6 Hours: DAKSH, CERT-In and Your Incident Response Playbook
RBI cyber incident reporting in 6 hours explained for NBFCs: DAKSH vs CERT-In, what counts as an incident, and an hour-by-hour response playbook you can use.
Under RBI's 2026 Cybersecurity Directions, NBFCs must report cyber incidents to RBI on the DAKSH platform within six hours of detection. Separately, the 2022 CERT-In Directions require any body corporate in India, including every NBFC, to report listed cyber incidents to CERT-In within six hours of noticing them. Housing finance companies report to NHB instead of RBI.
That means two reports, to two different bodies, inside the same six hours. Teams that have not practised this usually lose the first two hours just working out who should do what.
Two clocks, two reports
The two rules look alike, but they are not the same.
| Feature | RBI (DAKSH) | CERT-In |
|---|---|---|
| Who must report | NBFCs covered by the incident reporting provisions of the 2026 NBFC Directions | Service providers, intermediaries, data centres, body corporates and government organisations |
| Deadline | Within 6 hours of detection | Within 6 hours of noticing the incident, or of it being brought to notice |
| Where | DAKSH, RBI's supervisory monitoring platform | Email, phone or fax, as listed by CERT-In |
| What to report | Cyber incidents | The 20 incident types in Annexure I of the Directions |
| Extra | Analyse incidents, including forensic analysis where needed, for severity, impact and root cause | Keep ICT logs for 180 days within India; sync clocks to NIC or NPL time servers; name a Point of Contact for CERT-In |
Two practical points:
- The DAKSH six-hour rule appears in the chapters for Base Layer NBFCs with assets of ₹500 crore and above and for Middle Layer and above. Smaller Base Layer NBFCs should check their own chapter. The CERT-In rule applies to them anyway.
- For Middle Layer and above, RBI also asks NBFCs to notify CERT-In proactively. In practice, every NBFC should plan to file both.
What actually counts as a reportable incident?
Many teams think only a breach or ransomware needs reporting. CERT-In's list is much wider. Items that matter most for NBFCs include:
A fake app using your brand name to collect borrower details, or a takeover of your official social media account, is reportable even if your own servers were never touched.
The six-hour playbook, hour by hour
This is a practical example. Adapt it to your Cyber Crisis Management Plan, which RBI's Directions require you to have.
Detection
Someone spots something: an alert, a customer complaint, a vendor call. Record the exact time from a system synced to an official time server. That timestamp starts both clocks. Open an incident ticket and page the incident lead.
Triage and team
Confirm it is a real incident, not a false alarm. Classify the type against CERT-In's list and rate the severity. Bring in the CISO, IT, legal, compliance and communications. Name one person to own the DAKSH filing and one to own the CERT-In report.
Contain and preserve
Isolate affected systems, disable compromised accounts and block malicious IPs or domains. Before wiping anything, preserve evidence: take forensic images, export logs and note every action with a time. RBI expects you to analyse the incident for root cause later, and you cannot do that without evidence.
Draft both reports
Write down what you know, what you do not know yet, and what you have done. You will not have the full story. That is normal. A timely report with clear "under investigation" notes is better than a late, perfect one.
File and confirm
Submit on DAKSH and send the CERT-In report. Save proof of submission. Brief senior management.
Investigate and recover
Run the forensic investigation, find the root cause, restore clean systems and validate security controls before going back to normal. Send updates to RBI and CERT-In as your findings firm up.
SecurityLit's incident response follows the same arc: detection and analysis, containment and isolation, investigation and evidence, recovery and restoration, then a post-incident review. It offers 24/7 emergency response, with digital forensics and chain-of-custody procedures.
Five mistakes that burn the six hours
These come up again and again when teams run their first drill.
Waiting for certainty
Teams debate whether "it is really an incident" for hours. Classify early, and downgrade later if needed.
Only one person can file
The one person with DAKSH access is on leave or asleep.
Wiping before saving
Rebuilding a server first destroys the evidence you need for root cause analysis.
Clocks that disagree
Logs from different systems show different times, so nobody can say when detection happened.
Forgetting the vendor
Your loan management system, cloud provider or collection agency spots the incident, but their contract does not say how fast they must tell you.
The last one is easy to miss. If a third party runs a critical system, its contract should require prompt notification so your six hours are not spent waiting. A compliance pre-assessment can check your contracts and controls against your reporting duties.
The readiness checklist: what to fix before anything happens
Most failures in the six-hour window come from gaps that existed long before the incident. Check these now:
Your Point of Contact details are registered with CERT-In and still current.
All ICT systems sync time with NIC or NPL servers, or a time source that does not deviate from them.
Logs from all ICT systems are kept securely for a rolling 180 days within India. Cloud logs often fail this check, so review their retention and region settings.
At least two named people have working DAKSH access, and their logins are tested.
Report templates for DAKSH and CERT-In are drafted in advance.
Your Cyber Crisis Management Plan names owners, backups and phone numbers, not just job titles.
Someone is reachable 24/7, either in-house or through an incident response retainer.
If your team has no one to own the CCMP and the reporting process, a virtual CISO can set it up and keep it current.
Practise before it is real
A plan that has never been tested usually breaks at hour one. Run a tabletop exercise at least once a year: pick a realistic scenario, start the clock, and see whether your team can classify, contain and draft both reports in under six hours.
For a harder test, a red team exercise simulates a real attack without warning your defenders, so you learn whether your monitoring actually notices and whether your team starts the clock on time.
Frequently Asked Questions
Within how many hours must an NBFC report a cyber incident to RBI?
Within six hours of detection, on RBI's DAKSH platform, under the 2026 NBFC Cybersecurity Directions. Housing finance companies report to NHB.
Do NBFCs also need to report to CERT-In?
Yes. The 2022 CERT-In Directions require all body corporates to report listed cyber incidents to CERT-In within six hours of noticing them. RBI's Directions for Middle Layer and larger NBFCs also ask them to notify CERT-In proactively.
Does the six-hour clock start when the attack happens?
No. RBI's clock starts at detection. CERT-In's clock starts when you notice the incident or it is brought to your notice. That is why recording an accurate detection time matters.
What if we do not have full details within six hours?
Report what you know, clearly marked as preliminary, and send updates as your investigation progresses. Missing the deadline is a bigger problem than an incomplete first report.
Is a phishing campaign using our brand reportable?
Yes, if it falls within CERT-In's listed types, such as phishing, identity theft, spoofing or fake mobile apps. It can be reportable even if your own systems were not breached.
This article is general information based on the published Directions, not legal advice.
Need help when the clock starts, or want to test your six-hour plan before it is real?
Talk to SecurityLit's incident response team for 24/7 emergency response or book a free consultation to review your readiness.
Related Articles
Under RBI's 2026 Cybersecurity Directions, NBFCs must report cyber incidents to RBI on the DAKSH platform within six hours of detection. Separately, the 2022 CERT-In Directions require any body corporate in India, including every NBFC, to report listed cyber incidents to CERT-In within six hours of noticing them. Housing finance companies report to NHB instead of RBI.
That means two reports, to two different bodies, inside the same six hours. Teams that have not practised this usually lose the first two hours just working out who should do what.
Two clocks, two reports
The two rules look alike, but they are not the same.
| Feature | RBI (DAKSH) | CERT-In |
|---|---|---|
| Who must report | NBFCs covered by the incident reporting provisions of the 2026 NBFC Directions | Service providers, intermediaries, data centres, body corporates and government organisations |
| Deadline | Within 6 hours of detection | Within 6 hours of noticing the incident, or of it being brought to notice |
| Where | DAKSH, RBI's supervisory monitoring platform | Email, phone or fax, as listed by CERT-In |
| What to report | Cyber incidents | The 20 incident types in Annexure I of the Directions |
| Extra | Analyse incidents, including forensic analysis where needed, for severity, impact and root cause | Keep ICT logs for 180 days within India; sync clocks to NIC or NPL time servers; name a Point of Contact for CERT-In |
Two practical points:
- The DAKSH six-hour rule appears in the chapters for Base Layer NBFCs with assets of ₹500 crore and above and for Middle Layer and above. Smaller Base Layer NBFCs should check their own chapter. The CERT-In rule applies to them anyway.
- For Middle Layer and above, RBI also asks NBFCs to notify CERT-In proactively. In practice, every NBFC should plan to file both.
What actually counts as a reportable incident?
Many teams think only a breach or ransomware needs reporting. CERT-In's list is much wider. Items that matter most for NBFCs include:
A fake app using your brand name to collect borrower details, or a takeover of your official social media account, is reportable even if your own servers were never touched.
The six-hour playbook, hour by hour
This is a practical example. Adapt it to your Cyber Crisis Management Plan, which RBI's Directions require you to have.
Detection
Someone spots something: an alert, a customer complaint, a vendor call. Record the exact time from a system synced to an official time server. That timestamp starts both clocks. Open an incident ticket and page the incident lead.
Triage and team
Confirm it is a real incident, not a false alarm. Classify the type against CERT-In's list and rate the severity. Bring in the CISO, IT, legal, compliance and communications. Name one person to own the DAKSH filing and one to own the CERT-In report.
Contain and preserve
Isolate affected systems, disable compromised accounts and block malicious IPs or domains. Before wiping anything, preserve evidence: take forensic images, export logs and note every action with a time. RBI expects you to analyse the incident for root cause later, and you cannot do that without evidence.
Draft both reports
Write down what you know, what you do not know yet, and what you have done. You will not have the full story. That is normal. A timely report with clear "under investigation" notes is better than a late, perfect one.
File and confirm
Submit on DAKSH and send the CERT-In report. Save proof of submission. Brief senior management.
Investigate and recover
Run the forensic investigation, find the root cause, restore clean systems and validate security controls before going back to normal. Send updates to RBI and CERT-In as your findings firm up.
SecurityLit's incident response follows the same arc: detection and analysis, containment and isolation, investigation and evidence, recovery and restoration, then a post-incident review. It offers 24/7 emergency response, with digital forensics and chain-of-custody procedures.
Five mistakes that burn the six hours
These come up again and again when teams run their first drill.
Waiting for certainty
Teams debate whether "it is really an incident" for hours. Classify early, and downgrade later if needed.
Only one person can file
The one person with DAKSH access is on leave or asleep.
Wiping before saving
Rebuilding a server first destroys the evidence you need for root cause analysis.
Clocks that disagree
Logs from different systems show different times, so nobody can say when detection happened.
Forgetting the vendor
Your loan management system, cloud provider or collection agency spots the incident, but their contract does not say how fast they must tell you.
The last one is easy to miss. If a third party runs a critical system, its contract should require prompt notification so your six hours are not spent waiting. A compliance pre-assessment can check your contracts and controls against your reporting duties.
The readiness checklist: what to fix before anything happens
Most failures in the six-hour window come from gaps that existed long before the incident. Check these now:
Your Point of Contact details are registered with CERT-In and still current.
All ICT systems sync time with NIC or NPL servers, or a time source that does not deviate from them.
Logs from all ICT systems are kept securely for a rolling 180 days within India. Cloud logs often fail this check, so review their retention and region settings.
At least two named people have working DAKSH access, and their logins are tested.
Report templates for DAKSH and CERT-In are drafted in advance.
Your Cyber Crisis Management Plan names owners, backups and phone numbers, not just job titles.
Someone is reachable 24/7, either in-house or through an incident response retainer.
If your team has no one to own the CCMP and the reporting process, a virtual CISO can set it up and keep it current.
Practise before it is real
A plan that has never been tested usually breaks at hour one. Run a tabletop exercise at least once a year: pick a realistic scenario, start the clock, and see whether your team can classify, contain and draft both reports in under six hours.
For a harder test, a red team exercise simulates a real attack without warning your defenders, so you learn whether your monitoring actually notices and whether your team starts the clock on time.
Frequently Asked Questions
Within how many hours must an NBFC report a cyber incident to RBI?
Within six hours of detection, on RBI's DAKSH platform, under the 2026 NBFC Cybersecurity Directions. Housing finance companies report to NHB.
Do NBFCs also need to report to CERT-In?
Yes. The 2022 CERT-In Directions require all body corporates to report listed cyber incidents to CERT-In within six hours of noticing them. RBI's Directions for Middle Layer and larger NBFCs also ask them to notify CERT-In proactively.
Does the six-hour clock start when the attack happens?
No. RBI's clock starts at detection. CERT-In's clock starts when you notice the incident or it is brought to your notice. That is why recording an accurate detection time matters.
What if we do not have full details within six hours?
Report what you know, clearly marked as preliminary, and send updates as your investigation progresses. Missing the deadline is a bigger problem than an incomplete first report.
Is a phishing campaign using our brand reportable?
Yes, if it falls within CERT-In's listed types, such as phishing, identity theft, spoofing or fake mobile apps. It can be reportable even if your own systems were not breached.
This article is general information based on the published Directions, not legal advice.
Need help when the clock starts, or want to test your six-hour plan before it is real?
Talk to SecurityLit's incident response team for 24/7 emergency response or book a free consultation to review your readiness.