Understanding CERT-In VPN Compliance Requirements in India
When CERT-In issued its Directions on Information Security Practices in April 2022, the impact extended far beyond incident reporting timelines. The directives introduced specific compliance obligations for VPN service providers, cloud service providers, and the enterprises that rely on them. Understanding CERT-In VPN compliance India requirements has become critical for regulated enterprises in BFSI, healthcare, pharma, and IT services, particularly those operating hybrid infrastructure across multiple providers.
The challenge is structural. Enterprises that depend on VPN tunnels for remote workforce access or cloud infrastructure for production workloads now carry dual exposure: their own compliance obligations under CERT-In, and the downstream risk of their service providers failing to meet theirs. This post breaks down what the directives require from each party and what regulated enterprises must do to maintain compliance.
CERT-In Requirements for VPN Providers: KYC, Log Retention, and Reporting
Mandatory KYC for Subscribers
CERT-In’s April 2022 directions mandate that VPN service providers operating in India maintain validated Know Your Customer (KYC) records for all subscribers. This includes verified names, validated email addresses, contact numbers, and IP addresses allocated to subscribers at the time of registration. The requirement applies irrespective of whether the subscriber is an individual or an enterprise.
This was a significant departure from the privacy-first model that most commercial VPN providers had operated under globally. Several international VPN providers withdrew services from India rather than comply. For enterprises, this means the choice of VPN provider now carries a compliance dimension that it previously did not.
Log Retention Obligations
VPN providers must maintain logs of subscriber activity for a rolling period of five years, even after the cancellation or withdrawal of service. The logs must include timestamps, IP addresses (both allocated and source), and subscriber identity records. This five-year retention window aligns with CERT-In’s broader log retention requirements applicable to data centres and intermediaries, creating a uniform evidence preservation standard across service categories.
For VPN providers operating at scale, this introduces significant storage and retrieval infrastructure requirements. For enterprises evaluating providers, it introduces a vendor due diligence obligation: confirming that your VPN provider is actually retaining and protecting these logs in compliance with the directive.
Incident Reporting
VPN providers are classified as “service providers” under the CERT-In directions and must report cybersecurity incidents within the six-hour reporting window mandated by the directive. This includes unauthorised access to systems, data breaches affecting subscriber information, and any compromise of VPN infrastructure that could affect subscribers.
The reporting obligation sits with the provider, but the reputational and operational risk flows to the enterprise. Consider a mid-sized NBFC using a commercial VPN for its distributed workforce of 800 employees. If the VPN provider suffers a breach and fails to report within six hours, or reports inadequately, the NBFC faces regulatory scrutiny on its vendor risk management practices, not just the VPN provider’s compliance failure.
Requirements for Cloud Service Providers Under CERT-In Directions
Customer Data Retention and Cooperation
Cloud service providers (CSPs) operating in India must maintain records of customer identities, including KYC data validated at onboarding. They must retain customer data and associated metadata for a period of five years after the termination of the service relationship. The obligation extends to maintaining IP allocation records, usage timestamps, and any data that could support forensic investigation of cybersecurity incidents.
CSPs are also required to cooperate with CERT-In during investigations, providing relevant logs, customer data, and technical assistance as directed. This cooperation mandate has no ambiguity around timeline: CSPs must provide requested information within the timeframe specified by CERT-In, which in practice often means hours rather than days.
Infrastructure-Level Logging
Cloud service providers must enable and maintain accurate logs of their infrastructure, synchronized to Indian Standard Time sourced from NTP servers provided by the National Informatics Centre (NIC) or National Physical Laboratory (NPL). The clock synchronization requirement may appear minor, but it carries significant forensic implications. Inconsistent timestamps across cloud infrastructure logs and enterprise application logs can render evidence inadmissible during regulatory investigations.
This requirement creates a direct dependency for enterprises hosting workloads on cloud infrastructure. If your CSP’s logging infrastructure is not synchronized to approved NTP sources, the evidence generated from those systems may not satisfy CERT-In’s standards during an incident investigation.
Virtual Asset Service Providers
The directions also specifically call out virtual asset service providers and virtual asset exchange providers, requiring them to maintain KYC records and transaction logs in the same manner as VPN and cloud service providers. For enterprises in BFSI that interact with digital asset infrastructure, this adds another layer to their vendor compliance assessment framework.
Impact on Enterprises Using VPN and Cloud Services
Shared Responsibility, Unshared Accountability
The CERT-In directions create a layered compliance architecture. Providers carry their own obligations. Enterprises carry theirs. The complication arises because regulatory accountability does not follow the shared responsibility model that cloud providers typically articulate for security. When CERT-In investigates an incident affecting an enterprise, the enterprise cannot defer to its provider’s compliance status as a complete defence.
Consider a large insurance company regulated by IRDAI, running customer-facing applications on a public cloud provider and securing remote access for 3,000 agents via a commercial VPN. The enterprise faces compliance exposure on multiple fronts simultaneously: IRDAI’s outsourcing guidelines, CERT-In’s incident reporting requirements, CERT-In’s log retention mandates as they apply to the enterprise’s own systems, and the residual risk from each provider’s compliance posture.
This creates three structural challenges that most risk functions are not equipped to handle with manual processes. First, the enterprise must continuously verify provider compliance status across multiple regulatory dimensions. Second, it must maintain its own independent evidence of compliance, separate from what providers retain. Third, it must be able to produce consolidated compliance records within hours during an incident, not weeks.
Vendor Due Diligence as a Compliance Obligation
For regulated enterprises, the CERT-In directions effectively elevate vendor due diligence from a procurement best practice to a compliance requirement. If your VPN provider or cloud service provider is non-compliant with CERT-In directions, your enterprise carries derivative risk. Regulators will ask: what did you do to verify provider compliance? What contractual safeguards did you establish? How do you monitor ongoing compliance?
This is particularly acute for BFSI entities where RBI’s outsourcing guidelines already mandate specific controls over IT service providers. The CERT-In overlay adds cybersecurity-specific requirements to the existing outsourcing risk framework, requiring enterprises to assess providers against both sets of obligations simultaneously.
Compliance Obligations: Enterprises vs. Providers
The following table clarifies the distribution of obligations under CERT-In’s directions between service providers (VPN and cloud) and the enterprises that use them.
| Obligation | VPN/Cloud Provider | Enterprise (User) |
|---|---|---|
| Subscriber/Customer KYC | Must collect and validate | Must provide accurate information |
| Log retention (5 years) | Must retain subscriber/customer logs | Must retain own system logs independently |
| NTP synchronization (NIC/NPL) | Must synchronize infrastructure clocks | Must synchronize own systems; verify provider compliance |
| Incident reporting (6 hours) | Must report incidents affecting own infrastructure | Must report incidents affecting own systems, regardless of where hosted |
| Cooperation with CERT-In | Must provide data and technical assistance | Must provide data and cooperate independently |
| Vendor compliance verification | Not applicable | Must verify and document provider compliance status |
| Contractual safeguards | Must accept compliance obligations in contracts | Must ensure contracts contain CERT-In compliance clauses |
| Point of contact designation | Must designate PoC with CERT-In | Must designate own PoC with CERT-In |
The critical insight from this distribution is that enterprise obligations exist independently of provider obligations. An enterprise cannot outsource its compliance responsibility to a provider, even where the provider is fully compliant. The enterprise must maintain its own evidence, its own reporting capability, and its own documentation of the provider relationship’s compliance dimensions.
Documentation and Evidence Requirements
What Enterprises Must Maintain Independently
CERT-In VPN compliance India requirements demand that enterprises maintain documentation across several categories, independent of what their providers retain. This includes records of all VPN and cloud provider relationships, evidence of due diligence performed at onboarding and periodically thereafter, contractual provisions addressing CERT-In compliance, records of provider compliance status reviews, and internal logs from enterprise-owned systems that interact with provider infrastructure.
The five-year retention window means this is not a one-time exercise. Enterprises must maintain rolling documentation that covers every active provider relationship and extends five years beyond termination. For a large bank or insurance company with dozens of technology providers, this creates a significant evidence management challenge.
Evidence for Incident Response
During an incident, CERT-In expects enterprises to produce specific evidence within hours. This includes the timeline of events (requiring synchronized timestamps), affected systems and data, actions taken, and the status of provider cooperation. If the incident involves infrastructure managed by a VPN or cloud provider, the enterprise must demonstrate that it has contractual mechanisms to obtain provider cooperation and that those mechanisms are functioning.
A pharmaceutical company running clinical trial data on cloud infrastructure, for example, must be able to demonstrate during an incident investigation that its CSP is complying with log retention requirements, that the enterprise has independent access to relevant logs, and that timestamps across both environments are consistent and synchronized to approved NTP sources.
Audit Trail Integrity
The evidence trail must be tamper-evident. CERT-In’s directions implicitly require that logs and records cannot be modified after the fact, which means enterprises need immutable audit trails for compliance-relevant activities. This applies to internal system logs, records of provider interactions, incident response actions, and compliance verification activities.
For regulated enterprises already managing audit requirements from RBI, SEBI, or IRDAI, the CERT-In evidence requirements layer on top of existing obligations. The challenge is consolidating evidence management across multiple regulatory frameworks without creating redundant processes or gaps in coverage.
Centralizing Compliance Evidence Across Frameworks
The practical difficulty most enterprises face is maintaining separate evidence repositories for each regulatory framework while ensuring consistency across them. A single VPN deployment might touch CERT-In’s directions, RBI’s outsourcing guidelines, and SEBI’s cybersecurity framework simultaneously, each requiring slightly different evidence formats and retention periods.
This is where platforms like eQomply provide structural value. By consolidating compliance evidence, task tracking, and regulatory mapping into a single system, enterprises can maintain one source of truth that satisfies multiple regulatory requirements. When CERT-In requests evidence of VPN provider compliance verification, the enterprise can produce it from the same platform that tracks RBI outsourcing controls and SEBI cybersecurity assessments, with complete audit trails and timestamps.
Practical Steps for Compliance Leaders
Provider Assessment Framework
Compliance leaders should establish a structured assessment framework for VPN and cloud providers that specifically addresses CERT-In requirements. This framework should verify KYC practices, log retention capabilities and duration, NTP synchronization sources, incident reporting procedures and timelines, and willingness to cooperate with CERT-In investigations. The assessment should be documented and repeated periodically, with evidence of each review retained for the five-year window.
Contractual Provisions
Existing contracts with VPN and cloud providers should be reviewed and, where necessary, amended to include specific CERT-In compliance clauses. These should address the provider’s obligation to maintain logs for five years, the provider’s commitment to report incidents within six hours, the enterprise’s right to audit provider compliance, cooperation obligations during CERT-In investigations, and notification requirements if the provider’s compliance status changes.
Internal Readiness
Enterprises must ensure their own internal processes are aligned with CERT-In requirements regardless of provider compliance. This means designating a point of contact with CERT-In, establishing internal incident response processes that can function within the six-hour reporting window, synchronizing all internal systems to NIC/NPL NTP servers, and maintaining independent logs of all activities involving VPN and cloud infrastructure.
Conclusion
CERT-In VPN compliance India requirements represent a structural shift in how enterprises must manage their technology provider relationships. The directives create parallel obligations that cannot be delegated or deferred. Enterprises must verify, document, and continuously monitor provider compliance while maintaining their own independent evidence of regulatory adherence.
For compliance leaders at regulated enterprises, the priority is clear: establish documented processes for provider assessment, ensure contractual coverage of CERT-In requirements, and maintain centralized evidence that can be produced within hours during an incident or investigation. The five-year retention window and six-hour reporting timeline leave no room for ad hoc approaches.
If your enterprise is managing CERT-In compliance alongside RBI, SEBI, or IRDAI requirements across multiple VPN and cloud providers, eQomply can help you consolidate evidence management and regulatory tracking into a single auditable system. Schedule a demo to see how regulated enterprises are operationalizing multi-framework compliance without building parallel processes for each regulator.



