Home › Blog › AI tool security checklist

A security checklist for adopting AI tools in a company

Security review for AI tools is hard not because there are many items but because the questions differ from ordinary SaaS. Training use, prompt retention and onward sub-processing to a model provider are not on the existing checklist.

4 areas Vendor questions Korean requirements

The short answer

Reuse your SaaS security review unchanged and you will miss the three things that matter most: whether what you type is used for training, how long prompts and outputs are retained, and whether the tool sub-processes to another model provider.

The items below are written as questions you can send verbatim. Getting the answers in writing is the point — a sales rep saying it on a call is not a contract term.

Area 1 — Data handling

Training use — Is what we input used to train or improve models? If the default is yes, confirm how to turn it off and that the off state is written into the contract.

Retention — How long are prompts and outputs kept? You need a specific answer such as "30 days for incident response", plus the turnaround on a deletion request.

Storage location — Which countries is data stored in? For a regulated sector or a contract that requires domestic storage, this single item decides adoption outright.

Sub-processing — Does this tool call another model provider — an external LLM API? If so you need that provider’s training and retention terms too. This is where reviews most often break down.

Deletion and export — Can we get evidence of deletion at contract end? And can we export our own data out?

Area 2 — Access control

Authentication — Are SSO and multi-factor supported, and from which plan? Security features living only on the top tier is common.

Permission separation — Can access be scoped per user and per team? For any tool that indexes documents, confirm permissions apply at retrieval, not after.

Audit log — Is there a record of who submitted what, and can we query it? Without this log the blast radius of an incident cannot be established.

Deprovisioning — Can a leaver be cut off immediately? With SSO in place this happens automatically.

Area 3 — Contract and regulation

Processing agreement — If personal data is involved, confirm the processing agreement and the cross-border transfer notice requirements. Overseas storage adds steps.

Generative AI disclosure — Check whether the AI Framework Act disclosure obligation reaches your service, and whether this tool’s output goes to customers. Internal-only use has a different scope.

Certifications — Which of ISMS-P, ISO 27001 or SOC 2 do you hold? Ask for the certificate and its validity dates.

Breach notification — Within how many hours are we notified of a breach? What matters is whether a number appears in the contract.

Liability — What is the liability cap for a data leak? It is usually pegged to monthly fees, which is far from the real exposure.

Area 4 — Internal operations

Approving the tool is not the end. In practice, incidents come from approved tools used wrongly. So a usage policy has to come with the review: what data may go in, and what is prohibited.

Two failure modes dominate. Company documents processed through an unapproved personal account — shadow AI — and customer data pasted in with the identifying fields intact. Neither is stopped by a vendor security review.

Alongside the review, prepare three things: the list of approved tools, a definition of which data classes may be entered, and what happens on a violation. A list without the data-class definitions pushes the judgement onto individuals.

Frequently asked questions

Do we need a review just to trial the free plan?

Free plans are riskier, not safer. Training use is often on by default and controls like SSO and audit logs are absent. For a trial, use a sample with identifying fields removed rather than real company data.

The vendor will not answer in writing.

That is itself a finding. A tool whose data terms cannot be fixed in writing leaves you with nothing to stand on after an incident. If it passes at all, it should pass only on condition that its use is limited to non-sensitive data.

Different teams are already using several tools.

Build the list first — expense records and SSO logs will surface most of it. A policy written without the list diverges from reality, and then nobody follows it.

Does on-premise or a self-hosted model solve everything?

It solves data egress. Access control, audit logging and the usage policy all remain, and build plus run cost rises sharply — so check first whether your data sensitivity justifies that cost.

Check before adopting

Start with organisational readiness

The AX readiness assessment scores the technology and organisation axes together, showing which one a missing security process actually belongs to.

Check readiness