there are five questions, we send them before we design anything, and the answers change the architecture rather than decorating it. Here they are, with a real client's answers, so you can send them to your own vendor before they send you a proposal.

Most security questionnaires arrive too late. They turn up after the scope is agreed, from someone who was not in the sales conversation, and they ask forty questions of which six matter. By then the architecture is drawn and everyone is negotiating rather than designing.

We flipped it. We ask first.

What should we ask an AI vendor?

These five, in this order. The order matters, because each answer narrows the next.

  1. Data residency. Does client data have to stay onshore or in-country?
  2. External tools. Can any client data touch third-party or public AI services, or must everything be self-hosted and closed-loop?
  3. Storage and retention. Can the system cache or store data at any point, or must nothing persist beyond processing?
  4. Access controls. Who is permitted to see what, and are there role-based restrictions?
  5. Certifications and obligations. Any certifications, or regulator and client contractual obligations, that the architecture has to satisfy?

Five questions. If a vendor cannot answer all five about their own proposed build, they have not designed it yet, and you have learned something valuable for the price of an email.

What does a good answer look like?

This is a real set of answers from a business whose inputs are sensitive client measurement data. We have kept their wording.

 

Question Their answer What it changed
Data residency, onshore? "Yes" Rules out any default region. The build is pinned to Australian infrastructure from the first line, and cross-region failover is turned off deliberately.
External or public AI services? "Self-hosted. Inputs are sensitive client data which must not be exposed to public use" Rules out the convenient path. Changes the cost model, and we say so before quoting rather than after.
Storage and retention? "Either or. Storage would be reasonable, as long as it's privately hosted and on-shore" Caching is allowed, which materially improved both speed and cost. Worth asking rather than assuming the strict answer.
Access controls? "Depends on data type. Would be helpful to allow for changes to access over time as required. It would also be helpful for external teams to access selected data for their own purposes, without the ability to manipulate it, like an API" Surfaced the real requirement, which is read-only external access. That is a feature with a cost, and it would have been missed entirely.
Certifications and obligations? "Data privacy policies and internal AI usage guidance are the main ones. Otherwise, requirements for internal data structure for the Regulator and auditors would come into the design of specific outputs" The regulator shapes the output format, not just the security posture. Found in week one instead of month four.

Look at answer four. Nobody asked for "role-based access control". They asked for external teams to be able to read selected data without changing it. That is a read-only API, it is a feature with a cost and a design, and it surfaced because the question was open rather than a checkbox.

That is the whole argument for asking early. A questionnaire finds problems. A conversation finds requirements.

And look at answer three, which is the one that saves money. We expected "nothing persists". The real answer allowed caching, which made the system faster and cheaper than the version we would have built on an assumption.

Which standards apply in Australia?

In the order an Australian buyer actually meets them, which is not the order the internet will give you.

The Voluntary AI Safety Standard

Published by the National AI Centre in September 2024. Ten guardrails covering accountability and governance, risk management, data governance and security, testing, human oversight, user transparency, contestability, supply chain transparency and record keeping.

It is voluntary, it creates no new legal duty, and it is closely aligned to the mandatory guardrails proposed for high-risk settings. Read it as a preview of what you will eventually be required to demonstrate. It is also the most useful single document to hand a board that is asking what "responsible AI" means in practice.

The Essential Eight

If your security team runs anything, it runs this. Use it as the home for AI controls rather than starting a parallel framework, because a parallel framework is a document that gets maintained for one quarter.

ASD's AI guidance

The Australian Signals Directorate published Engaging with Artificial Intelligence, written explicitly for medium to large organisations, and its own advice is to apply it alongside the Essential Eight. There is a companion piece on deploying AI systems securely and a third on AI supply chain risks.

The OAIC's AI guidance

Two guides published in October 2024, including one on commercially available AI products with a selection checklist attached. This is the one your privacy officer will hand you, so read it before they do.

Add to that the two obligations that bite: APP 11 on securing personal information, and the Notifiable Data Breaches scheme, which gives you 30 days to assess a suspected eligible breach.

If you are APRA-regulated

CPS 234 and CPS 230 are the two that decide whether the build clears risk. CPS 230 commenced 1 July 2025 and may put your AI vendor on a material service provider register that goes to APRA, which changes the conversation from "are they good" to "can we document them".

NIST goes last

The NIST AI Risk Management Framework is American, it is genuinely good, and you will be asked for it when your buyer answers to an overseas parent. That is the honest reason it is on the list. It should not be the first thing an Australian vendor reaches for, and if it is the only framework they can name, ask what they know about the Australian ones.

 

Want our answers in writing?

Our hosting, data residency, subprocessors, breach notification and data deletion positions are all published rather than sent on request.

Read the Trust Centre

 

Who inside our business signs it off?

Three seats, and confusing them is why these reviews stall for six weeks.

 

Seat Signs off Why them
Whoever owns risk Residency, retention, the breach path They carry the consequence and usually already run the Essential Eight
Whoever owns the data Access controls The only person who knows which fields are actually sensitive
Whoever owns the outcome The trade-off "Self-hosted and closed-loop" is a real answer with a real price, and somebody has to accept it

The failure mode is asking one person all three. They will answer the first confidently, guess the second, and defer the third, and the project stalls in a place nobody can see.

The eight questions to ask about the vendor, not the build

The five questions above are about the system. These are about who is building it, and they are the ones that determine whether you can leave.

  • Does the deliverable IP assign to us, and at what moment?
  • Are prompts, evaluation sets and tool definitions inside that assignment?
  • Whose account holds the production API key, and can we rotate it without you?
  • On termination, how many days until our data is deleted, and will you confirm in writing?
  • Are the models accessed under zero-retention terms with keys scoped to us?
  • What is in the handover pack, listed, today?
  • What is your professional indemnity and cyber cover, in numbers?
  • What happens to the system if you go out of business?

For context on what good answers look like there, including our own, we wrote the whole thing up in who owns the AI system after we leave.

Frequently asked

Is a SOC 2 report relevant in Australia?
It is useful evidence and it is not an Australian framework. Plenty of Australian buyers ask for it because their procurement template came from somewhere else. If you are choosing what to invest in as a vendor, the Australian standards above will serve more of your buyers.

What if the vendor is small and has no certifications?
Most good Australian AI shops are small and uncertified right now, because the certifications are new and the market is young. Judge them on whether they can answer the five questions precisely, whether they volunteer their gaps, and whether their contract says what they say it says.

Should we require the data never leaves Australia?
Only if your obligations or your customers require it, because it constrains your options and raises your cost. Decide it deliberately rather than as a default reflex, and write down the reason.

How long should this review take?
If the five questions go out before scope, a fortnight. If they go out after, six weeks and a renegotiation.

Can we reuse our existing vendor security questionnaire?
Send it as well, by all means. It will cover the infrastructure questions competently and it will almost certainly miss retention, model access and what happens when the model is wrong, because it was written for software that does not make judgements.

What if we are the vendor and a buyer sends us forty questions?
Answer the six that matter, tell them which those are and why, and publish the rest so you never answer them twice. That is what a trust centre is for.

Where to go from here

Copy the five questions. Send them to whoever is proposing to build you an AI system. Ask for the answers in writing before scope is signed rather than after.

Our own testing approach, which is what question three turns into once you are building, is how we test an AI agent before it goes near a customer. The residency detail behind question one is in where your data actually goes when Claude reads your CRM. And what happens after go-live is the failure nobody builds for.

 

Talk to us

Or start with a free AI audit to see what you already have running.

One last thought. The most useful question on the list is number three, and it is the one nobody asks, because everybody assumes the answer is no. In this case the client said storage was fine as long as it stayed onshore and private, which made the whole system faster and cheaper.

Assumed constraints cost more than real ones. What are you assuming?

Sources