By Xhield Team · May 25, 2026 · 9 min read
Tags: CERT-In Breach Reporting Incident Response VAPT India Cybersecurity CISO Enterprise Security Attack Surface Management Compliance
A CISO I spoke with recently put it this way: "We ran a tabletop exercise in January. Simulated a ransomware incident. From the moment we assumed breach to the moment we had enough information to file a CERT-In report — it was eleven hours. And we thought we were reasonably well-prepared."
Eleven hours. Against a six-hour legal obligation.
That gap — between what organisations believe their detection and response capability is, and what it actually is under real pressure — is the most underdiscussed compliance risk in India right now. CERT-In's 6-hour breach reporting window gets cited in every compliance conversation. What gets cited far less often is what it actually takes, technically and operationally, to meet it.
This piece is about that.
What the 6-Hour Window Actually Demands
Let's be precise about what the CERT-In direction requires, because "report within 6 hours" understates the operational challenge significantly.
To file a CERT-In incident report within 6 hours of becoming aware of an incident, your organisation needs to have completed — within that window — all of the following:
Detection. You need to know something happened. This sounds obvious, but it's where many organisations fail. Detection requires that the affected systems are being monitored, that logs are being collected, and that someone or something is watching those logs in near real-time. For organisations with logging gaps — systems that aren't monitored, shadow IT assets outside managed infrastructure, or SIEM coverage that's narrower than the actual estate — detection can take days, not hours.
Triage and confirmation. False positives are the enemy of fast response. Before you can report a breach, you need to be confident it's a genuine incident, not a misconfigured alert. Triage requires an analyst (or automated capability) that can quickly separate signal from noise — and that requires both tool maturity and trained people.
Scope characterisation. CERT-In's reporting format requires you to describe what was affected: which systems, what categories of data, the estimated number of individuals impacted, the attack vector. You can't answer these questions without having visibility into your environment — logs, network flows, access records — and the ability to query them quickly.
Internal escalation and notification chain. The report has to come from somewhere in the organisation. That means your incident response plan needs to specify who owns CERT-In notification, who authorises the report, and what format it takes. Teams that haven't pre-defined this chain discover — at the worst possible moment — that it doesn't exist.
Each of these steps takes time. In a real incident, they compete with each other under conditions of uncertainty, pressure, and incomplete information. Six hours goes very quickly.
The Infrastructure Question
Meeting the 6-hour window is fundamentally an infrastructure problem before it's a process problem. If your monitoring stack can't surface a breach in time, no amount of incident response planning will save you.
Here's what the infrastructure needs to look like to give you a realistic shot at 6-hour compliance:
Centralised log collection with near-real-time ingestion. Logs sitting in separate silos — server logs here, application logs there, cloud logs somewhere else — cannot be correlated quickly enough during an incident. A centralised SIEM or log management platform that ingests from all relevant sources, in near real-time, is the baseline.
Coverage across your actual attack surface, not your assumed one. CERT-In's logging requirements apply to all ICT systems within your operational environment. That includes cloud workloads, third-party integrations, and yes — shadow IT assets. If a forgotten subdomain or rogue AWS instance is breached, you have a 6-hour obligation and zero logs. This is one of the most consequential gaps in most organisations' logging posture.
Alert tuning that makes triage fast. A SIEM generating thousands of unranked alerts is not a detection capability — it's noise. Effective triage within a 6-hour window requires alerts that are prioritised, contextualised, and routable to the right analyst without delay.
Query capability that can answer scope questions quickly. When an analyst needs to know "what data was on this server" or "which users accessed this system in the last 72 hours," the answer needs to be retrievable in minutes, not hours. This requires both data completeness (the logs exist) and query tooling that can interrogate them efficiently.
The 180-day retention requirement makes this harder. CERT-In requires logs to be retained for 180 days and stored within Indian jurisdiction. Many organisations are meeting retention in theory — logs are being kept — but haven't validated that those logs are actually queryable in an incident scenario. Archived logs that take hours to retrieve are not useful in a 6-hour window.
Where the Clock Actually Starts
One point worth understanding carefully: CERT-In's 6-hour window starts from when you become aware of the incident, not from when the incident occurred.
This is both reassuring and dangerous. Reassuring, because you're not penalised for a dwell time of days before detection — the clock starts at detection. Dangerous, because it creates a perverse incentive to avoid detection rather than improve it, and because it makes the question of when did we first become aware into a potential point of contention in any regulatory investigation.
In practice, this means your organisation needs clear, documented detection timestamps. Not just "we found it on Tuesday" but a timestamped alert, a log entry, a ticket — something that establishes when awareness began. Without that documentation, the question of whether you filed within 6 hours becomes impossible to answer definitively.
This is a detail most organisations haven't thought through. It's worth thinking through before you need it.
Testing Your Actual Capability: The Tabletop
The only reliable way to know whether your organisation can meet the 6-hour window is to test it — not in theory, but in a structured exercise that surfaces where the real gaps are.
A well-designed tabletop for 6-hour compliance should:
Start with a realistic scenario. Not an obvious, loud breach — ransomware lighting up every screen — but something subtler. A credential compromise. An exfiltration through a trusted third-party integration. An alert that looks like a false positive for the first two hours. The scenarios that stress-test 6-hour compliance are the ambiguous ones.
Impose realistic constraints. Key people are unavailable. The SIEM is generating 200 alerts. The affected system is a cloud instance that IT wasn't fully aware of. The constraints that exist in real incidents should exist in the exercise.
Clock every decision. When did detection occur? When was triage complete? When was the scope confirmed? When was the reporting chain activated? When was the CERT-In report drafted and ready? Mapping these timestamps against the 6-hour window shows you exactly where time is being consumed and where you'd fail.
Identify the log gaps. In the scenario, what questions can your team not answer because the logs don't exist? This is often the most valuable output of a well-run tabletop — a concrete list of logging gaps that would have prevented scope characterisation within the window.
End with a CERT-In report attempt. Have someone actually try to complete CERT-In's reporting format using only the information that would have been available at the point they'd have filed. How complete is it? What questions can't they answer? The gaps in the report are the gaps in your capability.
What Frequently Gets Missed
A few things that come up consistently when organisations actually test their 6-hour capability:
Cloud and SaaS blind spots. Logging is typically mature for on-prem infrastructure and core applications. It's frequently absent or incomplete for cloud workloads, SaaS tools, and API integrations — which are increasingly where breaches originate.
Third-party and supply chain incidents. If a vendor you integrate with is breached and your data is affected, you have a CERT-In reporting obligation. But you're dependent on that vendor to notify you — and vendor notification timelines are often far longer than 6 hours.
The scope question under pressure. Knowing what data was on a compromised system is harder than it sounds. Data classification, asset inventory, and access logs all need to be accurate and queryable. Most organisations discover during exercises that their data map is significantly out of date.
The notification chain breaking down. Incident response plans designate roles. People change jobs, go on leave, or are simply unreachable. The notification chain that looks complete on paper often has single points of failure that only become visible under pressure.
Practical Steps Worth Taking Now
If you haven't validated your 6-hour capability, a few things worth doing before your next audit cycle:
Work backwards from the CERT-In reporting form. Every field in that form is a question your detection and response capability needs to be able to answer quickly. Audit your ability to answer each one within 6 hours of a realistic detection event.
Audit your logging coverage against your actual attack surface — not your asset register. Use external discovery to find what's actually exposed, then map that against what's logging. The delta is your risk.
Run a tabletop. A half-day exercise will surface more real gaps than a year of compliance documentation reviews.
Pre-draft your notification templates. The CERT-In report format doesn't change. Having a pre-populated template that your team can complete quickly under pressure saves time when it matters most.
Establish your detection timestamp process. Whatever your first detection mechanism is — SIEM alert, EDR flag, external notification — make sure it generates a timestamped record that you can point to as "when we became aware."
The Honest Assessment
The 6-hour window is genuinely difficult for most Indian enterprises — not because the rule is unreasonable, but because meeting it requires a level of infrastructure maturity that takes time to build.
The organisations that are getting this right aren't meeting the window through heroic incident response. They're meeting it because they've invested in logging coverage, alert quality, and detection tooling to the point where the first few hours of an incident are spent confirming and scoping rather than searching.
That investment starts with knowing your actual attack surface — all of it, not just what's in your asset register. Because a breach you can't detect in time is a compliance failure you didn't have to have.
At xhield.tech, we help security teams understand their full attack surface before incidents happen — including the assets outside your asset register that your CERT-In logging obligations still cover. If you're working through your 6-hour compliance readiness, we'd like to talk.
Tags: CERT-In Breach Reporting Incident Response VAPT India Cybersecurity CISO Enterprise Security Attack Surface Management Compliance