MeitY Cloud Empanelment: Hosting Government Workloads in India

MeitY cloud empanelment is how the Government of India approves cloud services for use by ministries, state governments and public sector bodies. Under the MeghRaj initiative, also called GI Cloud, cloud service providers have their offerings audited against defined requirements for security, interoperability, data portability, service levels and contractual terms, with services hosted in India. Departments then buy from the empanelled list.

For software companies, empanelment matters even if they are not cloud providers: e-governance applications must usually run on an empanelled offering, and regulators such as SEBI require regulated entities to use empanelled providers. This guide explains the programme, deployment models, the audit process, what empanelment does and does not cover, and how vendors should design and host government and regulated workloads.

What is MeitY cloud empanelment?

MeitY launched the GI Cloud initiative, named MeghRaj, to accelerate the delivery of e-services through cloud computing while optimising government ICT spending. As part of it, MeitY set out policies, guidelines and an empanelment process for cloud service offerings. Empanelment means an offering has been audited and found to meet MeitY's requirements for a given deployment model. Empanelled offerings are listed by MeitY, and government organisations can compare and procure them, increasingly through the Government e-Marketplace (GeM).

Empanelment applies to the provider's service offering, not to the applications customers build on it. A department or vendor running an application on an empanelled cloud is still responsible for the security of its own application, data and configuration.

Background: government cloud in India

Before cloud adoption, government applications in India were hosted mainly in departmental server rooms, State Data Centres built under the National e-Governance Plan, and data centres run by the National Informatics Centre (NIC). These worked, but procuring hardware for each project was slow and capacity was often under-used. The GI Cloud initiative, launched in 2014, aimed to let departments use shared, on-demand infrastructure, either from government-run clouds such as the NIC National Cloud or from commercial providers. To use commercial providers safely, the government needed a way to vet their offerings, which led to the empanelment process. Today, government workloads may run on NIC infrastructure, State Data Centres or empanelled commercial clouds, depending on department policy and project requirements.

Deployment models

MeitY empanels offerings under different deployment models, which reflect how isolated the government workload is:

Model	Description
Public cloud	Shared, multi-tenant cloud services hosted in India.
Virtual private cloud	Logically separated environment for government users, distinct from the provider's general public offering.
Government community cloud	Cloud dedicated to government organisations, with stronger isolation.

The model required depends on the department's policy, the sensitivity of the data and the application, and the terms of the procurement. Check each project's requirements and the current MeitY guidance.

Choosing a model by data sensitivity

Departments generally match the deployment model to the sensitivity of the data and the criticality of the service. Public information portals and open data may suit public cloud offerings. Systems handling citizen personal data, such as welfare schemes, grievances or licensing, often call for virtual private cloud. Highly sensitive or critical systems may require government community cloud or government-run infrastructure. Defence, intelligence and certain security systems are usually outside commercial cloud entirely. The decision belongs to the department, often guided by its IT policy and CERT-In or sectoral advice, and is written into the tender. Vendors should ask early, because the model affects architecture, available services and cost.

Who must use empanelled cloud?

• Central and state government departments and agencies procuring cloud services, under MeitY's cloud policy and procurement guidelines.
• Public sector undertakings and government-funded projects that follow these guidelines.
• Regulated entities where a regulator requires it. SEBI's Framework for Adoption of Cloud Services by SEBI REs, for example, requires regulated entities to use cloud service providers empanelled by MeitY.
• System integrators and software vendors delivering applications for these customers.

Commercial companies are not required to use empanelled clouds, but some choose them to simplify sales to government or regulated clients.

Is it mandatory or voluntary?

For cloud providers, applying is voluntary, but empanelment is effectively required to sell cloud services to government. For government customers, using empanelled services is part of the procurement rules. For regulated entities, it depends on the regulator. There is no separate certification for applications built on top.

The empanelment and audit process

1. Application: the cloud provider applies to MeitY for empanelment of specific offerings and deployment models.
2. Audit: the Standardisation Testing and Quality Certification (STQC) Directorate, or cloud audit organisations empanelled for this purpose, audit the offering against MeitY's requirements. STQC publishes requirements for empanelling cloud audit organisations.
3. Evaluation: MeitY reviews audit results and other criteria, including data centre location in India.
4. Empanelment: approved offerings are listed with their deployment models and services.
5. Ongoing compliance: providers must maintain compliance, undergo periodic audits and renew empanelment.

What empanelment covers

MeitY's framework addresses several areas for cloud service providers:

• Security, typically assessed against international standards such as ISO/IEC 27001, ISO/IEC 27017 and ISO/IEC 27018, plus government-specific requirements.
• Data location: cloud services for government must be hosted and data kept within India.
• Interoperability and data portability, so departments can move between providers.
• Service level agreements covering availability, support and reporting.
• Contractual terms, based on MeitY's guidelines for government departments on cloud contracts, including data ownership, audit rights, exit management and law enforcement access.
• Service management, often referencing ISO/IEC 20000-1.

What it does not cover

Empanelment does not certify that an application is secure. Departments and their vendors must still:

• Secure the application, APIs and data according to government security guidelines and audits.
• Configure the cloud securely, including identity, networking, encryption and logging.
• Have the application security audited, often by a CERT-In empanelled auditor, before go-live.
• Meet CERT-In Directions for incident reporting and log retention.
• Follow data protection obligations under the DPDP Act.

Shared responsibility in government cloud

Empanelment covers what the cloud provider controls. Everything above that is the responsibility of the department and its vendors. A typical split for infrastructure and platform services looks like this:

Area	Cloud provider	Department and software vendor
Physical data centres in India	Responsible	Verify location
Hypervisor, hardware and core network	Responsible	None
Managed service security (databases, storage)	Responsible for the platform	Configure securely, control access, encrypt data
Operating systems on virtual machines	None	Patch, harden and monitor
Application code and APIs	None	Secure development, testing and audits
Identity and access	Provides tools	Configure MFA, roles and reviews
Logs and incident response	Provides platform logs	Collect, retain, monitor and report incidents
Data classification and backups	Provides backup services	Decide what to protect, test restores

What application security audits usually check

Government departments generally require an application security audit before a system goes live and after major changes. Auditors commonly test for vulnerabilities such as those in the OWASP Top 10, including broken access control, injection and authentication weaknesses; review configuration of servers, databases and cloud services; check that sensitive data is encrypted and not exposed in logs or URLs; confirm session management and password policies; test APIs and mobile apps that connect to the system; and verify that logging and audit trails capture administrative and sensitive actions. Findings must be fixed and retested before a "safe to host" certificate or equivalent clearance is issued. Building security testing into development reduces the number of findings and avoids launch delays.

How software vendors should approach government projects

1. Confirm the required deployment model and whether a specific empanelled provider or offering is mandated.
2. Check the current empanelment list for the provider, services and regions you plan to use, since not every service a provider offers is empanelled.
3. Design within empanelled services, avoiding managed services or regions outside the empanelled scope.
4. Keep all data, backups and logs in India, including monitoring and support tools.
5. Apply security controls: MFA, role-based access, encryption, centralised logging, vulnerability management.
6. Prepare for a security audit of the application before launch and periodically after.
7. Document architecture, data flows, and responsibilities between the department, vendor and cloud provider.
8. Plan exit and portability, using portable formats and infrastructure as code.

Procurement through the Government e-Marketplace

Government buyers increasingly procure cloud services through the Government e-Marketplace (GeM), where empanelled providers and their partners list cloud offerings. This simplifies buying compute, storage and managed services in smaller quantities, but buyers must still confirm that the specific service and model they order is within the provider's empanelled scope. System integrators building a solution often bundle cloud services with their software and support, and must make sure every component in the bundle meets the tender's hosting requirements.

Relevance for regulated private companies

Outside government, empanelment has become a shorthand for "approved Indian cloud" in regulated sectors. SEBI's cloud framework requires regulated entities to use MeitY-empanelled providers, and other regulators and large enterprises use empanelment as one input in vendor selection. For a fintech or SaaS company selling to these clients, hosting on an empanelled provider's Indian regions can shorten security reviews, though it never replaces the client's own assessment of the application.

Documentation you will need

• Evidence of the cloud offering's empanelment and deployment model.
• Architecture diagrams and data flow maps showing India-only hosting.
• Shared responsibility matrix.
• Security audit reports for the application.
• Access control, logging and incident response procedures.
• SLA and support arrangements.
• Exit and data migration plan.

Timeline and cost considerations

For cloud providers, empanelment involves preparing documentation, audits by STQC or empanelled auditors, and MeitY evaluation, which can take several months. For software vendors, the main effort is designing within the empanelled scope and passing application security audits. Government community cloud and virtual private cloud models usually cost more than public cloud because of isolation.

Benefits and limitations

• Benefits: clear baseline for government cloud use; data hosted in India; simpler procurement; regulators can rely on it.
• Limitations: covers the provider, not the application; newer cloud services may not yet be empanelled; requirements and lists change, so they must be checked for each project.

Common mistakes

• Using a non-empanelled service from an empanelled provider, such as a new managed AI or analytics service.
• Sending logs or backups to regions outside India.
• Assuming empanelment means the application is approved.
• Using global SaaS tools for monitoring or support that hold government data abroad.
• No exit plan, making migration difficult at contract end.

Best practices, tools and technologies

• Use cloud policies to restrict resources to approved Indian regions and services.
• Manage infrastructure as code for repeatable, auditable deployments.
• Encrypt data with keys managed in India.
• Centralise logs in India and keep them for at least 180 days.
• Run security testing in CI/CD and before audits.
• Keep a configuration baseline aligned with cloud security benchmarks.

We design and migrate applications onto Indian cloud regions with role-based access, audit logs and documented architecture through our migration and modernisation and web application development services.

How it relates to other frameworks

Framework	Relationship
FedRAMP	US federal equivalent for authorising cloud services.
ISO/IEC 27017 and ISO/IEC 27018	Cloud security and privacy standards commonly assessed.
SEBI CSCRF	Requires SEBI-regulated entities to use MeitY-empanelled cloud providers.
CERT-In Directions	Incident reporting and log retention for systems hosted on empanelled clouds.
DPDP Act	Personal data duties for citizen data in government applications.

Real-world example

A state government department commissions a citizen grievance portal from an Indian software company. The tender requires hosting on a MeitY-empanelled virtual private cloud. The vendor confirms that the compute, database, object storage and backup services it plans to use are within the provider's empanelled scope, deploys only in Indian regions, centralises logs in India for 180 days, uses MFA for all administrators, and passes a pre-launch security audit by a CERT-In empanelled auditor. A documented exit plan uses open formats so the department can move providers later.

Next steps

1. Check the project's deployment model requirement.
2. Verify empanelled services and regions.
3. Design for India-only hosting.
4. Plan the application security audit.
5. Document responsibilities and exit.

Frequently asked questions

What is MeitY cloud empanelment?

MeitY's approval of cloud service offerings for use by government, after audits against defined requirements.

Who audits cloud providers for empanelment?

The STQC Directorate or cloud audit organisations empanelled for this purpose.

Does empanelment certify my application?

No. It covers the cloud offering only; applications built on it need their own security audits, configuration reviews and controls.

What deployment models are empanelled?

Public cloud, virtual private cloud and government community cloud, depending on the offering.

Must government data stay in India?

Yes. Empanelled cloud services for government must be hosted within India.

Do private companies need empanelled clouds?

Not generally, but regulators such as SEBI require their regulated entities to use MeitY-empanelled providers.

Are all services from an empanelled provider covered?

No. Only the specific offerings and services in scope of the empanelment are covered.

What is MeghRaj?

The Government of India's GI Cloud initiative to promote cloud adoption in government, under which empanelment operates.

How do departments buy empanelled cloud?

From the empanelled list, increasingly through the Government e-Marketplace.

Is MeitY empanelment like FedRAMP?

Similar in purpose, as both approve cloud services for government use, though the processes and requirements differ.

Where can I find the current list of empanelled providers?

On MeitY's GI Cloud (MeghRaj) pages, which publish the audit and empanelment status of cloud service providers and their offerings.

Do government applications need a separate security audit?

Usually yes. Departments typically require an application security audit, often by a CERT-In empanelled auditor, before go-live and after major changes.