Cloud audit software and data residency: what to ask

Before putting client financial data into any cloud audit tool, a firm should establish three things: where the data is physically processed and stored and whether it leaves India, who inside the vendor's organisation can access it and under what circumstances, and whether any residency or access claim is an architectural fact the vendor can demonstrate or a policy statement that could change without the firm being told. A marketing page saying data stays in India is not the same as a contract or an architecture that makes that true.

Why this is a professional question before it is a technical one

A chartered accountant's confidentiality obligations under the ICAI Code of Ethics attach to client information regardless of where or how it is processed. Moving a client's trial balance, purchase register or bank statements into a cloud tool is a decision about disclosure, even when nobody frames it that way at the time. The technical questions below exist to support that professional judgement, not to replace it.

Where the data actually sits

"Our servers are in India" and "your data never leaves India" sound similar and are not the same claim. A vendor can host its primary database in an Indian data centre while using a backup service, an analytics tool, or a support system located elsewhere, all of which may handle the same client data. The question worth asking is not where the main system runs but where every system that touches the data runs.

Who inside the vendor can actually access it

Data residency answers where information sits. It does not answer who can look at it. A vendor's own support staff, engineers debugging an issue, or a third party running an integrated feature may have access to client data regardless of which country it is stored in. This is the question firms ask least often, because it requires trusting a vendor's internal process rather than checking a location.

• Is access to client data scoped by role, so that only staff working on a specific issue can see it, rather than broadly available to the vendor's whole team?
• Is access logged, so that if something goes wrong there is a record of who looked at what and when?
• Does any feature route data through a separate AI or analytics provider, and if so, is that provider named and does the same residency and access standard apply to them?
• What is the vendor's process when a client specifically asks what happened to their data, and can that process actually be exercised, not just described?

Telling an architectural fact from a policy

The most important distinction in this whole area is between something that is true because of how the system is built and something that is true because of a current policy choice. A policy can change with a product update and a line in a changelog nobody reads. An architectural constraint — data physically cannot leave a region because no system outside it has credentials to reach it — does not change on a whim, because changing it is itself a significant engineering decision.

1. 01Ask how the claim would be enforced, not just what the claim is"We don't send data outside India" and "our systems outside India have no network path to the data" sound similar. Only the second is a fact about the architecture rather than a current intention.
2. 02Ask what would need to change, and whether firms would be notifiedA vendor that can answer this specifically understands the distinction. A vendor that answers vaguely or treats the question as unusual may not have thought about it either.
3. 03Get residency and sub-processor commitments into the contract, not just the sales conversationA commitment that lives only in a conversation or a marketing page offers no recourse if it turns out not to be true.
4. 04Revisit the question periodically, not only at onboardingA vendor's architecture and sub-processor list can change over the life of a relationship. A commitment checked once at signup and never again is a point-in-time answer to an ongoing question.

A reasonable standard to hold a vendor to

A vendor handling audit client data should be able to state plainly, in writing, where data is processed and stored, who can access it and under what process, which sub-processors are involved including any AI provider, and what happens to the data if the firm leaves. A vendor that answers all of this specifically and in writing has earned a materially higher level of trust than one that answers generally or only verbally.