CERT-In and Incident Reporting Requirements

CERT-In's 2022 directions turned a compliance checkbox into an operational deadline: six hours from when you become aware of an incident to when you report it, with 180 days of logs sitting locally and synced to the correct clock. Meeting that clock reliably is not an audit problem — it is an architecture problem, and it forces a shift from annual assurance exercises to always-on, machine-verifiable compliance.

The 6-hour mandate and why it broke old playbooks

Before April 2022, most Indian enterprises treated cybersecurity compliance the way they treated ISO 27001 or SOC 2 — a periodic ritual. An auditor showed up once or twice a year, sampled a handful of controls, checked a handful of logs, and signed off. Incident reporting to CERT-In existed on paper, but the reporting window was loose enough that a security team could reasonably investigate first and report afterward. That model collapsed the moment the Indian Computer Emergency Response Team published its April 28, 2022 directions under Section 70B(6) of the Information Technology Act, 2000, and set a hard six-hour reporting clock for a defined list of incident types.

Six hours is not a lot of runway once you account for how incidents actually unfold. A phishing-triggered credential compromise typically takes 20–40 minutes just to correlate across identity logs, email gateway logs, and endpoint telemetry before an analyst is confident it is real. Add triage, severity classification, internal escalation to a CISO or designated point of contact, and drafting a report with the fields CERT-In expects — timestamps, IP addresses, indicators of compromise, systems affected — and a manual process eats the entire window before the report is even reviewed for accuracy. Organizations that tried to bolt the six-hour requirement onto existing manual SOC workflows discovered, often during their first reportable incident, that the clock was not negotiable and their process was not fast enough.

The deeper shift the directions forced is philosophical as much as procedural. Point-in-time audits answer the question "were you compliant on the day we looked?" CERT-In's regime answers a harder question: "can you prove, continuously, that you would detect a reportable event and report it within six hours, every single time, including at 3 a.m. on a public holiday?" That question cannot be answered by a quarterly control review. It can only be answered by an architecture that treats compliance as a live, continuously tested system property — which is exactly the discipline this article works through: what CERT-In requires, why static assurance fails against it, and how to build compliance-as-code, continuous monitoring, and evidence automation that make the six-hour clock a non-event rather than a fire drill.

The 2022 directions: what they actually mandate

It is worth being precise about scope, because a large share of compliance failures trace back to teams reporting either too much noise or missing genuinely reportable events because they misread the categories. The CERT-In directions apply to "service providers, intermediaries, data centers, body corporates and government organisations" — in practice, almost any entity operating IT infrastructure in India, not just regulated financial or critical-infrastructure sectors. The directions rest on four pillars.

Mandatory reporting within six hours

Twenty categories of incidents must be reported to CERT-In within six hours of being noticed or being brought to notice. The list includes targeted scanning or probing of critical systems, unauthorized access to IT systems or data, defacement of websites, malicious code attacks including ransomware and cryptojacking, attacks on servers, network devices, or software supply chains, data breaches, data leaks, attacks on IoT devices and associated systems, attacks on cloud infrastructure and virtualized systems, and attacks related to critical sectors such as power, transportation, and financial systems. The reporting trigger is deliberately broad: "unauthorized access" covers everything from a compromised low-privilege account to a full domain takeover, which means the classification logic in your detection pipeline has to be tuned to avoid both under-reporting and an unmanageable volume of over-reporting.

Synchronized time sources

All entities must connect to the Network Time Protocol (NTP) servers of the National Informatics Centre (NIC) or the National Physical Laboratory (NPL), or to NTP servers traceable to these sources, with a permitted deviation typically kept within a small tolerance. This clause looks minor next to the six-hour rule, but it is foundational: every downstream compliance argument — log correlation, causality chains, "who touched what when" — depends on clocks agreeing across the estate. A ten-minute clock skew between your firewall and your identity provider can make a forensic timeline unreconcilable, which in turn makes it impossible to certify to CERT-In (or to your own board) exactly when an incident began.

180-day log retention, stored in India

Entities must enable logs of all their ICT systems and maintain them securely for a rolling 180 days within Indian jurisdiction, and must provide these logs to CERT-In upon request as part of an incident investigation. This is a data residency and retention requirement simultaneously, and it interacts badly with architectures built around short-lived cloud log retention defaults (many managed logging services default to 14–90 days) or with multinational organizations whose SIEM lives in a different jurisdiction for cost or consolidation reasons.

Point of contact and registration duties

Data centers, virtual private server (VPS) providers, cloud service providers, and virtual private network (VPN) service providers must maintain customer registration records — names, addresses, contact numbers, the purpose of use, and validated ownership patterns — for a minimum of five years after cancellation of registration or subscription. Crypto exchanges and wallet providers carry additional KYC-style retention duties. Every regulated entity must designate a point of contact to liaise with CERT-In, and that contact's details must stay current in CERT-In's own systems.

Why point-in-time audits cannot meet a six-hour clock

A conventional audit cycle validates a sample of controls at a moment in time and infers that the sampled state is representative of the whole year. That inference was always statistically shaky, but it becomes actively dangerous under a hard reporting deadline for three structural reasons.

First, control drift is continuous, while audits are discrete. A firewall rule opened for a vendor integration in March and never closed, a logging agent that silently stopped shipping events after an OS patch in June, an NTP client that fell back to an unsynchronized local clock after a network change — none of these show up until the next audit cycle, and by then they may have been silently broken for months. Under CERT-In's regime, a silently broken logging pipeline is not a paperwork problem; it is the reason you cannot produce 180 days of logs on request, and it is the reason your incident response team missed the alert that should have started the six-hour clock in the first place.

Second, the artifacts an audit produces — PDF reports, spreadsheets, screenshots — are themselves stale the moment they are generated and carry no mechanism for re-verification. If a regulator or your own board asks "prove that this control was operating on the day of the incident," a point-in-time audit from four months earlier is evidence of nothing more than a passing grade at that one moment. Always-on assurance instead produces a continuous evidentiary trail: every control check, every log ingestion event, every alert triage decision is itself logged, timestamped against the same NIC/NPL-synchronized clock, and queryable retroactively.

Third, and most practically, a six-hour deadline requires the detection-to-report pipeline itself to be a tested, monitored system — not a document describing a process a human is supposed to remember to follow under stress. Fire drills matter, but a fire drill run once a quarter does not tell you whether your SOAR playbook correctly populates the CERT-In incident report template with the right IP addresses when three different logging formats are involved, or whether your escalation paging chain has a stale phone number for the deputy CISO. Only continuous, automated verification of the pipeline — treating the compliance pipeline itself as production software with its own monitoring — closes that gap.

Architecture for always-on assurance

Always-on assurance is not a single product; it is a layered architecture where each layer produces evidence the layer above consumes. Four layers recur across every implementation that has held up under real CERT-In reporting pressure.

At the base is the telemetry layer: agents, log forwarders, network taps, cloud API pollers, and identity provider event streams that produce the raw signal. This layer has to guarantee coverage — every asset, every cloud account, every SaaS tenant — because a single unmonitored system is a single point where a reportable incident can occur and never surface. Above that sits the correlation and detection layer: a SIEM or XDR engine that normalizes telemetry into a common schema, applies detection logic (signature, behavioral, and machine-learning-based), and produces alerts with a confidence score and a mapped incident category. This is where the CERT-In reporting clock effectively starts, so detection latency here is the single biggest lever an organization has over meeting the six-hour deadline.

The third layer is policy and control-as-code: version-controlled definitions of what "compliant" means for every asset class — retention periods, NTP configuration, encryption-at-rest settings, access control baselines — expressed as machine-readable policy that a scanning engine can continuously evaluate against live infrastructure state, rather than as a paragraph in a Word document that a human re-reads once a year. The fourth layer is evidence and reporting automation: the layer that takes a detected, classified incident and a verified compliance state and turns them into the specific artifacts CERT-In requires — the incident report fields, the log excerpts, the timeline — without a human manually assembling them from six different tools under time pressure.

Platforms built around agentic AI change what is achievable at each of these layers, particularly the top two. An agentic SOC model uses autonomous investigation agents to triage an alert, pull the relevant context from identity, endpoint, and network telemetry, and draft a classified incident summary in the same window a human analyst would still be reading the first log line — which is precisely the compression the six-hour clock demands. Algomox's CyberMox platform applies this pattern directly to CERT-In-relevant workflows: AI-driven XDR alert triage reduces the detection-to-classification interval from hours to minutes by having agents correlate signals across the estate automatically rather than waiting for a human to open five consoles.

Compliance-as-code: turning directions into policy

Compliance-as-code means expressing every requirement in the CERT-In directions as a testable assertion that a machine can evaluate against live system state, store the result of that evaluation as evidence, and re-evaluate on a schedule tight enough to catch drift before it becomes an incident. In practice this looks like a policy repository, checked into version control alongside your infrastructure-as-code, with one policy file per requirement family.

A retention policy, for example, is not a paragraph in a compliance manual; it is a rule evaluated against every log source's actual configured retention window, expressed roughly as: for every registered log source, assert that retention ≥ 180 days AND storage region == IN AND last successful write < 15 minutes ago. An NTP policy asserts that every host's configured time source resolves to an NIC/NPL-traceable server and that observed clock drift stays under a defined threshold, continuously, not just at provisioning time. A detection-coverage policy asserts that every asset in the CMDB has an active telemetry agent reporting within the last hour, catching the "silently stopped shipping logs" failure mode before an audit ever would.

The advantage of this approach is threefold. First, policies are reviewable and diffable like any other code — when the compliance team tightens the acceptable clock-drift threshold from five minutes to two, that change goes through the same pull request and approval workflow as an application change, with a clear audit trail of who changed what and why. Second, policies can be tested against synthetic infrastructure before they are deployed against production, the same way unit tests validate application logic, so a poorly written policy does not generate thousands of false positives across a live estate. Third, and most importantly for the six-hour deadline, policy evaluation results become the evidence base a reporting engine draws on: when an incident occurs, you do not need to manually reconstruct "was logging enabled on this host," because the policy engine has already been asserting and recording the answer to that question every fifteen minutes for months.

Compliance-as-code also changes how organizations handle the parts of the CERT-In directions that are organizational rather than technical — the designated point of contact requirement, for instance, can be encoded as a policy that checks whether the PoC record in your ticketing or identity system has been reviewed within the last quarter, flags it for renewal, and blocks a compliance dashboard from showing green if the PoC's contact details have gone stale. Treating organizational duties with the same rigor as technical controls closes a gap that pure technical monitoring tends to leave open.

Continuous monitoring: the telemetry backbone

Continuous monitoring is the operational expression of compliance-as-code: it is the always-running process that evaluates policies against live state and produces the detection signal a reportable incident needs to trigger. Building this backbone well requires decisions at three levels — coverage, normalization, and latency.

Coverage: closing the blind spots that create reporting gaps

Coverage gaps are the most common reason organizations miss the six-hour window entirely rather than merely reporting late. A reportable incident that occurs on an asset with no telemetry agent, in a cloud account that was never onboarded to the SIEM, or inside a SaaS application whose audit log API was never integrated, will not generate an alert at all — the clock never starts because nobody notices until a customer, a partner, or CERT-In itself notices first. A practical coverage program inventories every asset class — on-prem servers, containers, cloud workloads across every subscription and account, network devices, identity providers, SaaS applications, OT/IoT devices where applicable — and tracks live telemetry coverage as a first-class metric, not a one-time onboarding checklist. Shadow IT and unmanaged cloud accounts are the most common source of blind spots; a continuous threat exposure management program that continuously discovers and inventories assets, rather than relying on a static CMDB, closes this gap structurally.

Normalization: making twenty log formats into one queryable schema

A large enterprise easily has fifteen to thirty distinct log formats in flight — syslog from network gear, Windows Event Log from endpoints, cloud-native formats from AWS CloudTrail or Azure Activity Log, application-specific JSON from SaaS audit APIs. Without normalization into a common schema (a Common Event Format or an internal canonical schema mapped to something like the Open Cybersecurity Schema Framework), correlation across sources during an active incident becomes a manual, error-prone exercise that eats the six-hour clock. Investing in schema normalization up front is what makes a query like "show every authentication event, privilege escalation, and outbound connection for this user in the last 24 hours, across every system" answerable in seconds rather than requiring an analyst to manually cross-reference five different consoles.

Latency: the metric that decides whether six hours is achievable

Mean time to detect (MTTD) and mean time to classify (MTTC) are the two latency metrics that determine how much of the six-hour budget is left for human decision-making, escalation, and report drafting. If MTTD plus MTTC together consume four of the six hours, the organization has two hours left to classify severity correctly, get sign-off from a CISO or designated authority, and produce a report CERT-In will accept without follow-up queries — a thin margin for anything that goes wrong, such as a key approver being unreachable. Organizations that have successfully operationalized the six-hour rule generally target MTTD plus MTTC combined at under 60 minutes for high-severity categories, using a combination of behavioral detection tuned to CERT-In's twenty reportable categories and automated enrichment (asset ownership, business criticality, affected data classification) that would otherwise require manual lookup.

Automating the six-hour reporting workflow

The reporting workflow itself deserves to be engineered with the same rigor as any other latency-sensitive production system, because it is one: a state machine with a hard SLA and defined failure modes. A mature implementation breaks the six hours into an explicit budget across five stages, each with an owner, a target duration, and an automated fallback if the target is missed.

1. Detection and initial classification (target: 15–30 minutes). The SIEM/XDR engine or an investigation agent produces an alert mapped to one of the twenty CERT-In categories with a confidence score. Anything above a defined confidence threshold auto-opens an incident record and starts the compliance clock, rather than waiting for a human to manually create a ticket.
2. Enrichment and severity scoring (target: 15–30 minutes). Automation pulls asset ownership, data classification, business criticality, and blast-radius context (what else does this system talk to) so the human reviewer sees a fully populated picture rather than a bare alert.
3. Human validation and sign-off (target: 60–90 minutes). A designated approver — ideally with a defined backup and an escalation path if the primary is unreachable within a set time — confirms the classification and authorizes the report. This is the stage most organizations under-invest in operationally, treating it as "someone will see the Slack message," which fails exactly when it matters most, such as outside business hours.
4. Report generation (target: under 15 minutes). A templating engine auto-populates the CERT-In incident report format — incident category, timestamps in IST cross-referenced against the NIC/NPL-synchronized clock, affected systems, IP addresses, indicators of compromise, and remedial actions taken — pulling every field from the already-normalized telemetry rather than requiring an analyst to retype data from five screens.
5. Submission and acknowledgment tracking (target: under 15 minutes). The report is submitted through CERT-In's designated channel, and the submission itself — timestamp, submitting user, acknowledgment receipt — becomes part of the permanent evidence trail.

Building automated fallbacks for stage three is what separates organizations that reliably meet the deadline from those that miss it under pressure. A common pattern is a tiered escalation: page the primary approver, and if there is no acknowledgment within twenty minutes, automatically escalate to a secondary approver and notify the CISO, with every escalation step itself logged as evidence that due diligence was exercised even if a report ends up slightly late. CERT-In has historically shown more tolerance for organizations that can demonstrate a robust, evidenced process with a narrow, explainable miss than for organizations with no demonstrable process at all.

Evidence packaging deserves separate attention. When CERT-In or an internal audit later asks "prove you handled this correctly," the answer should be a single, retrievable package: the original alert, every enrichment step, the approval chain with timestamps, the generated report, and the submission receipt, all cross-referenced against the synchronized clock. Building this package generation into the workflow itself — rather than reconstructing it after the fact from scattered tickets and emails — is the single highest-leverage investment in audit readiness, because it turns every real incident into a rehearsed, evidenced compliance artifact rather than a scramble to explain what happened months later when a regulator asks.

Log retention, time synchronization, and the 180-day rule

The 180-day retention requirement and the NTP synchronization requirement look like footnotes next to the headline six-hour rule, but they are the load-bearing infrastructure everything else depends on, and they fail in quiet, cumulative ways rather than dramatic ones.

Retention failures typically stem from mismatched defaults. Many managed cloud logging services — and a fair number of on-prem SIEM licenses — are priced and configured around 30- or 90-day hot retention with older data either purged or moved to a cold tier that is slow, expensive, or operationally painful to query. Meeting 180 days "for real" means the data has to be both retained and retrievable within a timeframe that supports an active investigation, not archived so deeply that pulling relevant logs takes days — which itself would breach the spirit, if not the letter, of providing logs to CERT-In on request during an incident. The practical answer is a tiered storage architecture: a hot tier covering the most recent 30–45 days for sub-second query performance during active triage, and a warm tier covering the remaining 180-day window with query latency in the minutes, both physically or logically located within Indian jurisdiction to satisfy the residency requirement.

Data residency compounds the retention challenge for multinational organizations whose SIEM or log aggregation platform is architected around a single global instance for cost efficiency. Two patterns have proven workable: maintaining a regional log store within India that receives a full copy of India-relevant telemetry and satisfies the 180-day/in-jurisdiction requirement independently of the global platform, or selecting a platform architecture that natively supports region-pinned data with policy-driven routing at ingestion time, so India-originating logs are routed and retained correctly without a parallel manual process. The second pattern is materially less operationally fragile because it removes a manual synchronization step that is easy to let drift out of compliance.

Time synchronization failures are subtler and more dangerous precisely because they are invisible until you need them. A host whose NTP client silently falls back to its local hardware clock after a network change will keep logging events with plausible-looking but wrong timestamps for months, and nobody notices until an investigator tries to build a causal timeline across systems and finds a ten-minute gap that does not add up. The fix is to monitor NTP health itself as a first-class continuous control — alerting on clock drift beyond a defined threshold, not just on synchronization failures — and to route every host's time source through infrastructure traceable to NIC or NPL servers as the directions specify, rather than through a generic public NTP pool that happens to be accurate today but offers no compliance traceability.

Roles, points of contact, and organizational readiness

Technology alone does not meet a six-hour deadline; the organizational design around it has to be equally deliberate. Three roles recur in every implementation that has held up under real incident pressure, and each needs a defined backup, not just a primary.

The designated CERT-In point of contact is the named liaison whose details must stay current in CERT-In's records and who is the accountable party for report accuracy and timeliness. This role should never be a single individual with no backup; a 24/7 rotation with a clear handoff protocol is the minimum viable structure, because reportable incidents do not respect business hours and a significant share of real-world incidents are first noticed overnight or on weekends. The incident commander role — often the on-call SOC lead or a rotating senior analyst — owns the operational triage and enrichment work and has pre-authorized decision rights to escalate a classification without waiting for a committee, which is what makes the aggressive stage-by-stage time budget in the reporting workflow achievable. The approval authority, typically the CISO or a delegate with explicit written delegation, signs off on the report before submission; building an explicit, time-bound delegation chain (if the CISO does not respond within twenty minutes, authority passes automatically to a named deputy) removes the single most common real-world cause of missed deadlines.

Readiness also means rehearsal. Tabletop exercises that specifically simulate the CERT-In six-hour clock — starting a stopwatch the moment a synthetic alert fires and measuring how long the organization actually takes to produce a submission-ready report — surface gaps that no policy document review will catch: a stale pager rotation, a report template missing a field CERT-In actually requires, an approver who does not know they are the deputy. Running this exercise quarterly, with the timing data itself logged and trended, turns organizational readiness into a measured, continuously improving control rather than a one-time training session that decays in institutional memory within months.

For organizations operating a hybrid or air-gapped estate — common in Indian government, defense, and critical infrastructure contexts — the same discipline applies with an added constraint: evidence assembly and policy evaluation have to run without dependence on external connectivity, which pushes toward on-prem or sovereign-deployed compliance tooling rather than SaaS-only platforms. This is a live design constraint for Algomox deployments across ITMox and CyberMox in sovereign environments, where the same compliance-as-code policies and evidence-automation workflows described above run entirely within the customer's own infrastructure boundary.

Measuring maturity: metrics that matter

An always-on assurance program needs its own scorecard, distinct from generic security metrics, because the questions that matter here are specifically about reporting reliability under a hard deadline. Six metrics form a practical baseline.

• Telemetry coverage ratio — the percentage of inventoried assets with active, healthy telemetry reporting within the last hour. Target above 98 percent; anything lower means blind spots are statistically likely to exist somewhere in the estate.
• Mean time to detect plus classify (MTTD+MTTC) — tracked separately for each of the twenty CERT-In categories, since a website defacement is detected differently than a ransomware encryption event. Target combined under 60 minutes for the highest-severity categories.
• Reporting SLA adherence rate — the percentage of reportable incidents where the CERT-In submission was made within six hours of first notice, tracked as a rolling twelve-month figure, with every miss root-caused and fed back into the workflow design.
• Policy drift rate — the number of continuous-compliance policy checks (retention, NTP, encryption, access baselines) that fail per week, trended over time; a rising trend indicates infrastructure change velocity is outpacing compliance automation and needs investment before it produces a real gap.
• Evidence package completeness — for each incident, whether the auto-assembled evidence package contained every required field without manual patching after the fact; incomplete packages point to gaps in normalization or enrichment logic.
• PoC and escalation chain currency — days since the designated point of contact and approval delegation chain were last verified as current and reachable.

These metrics belong on a live dashboard reviewed at least monthly by the CISO and, ideally, summarized quarterly for the board, because CERT-In compliance failures carry both regulatory and reputational consequences that boards increasingly expect to see tracked as an operational risk metric, not buried in an annual audit appendix.

A worked example: ransomware detection to submission

Concrete timelines make the architecture tangible. Consider a mid-size financial services firm running a hybrid estate — on-prem core banking systems, a private cloud for internal applications, and a public cloud footprint for customer-facing services. At 02:14 IST, an endpoint detection agent on a file server flags anomalous mass file-modification behavior consistent with ransomware encryption, cross-correlated within ninety seconds against a network sensor observing unusual SMB traffic volume to the same host and an identity log showing the same service account authenticating from an atypical internal IP address it has never used before.

The correlation engine assigns this a high-confidence score, auto-maps it to the CERT-In category "attack or incidents affecting systems related to Big Data, Blockchain, virtual assets... or attacks through malicious code such as ransomware," and opens an incident record at 02:16, which is the moment the compliance clock starts. An investigation agent immediately enriches the alert: it identifies the affected file server's business owner and criticality tier from the CMDB, pulls the last thirty minutes of process execution logs from the endpoint, identifies the specific ransomware family from a hash match against threat intelligence, and maps lateral movement risk by checking what other systems the compromised service account has access to. This enrichment, which would take a human analyst forty-five minutes of manual console-hopping, completes at 02:31.

The on-call incident commander receives a fully enriched incident summary via paging at 02:32, confirms the classification and severity at 02:41 after a nine-minute review, and the system automatically pages the designated approval authority. The primary approver does not respond within the twenty-minute escalation window, and at 03:01 the system automatically escalates to the named deputy CISO, who reviews and signs off at 03:12. The report generation engine, which has been assembling the CERT-In report template in parallel since the incident opened — populating incident category, affected system details, timestamps cross-referenced against the NIC-synchronized clock, indicators of compromise, and containment actions already taken (the affected server was automatically isolated from the network at 02:35 as part of the response playbook) — produces a submission-ready draft by 03:14. The approver reviews the final language and the report is submitted through CERT-In's channel at 03:22, with the acknowledgment receipt logged at 03:24.

Total elapsed time from first notice to submission: one hour and eight minutes, well inside the six-hour window, with roughly forty minutes of that consumed by the escalation to a secondary approver — exactly the scenario the tiered escalation design exists to absorb. Every step in this sequence, from the original alert through the final acknowledgment, is captured as a timestamped evidence record, so if CERT-In or an internal audit later asks for the full history, the answer is a single query rather than a reconstruction exercise. This is what "always-on assurance" concretely buys an organization: not just meeting the deadline, but meeting it with a fully evidenced, explainable process even when the ideal path (primary approver responds immediately) does not happen.

Build vs. buy, and the pitfalls that recur across implementations

Organizations building this capability face a genuine build-versus-buy decision at each of the four architecture layers, and the right answer differs by layer. The telemetry and correlation layers are rarely worth building from scratch given the maturity of commercial SIEM/XDR platforms and the specialized tuning required for accurate detection at low false-positive rates; the policy-as-code and evidence-automation layers, by contrast, often need custom work regardless of platform choice, because CERT-In's specific report fields and category mappings are not natively modeled in generic compliance tooling built for SOC 2 or ISO 27001. A practical pattern is to adopt a strong commercial or platform foundation for detection — an agentic SOC approach with AI-driven investigation reduces the burden of building custom correlation logic — and invest custom engineering specifically in the CERT-In-shaped policy definitions, report templates, and escalation workflows sitting on top of it.

Several pitfalls recur often enough to call out explicitly. Organizations frequently over-index on the six-hour deadline for the initial report and under-invest in the supplementary reporting CERT-In may request during an active investigation — the same evidence-automation discipline needs to extend beyond the first submission to follow-up requests, which can arrive with similarly tight turnarounds. Another common failure is treating the twenty reportable categories as static; CERT-In's guidance and interpretation evolve, and a classification mapping built in 2022 needs periodic review against current guidance rather than being frozen into detection rules and forgotten. A third recurring gap is conflating "we have a SIEM" with "we meet the retention and residency requirement" — many SIEM deployments default to shorter hot retention windows for cost reasons, and nobody explicitly re-verifies the 180-day, in-India requirement until an incident forces the question.

Finally, organizations that treat CERT-In compliance purely as a defensive, regulatory obligation tend to under-invest relative to those that recognize the same architecture — continuous telemetry coverage, fast correlation, automated evidence assembly — is also what reduces actual breach impact and dwell time, independent of the reporting deadline. Viewed that way, the investment case is not just "avoid a regulatory penalty" but "materially reduce the cost and duration of real incidents," which is the framing that tends to secure sustained budget rather than a one-time compliance sprint that atrophies within a year. Programs like continuous threat exposure management and identity-centric controls under privileged access management both reduce the raw volume of reportable incidents in the first place, which is the cheapest way to reduce six-hour-deadline pressure — fewer incidents to report beats faster reporting of more incidents every time.

Frequently asked questions