Main idea

"I want my data in my Azure." Answering straight away "fine, let's build hosting on the customer's side" treats the request as a specification. It isn't one: it is a symptom, and several causes produce the same sentence.

Regulatory obligation, residency requirement, CISO policy, a need to control the keys, an audit constraint, a desire for reversibility, or simply a culture in which sensitive data stays under direct control — each calls for a different answer.

And those answers don't cost the same. A dedicated region is sometimes enough. Customer-managed keys sometimes too. A single-tenant environment in some cases. Hosting in the customer's environment only in the last ones.

Why it matters

The cost gap between these answers is considerable, and the literal request almost always points to the most expensive one. Investigating the motive is therefore the highest-return action in the whole discussion.

It also guards against the opposite error — refusing outright — by showing that there is nearly always an intermediate level.

Nuances and limits

The motive is not always accessible: your contact may not know it, or may be relaying an instruction whose origin they don't know.

And the calibration has a political limit: a level that is technically sufficient can remain insufficient for what the customer needs to be able to declare to its auditor.

Open questions

• What do you do when the real motive can't be determined, for lack of access to whoever set the requirement?