An hour of preparation is worth more here than a week of it, and the useful hour is not the technical one.
The assessment is a working session, not a pitch, and it goes badly when the wrong people are in the room. What it needs is someone who can answer for risk, someone who can answer for the work, and someone who knows how the identity and the documents are actually set up. Everything below is preparation that makes those two hours produce a document worth keeping.
Three roles, and a fourth who does not need to attend. The security owner carries the risk if they say yes. The operating owner carries the cost of saying no. An assessment that hears only one of them produces a document the other will reject later, which is the most common way this work stalls.
The person who will be asked, later, why they approved it. They hold the residency requirement, the encryption and audit expectations, and any contractual constraint on where your data may sit. They also hold the veto, so hearing their real objection in hour one is worth more than persuading anyone else.
The person who feels the delay and the rework: the lead of the team whose work this would actually change. They bring the processes worth testing and the definition of a good outcome. Without them the shortlist becomes a list of features rather than a list of consequences.
Your identity setup, your cloud position, where documents actually live as opposed to where policy says they live, and what already exists that this would sit beside. If one person holds both IT and security here, say so; it changes the two-administrator conversation later.
An executive sponsor does not need to sit through the session, but someone has to own the go or no-go decision it ends in. Name that person before the call. If nobody owns the decision, the written assessment becomes an interesting document nobody acts on, and that is worth finding out first.
We are mapping what exists, not auditing you. A screenshot and an honest sentence are more useful than a diagram drawn for the occasion.
About two hours of working session, then our own work, then a written assessment back to you. Times are indicative; the order is not, because each part depends on the honesty of the one before it.
What people already use, what a compliance review has already blocked, what a previous attempt cost and why it stopped. We are looking for the standoff: which controls the risk owner needs before yes becomes possible, and what the operating owner is paying for the delay meanwhile.
We walk the instrument with you: residency for storage and for inference as separate questions, encryption, identity and multi-factor, audit and retention, our management access, and your compliance program. The residency tradeoff is disclosed with the catalogue numbers in front of you, and the acknowledgement that we hold no third-party attestation is made in writing here rather than discovered later.
We take the one or two processes you brought and test them against what a governed deployment can actually do today, including where the honest answer is that inference is the wrong tool and a deterministic one is better. Each candidate gets an outcome you define and a baseline you would accept as the measure.
What the environment would cost to run on your own cloud bill at the recommended posture, what the engagement would cost, and what we still do not know. Then the recommendation, including the shape of a no: not yet, not this process, or not with us.
The deliverable is yours whether or not you proceed, and it is written to be readable by someone who was not in the room. That is the test we hold it to.
With an environment and data-flow map: where your data sits now, where it would sit, and every crossing in between, drawn rather than described.
Baseline, Standard or Strict, with the reasons, and with any control you asked to raise or lower recorded as an override with its justification.
First candidates, each tied to an outcome you chose and a baseline you accepted, in the order we would actually build them.
What the environment would add to your own cloud bill at the recommended posture, presented as an estimate from what we have seen rather than as a quotation.
A recommendation we will stand behind, including when it is no. A bounded document that says do not do this yet is worth more to you than a proposal that says the opposite.
The posture you approve is a typed object that drives the infrastructure and renders the plan page inside the product, so what was agreed in the session is what the build reads. Every override travels with the reason it was accepted.
Print this, or paste it into the invitation. Everything on it can be answered in a sentence, and an unknown is a legitimate answer that tells us something.
| Item | Who usually holds it | Why we ask |
|---|---|---|
| Names of the three attendees, plus the sponsor who owns the decision | You, before the call | An assessment without a decision owner ends in a document nobody acts on |
| AI tools in use today, sanctioned or not | Operating owner and IT | Shadow use is the baseline, and it is usually the strongest argument for doing this |
| Any AI or acceptable-use policy, even a draft | Security or privacy owner | It becomes a content policy applied in the system rather than a document circulated |
| Sign-in method, multi-factor status, who administers identity | IT | Identity decides more of the deployment shape than any other input |
| Where the documents people would ask about actually live | Operating owner and IT | Determines whether a knowledge base is useful on day one or a later phase |
| Who may see what in those libraries today | Operating owner | Everything loaded into a knowledge base is readable by every user of that deployment |
| Residency wording from any contract, regulator or internal standard | Security or privacy owner | The wording decides whether the residency pin is needed, and the pin has a capability cost |
| Whether an existing cloud account will be used, or a new one opened | IT | The account is the isolation boundary, and it is the thing you own |
| One or two processes where delay or rework hurts | Operating owner | The shortlist is built from these, not from a feature list |
| What a good outcome would be, and what you measure today | Operating owner and sponsor | Outcomes are yours to define, and a baseline has to exist before the work starts |
| Your hardest objection, written down in advance | Whoever holds it | Objections raised at the end become follow-ups. Raised at the start, they shape the recommendation |
Nothing on this list needs a document produced for us. If an item is genuinely unknown, say unknown: several of these are unknown in most organizations, and finding that out is part of what the map is for.
A vendor that cannot answer these in front of your security owner is a vendor you will be arguing with in month four. Ask them early, and hold us to the same standard you would hold anyone else.
If you only read one page before the session, make it what we do not claim. It is the fastest way to find out whether we are the wrong answer for you, which is a better outcome for both sides than finding out after a deployment. The questionnaire is the second one.
Three people, two hours, one written assessment you keep whether or not you proceed.