CERT-In incident reporting and the 6-hour rule

What the directions require, and when they took effect

The operative instrument is CERT-In's directions of 28 April 2022, issued under sub-section (6) of section 70B of the Information Technology Act, 2000. It is short - eight pages including annexures - but it converts several things that were previously good practice into legal obligations, and it binds a far wider population than most readers assume. The directions became effective 60 days after issue, in June 2022. A follow-up notice dated 27 June 2022 moved that date to September 2022 for micro, small and medium enterprises, and separately for one narrow aspect of the records duty: the requirement that data centres, virtual private server providers, cloud service providers and VPN service providers maintain validated subscriber names and validated addresses. As at August 2026, CERT-In's page for its section 70B directions still lists only three documents - the April 2022 directions, the May 2022 FAQs, and that June 2022 extension. Nothing has replaced them.

• Synchronise all ICT system clocks to NIC or NPL time servers, or to sources traceable to them
• Report the listed categories of cyber incident to CERT-In within 6 hours
• Enable logs across all ICT systems and maintain them for a rolling period of 180 days
• Designate a point of contact to interface with CERT-In, and keep the details current
• Provide information or assistance when CERT-In directs it, in the format and timeframe specified
• For data centres, VPS, cloud and VPN service providers: register and retain defined subscriber records for five years

The six-hour clock: what starts it, and what must be reported

The clock runs from the point at which the incident is noticed, or at which the entity is brought to notice of it. It does not run from the moment of compromise, and it does not wait for an investigation to conclude. Annexure I to the directions lists twenty categories of mandatorily reportable incident, and the list is deliberately broad: it opens with targeted scanning or probing of critical networks and systems, and runs through unauthorised access, website defacement, malicious code including ransomware and cryptominers, attacks on servers and network devices, identity theft and phishing, denial of service and distributed denial of service, attacks on critical infrastructure and SCADA, data breach and data leak, attacks on IoT and digital payment systems, malicious and fake mobile apps, unauthorised access to social media accounts, attacks affecting cloud systems, and attacks on systems relating to big data, blockchain, virtual assets, robotics, drones, artificial intelligence and machine learning. CERT-In's May 2022 FAQs add proportion in two ways. Entities may report with whatever information is available at the time and supplement it later within a reasonable time. And the FAQs single out four kinds of incident as the ones that should go inside the six hours. Reporting a standalone vulnerability, unconnected with an incident, is separately confirmed as not mandatory.

• Incidents of severe nature - denial of service, distributed denial of service, intrusion, or the spread of a computer contaminant including ransomware - on any part of the public information infrastructure, including backbone network infrastructure
• Data breaches and data leaks
• Large-scale or frequently recurring incidents such as intrusion into a computer resource or a website
• Cyber incidents impacting the safety of human beings

Who is bound, and what non-compliance carries

The directions are addressed to service providers, intermediaries, data centres, body corporate and Government organisations. "Body corporate" takes its section 43A meaning - any company, and including a firm, sole proprietorship or other association of individuals engaged in commercial or professional activities - so the population is very large. The FAQs confirm that entities without a physical presence in India which serve users in the country must designate a point of contact, and that individual citizens are not the target. Three practical points matter more than the definitions. First, the reporting obligation attaches to whichever entity notices the incident; CERT-In states plainly that it is neither transferable nor capable of being indemnified or dispensed with, so it cannot be allocated by contract between a customer-facing business and its outsourcing partner. Second, by virtue of section 81 of the IT Act the statutory duty overrides confidentiality clauses in commercial contracts - an NDA is not a reason to delay a report. Third, non-compliance may attract the penal provision at sub-section (7) of section 70B, which provides for imprisonment of up to one year, or a fine of up to one lakh rupees, or both. CERT-In's FAQ adds that this power will be exercised reasonably and on occasions when the non-compliance is deliberate. Read that as a statement of intent, not as a safe harbour.

Logs: 180 days, and the jurisdiction question that trips people up

Entities must enable logs of all their ICT systems and maintain them securely for a rolling period of 180 days, and must provide them to CERT-In alongside an incident report or when directed. The direction says those logs shall be maintained within the Indian jurisdiction. The May 2022 FAQs then qualify this in a way that is easy to miss: asked whether a copy of logs must be stored in India only, CERT-In answered that logs may be stored outside India as long as the obligation to produce them to CERT-In within a reasonable time is met. A separate answer is firmer on financial records, stating that any service provider offering services to users in the country needs to enable and maintain logs and records of financial transactions in Indian jurisdiction. If your architecture leans on the softer reading, have it reviewed against the current CERT-In text and take your own legal advice - the direction and the FAQ are not phrased identically, and an FAQ is guidance rather than the instrument itself. On which logs to keep, CERT-In gives an explicitly non-exhaustive list that varies by sector, and says both successful and unsuccessful events should be recorded.

• Firewall and intrusion prevention system logs
• SIEM logs, and event logs of critical systems
• Web, database, mail, FTP and proxy server logs
• Application logs, SSH logs and VPN logs
• Both successful and unsuccessful events, not only failures
• Requisitions for logs are made by a CERT-In officer not below the rank of Deputy Secretary to the Government of India

Synchronised clocks, and why they sit in an incident-reporting direction

The very first direction in the document is about time. All ICT system clocks must be synchronised to the Network Time Protocol servers of the National Informatics Centre or the National Physical Laboratory, or to servers traceable to them - currently samay1.nic.in and samay2.nic.in for NIC, and time.nplindia.org for NPL. Entities whose ICT infrastructure spans multiple geographies may use another accurate and standard time source, provided it does not deviate from NPL and NIC, and organisations relying on native cloud time services may continue to do so. The FAQs clear up two things practitioners regularly get wrong: there is no requirement to set system clocks to Indian Standard Time, because NTP distributes UTC and conversion to local time happens at the host - but the time zone must be recorded alongside the timestamp so the conversion can be made accurately later. The reason this obligation shares a document with incident reporting is set out by CERT-In itself: a typical incident spans multiple systems within and across entities, and without accurate timestamps it is extremely challenging to re-create the sequence of events. Correlation rules and detection technologies also depend on time. If your clocks drift, your six-hour report becomes a narrative you cannot substantiate.

Extra duties on data centres, cloud, VPS and VPN providers

Data centres, virtual private server providers, cloud service providers and VPN service providers carry a records obligation on top of everything above. They must register accurate information about their subscribers and maintain it for five years - or longer where another law requires it - after any cancellation or withdrawal of the registration. The fields are specified in the direction: validated names of subscribers hiring the services, the period of hire including dates, IP addresses allotted to or used by them, the email address, IP address and timestamp used at registration or onboarding, the purpose for hiring the service, validated address and contact numbers, and the ownership pattern of the subscriber. One clarification carries real commercial weight: the FAQs state that this VPN duty does not apply to enterprise or corporate VPNs. For the purpose of the direction, a VPN service provider means an entity providing internet-proxy-like services to general internet subscribers using VPN technologies. A parallel duty falls on virtual asset service providers, virtual asset exchange providers and custodian wallet providers, who must retain KYC information and records of financial transactions for five years, held so that an individual transaction can be reconstructed - parties with IP addresses, timestamps and time zones, transaction identifiers, the accounts concerned, and the nature, date and amount.

The first six hours: a working runbook

The duty is far easier to meet when it has been rehearsed rather than improvised. The sequence below is a practical shape, not legal advice, and it should be adapted to your own escalation policy. One thing worth settling in advance is what the report actually looks like. CERT-In publishes an incident reporting form on its website which asks for the reporter's contact details, the affected entity, the incident type, whether the affected system is mission-critical, basic details of the affected system such as domain, IP address, operating system, location and ISP, and the occurrence and detection times. The form's own notes say it is not mandatory to complete or sign it - incidents may be reported by providing the relevant information in the communication itself, and reporting entities may add information beyond what the form asks. The directions name email (incident@cert-in.org.in), a toll-free telephone line and a fax number as channels, and state that methods and formats are published on the CERT-In website and updated from time to time. Confirm the current channel there before you need it, not during.

• Hour 0 - record the moment of noticing. That timestamp, not the moment of compromise, is what the six hours run from; capture who noticed, how, and in which system
• Hour 0 to 1 - test the incident against Annexure I and escalate to the point of contact you registered with CERT-In. Where the category is arguable, reporting costs far less than not reporting
• Hour 1 to 3 - assemble what exists: affected systems and their IP addresses, domain, operating system, location and ISP, occurrence and detection times, and a short factual description. Partial information is expressly acceptable
• Hour 3 to 5 - draft and clear the report internally. A confidentiality obligation to a customer does not defer it, and where a partner's systems were breached you still report what you noticed
• By hour 6 - send it through the current CERT-In channel and retain proof of despatch
• Afterwards - supplement with fuller detail within a reasonable time, preserve the relevant logs, and expect CERT-In to seek further information or assistance

Compliance is a legal posture, not a product feature

No platform, PrahiX ORA included, can make an organisation CERT-In compliant. Compliance here is a legal posture held by the entity itself. It rests on decisions, documented policy, named accountable people, and what is actually sent to CERT-In within six hours of somebody noticing something. Any vendor claiming to deliver compliance is describing an outcome it does not control. What tooling can honestly do is remove the practical obstacles that cause organisations to miss the window, and those obstacles are almost always evidentiary rather than legal. The gap is rarely a reluctance to report; it is that six hours after an alert, nobody can yet say which systems were touched, in what order, or when. Concretely, that means aggregating logs from network, security and physical-security sources into one store held in-country; making the 180-day rolling window a retention setting rather than an assumption; keeping collectors and sensors synchronised to a single traceable time source so that timestamps from different systems line up; and reconstructing an incident timeline fast enough that a factual report inside six hours is realistic. A converged platform - network operations centre (NOC), security operations centre (SOC) and video operations telemetry on one plane - helps chiefly because it shortens that reconstruction step. The report, the judgement about reportability, and the legal responsibility stay with you. It is also worth keeping the regimes distinct: the Digital Personal Data Protection Act, 2023 and its Rules notified in November 2025 impose a separate breach-intimation duty, owed to a different regulator on its own longer timetable, which is still being phased in. Satisfying the CERT-In six-hour duty does not discharge it.