CERT-In's Six-Hour Rule: What Indian Cloud Teams Must Have in Place Before the Incident

The CERT-In Directions of April 2022 give Indian organisations six hours to report a cyber incident. Most of the writing about them is legal: who is covered, what counts, what the penalty is. Almost none of it is operational, and the operational question is the one that decides whether you comply: at 2 a.m. on a Sunday, who notices, who decides, who has the facts, and who sends the report? This article is the checklist for that question, with the log sources and retention settings per cloud platform, the named contact, the report template and the detection coverage that make six hours achievable rather than aspirational.

The short answer. Under the CERT-In Directions of 28 April 2022, organisations in India must report listed cyber incidents to CERT-In within six hours of noticing them, keep logs of their ICT systems for a rolling 180 days, synchronise their clocks to a standard time source, and name a Point of Contact. Meeting the six hours depends more on detection and a rehearsed runbook than on the report itself.

Reviewed October 2026. The Directions were issued under Section 70B(6) of the IT Act and took effect in June 2022; CERT-In's FAQs clarified several points later that year. This is an engineering checklist, not legal advice; confirm scope and interpretation with counsel, particularly if you are a cloud, VPN, data centre or virtual asset service provider, which carry extra duties.

• 6 hours: from noticing an incident to reporting it to CERT-In
• 180 days: of ICT system logs to keep, rolling, within Indian jurisdiction
• 20: categories of incident that must be reported, from ransomware to data leaks

What the CERT-In Directions require

Five obligations apply to every service provider, intermediary, data centre, body corporate and government organisation, including foreign entities serving users in India. A sixth applies to specific kinds of provider.

• Report incidents within six hours. What it means in practice: Any incident in the listed categories, reported to CERT-In by email, phone or fax within six hours of noticing it or being told about it
• Synchronise clocks. What it means in practice: All ICT system clocks synchronised to the NTP servers of NIC or NPL; entities spread across geographies may use another accurate standard source that does not deviate from them. This lets logs from different systems be lined up
• Keep 180 days of logs. What it means in practice: Logs of all ICT systems, retained on a rolling 180-day basis within Indian jurisdiction, and provided to CERT-In with an incident report or when ordered
• Name a Point of Contact. What it means in practice: A designated person whose details are given to CERT-In and who receives and answers CERT-In's requests
• Act on CERT-In orders. What it means in practice: Provide information and assistance when directed, in the format and timeframe CERT-In specifies
• Keep subscriber records (providers only). What it means in practice: Data centres, cloud, VPS and VPN providers keep validated customer records for five years after the service ends; virtual asset providers keep KYC and transaction records for five years

The listed incident categories run to twenty and are broad: targeted scanning of critical systems, unauthorised access, defacement, malware including ransomware and cryptominers, attacks on servers and network devices, identity theft and phishing, denial of service, attacks on applications, data breaches and data leaks, attacks on IoT, digital payment systems and cloud systems, and malicious mobile apps. The honest reading is that almost any security incident a cloud estate will suffer is on the list. CERT-In's FAQ narrows the six-hour expectation to severe incidents on public information infrastructure, data breaches and leaks, large-scale or frequent incidents, and incidents that affect human safety; when in doubt, report.

Non-compliance is an offence under Section 70B(7) of the IT Act, punishable by imprisonment of up to a year, a fine of up to one lakh rupees, or both. The larger exposure for most organisations is not the fine but the position of having to explain to a regulator, an auditor or a customer why the report was late.

The clock starts when you notice

Six hours from noticing is the rule, and it cuts both ways. An organisation with no detection capability notices nothing and reports nothing, which is a compliance posture only until the first time someone else notices for them: a customer, a bank, a journalist, or CERT-In itself. Once you are "brought to notice", the clock runs regardless of your readiness.

The practical consequence is that detection coverage, not the reporting process, decides whether the six hours is achievable. A phishing compromise that your identity logs would have flagged at 11 p.m. but nobody saw until Monday may well be judged by a regulator or auditor to have a reporting window that opened at 11 p.m., leaving a 60-hour gap to explain.

The six-hour report is a first notice, not a final one. CERT-In's form asks for what you know: organisation and contact, incident type, time of occurrence and of detection, affected systems, symptoms, and actions taken so far. Send it with what you have; follow up as the investigation develops. Waiting for the full picture is how organisations miss the window.

From 13 May 2027, when the DPDP Act's breach-notification duty takes effect, a personal data breach also starts a second clock at the same moment: intimation to the Data Protection Board and affected individuals without delay, with a detailed report inside 72 hours. The two reports draw on the same facts, so the log checklist below serves both; our DPDP cloud compliance checklist covers the second clock.

The log checklist, per platform

"Logs of all ICT systems" is wide. The sources below are the ones an investigator actually asks for in the first six hours, and the ones that let you write the report. Each needs to be switched on, routed to a retained store in an Indian region, kept for 180 days or more, and protected from the attacker deleting it.

• Identity: sign-ins, MFA, privilege changes. Azure: Entra ID sign-in and audit logs, exported to Log Analytics; AWS: IAM Identity Center and CloudTrail management events; Google Cloud: Cloud Identity audit logs and Cloud Audit Logs admin activity
• Control plane: who changed what. Azure: Activity Log to Log Analytics; AWS: CloudTrail organisation trail to an S3 bucket in ap-south-1; Google Cloud: Cloud Audit Logs to a log bucket in asia-south1
• Network: flows, firewall, DNS. Azure: NSG flow logs or VNet flow logs; Azure Firewall diagnostics; DNS query logs; AWS: VPC flow logs; Network Firewall logs; Route 53 Resolver query logs; Google Cloud: VPC flow logs; Cloud Armor and firewall logs; Cloud DNS logging
• Servers and endpoints. Azure: Defender for Endpoint and Defender for Servers; Windows and Linux event forwarding via the Azure Monitor agent; AWS: GuardDuty, Inspector and an EDR agent on each instance; CloudWatch agent for OS logs; Google Cloud: Security Command Center; EDR agent; Ops Agent for OS logs
• Applications and data stores. Azure: App Service, SQL auditing and storage diagnostic logs; AWS: Load balancer access logs, RDS audit logs, S3 server access or data-event logging; Google Cloud: Load balancer logs, Cloud SQL audit, data access logs on storage
• Retention and protection. Azure: Workspace retention 180 days or more in Central or South India; export to immutable blob for the archive; AWS: Log group retention 180 days or more; S3 object lock on the trail bucket; separate account for the logs; Google Cloud: Log bucket retention 180 days with a retention lock; separate project for the logs

Three points that the table cannot show.

The retained copy must be somewhere the attacker cannot reach. A log store in the same subscription with the same administrators is an early target for an intruder. A separate subscription, account or project, with write-only access from production and read access for the responders, is the standard answer on all three platforms.

"Within Indian jurisdiction" is the Direction's wording. CERT-In's FAQ adds that copies may also be kept outside India if they can be produced to CERT-In in reasonable time, while service providers serving users in India must keep logs in Indian jurisdiction. Keeping the retained copy in an Indian region is the simplest way to meet both, and the question applies to every service that holds logs, not just your own subscriptions. Check where your SaaS security tools keep their copies; several default to US or EU tenancy and need an Indian data residency option selected.

Clock synchronisation is the obligation many teams have never checked. Every platform syncs VMs to its own time source by default, and CERT-In's FAQ confirms that customers relying on the cloud's native time service may continue to use it. If you run your own NTP servers, point them at NIC or NPL, or at another standard source that does not deviate from them, and record the decision.

The named contact and the runbook

The Point of Contact is a person, not a mailbox. CERT-In will call them, and they must be able to answer, which means the role needs a deputy, an out-of-hours number and a place in the on-call rota. Send the details to CERT-In once and keep them current when people leave.

The runbook that sits behind the contact fits on two pages and has five parts:

1. Triage criteria. Which alerts count as a reportable incident under the listed categories, and who makes that call at night. Over-reporting is cheaper than the alternative; the criteria should err towards reporting.
2. The report template. CERT-In's incident reporting form, pre-filled with the organisation and contact details, with the fields that need facts marked, and the submission channels written down: incident@cert-in.org.in, and the toll-free numbers published on CERT-In's site.
3. The fact sheet. Where the logs above live, who has read access, and the saved queries that answer "which accounts, which systems, since when".
4. The second and third clocks. The DPDP Board report, the sector regulator (RBI, SEBI, IRDAI, each with its own incident timeline; RBI's 2026 directions for commercial banks, for example, ask for a report on its DAKSH portal within six hours of detection), customers under contract, and your cyber insurer, with the timeframe for each.
5. The record. A single incident log where every decision and timestamp is written down as it happens, because the report, the regulator's questions and the post-incident review all come from it.

Rehearse it once a quarter. Pick a scenario from the listed categories, start a timer, and see whether the on-call person can produce a filled-in report inside the window with the logs you actually retain. The first run often finds a gap, commonly a missing log source or a contact who has changed jobs.

Detection coverage, and why 24/7 is the pre-condition

Each family of reportable incident has a signal that announces it, if the signal is switched on and someone is watching.

• Ransomware and malware. What detects it: EDR on every server and endpoint; mass file-change alerts on file shares and storage; Watch item: Servers without an agent are the blind spot
• Phishing and identity compromise. What detects it: Sign-in risk, impossible travel and MFA-fatigue alerts from the identity provider; Watch item: Legacy authentication that bypasses MFA
• Unauthorised access and privilege change. What detects it: Control-plane alerts on role assignments, new credentials and policy changes; Watch item: Service principals and access keys with no owner
• Denial of service. What detects it: Platform DDoS protection and load balancer health alerts; Watch item: Public endpoints nobody inventoried
• Data breach or leak. What detects it: DLP and classification alerts; egress anomalies; public bucket and share detection; Watch item: Backups and exports that leave the estate unmonitored
• Attacks on cloud systems. What detects it: Cloud security posture management and threat detection: Defender for Cloud, GuardDuty with Security Hub, Security Command Center; Watch item: Alerts routed to a mailbox instead of a person

The last column is the point. Every platform can generate the alert; the Direction is about what happens next. If alerts land in a mailbox that is read in office hours, the organisation notices incidents in office hours, and the six-hour window starts from a moment that could be 60 hours after the attacker did. A security operations capability that watches around the clock, triages within minutes and has the authority to invoke the runbook is the practical pre-condition for the Directions. That is why a managed security service should agree a short, written acknowledgement target for critical alerts: the six hours is spent on the report and the containment, not on finding out.

A 30-day plan

1. Week 1: appoint the Point of Contact and deputy, send the details to CERT-In, and write the two-page runbook with the report template pre-filled.
2. Week 2: switch on the log sources in the table for every production subscription, account or project; route them to a separate, retained store in an Indian region with 180-day retention and deletion protection. For the Microsoft 365 audit log, see our Microsoft 365 security checklist.
3. Week 3: record how each system's clock is synchronised (the cloud's native time service, or NTP servers that follow NIC or NPL); inventory every server and endpoint and close the EDR gaps; confirm where each SaaS security tool keeps its data.
4. Week 4: route critical alerts to a person who is awake, with a 15-minute acknowledgement target; rehearse one scenario end to end and fix what the rehearsal finds.
5. Day 30: file the evidence: the contact confirmation, the retention settings, the alert routing and the rehearsal record. That file answers the auditor and the board, and it is the first thing you will want on the day it matters.

Where CloudSwift fits

The log plumbing, the retained store and the detection coverage are what our network and security operations for cloud build into an estate, and the 24/7 watch, triage and runbook execution are what managed security services provide on top. For organisations whose sector regulator adds its own incident timeline, our security practice aligns the CERT-In, DPDP and sector reports so one set of facts feeds all three.

If you would like the week-one runbook written with you, book a consultation. The first conversation is the log inventory.

Frequently asked questions

Who has to comply with the CERT-In six-hour reporting rule?

All service providers, intermediaries, data centres, body corporates and government organisations in India; CERT-In's FAQ says this includes foreign entities serving users in India. There is no size threshold. Cloud, VPS, VPN and data centre providers, and virtual asset service providers, carry additional record-keeping duties on top of the common obligations.

When does the six-hour clock start?

When the organisation notices the incident or is brought to notice of it, for example by a customer, a partner or CERT-In. Detection coverage therefore decides when the clock starts; an incident nobody is watching for is still an incident once anyone else sees it.

Do the logs have to be stored in India?

The Directions say logs must be maintained within Indian jurisdiction for a rolling 180 days and produced to CERT-In when ordered. CERT-In's FAQ adds that copies may also be stored outside India provided they can be produced to CERT-In in reasonable time, and that service providers serving users in India must maintain logs in Indian jurisdiction. On Azure, AWS and Google Cloud, keeping the retained copy in an Indian region is the simplest way to meet both; check where any SaaS security tool keeps its copies too.

What should the six-hour report contain?

What you know at the time, in CERT-In's incident reporting format: organisation and contact details, the incident category, when it occurred and when it was detected, the systems affected, the symptoms and the actions taken. It is a first notice; supplementary information follows as the investigation develops.

How does this relate to the DPDP Act's breach notification?

From 13 May 2027 they run at the same time. A personal data breach is reportable to CERT-In within six hours under the Directions and, under the DPDP Act, to the Data Protection Board and affected individuals, with a detailed report to the Board within 72 hours. Both draw on the same logs and the same incident record, so one runbook should cover both.