Skip to content

ISO 27001, SOC 2, the DPDP Act and manual VAPT. Book a Free Scoping Call

CERT-In Directions Compliance in India: 6-Hour Reporting, Logs and NTP

What the CERT-In Directions of 28 April 2022 require: 6-hour incident reporting, 180-day logs, NTP sync, a point of contact and provider record-keeping.

14 min readBy , Associate Director

Reviewed by Sachin Shirish, Director, CEH, ISO 27001 Lead Auditor

Penetration Testing: CERT-In Directions, in practice. Illustrated cover by SecureRoot Risk Advisory.

CERT-In Directions compliance comes down to a short list: report listed cyber incidents to CERT-In within 6 hours of noticing them, keep logs of all ICT systems for a rolling 180 days, synchronise clocks to NIC or NPL time, and name a point of contact. Data centres, cloud, VPS and VPN providers and virtual asset businesses must also keep customer records for five years. The Directions were issued on 28 April 2022 under section 70B(6) of the IT Act, 2000.

The six directions at a glance

The Directions, No. 20(3)/2022-CERT-In dated 28 April 2022, set out six obligations and three annexures.

Direction Obligation Who it applies to
(i) Synchronise all ICT system clocks with NTP servers of NIC or NPL, or servers traceable to them All service providers, intermediaries, data centres, body corporate and Government organisations
(ii) Report incidents listed in Annexure I within 6 hours of noticing them Same
(iii) Act on CERT-In orders within the timeframe given, and designate a Point of Contact Same
(iv) Enable logs of all ICT systems and keep them securely for a rolling 180 days within Indian jurisdiction Same
(v) Register and keep validated subscriber details for 5 years after the registration ends Data centres, VPS providers, cloud service providers and VPN service providers
(vi) Keep KYC information and financial transaction records for five years Virtual asset service providers, exchanges and custodian wallet providers

The Directions took effect 60 days after issue. CERT-In later moved the date for MSMEs to 25 September 2022, along with the validated name and address requirements for providers under direction (v). Both dates have passed, so every obligation below is in force.

Who the Directions apply to

Almost everyone that runs systems for Indian users. CERT-In's FAQs on the Directions (May 2022) point to section 43A of the IT Act for "body corporate": any company, including a firm, sole proprietorship or other association of individuals engaged in commercial or professional activities (FAQ 25). A ten-person consultancy and a listed bank sit under the same text.

Three clarifications in the FAQs matter for scoping:

  • Foreign entities. The Directions apply to any entity in the matter of cyber incidents (FAQ 26), and service providers offering services to users in India must designate a point of contact even without a physical presence here (FAQ 29).
  • Individuals. Individual citizens are not covered (FAQ 7).
  • Contracts do not shift the duty. Where an outsourcing partner is breached but your customer data is exposed, any entity that notices the incident must report it. The obligation is neither transferable nor capable of indemnity (FAQ 13), and it overrides confidentiality clauses by virtue of section 81 of the IT Act (FAQ 22).

Reporting cyber incidents within 6 hours

Direction (ii) requires reporting of Annexure I incidents within 6 hours of noticing them or having them brought to notice (Directions, page 2). It names three channels: email to incident@cert-in.org.in, phone on 1800-11-4949 and fax on 1800-11-6969.

The clock starts at detection, not at the start of the compromise. CERT-In's answer on long-undetected incidents (FAQ 24) keeps the 6 hours tied to noticing, while making clear that organisations are expected to deploy appropriate security controls to detect and prevent incidents.

A complete picture is not required in 6 hours. The FAQs let entities report what is available and send the rest later within reasonable time (FAQ 30). The same answer lists what must be reported inside the window:

  • severe incidents such as DoS, DDoS, intrusion or ransomware on any part of public information infrastructure, including backbone networks
  • data breaches or data leaks
  • large-scale or most frequent incidents, such as intrusion into computer resources or websites
  • incidents affecting the safety of human beings

Treat the first report as a notification, not an investigation.

Which incidents are reportable

Annexure I of the Directions lists 20 incident types. Grouped by where they usually surface:

Group Annexure I items
Reconnaissance and access Targeted scanning or probing of critical networks; compromise of critical systems; unauthorised access to IT systems or data
Web and applications Website defacement or intrusion, including injected code or links; attacks on applications such as e-governance and e-commerce
Malware Virus, worm, Trojan, bots, spyware, ransomware and cryptominers
Infrastructure Attacks on database, mail and DNS servers and routers; DoS and DDoS; attacks on critical infrastructure, SCADA, OT and wireless networks; attacks on IoT devices
Data Data breach; data leak
Identity and fraud Identity theft, spoofing and phishing; unauthorised access to social media accounts; attacks affecting digital payment systems
Mobile Attacks through malicious mobile apps; fake mobile apps
Cloud and emerging tech Attacks or suspicious activity affecting cloud systems; Big Data, blockchain, virtual assets, robotics, 3D and 4D printing, drones; AI and machine learning systems

The FAQ annexure explains each type. Note that a data leak includes accidental exposure through improper configuration or user error, not only theft. Vulnerabilities on their own are not reportable: FAQ 15 says reporting a vulnerability unconnected with an incident is not mandatory at present.

Logs: 180 days, and where they must sit

Direction (iv) requires covered entities to enable logs of all ICT systems, keep them securely for a rolling 180 days within Indian jurisdiction, and provide them to CERT-In with an incident report or on order (Directions, page 3).

The FAQs add two answers that pull in different directions. FAQ 35 says logs may be stored outside India as long as they can be produced to CERT-In in reasonable time. FAQ 36 says any service provider offering services to users in India must maintain logs and financial transaction records in Indian jurisdiction. The safe design for most organisations is a retained copy in India, with any overseas SIEM treated as an additional store, not the only one.

On which logs, FAQ 37 gives a non-exhaustive list: firewall, IPS, SIEM, web, database, mail, FTP and proxy servers, event logs of critical systems, application, ATM switch, SSH and VPN logs. Both successful and unsuccessful events should be recorded.

Clock synchronisation with NIC or NPL

Direction (i) requires ICT system clocks to be synchronised with NTP servers of the National Informatics Centre or the National Physical Laboratory, or servers traceable to them. Entities spanning multiple geographies may use another accurate time source, provided it does not deviate from NIC and NPL.

The FAQs (40 to 43) settle three questions that come up in every review:

  • Clocks need not be set to IST. NTP delivers UTC, but time zone information must be recorded with the time.
  • Workloads relying on a cloud provider's native time service may continue to use it.
  • The published servers are samay1.nic.in and samay2.nic.in for NIC and time.nplindia.org for NPL, configured as sources on the enterprise NTP server.

The reason is forensic: FAQ 39 notes that without accurate timestamps the sequence of an incident across systems is very hard to rebuild.

Point of contact

Direction (iii) requires every covered entity to designate a Point of Contact and send the details to info@cert-in.org.in in the Annexure II format: name, designation, organisation name, office address, email, mobile, office phone and office fax. The details must be kept current, and CERT-In sends requests for information and directions to that person (Directions, pages 3 and 7).

The same direction obliges entities to act on CERT-In orders in the format and timeframe specified, which may be up to near real-time. Missing that timeframe is treated as non-compliance. Name a deputy, and update CERT-In when the role changes hands.

Data centre, cloud, VPS and VPN provider obligations

Direction (v) applies only to data centres, VPS providers, cloud service providers and VPN service providers. They must register and keep, for 5 years or longer as the law requires after cancellation or withdrawal of the registration: validated subscriber names, period of hire, IPs allotted, the email, IP and timestamp used at onboarding, the purpose of hire, validated address and contact numbers, and the customer's ownership pattern (Directions, page 3).

Two FAQ answers narrow the scope. Enterprise and corporate VPNs are not covered: a VPN service provider here means one offering internet proxy-like services to general internet users (FAQ 34). "Ownership pattern" means whether the customer is an individual, partnership, association or company, with brief particulars of key management (FAQ 33).

A SaaS company on a hyperscaler is usually outside direction (v), but not (i) to (iv).

Penalties for non-compliance

The Directions say failure to furnish information or comply may invite action under section 70B(7) of the IT Act. The FAQs introduction quotes that sub-section: imprisonment of up to one year, a fine of up to one lakh rupees, or both. FAQ 23 adds that the power will be exercised reasonably, where non-compliance is deliberate.

How VAPT and log monitoring support compliance

The Directions do not mention penetration testing, but they assume two capabilities: detecting an incident quickly, and producing evidence afterwards.

Log monitoring makes the 6-hour window meaningful. Logs that are enabled but unreviewed satisfy direction (iv) on paper and fail direction (ii) in practice, because nobody notices the incident until a customer does. Our guide to what managed SOC services in India include covers what continuous monitoring involves.

VAPT works on the other side. Many Annexure I categories, including application attacks, website intrusion, unauthorised access and cloud compromise, start with a known weakness. Regular vulnerability assessment and penetration testing reduces how often you reach the reporting threshold, and a good test also checks whether logging caught the tester. Our overview of the types of penetration testing explains which test fits which asset.

For cloud estates, the AWS cloud security audit checklist for Indian SaaS teams covers audit trails and log retention.

A practical evidence pack for the Directions contains:

  1. A register of ICT systems with log source, retention period, storage location and clock source for each.
  2. An incident classification sheet mapped to the 20 Annexure I types, with the FAQ 30 criteria marked.
  3. A 6-hour runbook with the reporting channels, a first-notice template and named approvers.
  4. The Annexure II point-of-contact submission and the date it was last updated.
  5. Vendor clauses requiring incident notification well inside your own 6-hour window.
  6. The latest VAPT report, with evidence that detection was tested alongside exploitation.

Where SecureRoot fits

The reporting obligation stays with your organisation; our role is to make it workable. We run VAPT across web, API, cloud and network, provide monitoring through our SOC as a service, and review cloud logging settings through a cloud security configuration review. Where the gap is ownership rather than tooling, a virtual CISO can own the security programme and drive priority controls such as logging.

Frequently asked questions

Do the CERT-In Directions apply to small companies and startups?

Yes. The Directions apply to service providers, intermediaries, data centres, Government organisations and body corporates, and CERT-In's FAQs define body corporate using section 43A of the IT Act: any company, including a firm, sole proprietorship or other association of individuals engaged in commercial or professional activities. The text sets no revenue or headcount threshold. CERT-In did give MSMEs more time, moving their effective date to 25 September 2022 through a separate order dated 27 June 2022, but that extension has long run out. A small SaaS company therefore needs the same basics as a large one: synchronised clocks, 180 days of logs, a point of contact filed with CERT-In, and a way to notice and report a listed incident within 6 hours. What scales with size is the tooling, not the obligation. A startup can often meet it with cloud-native logging, a monitored alert channel and a clear runbook.

When does the 6-hour reporting clock start?

The Directions start the clock when the entity notices the incident or has it brought to its notice, not when the attacker first got in. CERT-In's FAQ 24 keeps that position for incidents that stay undetected for a long time, while stating that organisations are expected to deploy appropriate security controls to detect and prevent incidents. Notice can come from a SIEM alert, an employee, a customer complaint, a vendor, a researcher or CERT-In itself. The practical question is who in your organisation counts as noticing. If a support engineer sees ransomware notes on a server at 2 am and nobody escalates until 9 am, that delay is hard to defend. Write down which roles must escalate, how fast, and who decides that an event matches an Annexure I category. Then keep a timestamped record of each step, because that record is your evidence that the window was met.

What if we do not have full details within 6 hours?

Report what you know. CERT-In's FAQ 30 says entities may provide information to the extent available at the time of reporting and send additional information later within reasonable time. A first report should cover what was observed, when it was detected, which systems and data appear affected, what containment has started, and who CERT-In should contact. The Directions list email to incident@cert-in.org.in, phone on 1800-11-4949 and fax on 1800-11-6969 as channels, and CERT-In publishes its incident reporting form on its website. Waiting to finish the investigation before reporting is the most common way organisations miss the window. Run two tracks: a small group, usually the point of contact with legal and the security lead, sends the first notice while responders keep working on containment. Keep a copy of every submission and every later update, with the time each was sent.

Can we store logs outside India?

The Directions require logs to be maintained within Indian jurisdiction, and CERT-In's FAQs then give two answers that need to be read together. FAQ 35 says logs may be stored outside India as long as the entity can produce them to CERT-In in a reasonable time. FAQ 36 says any service provider offering services to users in India needs to enable and maintain logs and records of financial transactions in Indian jurisdiction. Because the second answer is aimed at providers serving Indian users, the conservative design for most organisations is a retained copy of logs in an Indian region for at least 180 days, even if a global SIEM holds another copy elsewhere. Whatever you choose, test retrieval: pull a sample of firewall, identity and application logs from 150 days ago and time how long it takes. If you operate in a regulated sector, check your sector regulator's requirements too.

Does a VAPT finding have to be reported to CERT-In?

Not on its own. CERT-In's FAQ 15 states that reporting a vulnerability as a standalone item, unconnected with a cyber security incident, is not mandatory at present. A penetration test that finds an exploitable SQL injection flaw produces a vulnerability to fix, not an incident to report. The position changes if the test uncovers evidence of real compromise, such as an unknown web shell, unexplained admin accounts or signs that data has already left the environment. That is an Annexure I incident, and the 6-hour clock starts when you notice it. Agree in the rules of engagement that testers stop and escalate immediately on any sign of prior compromise. It also helps to ask the test team to record which of their actions your monitoring detected, because that shows whether you could meet the reporting obligation during a real attack.

Next step

If you want to know whether your logging, clock sources and detection would hold up under the CERT-In Directions, book a 30 to 45 minute scoping call. You will get a written scope, a timeline and a fixed price for the VAPT scope that fits your environment.

Have a Question About This?

If this raised something specific to your environment, a scoping call is the fastest way to get a direct answer.

We reply within one business day.

All Articles
  • Penetration Testing: How often to run VAPT. Illustrated cover by SecureRoot Risk Advisory.
    Penetration Testing13 min read

    How Often Should VAPT Be Done? Annual Baseline, Change Triggers and Regulator Cadence in India

    Once a year is the floor, not the plan. This guide sets out when VAPT must be repeated after change, what RBI, SEBI, IRDAI and PCI DSS each require, and how to set a risk-based cadence by asset type.

    Read Article
  • Penetration Testing: API security testing. Illustrated cover by SecureRoot Risk Advisory.
    Penetration Testing11 min read

    API Security Testing Services: OWASP API Top 10 Coverage and Retesting

    APIs fail on authorisation and business logic far more than on classic injection bugs, and a scanner cannot tell whether one tenant can read another's data. This guide sets out what a manual API security test covers, how each OWASP API Security Top 10 category is tested, what the report and the verified retest contain and what an engagement costs.

    Read Article
  • Penetration Testing: Red team or penetration test?. Illustrated cover by SecureRoot Risk Advisory.
    Penetration Testing6 min read

    Red Team vs Penetration Testing: Key Differences Explained

    The terms get used interchangeably, but red team vs penetration testing is a real distinction. One measures how vulnerable a system is; the other measures how well your organisation detects and responds to a determined attacker.

    Read Article