AI Implementation Security Requirements Guide

AI implementation security requirements: the 14 questions every review asks

An AI security review asks fourteen questions covering data flow, provider terms, access, hosting, logging and incident response. Most stall because answers are scattered across people. Written answers to all fourteen, prepared before the first meeting, remove most of the delay.

Your IT team is not trying to block the project. They are trying to avoid being the person who approved a system nobody can explain later. The NIST AI Risk Management Framework frames the same concern as govern, map, measure and manage, and a good AI vendor security questionnaire follows that logic in practical terms.

The fourteen questions, each with the evidence that closes it:

1. What data enters the system? Close it with a data inventory by field.
2. What leaves your network? Close it with a data flow diagram.
3. Which model providers are used? Close it with a named provider and model list.
4. Is data retained by the provider? Close it with the provider terms and your retention setting.
5. Is data used for training? Close it with the contract clause and proof of opt-out.
6. Who can access production data? Close it with named roles and an access policy.
7. Is access time-boxed? Close it with expiry rules and a ticket trail.
8. Are actions logged? Close it with a sample audit log.
9. Where is data hosted? Close it with region and account details.
10. How is data encrypted? Close it with transit and at-rest settings.
11. How are prompt injection and misuse handled? Close it with a threat model and test results.
12. What happens in an incident? Close it with a response plan and notification window.
13. What happens when the contract ends? Close it with a deletion procedure and confirmation.
14. Which subprocessors are involved? Close it with a subprocessor list.

Which questions stall deals most often?

Questions 2, 5 and 14 cause the most delay in our experience, because the honest answer depends on a third party. A vendor can describe its own controls confidently but cannot speak for a model provider without reading that provider's terms.

Questions 11 and 13 come next. Teams rarely have a written answer on prompt injection, and almost nobody has a documented deletion procedure for embeddings and logs. Settle those two early, because reviewers who spot a gap there start asking harder questions about everything else.

What data leaves your network, and what doesn't?

State the answer as a diagram: every system the data touches, in order, with the boundary of your network drawn on it. A reviewer should see in one glance which fields reach a model provider and which stay inside.

In our experience, most AI projects send far less than people fear, but only if the design is deliberate. A retrieval-based system keeps the document store inside your boundary and sends only the retrieved passages plus the question to the model.

Structured fields such as account numbers or national IDs can be masked or replaced with tokens before the call, then restored in the response.

The honest caveat is that masking has limits. It protects identifiers, but free text can still contain sensitive detail that no pattern catches. For that reason we classify data by source, not by guesswork about content.

What about prompts, embeddings and logs?

Reviewers often forget that derived data is still your data. Prompts, retrieved passages, embeddings and application logs can each reconstruct sensitive content, so each needs a retention rule and an owner.

A common gap is the vector database.

Embeddings are not designed to be reversed, but published work such as Text Embeddings Reveal (Almost) As Much As Text shows that much of the original text can be recovered from them in some settings. Treat them with the same classification as the source documents. Log the prompt and response metadata you need for debugging, and decide deliberately whether raw content is logged at all. This is the heart of LLM data security for an enterprise: the model call is one hop among many.

AI implementation security requirements for model providers: retention and training opt-out

Ask each provider three things in writing: how long prompts and outputs are retained, whether they are used for training, and who can read them. Business and API plans from major providers generally answer no to training, but the contract controls.

The published terms are specific, and each link below supports only the provider named beside it. OpenAI describes its position on business data and training. Anthropic's commercial terms cover API customers. Amazon's documentation on Bedrock data protection addresses whether inputs are used to train models or shared with model providers. Microsoft's Azure OpenAI data privacy page covers its service.

These are our paraphrases of pages that change. Read the current wording yourself, and confirm it applies to the plan tier you are buying.

Retention is the subtler question. Providers may keep prompts for a short window for abuse monitoring unless you qualify for zero-retention arrangements. Put the setting you have, not the setting you wish for, in the questionnaire.

How do you verify the provider's claims?

Do not paste marketing copy into a questionnaire. Link the contract clause or the documentation page, record the date you read it, and note the plan tier it applies to.

Terms change. Add a quarterly check to the vendor register so that a retention change at a provider does not reach production unnoticed.

Where a client requires it, route calls through a cloud platform they already trust, so the provider relationship sits inside a contract their security team has already approved. That can shorten the review, because the reviewer is assessing an agreement they already know.

Access controls: least privilege, time-boxed, audited

Engineers should hold no standing access to client production data. Access is granted per task, to named people, for a fixed window, and every session is logged. If a reviewer cannot read a sample log, the control does not exist.

Least privilege here has three layers. People get the narrowest role that completes the task. Services get scoped credentials, so an agent that reads tickets cannot also write to billing. Credentials expire automatically, and rotation is not left to memory.

What does time-boxed access look like in practice?

A support engineer needs to debug a failed workflow. They raise a ticket naming the system and the reason, a client approver signs it off, and access is issued for a set number of hours.

When the window closes, access is revoked without anyone remembering to do it. The ticket, the approval and the session log then form one trail.

This costs some speed on urgent fixes, and we say so openly: break-glass access exists, but it triggers a review afterwards. In our experience, reviewers respond better to a process that names its friction than to one that claims there is none.

Hosting and data residency: where does your data rest?

Hosting is a per-project decision made with the client: their cloud account, ours, or a managed platform in a named region. Whichever applies, the questionnaire states the region, the account owner and the encryption settings.

Residency has two halves. If your data must stay in a particular jurisdiction, the question is not only where it rests but where engineers can reach it from. Ask any vendor which locations their staff work from, and how access from those locations is limited, logged and approved.

Our default position is to keep data in the client's chosen region and to avoid copying production data to developer machines. Where residency rules are strict, we work against synthetic or masked data outside the boundary and touch real data only inside it, through the time-boxed, logged access described above.

Can the system run inside our own cloud account?

Yes, and for regulated clients it is often the cleanest answer. Deploying into your account means your logging, key management and network controls apply, and your team can revoke our access with one policy change.

The trade-off is operational weight. You carry the cost of the infrastructure, and your team must be able to patch and monitor it, or agree a managed arrangement with us. Our AI integration and DevOps consulting work usually starts with this decision, because it shapes every later answer.

Our answers to a standard vendor questionnaire

We keep a completed standard questionnaire ready, so a reviewer can read our answers before booking a call. It follows the fourteen questions above and carries the same evidence links.

Preparing it in advance was a deliberate choice. We have filled in a great many of these forms for clients. Most of the answers do not change between projects, so a reusable version saves both sides time.

You can request the full answers through our contact form, and learn more about the team behind them on the about Viithiisys page. The questionnaire is the document that does the heavy lifting in a review.

What does the questionnaire contain?

It answers each of the fourteen questions with a short statement and a link to the supporting policy or log sample. It also lists the sub-processors we use and the model providers we have worked with.

Where a question depends on the project, such as the hosting region, the answer states that it is agreed at scoping. If your team sends its own form, we map our standard answers onto it and flag anything project-specific for discussion, rather than returning a generic document.

How do you get IT to yes in one meeting, not six?

Send the questionnaire, the data flow diagram and the provider terms at least two days before the meeting. Use the meeting to resolve disagreements, not to collect basic facts. Bring the person who can actually answer.

Six-meeting reviews happen when each meeting produces new questions that nobody can answer on the spot. The fix is preparation. Name an owner for each of the fourteen questions, and make sure the engineer who built the integration is in the room, not only a salesperson.

Be ready to say no to some things. If a requirement is unreasonable for the architecture, say what would meet its intent instead. Reviewers respond better to a clear alternative than to silent compliance that is later found to be partial.

What should the one meeting cover?

Walk the data flow diagram first, because every other answer hangs off it. Then cover provider terms, access and hosting, and finish with incident response and exit.

Record decisions and open actions in writing that day.

If your team lacks senior engineering capacity to run this, our fractional CTO service puts an experienced lead in the review.

Once you agree the controls, our LLM development team can build to them.

If you are unsure where an AI project fits your existing processes before you start the review, our broken workflow assessment maps that out first.

If you would rather talk first, use our contact form.