Last reviewed: 5 August 2026. CERT-In’s cyber-security Directions create several duties that are often compressed into the phrase “180-day log retention.” For data centres and hosting providers, the real operating model also includes standard time, a designated point of contact, six-hour reporting for specified incidents, production of information when directed and separate subscriber-record retention.
Central distinction: 180-day ICT logs, five-year hosting-subscriber records and customer workload data are three different categories. They require different fields, access controls, retention logic and deletion rules.
This article is the operational companion to Advika’s Data Residency in India pillar. It explains the texts for infrastructure planning and is not legal advice.
What the 28 April 2022 Direction actually says
The CERT-In Direction issued on 28 April 2022 applies its core requirements to service providers, intermediaries, data centres, body corporates and government organisations. Paragraph (iv) requires them to enable logs of all ICT systems, maintain the logs securely for a rolling 180-day period and provide them with an incident report or when CERT-In orders or directs.
The same Direction requires covered entities to report specified incidents within six hours of noticing the incident or being brought to notice. It also requires a designated Point of Contact and permits CERT-In to request information or assistance in a specified format and timeframe.
| Requirement | Primary text | Operational consequence |
|---|---|---|
| Time synchronisation | Use NIC/NPL time or a standard source traceable or conforming to it | Every event needs reliable timestamp and time-zone context |
| Incident reporting | Specified incidents within six hours of notice | Detection and escalation cannot depend on business-hours ticket queues |
| ICT logs | Enable and securely retain for a rolling 180 days | Central collection, capacity planning, integrity protection and retrieval testing |
| CERT-In Point of Contact | Designate and keep details updated | Named authority and 24/7 internal escalation route |
| Assistance and information | Respond in the requested format and timeframe | Export procedures, evidence preservation and ownership must be predefined |
| Subscriber information | Specified hosting/VPS/cloud/VPN records for five years or longer where required | Separate KYC/account-record store with controlled access and expiry |
The location wording needs careful treatment
The Direction says the 180-day logs should be maintained within Indian jurisdiction. CERT-In’s later FAQ, question 35, says logs may be stored outside India as long as the entity can produce them to CERT-In within a reasonable time. The FAQ also states that it is explanatory and does not replace or amend the Act, Rules or Directions.
Because the two formulations are not identical, operators should preserve both sources: the binding Direction and the explanatory FAQ. A conservative design may maintain an India-accessible or India-resident copy, ensure rapid production, and state the architecture in the service agreement. The final legal interpretation should be confirmed by qualified counsel.
Customers should not receive a one-word answer such as “SIEM is global.” They need the log categories, primary and replica locations, retention, access teams, export time and evidence-integrity controls for their exact service.
Which logs are in scope for incident analysis?
CERT-In’s FAQ says the relevant set depends on sector and gives a non-exhaustive list: firewall, intrusion-prevention, SIEM, web, database, mail, FTP, proxy, critical-system event, application, ATM switch, SSH and VPN logs. It also says successful and unsuccessful events should be recorded from an incident-response and analysis perspective.
| Infrastructure layer | Useful event examples | Common failure |
|---|---|---|
| Edge and firewall | Allowed/blocked flows, DDoS action, policy changes | Only blocked traffic is retained, leaving no normal baseline |
| Hypervisor and cloud control plane | VM create/delete, console access, snapshot and network changes | Customer and operator actions cannot be distinguished |
| Identity and privileged access | Login success/failure, MFA, role change, sudo/admin events | Shared accounts remove attribution |
| Server and application | OS security events, service restarts, application authentication and errors | Logs rotate before central collection |
| Database | Administrative access, authentication, critical changes and audit events | Verbose logging is disabled because capacity was not planned |
| Backup and storage | Backup job, restore, deletion, key and policy changes | Recovery actions are not linked to an approved ticket |
| Network routing and DNS | BGP, route, DNS and configuration changes where relevant | Time sources differ across devices, breaking correlation |
The objective is not indiscriminate collection. Logs should be selected for security operations, protected from tampering, restricted to authorised personnel and retained consistently. Where logs contain personal data or customer identifiers, privacy, access and minimisation controls remain necessary.
180 days is a capacity and integrity problem, not only a policy line
A provider should estimate daily event volume for every platform, multiply it by retention and growth, then account for indexing overhead, replicas and incident spikes. Log loss caused by disk exhaustion is still log loss. Retention settings should be tested after upgrades and product changes.
- Define source onboarding standards and reject systems without reliable timestamps.
- Use central collection with monitored ingestion gaps and queue failures.
- Protect administrative access to the logging platform with MFA and least privilege.
- Separate operator, security and customer views where multi-tenancy requires it.
- Use integrity controls appropriate to the platform and preserve evidence during incidents.
- Test search and export against a realistic 180-day window, not only recent events.
- Document time zone, clock source and normalisation so investigators can reconstruct sequence.
The six-hour reporting rule requires a joint runbook
The reporting clock is measured from notice, so organisations need to record when an alert was generated, when a human or automated process recognised a qualifying incident, when severity was confirmed and when CERT-In was notified. Customers and providers can hold different evidence; their contract must prevent delay while responsibility is debated.
- Detect and preserve the first reliable timestamp.
- Triage whether the event matches a specified reportable incident or otherwise warrants reporting.
- Notify the designated CERT-In Point of Contact and customer incident contacts.
- Contain the threat without destroying evidence needed for analysis.
- Prepare the facts available within six hours; CERT-In’s FAQ allows additional information later within reasonable time.
- Continue investigation, customer communication and any DPDP or sector-specific breach workflow in parallel.
- Retain the report, evidence requests, exports and decision log.
A provider’s normal support SLA may allow several hours merely to acknowledge a ticket. That is unsuitable for a regulatory incident path. The incident channel needs different staffing, severity and authority.
Do not confuse logs with five-year subscriber records
Paragraph (v) of the Direction separately requires data centres, VPS providers, cloud service providers and covered VPN service providers to register accurate subscriber information. The listed data includes validated names, service period, allocated or used IPs, onboarding email/IP/timestamp, purpose, validated address and contacts, and ownership pattern.
Those records must be retained for five years or longer where law requires after cancellation or withdrawal. This does not mean that all hosted customer databases, files and backups should be retained for five years. Workload-data retention should follow the service contract, customer instruction and applicable law; keeping unnecessary copies can create new risk.
What a hosting customer should request
- A log-source and retention matrix for the purchased service.
- Primary, replica and archive locations, including any overseas platform.
- Time-synchronisation standard and recorded time-zone handling.
- Ingestion monitoring, integrity protection and access-control design.
- Expected search and export time for incident evidence.
- 24/7 incident contact and escalation authority.
- Allocation of CERT-In reporting and customer notification responsibilities.
- Subscriber-record fields, access, retention and deletion process.
- Controls preventing customer workload data from being retained under the wrong category.
- Change-notification process when SIEM, region or subprocessor architecture changes.
Advika’s public infrastructure context and evidence boundaries are described in the 2026 network, facilities and certifications fact sheet. Customers buying through StreamData can translate the operator layer into procurement questions with the StreamData DPDP-ready hosting checklist.
Frequently asked questions
Does the 180-day rule require hosting providers to retain every customer file?
No. The Direction concerns ICT-system logs. It is distinct from customer workload content and from the separate five-year subscriber-information requirement for specified service providers.
Must all logs physically remain in India?
The Direction says logs should be maintained in Indian jurisdiction. CERT-In’s later FAQ says logs may also be stored outside India if they can be produced in reasonable time. Operators should document a conservative architecture and obtain legal advice on the applicable interpretation.
Does the six-hour period begin when an attack first starts?
The Direction measures from when the covered entity notices the specified incident or it is brought to its notice. Organisations therefore need clear detection, triage and escalation timestamps.
Which logs should be retained?
CERT-In’s FAQ gives a non-exhaustive list including firewall, IPS, SIEM, web, database, mail, proxy, application, SSH and VPN logs. The appropriate set depends on the sector and system.
Are customer identity records part of the 180-day log rule?
They are governed separately. Data centres, VPS, cloud and covered VPN service providers must register specified validated subscriber information and retain it for five years or longer where law requires after cancellation or withdrawal.
Bottom line
CERT-In readiness is an evidence pipeline: synchronised systems generate the right events; logs are collected and protected for the required period; operators can search and export them quickly; incidents reach an authorised contact within the reporting window; and subscriber records are governed separately. A provider should be able to demonstrate that pipeline, not merely state “logs retained for 180 days.”
