CERT-In Directions: 6-Hour Reporting and 180-Day Logs Explained

On 28 April 2022, the Indian Computer Emergency Response Team (CERT-In) issued Directions under Section 70B(6) of the IT Act, 2000. They took effect on 28 June 2022 and apply to a very wide range of organisations in India. The best-known requirement is that specified cyber incidents must be reported to CERT-In within six hours of being noticed.

This guide is general information, not legal advice.

What are the CERT-In Directions?

CERT-In is India’s national agency for responding to cyber security incidents. Section 70B of the IT Act lets it call for information and issue directions to service providers, intermediaries, data centres, body corporates and others. The 2022 Directions set six main requirements:

CERT-In published FAQs in May 2022 to clarify how the Directions apply.

History and why they were introduced

CERT-In introduced the Directions because it said it was missing timely information about incidents and lacked the logs needed to analyse them.

Main objectives:

1. Faster visibility of cyber incidents affecting India.
2. Better forensic capability through logs and accurate timestamps.
3. A clear contact channel with every covered organisation.
4. Traceability for hosting, VPN and virtual asset services.

Who needs to comply?

The Directions apply to service providers, intermediaries, data centres, body corporates and government organisations. In practice this covers almost every company with IT systems in India.

Is it mandatory?

Yes. Section 70B(7) of the IT Act provides that failing to provide information or comply with directions is punishable with imprisonment of up to one year, a fine of up to INR 1 lakh, or both.

Key requirements

Six-hour incident reporting

Report incidents listed in Annexure I of the Directions within six hours of noticing them. The list includes:

• targeted scanning or probing of critical networks and systems;
• compromise of critical systems or information;
• unauthorised access to IT systems and data;
• website defacement, or intrusion and unauthorised changes such as inserting malicious code or links;
• malicious code attacks such as viruses, worms, trojans, ransomware, cryptominers and spyware;
• attacks on servers (database, mail, DNS) and network devices;
• identity theft, spoofing and phishing attacks;
• denial of service and distributed denial of service attacks;
• attacks on critical infrastructure, SCADA, operational technology and wireless networks;
• attacks on applications such as e-governance, e-commerce and others;
• data breaches and data leaks;
• attacks on IoT devices and associated systems;
• attacks or incidents affecting digital payment systems;
• attacks through malicious mobile apps, and fake mobile apps;
• unauthorised access to social media accounts;
• attacks or suspicious activities affecting cloud systems;
• attacks or suspicious activities affecting big data, blockchain, virtual assets and exchanges, custodian wallets, robotics, 3D and 4D printing, additive manufacturing and drones;
• attacks or suspicious activities affecting AI and machine learning systems.

Reports go to incident@cert-in.org.in, by phone or through the CERT-In website, using the format on CERT-In’s site. You can report with the information available and add details later.

180-day logs in India

Enable logs of all ICT systems and keep them securely for a rolling 180 days, within Indian jurisdiction. Provide them to CERT-In when it asks, or with an incident report. The FAQs explain that logs may be stored outside India if the obligation to produce them within the time CERT-In specifies is met, but many organisations keep a copy in India to be safe.

Clock synchronisation

Connect to NTP servers of NIC or NPL, or to NTP servers traceable to them. Organisations across multiple countries may use other accurate time sources, as long as their time doesn’t deviate from NPL and NIC.

Point of contact

Designate a point of contact and share details with CERT-In in the specified format. Keep it current.

Five-year records for hosting and VPN providers

Data centres, VPS, cloud service providers and VPN service providers must keep, for five years or longer if required by law, accurate information including validated subscriber names, the period of hire, IP addresses allotted, email address, IP and timestamp used at registration, ownership pattern of subscribers, purpose of hiring and validated address and contact numbers. The FAQs clarify that the VPN record-keeping rules are aimed at providers offering VPN services to the public, not enterprise VPNs used by a company’s own staff. Check the FAQs for how the rules apply to your services.

How to implement

1. Name a point of contact and register them with CERT-In.
2. Map Annexure I incidents to your detection rules and incident categories.
3. Build a six-hour workflow: detection, triage, decision to report, report submission, follow-up. Make sure it works at night and on weekends.
4. Prepare report templates in CERT-In’s format.
5. Centralise logs for all ICT systems: cloud, servers, network, applications, identity, endpoints. Store at least 180 days, with a copy in an Indian region where practical.
6. Synchronise clocks to NIC or NPL NTP servers, or traceable sources, across all systems including cloud.
7. If you are a hosting or VPN provider, implement subscriber validation and five-year record retention.
8. Test with a tabletop exercise that includes the six-hour clock.
9. Align with other regimes: the DPDP Board, sector regulators (RBI, SEBI, IRDAI) and customer contracts.

Documentation and policies

• Point of contact registration
• Incident response procedure with CERT-In reporting steps and timeline
• Annexure I mapping to incident categories
• Report templates and submission records
• Log management policy and retention configuration (180 days, Indian jurisdiction)
• NTP configuration standard
• Subscriber validation and record-keeping procedures (hosting and VPN providers)
• Exercise records

Audits and enforcement

• CERT-In can direct organisations to provide information and can act on non-compliance under Section 70B(7).
• CERT-In empanels information security auditing organisations that companies and government bodies use for audits.
• Sector regulators such as RBI, SEBI and IRDAI also expect CERT-In compliance in their own frameworks.

Cost

Benefits

• Faster coordinated response to major cyber incidents.
• Better forensic capability through complete, time-accurate logs.
• Alignment with regulator expectations in Indian financial sectors.
• Readiness for the DPDP Act’s breach reporting.

Risks of non-compliance

• Imprisonment of up to one year and/or a fine of up to INR 1 lakh under Section 70B(7).
• Regulatory scrutiny from sector regulators.
• Reputational damage after an unreported incident becomes public.

Common mistakes

• Counting six hours from confirmation instead of from noticing the incident.
• Logs only for some systems: the Directions say all ICT systems.
• Logs deleted after 30 or 90 days by default cloud settings.
• Cloud servers using default time sources without checking they are traceable to NIC or NPL.
• No out-of-hours reporting path.

Challenges for IT companies

• Very short reporting window compared with the DPDP Board, the GDPR and NIS2.
• Broad incident list, including scanning and suspicious activity, which can create many reports.
• Log storage costs at scale.
• Multi-country companies reconciling Indian log and time rules with global set-ups.

Best practices

• Treat CERT-In reporting as part of a single incident playbook that also covers the DPDP Board, sector regulators and customers.
• Pre-approve who can submit reports so decisions aren’t delayed.
• Keep 180 days of logs hot and one year archived to meet both CERT-In and the DPDP Rules.
• Use cloud-native NTP configuration that references traceable sources.
• Review the CERT-In FAQs whenever your architecture changes.

Tools that help

How the CERT-In Directions relate to other frameworks

Real-world examples

• VPN providers. Several VPN services removed their physical servers from India in 2022 rather than keep subscriber records for five years.
• Industry pushback. Industry bodies asked CERT-In to extend the six-hour window; CERT-In kept it, clarifying in its FAQs that reports can start with available information and be updated.
• Illustrative scenario, not a real company: a Pune SaaS company hosted overseas detects suspicious login attempts on its admin panel at 11 pm. Its on-call engineer follows the playbook, files an initial report to CERT-In by 4 am with available details, and later adds findings from its 180-day log archive.

Frequently asked questions

What is the CERT-In 6-hour rule? Specified cyber incidents must be reported to CERT-In within six hours of noticing them or being told about them.

Which incidents must be reported? Those listed in Annexure I of the Directions, including data breaches, ransomware, unauthorised access, DDoS attacks, phishing and attacks on cloud systems.

How long must logs be kept? 180 days on a rolling basis, within Indian jurisdiction, for all ICT systems.

Do the Directions apply to foreign companies? According to CERT-In’s FAQs, they apply to entities providing services to users in India.

What are the penalties? Up to one year’s imprisonment, a fine of up to INR 1 lakh, or both, under Section 70B(7) of the IT Act.

Do we still report to CERT-In if we report a breach to the DPDP Board? Yes. They are separate obligations with different timelines.

Which time servers should we use? NIC or NPL NTP servers, or servers traceable to them.

Next steps

• Register a point of contact with CERT-In.
• Write and test a six-hour reporting workflow.
• Extend log retention to at least 180 days for all ICT systems, ideally one year.
• Point every system’s clock at a traceable time source.