CERT-In's 6-Hour Rule: On-Prem Logging for India's Reporting Mandate

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 in-country log-retention rule is a storage-placement and immutability problem. 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), carrying up to a year's imprisonment or a fine, 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.

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 stored within Indian jurisdiction, and produced to CERT-In on demand. 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.

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, In Jurisdiction: Log Custody as a Control

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 the sharp one — the logs must be stored within Indian jurisdiction. A SIEM whose indices live in a US or EU region, however convenient, fails that clause regardless of what the contract promises.

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 policy or a Loki compactor 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 policy: 180-day CERT-In retention floor on an in-India,
# object-locked store. The policy IS the evidence the retention window is met.
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-*", "audit-*", "netflow-*"]
      priority: 100

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 time.nic.in    iburst        # National Informatics Centre
server samay1.nplindia.org iburst   # National Physical Laboratory (NPL)
server samay2.nplindia.org iburst

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

# 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 captures the security-relevant verbs at request-and-response level, 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 — request+response body, the exfiltration surface.
  - level: RequestResponse
    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

An Indian breach runs 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 — 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 needs 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 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.