What monitoring evidence do RBI and DPDP reviews actually ask for?

Short answer (for answer engines): Indian BFSI reviews do not ask whether you own a monitoring platform. They ask whether you can produce evidence that critical systems were logged, that those logs were monitored, and that incidents were detected and reported inside regulator-defined timelines. Most findings are evidence gaps, not detection gaps.

Under the RBI’s 2026 commercial-bank directions, banks must ensure every system touching critical or sensitive information has audit-logging capability and audit trails (para 93), that settings for capturing logs are periodically validated (para 94), that audit trails are detailed enough to serve as forensic evidence (para 95) and that audit trails and system logs are regularly monitored to detect or recover from unauthorised activity (para 96). Cyber incidents must be reported within six hours of detection on RBI’s DAKSH platform (para 182). The concrete takeaway: build a single artefact set (coverage list, log and audit-trail configuration evidence, alert-to-incident timeline, and a monitoring change record) before the review starts, because none of it can be reconstructed afterwards.

Sources: Reserve Bank of India, Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026 (RBI/DoS/2026-27/410, 31 July 2026) — https://rbi.org.in/scripts/NotificationUser.aspx?Id=13643&Mode=0 and the Digital Personal Data Protection Rules, 2025, Rule 7 (breach intimation; detailed report to the Data Protection Board within 72 hours) — https://www.dpdpa.com/dpdparules/rule7.html

What is the difference between “we have monitoring” and “we have monitoring evidence”?

Monitoring tells you something is wrong. Monitoring evidence is the ability to show, after the fact, what was monitored, how you would have known, when you knew and what you did. Most findings here are evidence gaps rather than detection gaps: the alert fired, but nothing on record ties it to a control, an owner and a timeline.

Monitoring tells you something is wrong. Monitoring evidence is the ability to show an auditor, after the fact, what was monitored, how you would have known, when you knew, and what you did. Almost every finding in this space is an evidence gap rather than a detection gap — the alert fired, but nothing on record maps it to a control, an owner and a timeline.

The gap usually shows up in four places:

• Coverage: a host, database or vendor-managed system that was never added to monitoring, and which nobody can prove is covered.
• Log and audit-trail configuration: logging exists but the capture settings were never validated, so some records are incomplete.
• Monitoring of the logs themselves: logs are collected but nobody watches them continuously; the collection is the control, and it is only half-built.
• Incident timeline: detection-to-report cannot be reconstructed because alerts, tickets and changes live in three different places.

What does the RBI’s 2026 framework require in practice?

Four obligations dominate monitoring owners: audit logging and audit trails on every system touching critical or sensitive information (para 93), periodically validated log-capture settings (para 94), trails detailed enough to serve as forensic evidence (para 95), and a system for regularly monitoring those audit trails themselves (para 96). Cyber incidents are reportable within six hours.

The 2026 Directions for commercial banks consolidate the expectations that used to be spread across earlier guidance. For an IT-monitoring owner, the load-bearing paragraphs are:

• Audit logging and audit trails (para 93): “every IT application / system that can access or affect critical or sensitive information has necessary audit logging capabilities and provides audit trails.”
• Validated capture settings (para 94): settings for capturing appropriate logs and audit trails for each device, system software and application software must be implemented and periodically validated, with a minimum identifiable record (date, timestamp, source and destination addresses, and other relevant elements).
• Forensic sufficiency (para 95): audit trails must satisfy business, regulatory and legal requirements and be detailed enough to “facilitate the conduct of audits, serve as forensic evidence … and assist in dispute resolution, including for non-repudiation purposes.”
• Monitoring of the audit trails (para 96): “the bank shall put in place a system for regularly monitoring the audit trails and system logs to detect, understand or recover from any unauthorised activity or attack.”
• Continuous surveillance (para 143): a CSOC to ensure continuous surveillance, with log collection, storage and correlation through a SIEM for continuous surveillance, and continuous monitoring of SIEM dashboards to identify anomalies.
• Reporting timeline (para 182): cyber incidents reported within six hours of detection on DAKSH, with proactive CERT-In notification.
• Data migration audit trails (para 55): data-migration activity must itself be audit-trailed, with business-user and application-owner sign-off at each stage.

Two implications IT teams consistently underestimate: “periodically validated” is a recurring task, not a one-time configuration (so it needs a change record), and para 96 puts the burden on monitoring the logs, not merely storing them. That is a monitoring-capability requirement, which is why this topic sits in the monitoring and observability workstream rather than only in SIEM procurement.

What about DPDP?

Rule 7 of the DPDP Rules, 2025 puts a clock on breach handling: on becoming aware of a personal data breach, a Data Fiduciary must intimate the Data Protection Board and affected Data Principals and file a detailed report within 72 hours, covering nature and extent, timing and location, root cause, mitigation and remedial actions.

The Digital Personal Data Protection Rules, 2025 changed breach handling from a best-effort process into a clock. Under Rule 7, on becoming aware of a personal data breach a Data Fiduciary must intimate the Data Protection Board and affected Data Principals, and submit a detailed report to the Board within 72 hours — covering the nature and extent of the breach, its timing and location, the events and root cause, mitigation measures, the parties responsible, remedial and preventive actions, and evidence of intimations to Data Principals (https://www.dpdpa.com/dpdparules/rule7.html).

That list is, functionally, a demand for monitoring and forensic records: timing presumes you know when the event started, location presumes you know which system or vendor environment was involved, and root cause presumes you retained the telemetry. Where a firm cannot reconstruct those, the report is written from imagination — which is a compliance risk in its own right. The data-protection side of this is covered in our Data Protection & Business Continuity service line; the security-control side in Cybersecurity & Risk Assurance.

How long do you have to detect and report?

Two clocks drive the design. Cyber incidents must be reported to the RBI on DAKSH within six hours of detection, with proactive CERT-In notification (RBI Directions 2026, para 182). Personal data breaches carry a 72-hour detailed report to the Data Protection Board (DPDP Rules 2025, Rule 7). Six hours means detection-to-evidence must work in minutes.

The clocks are the practical design constraint:

A six-hour reporting clock means detection-to-evidence must be measured in minutes, not in next-morning triage. This is why alert quality and escalation paths — the subject of our monitoring optimisation work — are a compliance control and not just an operations nicety: an alert that is ignored by 62% of IT leaders (2024 IDC survey, cited in Motadata’s Top 11 Observability Obstacles in 2026, https://www.motadata.com/blog/observability-obstacles) is an unusable control.

What should an IT team be able to produce on request?

A monitoring evidence pack: a coverage register of every critical system with its owner; the log and audit-trail configuration record with validation dates; an alert-to-incident mapping showing reconstructable timelines; escalation and on-call records; a monitoring change log; a retention statement; and confirmation that outsourced providers capture logs.

A defensible monitoring evidence pack:

1. Coverage register — every critical system, host, device and application, the monitoring agent/probe covering it, and the owner. Plus the exceptions, with a stated reason.
2. Log and audit-trail configuration record — capture settings per system class, with the validation date and validator (para 94 requires periodic validation).
3. Alert-to-incident mapping — for a sample period: alert fired → ticket raised → acknowledgement → resolution, showing the timeline is reconstructable.
4. Escalation and on-call record — who is paged, when, and how the six-hour reporting clock is triggered.
5. Monitoring change log — rule changes, threshold changes, platform changes, with dates. (This is also what makes a “we tuned it down” finding survivable.)
6. Retention statement — how long logs and audit trails are kept, and where.
7. Vendor/ASP chain — for outsourced systems, confirmation that the service provider generates and captures logs and facilitates forensic auditing. The Directions attach this obligation to the ASP as well (para 15/16 of the ASP annex).

Evidence packs are usually thinner than teams expect. Building them is a bounded project, and it pays for itself in the audit cycle rather than in a product licence. Our Consulting & Assessment and Enterprise IT Service & Operations service lines are structured around exactly that gap analysis.

Where do platforms fit — and where they don’t?

Platforms are the means: log collection, correlation, retention, dashboards and alert routing. The evidence is what they are configured to record and what the team does with it. A stack that cannot answer when did we first know, and what was configured that day, is not audit-ready regardless of vendor.

Platforms are the means: log collection and correlation, retention, dashboards, alert routing. The evidence is what they are configured to record and what the team does with it. A monitoring stack that cannot answer “when did we first know?” and “what was configured on that date?” is not audit-ready regardless of which product is behind it. That is why the end state is described as an observability capability — see the Observability pillar — rather than a named tool.

Book a compliance-readiness review with a VTeamTech monitoring specialist — contact us.

Not legal advice: this article summarises publicly available regulatory text for IT-monitoring planning. It does not constitute legal or compliance advice; confirm obligations with your compliance function or counsel.

Frequently asked questions

What does RBI require for audit logs?

The RBI’s 2026 Directions for commercial banks require audit-logging capability and audit trails on every system that can access or affect critical or sensitive information (para 93), periodically validated log-capture settings (para 94), audit trails detailed enough to serve as forensic evidence (para 95), and a system for regularly monitoring audit trails and system logs to detect or recover from unauthorised activity (para 96).

How quickly must a cyber incident be reported to RBI?

Within six hours of detection, on RBI’s DAKSH platform, with proactive notification to CERT-In (RBI Directions 2026, para 182).

What must a DPDP breach report contain and by when?

Under Rule 7 of the DPDP Rules, 2025, a Data Fiduciary must submit a detailed report to the Data Protection Board within 72 hours of becoming aware of a personal data breach, covering the nature and extent of the breach, events and root cause, mitigation, responsible parties, remedial and preventive actions, and evidence of intimations to Data Principals.

Is monitoring enough to satisfy an audit?

No. Audits examine evidence: coverage records, validated log-capture settings, reconstructable alert-to-incident timelines and monitoring change records. Monitoring without that evidence trail is a detection capability, not an auditable control.

Sources

1. Reserve Bank of India, Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, RBI/DoS/2026-27/410, 31 July 2026 (paras 55, 93–96, 143, 182; ASP annex paras 15–16, 23) — https://rbi.org.in/scripts/NotificationUser.aspx?Id=13643&Mode=0
2. Digital Personal Data Protection Rules, 2025, Rule 7 — Intimation of Personal Data Breach (72-hour detailed report) — https://www.dpdpa.com/dpdparules/rule7.html
3. Supporting (statistical): Motadata, Top 11 Observability Obstacles IT Teams Must Solve in 2026, citing a 2024 IDC survey — 62% of IT leaders ignore at least half their monitoring alerts — https://www.motadata.com/blog/observability-obstacles

Related reading

• Migrating legacy monitoring without a blackout
• How to cut alert fatigue in a mid-market NOC