The 29th National Conference on e-Governance ran on 1 and 2 July 2026 in Jaipur, jointly organised by MeitY and the Department of Administrative Reforms and Public Grievances, with Secure Digital Infrastructure as one of its six breakout tracks and the Jaipur Declaration on e-Governance adopted at the close. That agenda line matters more than it looks. It is an admission, at the level of the two ministries running India's digital governance programme, that the infrastructure question and the security question for government IT have become the same conversation.
A zero trust, multi-cloud architecture is what that conversation is increasingly pointing toward. Multi-cloud spreads government workloads across more than one empanelled provider instead of one hyperscaler; zero trust replaces the old assumption that anything inside the network perimeter can be trusted with continuous verification of every user, device, and workload, regardless of where it sits. Neither one does much good without the other. Multi-cloud without zero trust just multiplies the number of perimeters an attacker can try, and zero trust bolted onto a single, flat network still leaves an agency dependent on one provider's roadmap, pricing, and uptime.
Here is the part that gets skipped in a lot of vendor pitches on this topic. This is not purely an infrastructure decision for the IT wing to finalize on its own. A large share of what makes a government cloud programme actually defensible is whether it satisfies MeitY's empanelment route, whether logging is unified enough to meet CERT-In's incident reporting window, and whether the data-handling design holds up against the DPDP Act's security-safeguard duty. That is a procurement and compliance problem as much as an architecture one. Design it as only one or the other and the programme stalls at audit, not at launch.
This guide walks through what zero trust and multi-cloud actually mean for a government or PSU project, why the two now travel together, how the responsibility splits between the cloud provider, the managed service layer, and the agency itself, what a badly designed rollout costs, and a readiness playbook a project team can start against this quarter. It is written for the people who have to make it work in practice: IT heads at PSUs, government CTOs, and the security and compliance teams sitting alongside them.
Talk to the SecNinjaz cloud team →
What Zero Trust and Multi-Cloud Actually Mean Here
Zero trust, as defined in NIST Special Publication 800-207, replaces the old castle-and-moat model, where anything inside the network was implicitly trusted, with continuous verification of every access request based on identity, device posture, and context. Nothing is trusted by default because of where it sits on the network. NIST SP 800-207A extends the same model specifically to cloud-native and multi-cloud environments, which is the relevant extension for this discussion rather than the original on-premise-focused version.
Multi-cloud, in the Indian government context, usually means running workloads across more than one MeitY-empanelled Cloud Service Provider (CSP), often a mix of global hyperscalers and Indian providers such as CtrlS, ESDS, or Yotta, rather than committing an entire department's infrastructure to a single vendor. MeitY's GI Cloud programme, branded MeghRaj, is the mechanism behind this: CSPs are empanelled after an STQC-administered audit, and public sector buyers are expected to procure from that empanelled list rather than negotiating security requirements from scratch with every vendor.
The two ideas reinforce each other in a government setting specifically because of how procurement works. An agency rarely gets to pick one perfect cloud and stay there. Different workloads land on different empanelled CSPs for different reasons, cost, regional data center availability, a specific service catalogue, and the security model has to work the same way regardless of which CSP a given workload sits on. That is what zero trust is actually solving for in a multi-cloud government estate: consistent verification and policy enforcement across providers that were never designed to share a single security model.
Why Government and PSU Projects Need Both, Not Either
Scale and mandate are why this stopped being optional. MeitY's empanelment programme has been running since a 2013 strategic direction paper and a 2016 empanelment framework, and all three major hyperscalers plus a growing list of Indian providers now hold CSP empanelment. NICSI's cloud delivery model on top of that separates the CSP layer, which supplies compute, storage, network, and platform services, from the Managed Service Provider (MSP) layer, which handles onboarding, SLA-backed operations, monitoring, and governance support. That two-layer structure is already a multi-party model before an agency adds its own zero trust design on top.
CERT-In's 2022 directions add a second pressure point: reportable cyber incidents must reach CERT-In within six hours of being noticed. That is a demanding window if logging and monitoring are fragmented across two or three CSPs with no common view, and considerably more workable if identity, access, and monitoring are unified through a zero trust control layer that sits above the individual clouds.
The IndiaAI Mission's compute empanelment adds a third dimension specific to 2026: MeitY ran a Request for Empanelment for AI compute and cloud services from CSPs, MSPs, and data center operators, aiming to make thousands of GPUs available to government-linked AI work. Government and PSU projects adding AI workloads on top of existing e-governance systems are, almost by default, adding another provider to an already multi-cloud estate, which raises rather than lowers the case for a unified zero trust layer across all of it.
How the Government Cloud and Security Mandate Has Evolved
| Period | What changed |
|---|---|
| 2013 | MeitY publishes its strategic direction paper on cloud policy, the starting point for GI Cloud. |
| 2016 | MeitY begins formal empanelment of Cloud Service Offerings under the MeghRaj initiative. |
| 2022 | CERT-In's directions mandate cyber incident reporting within six hours and set baseline logging expectations for regulated entities. |
| 2023 to 2025 | The Digital Personal Data Protection Act, 2023 is enacted, with the DPDP Rules notified in November 2025, adding a formal security-safeguard duty for anyone handling personal data, government bodies included. |
| 2024 to 2026 | MeitY runs an empanelment process for AI compute and cloud services under the IndiaAI Mission, adding GPU-focused providers to the government's cloud vendor base. |
| July 2026 | The 29th National Conference on e-Governance adopts the Jaipur Declaration, with Secure Digital Infrastructure as a named breakout track. |
The Layers Behind a Zero Trust, Multi-Cloud Design
Not every control in a zero trust architecture carries equal weight for a government workload, and it helps to think in layers rather than a single flat checklist.
| Layer | What it covers | Why it matters for government and PSU work |
|---|---|---|
| Identity and access | MFA, privileged access management, per-request authentication | The starting layer; most breaches begin with a compromised or over-privileged credential rather than a network exploit |
| Device and workload posture | Endpoint compliance checks, workload attestation across clouds | Confirms a device or workload meets baseline security before it gets anywhere near sensitive systems, regardless of which CSP hosts it |
| Network microsegmentation | Software-defined perimeters, east-west traffic restriction | Stops lateral movement once a single account or workload is compromised, the failure mode a flat network cannot contain |
| Data governance and localization | Encryption at rest and in transit, India-hosted data boundaries, DPDP classification | MeitY empanelment already requires India-hosted data for empanelled CSPs; the agency still owns classification and DPDP mapping on top of that |
| Continuous monitoring | Unified logging and SIEM across all clouds in use | The layer that actually makes CERT-In's six-hour reporting window achievable across a multi-cloud estate |
A rollout that starts with network segmentation before identity is backwards in practice. Nearly every zero trust framework, NIST's included, treats identity as the layer everything else is built on.
Who Owns What: CSP, MSP, and the Architecture Partner
A common assumption trips up agencies moving into this model for the first time: that empanelment by MeitY, or a signed MSP contract, closes the whole security gap. It does not. Coverage of compute and platform services is the CSP's job. Day-to-day operations sit with the MSP. Designing and running the zero trust layer itself, and proving compliance on top of it, is a third role that neither of the first two automatically fills.
| Responsibility | Cloud Service Provider (CSP) | Managed Service Provider | Architecture and security partner | Government agency / PSU |
|---|---|---|---|---|
| Underlying compute, storage, network SKUs | Yes | Relies on it | Relies on it | Procures it |
| MeitY empanelment and STQC audit of the offering | Yes | N/A | N/A | Verifies it |
| Onboarding, SLA operations, help desk | No | Yes | Coordinates with it | Oversees it |
| Zero trust policy design, IAM architecture, microsegmentation | No | Rarely | Yes | Approves and owns the design |
| DevSecOps pipeline security and CI/CD gating | No | Sometimes | Yes | Sets the security bar it must meet |
| Data classification and DPDP obligations | No | No | Advises on it | Owns it, as the data fiduciary |
| CERT-In six-hour incident reporting | Provides raw logs | Supports operations | Builds the unified logging layer | Files the report |
An agency that assumes MeitY empanelment or an MSP contract covers the middle two rows is skipping exactly the work that makes an architecture defensible later.
Where Architecture Meets Compliance: The DevSecOps Angle
Faster deployment does not move the compliance boundaries a government system has to operate inside, and this is the section most cloud migration pitches skip entirely.
A zero trust architecture that only exists as a network diagram and a set of firewall rules is not the same as one enforced through the actual software delivery pipeline. DevSecOps managed services close that gap by embedding security checks into the build and deployment process itself: policy-as-code that blocks a misconfigured storage bucket before it ships, infrastructure-as-code scanning that catches an over-permissive IAM role at commit time rather than in production, and secrets management that keeps credentials out of source code across every cloud a workload might land on. This matters specifically in a multi-cloud government estate because the pipeline is often the one place with a consistent view across CSPs that individual cloud consoles do not provide on their own.
That pipeline-level discipline is also what makes CERT-In's six-hour reporting window realistic rather than aspirational. Unified logging has to originate somewhere, and a DevSecOps pipeline that enforces consistent logging and monitoring configuration at deployment time is a more reliable source of that consistency than asking every team to configure it correctly by hand on every cloud separately.
The same logic applies to the DPDP Act's security-safeguard duty. Section 8(5) requires data fiduciaries, government bodies and PSUs handling personal data are not exempt from this obligation the way they are exempt from consent requirements for investigative work, to implement reasonable security safeguards to prevent a personal data breach. A DevSecOps pipeline that gates deployments against a defined security baseline is one of the more concrete, auditable ways to demonstrate that duty was actually met, rather than asserted after the fact.
What Getting This Wrong Actually Costs
There is a real cost schedule behind a badly designed rollout, and it is not limited to a slower migration timeline.
| Failure point | Consequence |
|---|---|
| Inadequate security safeguards under DPDP Section 8(5) | Up to ₹250 crore penalty, the highest tier in the Act's Schedule |
| Failure to notify a breach to the Data Protection Board or affected individuals | Up to ₹200 crore penalty, assessable alongside the safeguards penalty for the same incident |
| Missed CERT-In six-hour reporting window | Regulatory non-compliance exposure on top of any DPDP penalty already triggered |
| Single-CSP dependency dressed up as a cloud strategy | Service continuity risk and weak negotiating position on pricing and roadmap the moment renewal talks begin |
| Zero trust bolted onto a flat, unsegmented network | Lateral movement risk persists after a breach despite the zero trust label on the architecture diagram |
| Bypassing the empanelled CSP and MSP governance route | Procurement findings and tender disqualification risk during audit |
None of these are hypothetical. They are the direct, traceable result of treating speed to deployment as a substitute for the identity, segmentation, and logging work rather than as an addition to it.
A Maturity Model for Government Zero Trust and Multi-Cloud Adoption
Most agencies sit somewhere on a five-level curve, and knowing where a given project actually sits matters more than jumping straight to the top.
Level 1: Single CSP, perimeter-based network, implicit trust inside the boundary ↓ Level 2: Documented cloud strategy and empanelled CSP selection, security still perimeter-based ↓ Level 3: Identity-first controls, MFA and privileged access management layered onto existing infrastructure ↓ Level 4: True multi-cloud with microsegmentation, DevSecOps pipeline gating, and continuous monitoring ↓ Level 5: Policy-as-code zero trust enforced uniformly across every cloud in use, with logging built to meet CERT-In's reporting window by design
Skipping Level 3's identity work to chase Level 4's multi-cloud footprint is the most common way these programmes underdeliver: more clouds without a unified identity layer is just more surface area, not more security.
A Readiness Playbook for Designing These Architectures
- Inventory workloads and classify the data behind each one. A government estate almost always has more systems, and more personal data, in play than the IT wing's working list shows on the first pass.
- Match workloads to empanelled CSPs on merit, not on whichever vendor's credits are largest. Regional data center availability, service catalogue depth, and existing departmental relationships all belong in that decision.
- Design the identity and access layer before touching network segmentation. MFA, privileged access management, and per-request verification are the foundation everything else in a zero trust model sits on.
- Build microsegmentation and a software-defined perimeter across every cloud in scope, not just the primary one, so lateral movement is contained the same way regardless of where a workload sits.
- Embed security into the DevSecOps pipeline directly, with policy-as-code, infrastructure-as-code scanning, and secrets management enforced at deployment rather than reviewed after the fact.
- Stand up centralized logging that meets CERT-In's six-hour reporting window across all clouds in use, not a separate log stream per provider that someone has to manually reconcile during an incident.
- Map every data flow against DPDP obligations, including the Section 8(5) security-safeguard duty, before the migration goes live rather than during the first audit.
- Migrate workload by workload with a defined rollback path for each, rather than a single cutover date for the entire estate.
Common Mistakes and Edge Cases
Treating multi-cloud as just two vendor contracts. Running workloads on two empanelled CSPs without a shared identity and policy layer between them is parallel infrastructure, not a multi-cloud security strategy.
Assuming CSP empanelment covers the agency's own obligations. MeitY empanelment and the STQC audit behind it certify the cloud offering. They do not certify the agency's data classification, consent handling, or DPDP compliance on top of it.
Bolting zero trust onto a legacy flat network. Adding identity checks at the login screen while leaving east-west traffic unsegmented behind it stops almost none of the lateral movement zero trust is meant to prevent.
Leaving the DevSecOps pipeline out of the zero trust scope. A build system with standing credentials and no policy gating is often the softest target in an otherwise well-defended estate, precisely because it does not look like a production system.
Underestimating what unified logging across clouds actually takes. Each CSP's native logging format is different, and reconciling them manually during a live incident is not compatible with a six-hour CERT-In reporting window.
Deferring data classification until after migration. Moving a workload first and figuring out its DPDP classification afterward routinely surfaces sensitive data sitting somewhere it should not be, after the fact rather than before.
When to Use What: A Few Decision Points
A single empanelled CSP versus true multi-cloud. A single, well-chosen empanelled CSP may be sufficient for a smaller PSU with one primary workload and modest continuity requirements. Once citizen-facing uptime, disaster recovery across regions, or AI compute needs enter the picture, a single-provider estate becomes the harder position to defend, not the simpler one.
Building zero trust in-house versus bringing in a specialist architecture partner. An agency with a mature internal IAM and network team can lead the identity and segmentation design itself. Most government IT wings do not have that depth in-house for a multi-cloud rollout on a first attempt, and an outside architecture partner closes that gap faster than building the capability from zero mid-project.
A full DevSecOps managed service versus an internal DevOps team with security added on. Internal teams should own day-to-day deployment. Where the pipeline needs to satisfy an external audit, MeitY empanelment conditions, or CERT-In logging requirements, a managed DevSecOps layer with that specific accountability tends to hold up better under review than security added on as an afterthought to an existing DevOps process.
A phased, workload-by-workload migration versus a single cutover. A single cutover works for a small, self-contained system with a short outage window. Anything citizen-facing, high-volume, or tied to other departmental systems is better served by migrating one workload at a time, with a defined rollback path, so a problem in one system does not take the whole estate down at once.
How SecNinjaz Fits Into This
The pattern running through this guide is that zero trust and multi-cloud design for government work sits across three roles at once, infrastructure, security, and compliance, and most vendors cover only one. SecNinjaz's IT Engineering practice covers Infrastructure Architecture and Design, Cloud Computing Services, System Integration, and Managed Services and IT Support, the layer that turns a multi-cloud strategy into a working estate across empanelled CSPs rather than a slide deck.
The security layer sits with SecNinjaz's Cybersecurity practice, covering Vulnerability Assessment, Penetration Testing, Red Teaming, Purple Teaming, Breach and Attack Simulation, and AI SOC Automation, the capabilities that turn a zero trust diagram into an architecture that has actually been tested against real attack paths. The compliance layer runs through the GRC and DPDP practice, Regulatory Compliance, Risk Management, and Audit and Gap Assessment, which is where the DPDP mapping and CERT-In readiness work gets documented in a form an auditor accepts.
SecNinjaz holds ISO/IEC 27001:2022 for information security and ISO/IEC 20000-1:2018 for IT service management, along with CMMI Level 3 for engineering process maturity, the combination most directly relevant to a managed cloud and DevSecOps engagement of this kind. For government departments, PSUs, and Smart Cities or municipal command centre projects that cannot afford a cloud migration to stall at audit, that combination of infrastructure delivery, tested security architecture, and documented compliance is the pairing worth looking for, whether the project works with SecNinjaz or anyone else.
Talk to the SecNinjaz cloud team →
Frequently Asked Questions
What does zero trust actually mean for a government cloud project?
It means no user, device, or workload is trusted by default because of where it sits on the network. Every access request is verified against identity, device posture, and context, as defined in NIST SP 800-207 and extended to cloud-native and multi-cloud environments under NIST SP 800-207A. For a government project, that replaces the older assumption that anything inside the departmental network perimeter is automatically safe.
Why do government and PSU projects need multi-cloud instead of a single empanelled provider?
A single provider creates a continuity and negotiating-position risk, and most government estates already span more than one workload with different regional, service, or cost requirements. Multi-cloud, built on MeitY's empanelled CSP list, spreads that risk, provided a unified identity and monitoring layer sits above the individual clouds rather than treating each one as a separate silo.
Does MeitY empanelment mean a cloud provider is automatically DPDP compliant?
No. MeitY empanelment, audited by STQC, certifies that the cloud offering meets a defined set of security, audit, and operational standards, including India-hosted data. It does not cover the agency's own data classification, consent handling, or the DPDP Act's security-safeguard duty, which remains the agency's responsibility as the data fiduciary regardless of which empanelled CSP it uses.
How does CERT-In's six-hour reporting rule affect architecture design?
CERT-In's 2022 directions require reportable cyber incidents to be notified within six hours of being noticed. Meeting that window across a multi-cloud estate requires centralized, unified logging rather than separate log streams per provider that have to be manually reconciled during an active incident, which is one of the strongest practical arguments for building the zero trust monitoring layer early rather than after the first incident.
What is DevSecOps and why does it matter for zero trust specifically?
DevSecOps embeds security checks directly into the software build and deployment pipeline: policy-as-code, infrastructure-as-code scanning, and secrets management enforced at deployment time. For zero trust, it matters because the pipeline is often the one consistent point of control across a multi-cloud estate, and a build system left outside the zero trust scope, with standing credentials and no policy gating, is a common soft target precisely because it does not look like a production system.
What penalties apply if a government system's security safeguards fail under DPDP?
Failure to implement reasonable security safeguards under Section 8(5) of the DPDP Act, 2023 carries a penalty of up to ₹250 crore, the highest tier in the Act's Schedule. A related failure to notify the Data Protection Board or affected individuals of a breach can attract a separate penalty of up to ₹200 crore, and both can apply to the same incident.
Should an agency build zero trust in-house or bring in an architecture partner?
It depends on existing depth in identity and network engineering. An agency with a mature internal IAM and network team can lead the design itself. Most government IT wings attempting a multi-cloud rollout for the first time do not have that depth yet, and bringing in a specialist architecture partner for the identity, segmentation, and DevSecOps pipeline design typically closes the gap faster than building the capability internally mid-project.
Where should a PSU start if it has no zero trust or multi-cloud strategy yet?
Start with a full workload and data inventory, classify what is genuinely sensitive under DPDP, and design the identity and access layer before touching network segmentation or adding a second cloud provider. Multi-cloud without an identity-first foundation underneath it just adds more surface area to defend, not more resilience.
