The complete CERT-In Direction guide

On 28 April 2022, CERT-In (the Indian Computer Emergency Response Team, under MeitY) issued Directions under sub-section (6) of section 70B of the Information Technology Act, 2000, "relating to information security practices, procedure, prevention, response and reporting of cyber incidents." The directions came into force on 27 June 2022 and remain in force in 2026.

This is the single most under-complied-with cyber instrument in India. Most SMEs and even some mid-market organisations either do not know it exists, or assume it applies only to telecom or banks. It applies to every Indian organisation running IT systems.

The directions are explicit about scope. Applies to:

• Service providers, intermediaries, data centres, body corporates and government organisations.
• VPN service providers, cloud service providers, virtual private server (VPS) providers, virtual asset service providers (VASPs), virtual asset exchange providers, custodian wallet providers.
• Any "body corporate" — defined in IT Act §43A — which means any company, firm, sole proprietorship, or association engaged in commercial or professional activities.

Practical translation: if you are a registered Indian business, the directions apply to you. A 5-person SaaS startup. A 50,000-person bank. A solo consultant with a registered LLP. An e-commerce site running on a single VPS. All in scope.

The most-cited provision: any reportable cyber incident must be reported to CERT-In within 6 hours of noticing or being brought to notice. Not 6 hours from incident occurrence — 6 hours from awareness.

Practitioner reading:

• Clock starts when an authorised person in your organisation becomes aware of an incident matching one of the reportable types.
• "Notice" includes any reasonable indication — a SOC alert, a customer report, a vendor notification, an automated detection.
• The 6 hours runs continuously, including nights and weekends.
• You report what you know at that point. You can update the report as investigation progresses. Waiting until you have full root-cause analysis is a violation.

Annexure I of the directions lists 20 reportable categories. The ones that hit Indian SMEs most often:

• Targeted scanning / probing of critical networks / systems.
• Compromise of critical systems / information.
• Unauthorised access of IT systems / data.
• Defacement of website or intrusion into a website.
• Malicious code attacks (ransomware, trojans, worms, viruses, spyware).
• Attacks on servers (database, mail, DNS), network appliances (routers, firewalls).
• Identity theft, spoofing and phishing attacks.
• Denial of Service (DoS / DDoS).
• Attacks on critical infrastructure, SCADA, IoT.
• Attacks or incidents affecting Digital Payment systems.
• Attacks through malicious mobile apps.
• Fake mobile apps.
• Unauthorised access to social media accounts.
• Attacks or malicious / suspicious activities affecting cloud computing systems / servers / software / applications.
• Attacks or malicious activities affecting systems related to BGP routing, IPv6 routing, DNS infrastructure.
• Data breach.
• Data leak.
• Attacks on IoT devices and associated systems, networks, software, servers.
• Attacks or incidents affecting Virtual Asset Service Providers, Virtual Asset Exchange Providers, Custodian Wallet Providers.
• Attacks or malicious / suspicious activities affecting Systems / Servers / networks / software / applications related to Big Data, Block chain, virtual assets, virtual asset exchanges, custodian wallets, robotics, 3D and 4D Printing, additive manufacturing, Drones.

CERT-In provides multiple reporting channels:

• Email: [email protected]
• Online portal: via the CERT-In website incident reporting form.
• Phone: 1800-11-4949 (toll free), 011-2436-8572.
• Fax: per the published direction.

Email plus portal is the practical pattern. Have an email template pre-drafted in your incident-response runbook with placeholders for incident type, time of detection, affected systems, current status, mitigation actions, point-of-contact details. The reporting format is specified in Annexure II of the direction.

You are required to enable logs of all your ICT systems and maintain them securely for a rolling period of 180 days within the Indian jurisdiction.

Practitioner reading:

• Logs must be enabled — "we don't log because of cost" is a direct breach.
• Logs must be securely stored — access controlled, integrity protected, ideally tamper-evident.
• 180 days online (queryable), not just archived. Archived backups do not count if you cannot reasonably retrieve them on request.
• Storage within India — log servers in foreign regions are non-compliant. Many SaaS-heavy stacks fail this without realising.
• Logs must be made available to CERT-In on request.

The direction does not enumerate exhaustively. Practitioner baseline:

• Authentication and authorisation — every login (success and failure), MFA challenges, role/permission changes, password resets.
• Privileged actions — admin console actions, sudo, root, IAM changes.
• System logs — Linux syslog, Windows Event Log, system startup/shutdown.
• Application logs — application errors, transaction logs, audit logs of business events.
• Network logs — firewall accept/deny, VPN session start/end, DNS queries (where feasible), proxy logs.
• Cloud audit trails — AWS CloudTrail, Azure Activity Logs, GCP Audit Logs, with multi-region coverage and integrity validation.
• Database logs — at minimum, audit log of DDL/DML on production databases for sensitive tables.
• Endpoint logs — EDR telemetry, antivirus events, USB/external-media events.

Specific to data centres, VPS providers, cloud providers, VPN providers, VASPs:

• Maintain accurate KYC of subscribers / customers — name, address, contact, validated email, validated phone, ownership pattern, purpose of using the service.
• Retain KYC for 5 years from registration cancellation or longer if specified by other law.
• Retain transaction records for VASPs for 5 years.
• Make KYC available to CERT-In on lawful request.

This provision drove a number of foreign VPN providers (Surfshark, NordVPN, ExpressVPN) to exit India in 2022.

Additional obligations for these specific service categories:

• Maintain logs of validated names of subscribers, period of hire, IPs allotted, email used to register, time stamp at registration, purpose, validated address and contact, ownership pattern.
• Retain for 5 years post cancellation.
• Cooperate with CERT-In on requests for information related to investigations.

All ICT systems must synchronise their server time to the NTP servers of NIC or NPL (or NTP servers traceable to these). Practical implications:

• NIC NTP: samay1.nic.in, samay2.nic.in.
• NPL NTP: time.nplindia.org, time.nplindia.in.
• Hardware appliances and VM hosts must point at these or an internal NTP server that itself syncs to these.
• Document the NTP configuration in your IT runbook for inspection evidence.

Every applicable entity must designate a Point of Contact (POC) for cyber incident communication. Recommendations:

• Name, designation, email and phone of a senior officer.
• An always-on inbox like [email protected] as the email POC, monitored 24x7.
• Update CERT-In if the POC changes.
• Publish the POC on your website (typical location: /security.txt in the well-known directory).

Non-compliance falls under IT Act §70B(7): "Any service provider, intermediary, data centre, body corporate or person who fails to provide the information called for or comply with the direction issued by the Indian Computer Emergency Response Team, may be punished with imprisonment for a term which may extend to one year or with fine which may extend to one lakh rupees or with both."

The reputational and contractual penalties are usually larger than the statutory fine — a CERT-In notice during diligence is a deal-killer for most enterprise sales.

• "It only applies to telecom / banks." Wrong. It applies to every body corporate.
• "We don't have any logs." Direct violation.
• Logs in a foreign region. S3 / CloudWatch Logs in us-east-1 for an Indian company is a localisation breach.
• "We'll report when we know what happened." The 6-hour clock runs from awareness, not from understanding.
• No point-of-contact published or designated. Inspection finding within minutes.
• Server time synced to pool.ntp.org only. Add NIC or NPL.
• Incident response runbook with no CERT-In template. When the incident lands, you do not have time to draft from scratch.
• "We had a near-miss, no need to report." Many of the 20 categories include "attacks" not just successful compromises. Read the list.
• VPN provider operating in India without subscriber KYC. Material breach.
• Cloud audit trails disabled to save cost. Direct violation of the logging requirement.

This is the cheapest compliance you will ever do. 30 days, mostly checklist work:

• Week 1. Designate the POC, update the IRP runbook with the CERT-In email template, publish a security.txt with POC contact, draft the 6-hour reporting playbook.
• Week 2. Enable logs everywhere — auth, system, application, cloud audit trails. Confirm 180-day retention and that storage is in an Indian region. Add log integrity and access control.
• Week 3. NTP config audit; point all servers at NIC or NPL. Document the configuration. If you are a VPN/datacentre/cloud provider, confirm KYC retention practices for 5 years.
• Week 4. Tabletop exercise of an incident — walk through the 6-hour reporting flow. Train the SOC and on-call. File the runbook in a place every responder can find at 3am.