What a dashboard actually answers
A dashboard is a very good answer to one question: what does the network look like right now. It is a poor answer to almost every question a regulator asks, because every one of those questions is about a specific moment in the past, what the system showed at 02:40 on a Sunday, who saw it, and what they did in the next six hours. A screen that refreshes every thirty seconds does not retain the version of itself from three weeks ago. If the only record of an event is a chart someone glanced at and moved past, there is no record at all. There is a memory of a record, and memories do not hold up under audit.
Monitoring and evidence solve different problems, and the gap between them is exactly where compliance findings live. Monitoring answers "is something wrong right now". Evidence answers "prove, after the fact, to someone who was not there, exactly what happened, when, and who acted on it", and it must survive being disputed. That distinction shows up directly in how a security operations programme gets assessed: a complete log of cyber events, classified by severity, with timestamps from detection through notification, is what gets checked, and missing entries, particularly for events that appear in a system log but never reached the incident register, get treated as unreported incidents, not gaps in paperwork. The system log proved something happened. It did not, on its own, prove that anyone noticed it, classified it correctly, or acted inside the required window. That second part is what evidence has to carry, and a live dashboard was never built to carry it.
The evidence chain, in one view
A dashboard tells you the system is fine right now. A regulator asks what it showed at a specific moment weeks ago, and whether anyone acted on it in time. Only a chain built for the second question survives being written down.
- Answers "is it fine right now"
- Overwrites its own history every refresh
- An unverifiable claim about a screen nobody photographed
- Proves system state at this instant, nothing before it
- Answers "what happened, when, and who acted"
- Captured the instant the event happens, hash-chained after
- Verifiable independent of who is asking, or when
- Survives being disputed, weeks or months later
The RBI window is a test of the evidence chain, not the monitoring
For regulated entities under RBI's cybersecurity framework, this stops being an abstract distinction and becomes a clock. Unusual cyber incidents must reach RBI's cybersecurity cell through the DAKSH portal within six hours of detection, with a full root cause analysis following within 21 days.
Read that timeline as a test, not a formality. Whoever is on shift when a critical incident lands at 02:40 on a Sunday needs to know they have until roughly 08:40 to file, and filing on time is only half the requirement. The entity also has to reconstruct, afterward, exactly how the incident was detected, how it was classified, and what the evidence trail looked like at every step, because filed notifications are cross-referenced against the internal incident register, and a mismatch between what the systems recorded and what got reported is the finding auditors look for first.
That two-stage structure, a same-day notification deadline followed by a 21-day evidentiary deep-dive, means the evidence chain has to do two different jobs on two different timescales. In the first six hours it must produce enough certainty to classify and notify correctly under pressure. Over the following three weeks it has to hold up to a root cause analysis read by people who were nowhere near the incident when it happened, and who have every reason to ask why the timeline in the report does not match the timeline in the logs.
What monitoring must produce to become evidence
Three properties separate a log that is evidence from a chart that is not, and none of them come from the monitoring tool doing more monitoring. They come from how the output is captured and preserved.
Tamper-evidentA record that can be edited after the fact is not a record of what happened, it is a record of what someone decided, later, they would like it to show. Capturing events the instant they happen and chaining each entry cryptographically makes any tampering attempt detectable, rather than silent.
Time-stamped to the minuteA dashboard that shows status answers “is it fine now”. An investigation needs the sequence: the state at detection, what changed at each step, and how much time elapsed between each one, because a log that cannot place an event to the minute cannot prove a six-hour window was met.
Retained and correlatedA single system's log proves that system saw something. A regulator's question is usually broader: did the SOC see it, was it classified, did the notification go out, does the incident register match. That needs the NMS event, the SOC's decision log and the filed notification checked against each other after the fact, not just individually true.
The difference between "the dashboard showed green" and a timestamped, hash-chained entry is that the second one still says the same thing regardless of who is asking, or when.
Where Rhinexa NMS and Rhinexa Sentinel carry this weight
This is the part that separates "we have monitoring" from "we can show what happened", and it is built at the pipeline level, not the dashboard level.
Rhinexa NMS is the system of record for what the network looked like and when it changed: the topology state, the device inventory, the link and interface events that establish, after the fact, what was connected and reachable at a given timestamp. For an investigation, this is what answers "was this device even supposed to be on this segment" and "when did this interface state change relative to the incident". That answer has to come from a retained, queryable history, not from someone's memory of what the topology map looked like that week.
Rhinexa Sentinel, in this pipeline, is the layer that turns raw network behaviour into a specific, attributable event, the broadcast anomaly, the rogue device, the traffic pattern that does not match baseline, with enough detail, source, destination, protocol, timestamp and the specific check that fired, to become the seed of an incident record rather than a line on a chart that scrolled past. What matters for compliance is not the alert popping up on someone's screen the moment it happens. It is the durable, timestamped artefact that alert leaves behind, which can be pulled back out weeks later and still say exactly what it said the day it fired.
Put together, the pipeline that produces evidence a regulator can check looks less like a dashboard and more like a chain of custody: Rhinexa Sentinel detects and timestamps the anomaly, Rhinexa NMS confirms and contextualises what was actually on the network at that moment, the SOC's classification and escalation decision is logged against the same timeline, and the filed RBI notification references that same chain rather than a fresh narrative reconstructed after the fact. Every link has to be independently retrievable and mutually consistent, because that consistency, not the existence of any single log, is what a cross-reference check is testing for.
A short checklist for evidence-grade monitoring
- Can you reproduce the exact state of the network at a specific past timestamp, not today's dashboard, but what Rhinexa NMS showed three weeks ago at 02:40?
- Is every alert that fired preserved with its original detail, source, destination, protocol, and the specific rule or baseline deviation that triggered it, independent of whether anyone acted on it that day?
- Is the classification decision logged, with a timestamp, separately from the raw alert, so you can show not just that something was detected, but when a human or an automated process decided what it was?
- Does the incident register cross-reference cleanly against system logs, would an auditor pulling a random anomaly from Rhinexa NMS find a matching entry, or a gap?
- Can you reconstruct the full timeline from detection to notification inside the reporting window, with timestamps at each step, not a narrative written after the fact to fit the deadline?
If any of those produce a "we would have to piece that together" answer, the monitoring is working. It is the evidence chain that is not, and that is the gap a regulator finds first.
A dashboard tells you the system is fine right now. A regulator wants to know what the system showed at a specific moment weeks ago, and whether anyone acted on it in time. Only one of those claims survives being written down.
