Publishing the questions costs us the advantage of asking them cold. That trade is the whole argument.
See the questions beforethe call.
Most vendor security questionnaires arrive from the buyer and are answered by a sales engineer. This one runs the other way: it is our instrument, we walk it with you during discovery, and it is published here in summary so your security owner can read every question before sitting down with us. Nothing in it is a trick, and two of its disclosures are ones most vendors would keep until after signature.
A client-facing instrument that captures what your deployment must do, surfaces the tradeoffs honestly, and ends in a configuration rather than a document. It never assumes a requirement without asking.
01
When it happens. During discovery, the first phase of every engagement, in the same working session as the assessment. Not after a contract, and not as homework sent afterwards.
02
Who it is written for. The IT director, the CTO and the security reviewer, in plain language. If a question needs a definition, the definition sits next to it rather than in an appendix nobody opens.
03
What it produces. A resolved posture: the typed object that drives your infrastructure, renders the plan page you see inside the product, and feeds the machine-readable export. All three read the same value, so they cannot drift apart.
What it is not
It is not an audit, not a contract, and not a substitute for your own program. It captures technical posture, so it says nothing about your organizational controls, your audit scope, your choice of auditor, or application-level security review. Those remain yours, and the deployment is necessary rather than sufficient for any compliance objective you hold. See compliance alignment.
Three jobs, honestly named.
QUESTIONNAIRE · 02
An instrument like this is usually a sales artifact pretending to be a technical one. This one does three jobs, and all three are named here.
01
Qualification.
It surfaces what prompted the evaluation and who holds the veto, early enough to matter. It also surfaces the cases where we are the wrong answer: a requirement the chosen region cannot support, or a control you need that we do not have. Finding that in discovery is cheaper for you than finding it in month three.
For both sidesDiscovery
02
A trust artifact.
Asking a buyer in writing, before any sale, whether they understand that we hold no third-party attestation is the strongest version of the glass-box claim we can make. The same is true of the residency disclosure. A vendor who publishes the questions it will ask has less room to manage the answer.
WrittenBefore signature
03
Configuration input.
The answers become your deployment's committed posture configuration, not a summary of a conversation. Any override carries a written reason, and it shows up as a standing exception on your plan page inside the product, where you can read it whenever you like rather than when we remember to mention it.
Drives the buildVisible in product
The seven sections.
QUESTIONNAIRE · 03
What each section establishes, then the questions themselves. These are representative rather than exhaustive: the instrument carries more, and none of it is harder than what is here.
Section
What it establishes
What it drives
1. Context and current AI landscape
What you do, how many people, what is already in use and what prompted this
Scope, first capabilities
2. Data residency
Storage, processing and inference as three separate questions, with the tradeoff disclosed
Region, routing, the pin
3. Security controls
Encryption, identity and multi-factor, audit logging, retention, network
Most of the posture tier
4. Operational requirements
Availability and recovery expectations, hosting shape, change management, administrators
Topology, approval rules
5. Compliance program
What you hold, what your own customers ask you for, what you expect from us
Evidence pack, disclosures
6. Posture recommendation
The tier the answers map to, and every override with its written reason
The resolved posture
7. Posture commitment
Your approval of that posture as the deployment's configuration
The build, and the evidence
Sections 1 to 4 are captured below; 5 to 7 in the next section. Terms used in the questions are defined in the glossary.
1. Context and current AI landscape
01
What your organization does, in your own words, and how many people would actually use the deployment.
02
Do you already hold a cloud account for this, or does one need to be opened in your name?
03
What AI tools are your people using today, sanctioned or not, including personal subscriptions and browser tabs?
04
What prompted this evaluation? A rollout that disappointed, a pilot that stalled in production, a review that blocked a tool because the data flow could not be scoped, or a new initiative.
05
What are the first uses you have in mind, and who feels the delay today?
2. Data residency
06
Is residency required for storage? Documents, the index, conversation history, logs. Required, preferred, or no preference.
07
Is residency required for the application's own processing, as distinct from storage and from inference?
08
Is residency required for model inference? This is the question with a price attached, and the disclosure below is read before it is answered.
09
Having read the disclosure, which posture do you select: pinned, with no cross-border routing; flexible, accepting cross-border routing for current-generation models with the disclosure recorded; or unconstrained.
10
If pinned: are the previous-generation in-region models acceptable as your primary conversational model, or does that need evaluating first?
11
If flexible: has your legal or compliance function accepted cross-border routing in writing, and has a transfer ever been blocked or questioned before?
3. Security controls
12
Do you require customer-managed encryption keys, and is there a data classification that drives that requirement?
13
Do you require multi-factor authentication for everyone, for administrators only, or not at all? What do people sign in with today?
14
Do you require our management access to be scoped and session-capped? At the Baseline posture no cross-account role for us exists at all.
15
Do you require account-level audit logging, and how long must logs be retained: 90 days, one year, seven years, or something else?
16
Do you require network flow logging, validated cryptographic endpoints, or private connectivity from your own network? Connectivity into your own office network is scoped per engagement and is not part of the standard deployment.
4. Operational requirements
17
What availability do you need, and what are your recovery expectations for data and for service? We record these as requirements, and we publish no response-time or uptime commitment.
18
How should the front end be hosted: managed hosting, which is simpler and cheaper, or inside a private network, which the higher postures require?
19
What change management do you expect? Pull requests with approvals, a manual approval step, or no formal process today.
20
Who administers the deployment on your side, and is there more than one? A single-administrator deployment can self-approve a promotion with a written justification, recorded as exactly that, and we never call it segregation of duties.
One answer that is already settled
Model invocation logging is not one of the choices. It runs at every deployment, and it deliberately carries no prompt or answer text: model, caller identity, latency, token counts. So the question a reviewer should ask here is what the record is used for, and the answer is metering settlement and evidence. Administration.
Recommendation and commitment.
QUESTIONNAIRE · 04
The last three sections turn answers into a configuration. This is where an override stops being a conversation and becomes a recorded exception with your name on it and ours.
5. Compliance program
21
Does your organization hold any certifications today, and are you pursuing one?
22
Do your own customers send you security documentation requests, and in which format?
23
What compliance documentation do you expect from us? Controls mapping, architecture diagrams, completed questionnaires, test results.
24
Do you acknowledge that org.tech holds no third-party attestation? Understood, or needs more context. This one is answered in writing.
6. Posture recommendation
25
Which tier do the answers map to? No residency requirement and the simplest path maps to Baseline. Audit logging, managed keys or enforced multi-factor map to Standard. A residency pin and session-capped access map to Strict.
26
Which individual controls are overridden, in which direction, and with what value?
27
What is the reason for each override, and who approved it? Name and date, recorded verbatim.
28
Does the override require a disclosure, and what exactly does that disclosure say?
7. Posture commitment
29
Do you approve the resolved posture as your deployment's configuration? It is committed to your own infrastructure repository.
30
The deployment reads it. The same object activates the controls, so the configuration is not a description of the build, it is an input to it.
31
Verification after deployment confirms that the deployed state matches the committed posture, and the plan page inside the product renders it back to you with its standing exceptions.
32
Any later change needs a new answer or an explicit override request with a documented reason. Posture does not drift quietly.
The disclosures.
QUESTIONNAIRE · 05
Two of these you acknowledge in writing before anything is built. They are the reason the instrument exists in this form, and they are the two things a competitor would leave until after signature.
Disclosure one · attestation
org.tech provides technical controls designed to align with SOC 2 Trust Services Criteria and ISO/IEC 27001. We hold no third-party attestation, of either type. The deployment supports your compliance program; it does not replace your own organizational controls or, where you need one, your own audit engagement. A SOC 2 report is issued by an independent audit firm, and no vendor can hand you one. Compliance alignment.
Disclosure two · residency costs capability
Pinning inference to Canada limits which models you can use, and we put the numbers in front of you before you choose. Every current frontier model routes outside Canada. The in-region generation set is previous-generation: Claude 3 Sonnet and Haiku, Llama 3 8B and 70B, Mistral Large 24.02, Mixtral 8x7B and Mistral 7B. Sound for retrieval, summarising and classification; materially weaker on reasoning, long context and tool use. A second, OpenAI-compatible model plane has no Canadian region at all, so a pinned deployment cannot serve it under any posture. Data residency.
104models
Catalogue · 5 Sep 2026
13
In-region · in Canada
1
Routed · within Canada only
72
Served · US and global
The remaining 18 are reachable but processed outside Canada. The catalogue is generated from the provider's live model list by a script and classified by where inference actually runs, so these figures are read from the product rather than typed into copy.
Disclosure three · every downgrade is visible
Any control set below the recommended tier's default carries a written reason in the posture, and that reason becomes a standing exception rendered to you inside the product, on the same page as your resolved controls. We would rather you read what we have not closed than discover it. Evidence pack.
How to get the whole thing.
QUESTIONNAIRE · 06
There is no download form on this page, and there is no gated version with better content. The full instrument is walked with you in the assessment, because half its value is in the conversation each question starts.