CERT-In Directions (Section 70B) — a practitioner reference

ControlForge free guide · 2026-05-23 · Reflects CERT-In Directions dated 28 April 2022, effective 27 June 2022, with FAQs and supplementary guidance through 2025

Quick reference

Applies to: any service provider, intermediary, data centre, body corporate, and "any other person" operating in India or providing services to users in India. Includes VPN providers, cloud service providers, virtual asset service providers (cryptocurrency exchanges), data centres, hosting providers, IT companies, and effectively any organisation operating significant ICT infrastructure in or serving India.
Mandatory or voluntary: mandatory. Issued under sub-section (6) of Section 70B of the Information Technology Act, 2000. Non-compliance attracts criminal liability.
Year published: directions issued 28 April 2022, effective 27 June 2022. Additional clarifying FAQs released by CERT-In; supplementary directives in 2023 and 2024 addressed government-entity baseline guidelines and sector-specific obligations. Directions remain in force as of May 2026 with no major substantive amendment.
Issuing body: Indian Computer Emergency Response Team (CERT-In), Ministry of Electronics and Information Technology (MeitY), Government of India.
Penalties: under Section 70B(7) of the IT Act, non-compliance with Section 70B(6) directions may attract imprisonment up to 1 year, fine up to ₹1,00,000, or both. CERT-In's review committee process governs enforcement referral.
ControlForge density: 29 controls curated; 9 cross-framework clusters reference CERT-In — focused around incident reporting, log retention, and forensic readiness.

What it is

CERT-In is the Indian national agency for incident response and cybersecurity coordination, designated under Section 70B(1) of the IT Act, 2000 by notification dated 27 October 2009. Its statutory functions include collecting and analysing information on cyber incidents, issuing alerts and advisories, coordinating response activities, and giving directions to service providers and others on cyber-incident reporting and prevention.

The CERT-In Directions dated 28 April 2022 — formally titled "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 for Safe & Trusted Internet" — are the operative regulatory instrument that defines mandatory cyber-incident reporting and related obligations for organisations operating in India.

The Directions amended the earlier voluntary reporting regime under the CERT-In Rules, 2013 (issued under Section 70B(5)) by making reporting mandatory for an expanded list of incident categories, shortening timelines to 6 hours from awareness, mandating system clock synchronisation with trusted NTP sources, mandating 180-day in-India log retention, and adding 5-year subscriber/customer data retention for specific service categories including VPNs, cloud, and virtual asset service providers.

The Directions are concise — a few pages — but operationally substantial. They are read together with:

CERT-In Rules, 2013 — procedural and structural rules for CERT-In's functioning.
CERT-In FAQs — clarifying guidance issued in response to industry queries throughout 2022.
CERT-In Guidelines on Information Security Practices for Government Entities (2023) — supplementary guidance for government departments and PSUs.
CERT-In Cyber Security Audit Policy Guidelines (2025) — referenced by SEBI's August 2025 CSCRF clarifications; raised audit-firm and methodology expectations across sectors.

Structure at a glance

The Directions are organised around five operational obligation streams:

1. Time synchronisation (Direction (i)). All service providers, intermediaries, data centres, and body corporates shall connect to the NTP servers of National Informatics Centre (NIC) or National Physical Laboratory (NPL), or to NTP servers traceable to these for time synchronisation. Cross-border use of foreign NTP infrastructure is restricted for in-India systems.

2. Mandatory cyber incident reporting (Direction (ii) + Annexure I). Service providers, intermediaries, data centres, body corporates, and government organisations shall mandatorily report cyber incidents within 6 hours of noticing such incidents or being brought to notice. 20 incident categories are listed in Annexure I (see "Reportable incident categories" below).

3. Information furnishing on demand (Direction (iii)). When CERT-In requests information or assistance in connection with cyber incidents, the entity shall furnish the information or assistance as specified, within the requested timelines.

4. Log retention in India (Direction (iv)). All service providers, intermediaries, data centres, and body corporates shall enable logs of all their ICT systems and maintain them securely for a rolling period of 180 days within Indian jurisdiction. Logs shall be provided to CERT-In along with reporting of incidents or when ordered by CERT-In.

5. KYC and subscriber data retention (Direction (v) + (vi)). Data centres, virtual private server providers, cloud service providers, virtual private network service providers, and virtual asset service providers (cryptocurrency exchanges and wallet providers) shall register and maintain accurate subscriber/customer information, with retention for 5 years or longer as mandated by law even after withdrawal/cancellation of registration. Specified categories of subscriber data must be maintained including name, period of hire, IP addresses allotted, email address, contact number, and purpose of hiring services.

Reportable incident categories (Annexure I). The 20 categories include: targeted scanning/probing of critical networks/systems; compromise of critical systems/information; unauthorised access to IT systems/data; defacement of website or intrusion into a website; malicious code attacks; attacks on servers; identity theft, spoofing, phishing attacks; DoS/DDoS attacks; attacks on critical infrastructure; SCADA and operational technology attacks; attacks on applications; attacks on IoT devices; attacks affecting digital payment systems; data breach; data leak; attacks on AI/ML systems; fake mobile apps; attacks on cloud-hosted systems; attacks/incidents involving blockchain or virtual asset systems; and any other cyber security incident that may have an adverse impact.

Who must comply

The scope language ("service providers, intermediaries, data centres, body corporates, and any other person") is deliberately broad. In practice, in-scope categories include:

Telcos, internet service providers, telecom-licensed entities — already operating under DoT licence conditions with parallel cyber obligations.
VPN service providers — explicitly named in Directions (v), with full subscriber-data retention obligations.
Cloud service providers, virtual private server providers, data centres — explicitly named; subscriber-data retention applies.
Virtual asset service providers (crypto exchanges, wallet providers) — explicitly named; full KYC and subscriber-data retention.
Body corporates operating ICT systems — covers most companies registered under the Companies Act with material IT operations.
Government departments, ministries, PSUs — subject to additional 2023 government-entity guidelines.
Foreign organisations serving Indian users — extraterritorial reach via the "any other person" language and via the cyber incident reporting trigger when incidents affect Indian users or infrastructure.

There are no statutory carve-outs by entity size. Practically, the obligations apply across small startups, mid-size organisations, and large enterprises — though enforcement focus has concentrated on larger entities and sectors of particular regulatory attention (cryptocurrency, VPNs, cloud).

Multi-regulator overlap is the defining operational complexity. SEBI REs, RBI-regulated banks/NBFCs/payment system operators, IRDAI insurers, and telecom-licensed entities all carry CERT-In obligations in addition to their sectoral regulator's cyber obligations. CERT-In reporting is parallel to (not substituted by) sectoral incident reporting — a single incident may trigger four notifications simultaneously: CERT-In within 6 hours, RBI CIMS within 6 hours (for banking and payment system operators), the SEBI prescribed format (for SEBI REs), and DPBI within 72 hours for the detailed notification under DPDPA where personal data is affected. Each notification has its own format, channel, and content requirements; the operational discipline of coordinated multi-regulator submission is itself a control that needs pre-staging.

Core obligations / control families

Time synchronisation. Configure all ICT systems' NTP clients to use NIC/NPL servers or traceable NTP infrastructure. Document the time-source configuration. Maintain accurate time across endpoints, servers, network devices, and applications. Important because incident timeline reconstruction depends on synchronised logs. Maps into ControlForge cluster cl-time-synchronisation.

Cyber incident reporting — the 6-hour clock. Establish a process for incident classification against the 20 Annexure I categories; pre-staged reporting channel with CERT-In (via the prescribed report-an-incident form on incident.cert-in.org.in); incident response team trained on classification and submission; 6-hour SLA from internal awareness, not from external disclosure; structured incident report including category, time of incident, mode, suspected actors, target, impact, indicators of compromise. Coordination with parallel reporting regimes (sectoral regulators, DPBI). Maps into cl-incident-reporting-external, cl-ir-reporting, and cl-incident-response-execution.

Information furnishing on demand. When CERT-In sends a notice requesting information (logs, configuration, user data, system snapshots, forensic artefacts), the response must be furnished within the specified timeline. Practical implication: maintain operational readiness to extract and provide such data, including forensic preservation, log archives, and authorised contact points known to CERT-In. Maps into cl-forensic-evidence-collection.

180-day log retention in India. Enable logging for all ICT systems; secure log storage within Indian jurisdiction; rolling 180-day retention minimum; log integrity protected against tampering. In-India is the critical phrase — logs stored outside India do not satisfy the requirement. Cloud-based logging services must run from Indian regions or maintain parallel Indian-region copies. Maps into cl-logging and cl-data-localisation.

Subscriber/customer data retention for specified categories. For VPNs, cloud, data centres, virtual private server providers, virtual asset service providers: maintain KYC-validated customer data for 5 years post-withdrawal. Specific fields required (name, period of hire, IPs allotted, email, phone, purpose). KYC verification using government-recognised identity documents. This was the most controversial element of the Directions — several VPN providers exited the Indian market rather than comply.

For virtual asset service providers (cryptocurrency exchanges, wallet providers), additional record-keeping obligations apply: maintain transaction records for 5 years including transactions and the nature of services availed; maintain KYC records and records of financial transactions per existing anti-money-laundering obligations. The CERT-In subscriber-data obligations layer on top of FIU-IND, PMLA, and (where applicable) RBI obligations for crypto/virtual-asset-related activities. The compliance burden for in-scope virtual asset service providers is among the highest under any single Indian regulatory instrument, and several Indian crypto exchanges have invested in dedicated compliance infrastructure to manage it.

Practical implementation depth. For each obligation, the audit-ready evidence profile differs by entity type. Cloud and SaaS providers focus heavily on log retention in India and incident reporting readiness; VPN and virtual-asset providers focus on subscriber-data retention; general body corporates focus on time sync, log retention, and incident reporting. The Directions apply uniformly, but implementation effort scales with the scope and sensitivity of the services provided.

Vulnerability and incident readiness. Implicit in the Directions: organisations are expected to maintain reasonable security practices including vulnerability identification, patching, secure configuration, monitoring. CERT-In's parallel guidelines (information security practices for government entities, 2023; cyber security audit policy guidelines, 2025) extend these expectations. Maps into cl-vuln-identification.

Audit readiness under CERT-In Cyber Security Audit Policy Guidelines (2025). The 2025 audit policy guidelines, referenced by SEBI's August 2025 CSCRF clarifications, raised expectations for CERT-In empanelled audit firms: methodology depth, manual penetration testing, sector-specific audit programmes, audit report formats, and findings-tracking obligations. Maps into cl-mandatory-audit.

How auditors test it

CERT-In obligations are not subject to a certification regime. Compliance is tested through three channels:

1. CERT-In itself. CERT-In monitors incident reporting completeness and timeliness, reviews submissions, and can issue follow-up information requests. Non-compliance triggers a review committee process under Rule 19 of the CERT-In Rules; the Director General may authorise a complaint under Section 70B leading to prosecution under Section 70B(7).

2. Sectoral regulators. RBI inspections under Master Directions on IT Governance and CSITE; SEBI cyber audits under CSCRF; IRDAI under Information and Cyber Security Guidelines; TRAI for telcos. These regulators check CERT-In compliance as part of broader cyber audits and may share findings with CERT-In.

3. Customer/contractual audits. Enterprise customers in India increasingly include CERT-In compliance in vendor due-diligence checklists, particularly for cloud providers, VPN providers, and SaaS firms handling India-resident data. Customer audits sample log retention configuration, incident response readiness, and subscriber data handling.

Evidence patterns commonly tested:

Time synchronisation: NTP configuration on a sample of servers/network devices showing NIC/NPL or traceable upstream; documented policy on NTP source selection.
Incident reporting: incident reporting procedure document; CERT-In submission history for the audit period; awareness-to-submission timing analysis; sample incident classified and traced through submission process; tabletop exercise records.
Log retention: log retention configuration documentation; storage location (Indian jurisdiction); sample log queries showing 180-day coverage; integrity controls (write-once, immutable, signed).
Subscriber data (for in-scope categories): KYC procedure documentation; sample customer records showing required fields; retention policy and procedure; access controls on the subscriber-data store.

Inspector intensification themes in 2025-26 (consistent with parallel RBI/SEBI inspection patterns):

Documented and exercised connection between internal incident awareness and the 6-hour reporting submission.
In-India log retention proof — particularly for organisations using foreign-region cloud logging or SaaS observability platforms.
VPN/cloud provider subscriber-data programmes (where applicable) — KYC quality, retention completeness, deletion procedure on withdrawal.

How it relates to other frameworks

CERT-In Directions sit at the operational base of India's cyber regulation stack:

RBI Master Directions IT Governance (April 2024) and CSITE annexes — RBI imposes its own 6-hour CIMS reporting for banks, NBFCs, payment system operators, in addition to CERT-In. Both regimes run in parallel; both must be filed for incidents in scope. Coordination procedure required.
SEBI CSCRF — SEBI's cyber audit obligations explicitly reference CERT-In empanelled audit firms; the August 2025 technical clarifications directed REs to follow CERT-In Cyber Security Audit Policy Guidelines.
IRDAI Information and Cyber Security Guidelines 2026 — concept-equivalent for insurance entities; CERT-In reporting runs in parallel.
DPDPA 2023 + Rules 2025 — privacy regime with its own breach notification regime through DPBI (initial without undue delay; detailed within 72 hours). A cyber incident affecting personal data triggers CERT-In (6h), DPBI (72h detailed), and sectoral regulators (RBI/SEBI/IRDAI) simultaneously.
IT (Intermediary Guidelines) Rules 2021 (with 2023/2024 amendments) — intermediary obligations including grievance officers and content moderation; separate but overlapping with CERT-In's incident reporting for intermediary-targeting attacks.
NIST CSF 2.0 — concept-aligned at the response and detection function level; CERT-In is more prescriptive on the timeline and log-retention dimensions.
ISO/IEC 27001:2022 — A.5.24–A.5.27 (information security incident management lifecycle) and A.5.31 (legal/contractual requirements) cover the management-system side of CERT-In compliance.

Most cross-framework density in ControlForge for CERT-In sits in cl-incident-reporting-external, cl-logging, cl-mandatory-audit, and cl-forensic-evidence-collection — the natural intersection points with RBI, SEBI, IRDAI, NIST CSF, and ISO 27001.

Common pitfalls

Five recurring failure patterns:

6-hour clock measured from public disclosure. The Directions specify 6 hours from awareness, not from external disclosure or media attention. Internal triage that takes 12 hours, then submission, exceeds the SLA. Fix: incident classification triggered at first internal awareness (security operations alert acknowledged, helpdesk ticket categorised as cyber incident); reporting submission within 6 hours including provisional details with later supplementation.
Log retention outside India. Logs streamed to a global SIEM hosted in foreign regions; cloud-native logging services running outside India; SaaS observability platforms outside Indian jurisdiction. The Directions are explicit: 180-day retention in India. Fix: parallel Indian-region log archive even if primary observability runs globally; or move logging to Indian-region service.
VPN/cloud subscriber-data programmes incomplete. For in-scope categories, KYC weak; subscriber data fields missing; retention not enforced for 5 years post-withdrawal; deletion process erases records before the 5-year period. Fix: data-model design with required fields enforced at registration; retention policy enforced via legal hold against accidental deletion; documented exit procedure preserving the 5-year window.
Time synchronisation drift. NTP sources documented but configuration drift over time — some endpoints using default Microsoft/Apple NTP, mobile devices using device-vendor sources outside Indian jurisdiction. Fix: NTP configuration baseline enforced via GPO/MDM; quarterly compliance scan to detect drift.
Information-furnishing requests not anticipated. When CERT-In sends a notice requesting logs, configuration, or forensic artefacts, the organisation cannot respond within the timeline. Often because authorised contact points are stale or the forensic preservation chain is broken. Fix: dedicated CERT-In liaison role with current contact info; documented forensic preservation procedure; periodic exercise of the "CERT-In has sent a notice" scenario.

Two further patterns worth flagging:

Coordination gap with sectoral regulators. A single incident triggers CERT-In (6h), RBI/SEBI/IRDAI (per sectoral timelines), DPBI (72h detailed for personal data). Organisations file CERT-In on time but miss the sectoral or DPBI submission, or vice versa. Fix: incident response runbook with explicit multi-regulator submission tree; tabletop exercises exercising the full submission chain.
Reporting threshold inflated. Organisations triage "minor" incidents as below reporting threshold and don't file. The Annexure I list is broad — targeted scanning probes critical systems is reportable. Fix: conservative classification policy with explicit thresholds and named responsible roles; CISO-level sign-off for non-reporting decisions on Annexure I-eligible events.
MSSP/cloud-provider reliance creates accountability gaps. Some organisations outsource the SOC and incident-monitoring function to MSSPs and assume the MSSP will handle CERT-In reporting. The Directions place the obligation on the service provider/intermediary/body corporate itself, not on its MSSP. The MSSP contract may specify reporting handoff, but the regulatory accountability remains with the in-scope entity. Fix: contractual clarity on who files what; the organisation retains the named CERT-In liaison; MSSP-detected incidents flow into the organisation's own reporting workflow rather than being filed under the MSSP's identity.

When to use this framework

CERT-In compliance is not optional for organisations in scope. The practical question is how comprehensively to implement, not whether. Implementation depth scales with:

Organisation size and ICT footprint — larger ICT footprint = more incident-reporting touchpoints and larger log volumes.
Sector — VPN, cloud, virtual asset service providers carry the heaviest subscriber-data obligations.
Multi-regulator overlap — entities under RBI, SEBI, IRDAI need integrated reporting workflows.
Cross-border data flows — log retention and subscriber data must be addressed for foreign-region cloud and SaaS use.

For organisations starting from scratch, the sequencing that works:

Time synchronisation — typically a 1-day configuration change across the estate.
Log retention in India — Indian-region archive setup; usually 1–3 months effort depending on existing observability architecture.
Incident reporting readiness — procedure, classification, runbook, submission template, tabletop exercise. 2–4 weeks.
Information furnishing readiness — liaison role, forensic procedure. 1–2 weeks of governance work.
Subscriber-data programme (for in-scope categories) — KYC and retention data model. Material — typically 3–6 months.