CERT-In Log Retention: India's 6-Hour Rule and 180 Days

Most compliance writing about India's CERT-In Directions is written by and for lawyers, and stops at the obligation. That leaves the interesting half unsaid, because every clause in the 28 April 2022 Directions resolves — once you take it seriously — into an infrastructure decision. A six-hour reporting window is a detection-and-evidence pipeline with a latency budget. A 180-day log-retention rule is a storage-placement and immutability problem — including a genuine, unresolved tension in CERT-In's own documents over where that storage must sit. A mandate to synchronize clocks to a national time source is a genuine engineering primitive that most observability stacks quietly ignore. This article is the engineering read of that regime: not a legal register — your counsel will produce a sharper one — but the translation layer between the register and the platform that has to honour it.

The Directions were issued under Section 70B(6) of the Information Technology Act, 2000, and apply broadly: service providers, intermediaries, data centres, body corporates, and government organisations. They are not aspirational guidance. Non-compliance is an offence under Section 70B(7) of the same Act — up to a year's imprisonment, a fine of up to one lakh rupees, or both — and CERT-In can compel logs and information at any time, not only during an incident. The theme is the one Stribog holds across every regime, from the EU's NIS2, DORA, and AI-Act convergence to India's own DPDP Act: a compliance guarantee is only as strong as the technical control beneath it, and a control an auditor — or a regulator on a six-hour clock — can verify beats one taken on trust. The same evidence pipeline is what answers a third-party auditor under MeitY empanelment's contract chain.

This post is deliberately distinct from our general self-hosted observability piece, which is about owning your telemetry for operational reasons. Here the driver is legal custody: the same OpenTelemetry, Loki, and OpenSearch components, but architected against a statutory reporting clock, a jurisdictional retention boundary, and an evidentiary integrity bar. The overlap in tooling is real; the design constraints are not the same.

What the Directions Actually Bind

Strip the legal framing and the Directions impose five obligations an architect can design against. First, the six-hour rule: any incident listed in the Directions' Annexure I — data breaches, unauthorised access, critical-system compromise, targeted scanning, attacks on cloud, IoT, payment, and AI/ML systems, among a long list — must be reported to CERT-In within six hours of the entity noticing it. Second, logs of all ICT systems must be maintained for a rolling 180 days and produced to CERT-In on demand; the Directions' text also says the logs must be "maintained within the Indian jurisdiction," though CERT-In's own FAQ complicates that clause (the next section takes the tension seriously). Third, all system clocks must be synchronized to the NTP servers of the National Informatics Centre (NIC) or the National Physical Laboratory (NPL), or to servers traceable to them — per CERT-In's own FAQ on the requirement, the named servers are samay1.nic.in, samay2.nic.in, and time.nplindia.org — a duty with its own engineering treatment: bounding and proving clock error.

Fourth, a subset of providers — data centres, virtual private server (VPS) providers, cloud service providers, and VPN providers — must record accurate subscriber KYC and hold it for at least five years after a registration is cancelled; virtual-asset exchanges and custodian-wallet providers carry the same five-year duty over KYC and transaction records. Fifth, every covered entity must designate a point of contact to interface with CERT-In. Of these, the first three are the ones that reshape a platform, and the rest of this article treats them as the design surface they are.

The Six-Hour Clock Is an Engineering SLA

Treat the six hours as a service-level objective and the requirement becomes tractable. The budget spans four stages: notice the incident, correlate the evidence, classify it against Annexure I, and file. "Notice" is the treacherous one, because it is not a moment you control — it is a property of your detection coverage. An intrusion no rule catches is not noticed, and the clock has not started; the day it surfaces, you owe a report in six hours with a forensic trail you can only assemble from logs already in hand. That is why runtime threat detection with Falco or Tetragon is upstream of the whole reporting duty: the sooner and more reliably you notice, the more of the six hours is left for the work that actually goes in the report.

The rest of the pipeline is ordinary engineering done under a deadline. Detections flow into an in-perimeter SIEM — Wazuh, or an OpenSearch cluster fed by your collectors — where correlation turns a scatter of events into an incident with a timeline. Classification against Annexure I can be partly codified: a compromise of a critical system, a confirmed data breach, and unauthorised access are reportable; a blocked scan may be. The point of contact and an incident-response runbook carry it the last step to CERT-In. The failure mode is architectural, not procedural: if the evidence lives in a third party's managed service, the export request itself can outlast the window.

Click to zoom

180 Days: Retention, Coverage, and an Open Question on Location

The retention rule has three parts that are easy to conflate and expensive to get wrong: duration, coverage, and location. Duration is a rolling 180 days minimum — a floor, not a target, and one worth exceeding for logs that also serve a DPDP or sectoral retention duty. Coverage is all ICT systems, not just the application tier: node and syscall logs, the Kubernetes audit stream, network flow, authentication events, and infrastructure services all count. Location is where the primary sources disagree with each other, and an honest read has to say so.

Clause (iv) of the Directions — the binding instrument, issued under Section 70B(6) of the IT Act — says logs "shall be maintained within the Indian jurisdiction." CERT-In's own FAQ takes up the same question directly. Q35 asks: "Is it required to store copy of logs in India only?" and answers: "The logs may be stored outside India also as long as the obligation to produce logs to CERT-In is adhered to by the entities in a reasonable time." Read the two sentences together rather than skimming for a permission: the question is whether a copy must sit in India *exclusively*, and the answer's "also" is naturally read as permitting an *additional* offshore copy on top of the India-based one, not as replacing it — though CERT-In has never spelled that out plainly enough to close the question. What the FAQ does spell out, on its own second page, is that it "is not a legal document and in no way whatsoever replaces, amends or alters any part of the IT Act, 2000" or the CERT-In Rules made under it — so whichever reading of Q35 you find more natural, it cannot on its own terms override clause (iv). Q36 carries no such ambiguity: financial-transaction logs specifically must sit in Indian jurisdiction for any provider serving Indian users, with no reasonable-time exception offered. CERT-In has not publicly reconciled its binding clause with its own FAQ, and this article will not do that reconciling for you. Design to the Directions' text — a rolling copy of logs maintained within Indian jurisdiction — and treat the FAQ's leniency, whatever it turns out to mean, as a fallback you would rather not need to invoke.

Enforced custody is a property of the store, not a line in a policy. The logs land in an in-India object store — Ceph, or one of the sovereign S3-compatible options after MinIO — with object-lock so a rolling window cannot be silently truncated, and with retention set per class. On Kubernetes, that is an OpenSearch ISM lifecycle — policy, rollover alias, and bootstrap write index together — or a Loki compactor, each bounded to the jurisdiction-pinned bucket. The retention configuration is itself audit evidence: it demonstrates, mechanically, that the 180-day floor is met and that nothing older is being discarded before its class allows.

# OpenSearch ISM — CERT-In 180-day floor needs three pieces (not a policy alone).
# Primary docs (ISM policies → "Sample policy with ISM template for auto rollover"):
#   index name must match ^.*-\d+$ (e.g. security-000001);
#   set plugins.index_state_management.rollover_alias;
#   bootstrap a write index with is_write_index: true.
# Skip 2–3 and rollover fails (policy stuck). Drop rollover and keep age-only delete
# on a continuous write index, and you under-retain — worse for the 180-day floor.
#
# 1) Policy — hot rolls daily; warm trims replicas; delete after 200d (>180d headroom).
#    PUT _plugins/_ism/policies/certin-security-log-retention
policy:
  policy_id: certin-security-log-retention
  description: "CERT-In 70B: >=180d security logs, in-India object-locked store"
  default_state: hot
  states:
    - name: hot
      actions: [{ rollover: { min_index_age: "1d" } }]
      transitions:
        - state_name: warm
          conditions: { min_index_age: "7d" }
    - name: warm
      actions: [{ replica_count: { number_of_replicas: 1 } }]
      transitions:
        - state_name: delete
          conditions: { min_index_age: "200d" }   # >180d floor + legal-hold headroom
    - name: delete
      # Guarded by S3 Object Lock (WORM) on the in-IN bucket: a misfired delete
      # cannot truncate the window before the lock retention elapses.
      actions: [{ delete: {} }]
  ism_template:
    - index_patterns: ["security-*"]   # one alias family per policy; see audit/netflow note
      priority: 100
# Mirror steps 1–3 for audit-* and netflow-* with their own aliases (e.g. audit / netflow).

# 2) Index template — stamps rollover_alias on every matching index at create time.
#    PUT _index_template/certin_security_rollover
index_patterns: ["security-*"]
template:
  settings:
    plugins.index_state_management.rollover_alias: security

# 3) Bootstrap write index — concrete name ends in -digits; shippers write the alias only.
#    PUT security-000001
aliases:
  security:
    is_write_index: true
# Always write Fluent Bit / Vector to the alias (security), never to a long-lived bare
# index (security-app). Only a rolling ^.*-\d+$ write surface ages each day out at 200d
# without deleting the live write index.

Click to zoom

Synchronized Time Is a Compliance Primitive

The clock-synchronization clause is the one teams skim, and it is the one that quietly decides whether the rest holds up. The Directions require every ICT system to synchronize to NIC or NPL time, or to a source traceable to them; entities spanning geographies may use another accurate standard source, provided it does not deviate from NIC and NPL. The reason is evidentiary. A six-hour report and a 180-day archive are only as trustworthy as the timestamps in them. If two systems disagree on the time by minutes, the incident timeline you hand CERT-In is wrong, cross-system correlation in the SIEM breaks, and "within six hours of noticing" becomes unprovable because you cannot pin when noticing occurred.

The implementation is unglamorous and cheap: chrony on every node, pointed at the national sources, with drift monitored as a first-class signal rather than assumed. Clock skew then becomes an alert — a compliance failure you catch before a regulator does — instead of a silent corruption of your evidence. For records where you need to prove a log existed at a point in time, layer RFC 3161 trusted timestamping over the archive segments, so the retained window is not just present but attestable.

# /etc/chrony/chrony.conf — sync every node to NIC/NPL, traceable per CERT-In.
# Deviation from the national source is monitored, not assumed.
server samay1.nic.in     iburst   # National Informatics Centre (CERT-In FAQ Q43)
server samay2.nic.in     iburst
server time.nplindia.org iburst   # National Physical Laboratory (NPL)

makestep 1.0 3          # correct large offsets at start, then discipline gently
rtcsync                 # keep the hardware clock aligned
logdir /var/log/chrony            # local, in-jurisdiction time logs
log tracking measurements statistics

# Verify + alert on drift (scrape into the SIEM):
#   chronyc tracking      # 'System time' offset vs the national source
#   chronyc sources -v    # reachability of NIC/NPL; alert if all unreachable
# A node whose offset exceeds threshold, or that loses NIC/NPL, is a finding.

Completeness: Logging Every ICT System, Not Just the App

"Logs of all ICT systems" is a coverage mandate, and on Kubernetes the layer teams most often miss is the control plane. Application logs tell you what a workload did; they do not tell you who changed an RBAC binding, exec'd into a pod, or read a Secret. That is the kube-apiserver audit log, and it is off or minimal by default. A CERT-In-grade posture turns it on with a policy that records the security-relevant control-plane trail — without retaining secret values — then ships it to the same in-India store as everything else. Pair it with runtime and network logging and you have the four planes an incident actually crosses: control, runtime, network, and identity.

# kube-apiserver audit policy — capture the security-relevant control-plane trail.
# Fed to the in-India SIEM alongside runtime (Falco/Tetragon), netflow (Hubble),
# and auth (IdP) logs so an incident can be reconstructed across every plane.
apiVersion: audit.k8s.io/v1
kind: Policy
omitStages: ["RequestReceived"]
rules:
  # Secret / config access — metadata only: who, when, which object. The
  # access pattern is the exfiltration signal; the value must never be retained.
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
  # Exec / attach / port-forward into running pods — hands-on-keyboard signal.
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["pods/exec", "pods/attach", "pods/portforward"]
  # RBAC changes — privilege escalation and persistence.
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["roles", "clusterroles", "rolebindings", "clusterrolebindings"]
  # Everything else at metadata level — coverage without unbounded volume.
  - level: Metadata

The KYC Retention Tier and Who Carries It

If you operate infrastructure others build on — a data centre, a VPS or cloud service, a VPN — the Directions add a second, much longer retention class you must not collapse into the first. Accurate subscriber records must be kept for at least five years after a registration is cancelled, and virtual-asset exchanges and custodian-wallet providers carry the same five-year duty over KYC and transaction history. That is a different lifecycle from the 180-day security log: different data, a far longer window, and stricter access controls, because it is personal and identifying. Modelling it as its own retention tier — separate indices, separate object-lock durations, separate access policy — keeps a five-year KYC obligation from either bloating your hot security store or, worse, being aged out on the 180-day schedule by accident.

This is where CERT-In and the DPDP Act meet on the same records, pulling in different directions: CERT-In compels you to retain subscriber and log data, while DPDP constrains how long and for what purpose personal data may be kept. The reconciliation is not a contradiction — retention required by law is a lawful basis — but it must be explicit in the architecture: labelled purpose, bounded access, and a defensible deletion schedule once the statutory window closes. A self-hosted stack makes that boundary yours to draw; a managed SIEM makes it a negotiation with a vendor.

Two Clocks, One Perimeter: CERT-In and DPDP Together

From 13 May 2027, when Rule 7 of the DPDP Rules, 2025 (notified as G.S.R. 846(E) on 13 November 2025, commencing eighteen months later per Rule 1(4)) takes effect, an Indian breach will run two notification clocks at once. CERT-In's six hours is the tighter and earlier; the DPDP Rules add a two-stage notice to the Data Protection Board — an initial intimation without delay, then a detailed report within seventy-two hours, or such longer period as the Board allows — plus notice to affected individuals. One incident can trigger both, on clocks that start together and expire hours apart. They are not redundant: CERT-In is a national cyber-incident duty, DPDP a personal-data-breach duty, and a single event can be one, the other, or both. The engineering implication is that you build for the tightest overlapping obligation and satisfy the looser ones as a subset.

That is why a single, in-perimeter evidence plane is the leverage point. The same in-India, time-synced, immutable log store that makes the six-hour CERT-In clock survivable also produces the forensic detail the seventy-two-hour DPDP report will need and the audit trail an SDF's annual assessment consumes. Build it once, to the tightest bar, and the parallel regimes — CERT-In, DPDP, and the EU frameworks for teams operating across both — draw on one source of truth rather than three bolt-on integrations. The pattern is not unique to India: DORA runs the same architecture through its own 4-hour/72-hour/one-month clock for EU financial entities, on evidence that has to already be in hand before the clock starts.

The Exit Ramp and the Long Game

The optionality argument here is unusually concrete. A managed SIEM's retention, jurisdiction, and export behaviour are the vendor's to change, and its query language, detection rules, and dashboards are lock-in you feel most acutely the day you need to leave. A self-hosted stack built on OpenTelemetry, OpenSearch or Loki, and object storage is portable by construction: the pipeline is OTLP, the store is S3-compatible, the rules are yours. Should you need to move colos, change object-store backends, or bring a second jurisdiction in-house, the evidence plane moves with you. That is the optionality pillar applied to compliance data — you are never one vendor decision away from losing custody of the records a regulator can demand.

The long game is that this regime will harden, not relax. The 2022 Directions were a step-change from the advisory posture before them, and the enforcement, the scope, and the expectations around evidence quality all trend upward — as they have under every comparable framework. An architecture tuned to the exact text of 2022 will need rework each time the surface shifts; the one that endures is built on the invariant beneath the clauses: security telemetry whose location, clock, integrity, and retention are properties of a platform you operate, verifiable by an auditor and changeable with a pull request. Build the log-custody boundary before you are compelled to, and the next tightening of the Directions is a configuration change. Treat it as a vendor feature to buy later, and it is an incident waiting for its six-hour clock to start.