CERT-In VAPT Compliance: What the April 2022 Directive Actually Requires (and What It Doesn't)

The Misconception That's Getting Companies Fined

When CERT-In issued its April 2022 cybersecurity directive, it triggered a wave of procurement calls for VAPT reports. Security vendors — and frankly a lot of compliance consultants — implied that VAPT was what CERT-In was requiring. It is not. Understanding the distinction matters because companies that bought VAPT reports and called it done may still be non-compliant, while companies that dismissed the directive as "just a VAPT requirement" never addressed the actual obligations.

This article explains exactly what the directive requires, what it does not require, and where VAPT fits in a compliant posture.

What the April 2022 Directive Actually Says

The Ministry of Electronics & Information Technology (MeitY) directed CERT-In to issue mandatory directions under Section 70B(6) of the IT Act 2000. The resulting direction — CERT-In Direction No. 20(3)/2022 — was published on 28 April 2022 and came into effect 60 days later.

The Six Core Obligations

1. Synchronise clocks with Indian Standard Time (IST) Every ICT system — servers, workstations, network devices, cloud instances — must synchronise to NTP servers at the National Informatics Centre (NIC) or NPL. This sounds trivial, but mismatched timestamps between your application logs and your firewall logs make forensic investigation impossible. Penalty-triggering scenarios: you report an incident but CERT-In's forensic team finds your timestamps don't match any known attack timeline.

2. Mandatory incident reporting within 6 hours This is the operative clause. If you experience any of the 28 listed incident types, you must report to CERT-In within 6 hours of detection — not 6 hours of becoming certain it was an incident, 6 hours of detection. The 28 categories include:

1. Targeted scanning of critical networks
2. Compromise of critical systems
3. Website defacement
4. Malware propagation
5. Unauthorised access to IT systems
6. Data breach or theft
7. Attacks on internet infrastructure
8. Phishing and fraudulent websites
9. DDoS attacks
10. Cryptomining / cryptojacking
11. Ransomware attacks

4. Maintain ICT system logs for 180 days All logs must be retained for a minimum of 180 days within Indian jurisdiction. If you use a foreign SIEM or cloud logging service, logs must be mirrored to India. This covers: server logs, application logs, network device logs, firewall logs, and VPN logs.

5. Virtual Asset Service Providers (VASPs) must maintain KYC records for 5 years Specifically applicable to crypto exchanges, wallet providers, and custodians. Customer identity records, transaction logs, and financial records must be retained for 5 years.

6. Virtualisation and cloud providers must provide subscriber information on request If you are a cloud, VPN, or hosting provider, you must be able to produce subscriber information on a CERT-In request within the timeframe specified in the request.

So Why Does Everyone Talk About VAPT?

VAPT comes into the CERT-In picture in three legitimate ways:

1. Vulnerability Disclosure Policy (VDP) recommendations CERT-In has separately recommended (not mandated) that organisations maintain a VDP — a published process for security researchers to report vulnerabilities. Running regular VAPT scans is the natural complement: if you're encouraging responsible disclosure, you should also be proactively finding your own vulnerabilities.

2. Sector-specific CERT-In empanelment requirements CERT-In maintains a list of empanelled security auditing organisations. Certain regulated sectors — banking, critical infrastructure, government portals — are required by their own regulators (RBI, SEBI, MoD) to use CERT-In empanelled vendors for security audits. This is where "CERT-In VAPT" as a phrase comes from: it means "VAPT conducted by a CERT-In empanelled vendor," not "VAPT required by CERT-In."

3. DPDP Act "reasonable security safeguards" standard As discussed in our DPDP checklist, the DPDP Act requires reasonable security safeguards. An annual VAPT from a CERT-In empanelled vendor is the most widely accepted evidence of meeting that standard. So VAPT is DPDP-driven, not CERT-In-driven.

The Compliance Matrix

Building a CERT-In Compliant Posture: Practical Steps

Step 1: Build your CERT-In reporting infrastructure

1. Register a PoC with CERT-In at cert-in.org.in — this takes less than 30 minutes and most organisations have not done it
2. Create an incident classification checklist against the 28 categories — laminate it and put it near whoever is on call
3. Set up the CERT-In reporting email/portal on a phone that is checked 24/7

Step 2: Implement log retention

Step 3: NTP synchronisation

# Ubuntu / Debian — configure NIC NTP servers
sudo nano /etc/systemd/timesyncd.conf
# Add:
# NTP=time.nic.in
# FallbackNTP=time2.nic.in

sudo systemctl restart systemd-timesyncd
timedatectl show-timesync

Step 4: Pair CERT-In compliance with VAPT (for DPDP)

Once the CERT-In mechanics are in place, run a VAPT to satisfy the DPDP "reasonable security" standard. The two work together:

1. CERT-In compliance = your response capability (you can detect, report, and preserve)
2. VAPT = your prevention capability (you found and fixed vulnerabilities before they were exploited)

How Bachao.AI Maps to CERT-In Requirements

Get your CERT-In aligned VAPT report at bachao.ai/cert-in-vapt-india. Scope-based pricing, 7–10 business day turnaround, and a report structured to satisfy both CERT-In incident response expectations and DPDP Act compliance requirements.

Written by Shouvik Mukherjee, Founder, Bachao.AI. 15+ years in software engineering, now building AI-powered security products. Fourth-time founder. DPIIT Recognised Startup.