Sovereign Cloud Certification for Indian SMBs: What to Ask Vendors

Your CFO forwards you a proposal. The vendor calls their service a "sovereign cloud" with "100% India-hosted data," quotes ₹2.4 lakh a year, and wants a three-year commitment. Somewhere in the deck is a logo of a government body, a badge that says "MeitY empanelled," and a line about "end-to-end encryption." It sounds reassuring. It is also, very often, a marketing layer sitting on top of infrastructure you have not actually verified. This matters more than it used to. Indian SMBs now hold customer KYC documents, GST invoices, employee Aadhaar-linked payroll data, and in many cases health or financial records, all under the Digital Personal Data Protection Act, 2023, which the government is phasing in with its rules and timelines. The sales pitch around "sovereignty" is trying to solve a real anxiety, and some vendors are happy to sell you the anxiety along with the product. This guide is the checklist I wish more buyers carried into vendor meetings. It covers what "sovereign cloud" should mean in practice, the questions to ask about data residency, encryption key control, and compliance evidence, and how to tell a premium worth paying from a premium you are paying for a logo. If you are in a 10 to 200 person company and you have to make this call without a dedicated security team, read it before you sign anything.

Key Takeaways

• "India-hosted" and "sovereign" are not the same thing. Ask where the data is stored, where it is processed, where backups live, and which personnel can access it, each as a separate question.
• The only sovereignty claim that means much is control of the encryption keys. If the provider holds the keys and can be compelled to hand them over, your data is not sovereign regardless of the datacentre's postcode.
• Ask for evidence, not badges. Ask for the MeitY empanelment letter, the scope of the audit report (SOC 2 Type II, ISO 27001 certificate with its Statement of Applicability), and the specific services covered.
• Map the premium to a real requirement. If your data is low-sensitivity, a standard Indian region from a hyperscaler may serve you well at a fraction of the cost.
• Put data location, sub-processor list, breach notification timelines, and exit terms into the contract. A verbal assurance from a sales engineer is worth nothing in a dispute.
• Model the total cost, including egress, support tiers, and the cost of leaving, before comparing sticker prices.

What does sovereign cloud actually mean for an Indian SMB?

The term has been stretched so far it now covers almost anything with an Indian IP address. A useful working definition for a small business is this: your data is stored and processed inside Indian jurisdiction, the people and legal entities with access to it are identifiable and subject to Indian law, and the cryptographic keys that unlock it are controlled by you or by an Indian entity you can hold accountable. Each part of that definition matters, and vendors frequently satisfy one while silently skipping another. A datacentre in Mumbai run by a foreign parent company whose support engineers in another country can open your tenant is in India, but it is not sovereign in any sense your auditor will care about.

Three layers that get conflated

• Data residency: where the bytes physically sit at rest. This includes primary storage, replicas, snapshots, logs, and backups. Many vendors store primary data in India and quietly replicate telemetry or backups abroad.
• Data processing and access: where computation happens and which humans can see the data. Support staff, managed-service operators, and automated monitoring pipelines all count.
• Legal and key control: which legal regime can compel disclosure, and who holds the encryption keys. This is the layer most often glossed over.

When a vendor says "sovereign," ask which of these three they mean. A serious provider will answer each one separately and in writing. A vague provider will repeat the word.

Why this matters more for SMBs than you might think

Large enterprises have legal teams that will parse these distinctions. An SMB usually does not, and that is exactly the gap vendors exploit. A 40-person pharmacy chain in Pune, a textile exporter in Surat, or a SaaS startup in Bengaluru serving banks will each face questions from clients or regulators about where data lives. When those questions come, "our vendor said it was sovereign" is not an answer that survives scrutiny.

How do I check data residency claims from a cloud vendor?

Start by treating residency as a set of specific facts you can verify, not a feature. The following sequence works well in a first vendor call and a follow-up written request.

1. Ask for a data-flow diagram, not a brochure. A credible provider can show you where primary storage, read replicas, backups, disaster-recovery sites, logs, metrics, and support tooling live. If the diagram has arrows crossing international borders, that is useful information, not a deal-breaker, but you need to know.
2. Ask about the disaster-recovery region specifically. This is the most common gap. A vendor may run production in Mumbai and fail over to Singapore, Hyderabad, or a third country. Get the DR region named in writing. Some Indian-hosted offerings are primary-in-India, DR-outside-India, which may or may not fit your obligations.
3. Ask where backups and snapshots are retained, and for how long. Backups are the forgotten copy. Retention periods of 30, 90, or 365 days mean your residency story must cover those too.
4. Ask about telemetry and logs. Application logs often contain personal data: IP addresses, user IDs, sometimes email addresses in error messages. Find out whether logs ship to a centralised SaaS observability tool hosted abroad.
5. Request the sub-processor list. Every serious cloud contract includes one. Read it. If a sub-processor in a foreign country can access customer data for support or maintenance, that counts toward your residency analysis.

Common Mistake: trusting the region name

Hyperscalers offer region names like "Mumbai" or "Hyderabad," and many managed services built on top of them still have global control planes or global identity services. A resource in the Mumbai region can have metadata, billing records, IAM configurations, or certain managed-feature telemetry processed elsewhere. This is not necessarily a breach or a scandal. It is simply a fact that a region name does not guarantee every byte about your workload stays put. Ask the vendor which control-plane functions are regional and which are global.

Who should hold my encryption keys, and why does it matter?

This is the question that separates genuine sovereignty from a badge. If your provider holds both your encrypted data and the keys, then the provider can decrypt your data whenever it chooses or whenever a court or authority compels it. Their datacentre being in Chennai does not change that.

Encryption key management comes in several models, and the differences are real money and real control.

Key model	Who holds keys	Control you get	Typical cost premium	Good fit when
Provider-managed keys	Cloud provider	Low; provider can decrypt	Included in base price	Low-sensitivity data, standard compliance needs
Customer-managed keys (CMK) in provider KMS	You, via provider's key service	Medium; you can revoke access, but provider infrastructure still processes keys	Modest, often 10 to 25% on key-related services	Mid-sensitivity data where revocation control is enough
Bring your own key (BYOK)	You generate; imported to provider	Higher; key originates with you	Moderate, plus operational overhead	Regulated sectors wanting key provenance
Hold your own key (HYOK) / external KMS on-prem or in Indian HSM	You, or an Indian entity under your contract	Highest; provider never sees plaintext keys	Significant; hardware and staff	Sensitive personal data, financial, healthcare

For most Indian SMBs the realistic target is customer-managed keys with a key store that sits within India and where you hold the administrative credentials. Full HYOK with an on-premise HSM is often overkill unless you are a payments processor or handle very sensitive health records. A reasonable middle path for many companies is a cloud HSM service or external key manager running in an Indian region under a contract you control.

Questions to ask about keys

• Who can create, rotate, disable, or delete a key? Can the provider do any of these without my approval?
• If I revoke the key, how quickly does access stop, and what is the process to prove that revocation happened?
• Does the provider's support staff have any standing access to key material, or only to the metadata about keys?
• Where is the key store physically located and where are its backups?
• Is the HSM FIPS 140-2 Level 3 validated, or the equivalent current standard, and can you see the certificate?
• If the provider receives a lawful order for data, what is their stated process, and do they notify the customer where the law allows?

Pro Tip: test key revocation before you sign

Ask for a sandbox account and rehearse the revocation scenario yourself. Create a key, encrypt a test object, revoke the key, and confirm access is cut and the object is unreadable. Many buyers skip this, and then discover during an actual incident that the revocation path involves a support ticket and a four-hour SLA. Doing it in the trial is free information.

What compliance proof should I demand before paying a premium?

Badges and logos are cheap. Evidence is what you want. The following is what I ask for in every serious evaluation, and the list is deliberately specific because vague claims are where vendors hide.

MeitY empanelment

The Ministry of Electronics and Information Technology empanels cloud service providers for government workloads. If a vendor claims MeitY empanelment, ask for the empanelment letter or certificate, the date of the current empanelment, and the specific services covered. Empanelment applies to particular service offerings and to particular categories of workload, so a vendor can be empanelled for one product line and marketing a different one. Verify on the official MeitY list where published, and ask for the reference number.

ISO/IEC 27001 and SOC 2 Type II

ISO 27001 is a certification of an information security management system. The certificate alone is thin. Ask for the Statement of Applicability, which lists which controls the organisation has implemented and which it excluded, and the scope of the certification, meaning which products, locations, and business units it covers. A certificate covering "corporate headquarters" tells you nothing about the cloud product you are buying.

SOC 2 Type II is an attestation over a period of time, typically six to twelve months, that controls operated effectively. A Type I report only covers a point in time. Always ask for Type II, the reporting period, and the exceptions noted by the auditor. Exceptions are not always a red flag; a clean report with zero exceptions over a long period is sometimes less credible than one with a few documented, remediated exceptions.

DPDP Act readiness

The DPDP Act, 2023 and its rules place obligations on data fiduciaries and their processors, including requirements around consent, purpose limitation, breach notification to the Data Protection Board and affected individuals, and data retention. Your cloud provider will typically act as a data processor. Ask for their data processing agreement, how it maps to DPDP obligations, their breach notification timeline to you, and how they support your ability to honour data principal rights such as erasure requests. Do not accept a generic "we are compliant" statement. The rules and timelines are being operationalised, so ask how the provider is tracking changes.

CERT-In incident reporting

CERT-In directions require certain entities to report cybersecurity incidents within a defined window, and cloud service providers have obligations too. Ask whether the provider reports to CERT-In as required and how they will coordinate with you if an incident affects your data.

Sector-specific rules

If you are in banking, insurance, or payments, RBI and IRDAI guidance on outsourcing and cloud use is directly relevant. RBI's guidance on outsourcing of IT services and its directions for regulated entities set expectations around data localisation, audit rights, and exit management. Healthcare has its own set of expectations. Name your sector to the vendor and ask how they support that specific regulator's requirements.

Pro Tip: read the audit scope in the contract, not the brochure

Most providers give you the right to audit only through their third-party reports, not your own on-site inspection. That is normal for multi-tenant clouds. What matters is whether the scope of those reports includes the exact services you intend to use. I have seen SMBs buy a managed database service that was explicitly excluded from the SOC 2 scope in the fine print. Get the scope list in writing.

A worked example: a 25-person logistics firm in Gurgaon

Consider a realistic case. A 25-person freight forwarding company in Gurgaon runs a transport management system, a customer portal, and a document store holding bills of lading, GST invoices, and customer KYC for corporate clients. It was spending about ₹45,000 a month on on-premise servers, a leased rack in a colocation facility, a backup vendor, and the labour of a part-time sysadmin who was also the office IT person.

The owner shortlisted three options: a sovereign cloud offering from a local Indian provider marketed at ₹1.1 lakh a month, a hyperscaler's Mumbai region with managed services at roughly ₹52,000 a month before discounts, and a hybrid model keeping the document store on-prem with the application tier in a standard Indian cloud region.

Here is how the evaluation actually went when we ran it.

1. Classify the data first. The KYC documents and invoices were personal and financial data under DPDP obligations. The transport telemetry was not. This split meant they did not need the premium across the whole estate.
2. Demand the residency diagram. The local sovereign provider's diagram showed Mumbai primary and Hyderabad DR, both in India. The hyperscaler's diagram showed Mumbai primary, DR in Hyderabad, but a global identity layer and a SaaS logging tool hosted outside India. The logging tool received application logs including customer IP addresses.
3. Test the keys. The sovereign provider offered an Indian-hosted external key manager with the customer holding the admin role. The hyperscaler offered customer-managed keys in its KMS for roughly a 15% premium on key services.
4. Verify the evidence. The sovereign provider had a MeitY empanelment letter covering the specific storage service, but its SOC 2 report excluded the backup service. The hyperscaler's SOC 2 Type II and ISO 27001 scope covered everything the team intended to use.

The final design was a hybrid. The document store containing KYC and invoices went to the sovereign provider's storage with customer-managed keys in an Indian external KMS, accepting a higher unit price for that narrow workload. The application tier and transport telemetry went to the hyperscaler's Mumbai region with logs scrubbed of personal identifiers before shipping to any SaaS tool. The on-prem rack was retired after a six-week parallel run.

Monthly cost landed at around ₹19,000 all in. That is not the ₹18,000 someone would quote in a sales deck, and it is more than the cheapest option, but it was roughly 58% below the old on-prem spend and the company could show a regulator or client exactly where each category of data lived and who held the keys. The premium they paid bought them specific, documented controls on the data that needed them, and nothing more.

What is the real cost difference between sovereign and standard Indian cloud?

Sticker prices mislead in both directions. A sovereign offering may look expensive per vCPU and still be cheaper once you account for the costs you would otherwise carry: a compliance consultant, a separate backup vendor, an external key manager you would have bought anyway, and the staff time to maintain your own certifications.

Conversely, a hyperscaler's headline price is rarely what you pay. Egress charges, support plan tiers, premium managed services, and the cost of licences that only run on certain platforms all add up. When you compare, build a three-year total cost of ownership model with these line items:

• Compute, storage, and database at expected steady-state and peak
• Backup and DR region costs, including cross-region transfer
• Egress, measured against your real outbound traffic, not the marketing estimate
• Key management service fees and HSM costs if applicable
• Support plan tier, priced in rupees and with GST accounted for
• Migration and exit costs, including a realistic estimate of what it would cost to leave in year three
• Internal staff time for administration and audit preparation

Pay in rupees where you can, and check the currency and GST treatment on the invoice. For many SMBs, the question of how the vendor bills GST on cloud services and whether input tax credit flows cleanly is worth a conversation with your CA before you sign.

Which vendor questions should I ask on the first call?

The first meeting is where you set the tone. Vendors who respect you will answer specifics. Vendors who do not will pivot to features. Here is a compact list to bring.

1. Show me the data-flow diagram for my workload, including DR, backups, logs, and support access.
2. Name every country where my data, metadata, or logs will be stored or accessed, including sub-processors.
3. Who holds the encryption keys by default, and what can I change?
4. Can I revoke key access myself, and how fast does it take effect?
5. Provide the MeitY empanelment reference for the specific services I plan to use.
6. Provide your SOC 2 Type II report and ISO 27001 Statement of Applicability, and tell me which services fall within scope.
7. What is your breach notification timeline to me, and how do you support DPDP obligations?
8. What happens to my data at exit, and what does exit cost?
9. Will you put these answers in the contract as commitments?

If a vendor answers the first six clearly and quickly, you have a credible partner to negotiate with. If they stall, you have learned something important before signing.

Common mistakes Indian SMBs make in cloud sovereignty decisions

Over-buying for low-sensitivity data

A marketing site, an internal wiki, and a ticketing tool rarely need sovereign-grade hosting. Buying premium for everything is an easy way to waste a lakh a year. Classify first.

Under-buying for high-sensitivity data

The opposite error is equally common. A healthcare clinic or a lender stores patient or borrower records on a general-purpose plan because the price was right, then discovers during a client audit that backups replicate to a foreign region. Fixing this after the fact costs far more than doing it right initially.

Ignoring the people layer

Technology controls fail when the people operating them have too much access. Ask who in the vendor's support organisation can see your environment, what approval process governs that access, and whether access is logged and reviewed. Ask for your own admin accounts to be separated from vendor operators wherever the platform allows.

Skipping the exit plan

Every SMB I have seen get stuck with a cloud provider was stuck because data export was slow, expensive, or proprietary. Before you sign, confirm the export format, the export time for your data volume, and whether you can get a complete copy including backups and logs. Write the exit clause into the contract.

Where eDarpan fits in

If you read this and realise your team does not have the bandwidth to run this evaluation properly, that is a normal situation for an Indian SMB. eDarpan works with businesses on exactly these decisions: our IT consulting team can run the data classification and vendor questionnaire with you, and our cloud migration and managed services practice handles the implementation, key management setup, and ongoing audit evidence collection once you have chosen a path. If you are weighing a move off your current hosting, the context in our piece on whether Indian SMBs should switch from AWS or Azure is worth reading alongside this one.

Pricing and licensing shifts also change the math. Our note on AWS and Azure pricing changes Indian SMBs should recheck covers the cost lines that tend to move without warning. And if your data sovereignty question is really about where your SaaS data lives, our look at what sovereign datacentres in India gain and lose for SMBs goes deeper on residency tradeoffs. For productivity suites, the licensing and data handling comparison in our Google Workspace versus Microsoft 365 analysis is useful, and for a broader picture of what you are paying for, see our Microsoft 365 versus Google Workspace pricing breakdown. Our Microsoft 365 and Google Workspace licensing teams can also help you account for data handling in your productivity stack, which is often where sensitive customer data quietly ends up.

If you want a second opinion on a vendor proposal you have already received, Innovate Maryland Emerging Technology Center by MDGovpics via flickr (BY 2.0), sourced through Openverse.