An AI security checklist for small organizations

Run this AI security checklist once a quarter, and again whenever someone adds a new AI tool. It covers 7 areas: inventory, accounts, data, tools and connections, self-hosted software, people, and incidents. If it turns up more problems than you can fix at once, start with anything on the CISA Known Exploited Vulnerabilities list, move to Critical and High severity issues next, and schedule the rest.

What this checklist is for

Most small organizations have no security team. One person looks after the laptops, the accounts and maybe a server, and that person might be you. Meanwhile AI tools arrive with little warning. Someone signs up for a chat assistant. An AI feature switches on inside software you already pay for. A staff member installs a model on a laptop to try it out.

Each item below is a short action with a line on why it matters. Work through the groups in order, because later items depend on knowing what you have. For each item, mark it as done, not applicable or to fix, and write down who owns the fix.

Why AI security matters for a small organization

AI tools mostly bring old risks into new places. Accounts get shared, keys end up in documents, sensitive data gets pasted where it shouldn’t go, and software goes unpatched. What changes is speed and reach. An assistant connected to email, files and payments can act on a lot of data quickly. Self-hosted AI software is often new and changes fast, and it tends to be installed by an enthusiast rather than by whoever patches the servers.

In a small organization, one leaked key or one exposed admin page can be the whole incident. Most of the fixes cost little beyond your time.

The checklist

Inventory

List every AI tool and AI feature in use. For each one, record the owner, the plan (free, paid, team or enterprise) and what it connects to. You cannot secure a tool you don’t know about.
Include AI software installed on servers and laptops. A local model or chat interface running on a spare machine counts. These installs are easy to miss and often get the least maintenance.

A shared spreadsheet is enough. A typical row might read: “Meeting notes assistant, owner: operations lead, paid team plan, connected to calendar and shared drive.”

Accounts and access

Use work accounts only. A personal account leaves with the person who owns it, and you cannot see or control what is in it.
Turn on single sign-on or multi-factor authentication wherever it is offered. Then a stolen password alone won’t open an account that holds your data.
Remove people who leave. Add every AI tool to your offboarding steps so access ends on the person’s last day.
Review admin rights. Keep the list of admins short and check it each quarter.
Store API keys in a password manager or secrets store. Never put an API key in a document, a chat message, a shared code file or a prompt. Anyone who sees a key can often spend your money and reach your data.
Rotate any key that may have leaked. If a key was pasted somewhere it shouldn’t have been, create a new one and revoke the old one. Don’t wait to find out whether someone used it.

Data

Decide your data categories. For example: public, internal and restricted. Restricted might cover donor records, health information, client case files and passwords. People need a rule they can remember.
Keep restricted data out of AI tools unless a tool has been approved for that data.
Turn off training on the plans you use. Many vendors let you stop your inputs from being used to train models. The setting and its default often differ between free and paid plans, so check each plan you use, not each vendor.
Set retention as short as the vendor allows. Data that isn’t kept can’t leak later.

Tools, settings and connections

Connect assistants only to what the task needs. An assistant that drafts email replies doesn’t need access to every shared drive.
Require approval before an assistant sends, deletes or pays. A person should confirm any action that is hard to undo. That limits the damage if the assistant makes a mistake or is misled by content it reads.
Review connected apps regularly. Check which apps and integrations can reach your email, files and calendars, and remove the ones nobody uses.

Self-hosted AI software and patching

This group applies if you run AI software yourself, for example an inference server, a chat interface or an LLM app builder.

Keep it updated. These projects move fast and release security fixes often. Running an old version is an easy way to stay exposed to a problem that already has a fix.
Do not expose admin interfaces to the internet. Keep admin pages reachable only from your internal network or through a VPN.
Put it behind sign-in. Don’t assume authentication is on by default. Check it before anyone else can reach the address.
Follow its security advisories and RSS feed. Subscribe so that news of a fix comes to you. You can also follow advisories by product on this site.

People

Give short training on safe use. A brief session should cover which data can go into which tools, what a suspicious request looks like and who to ask. It does more good than a long document nobody reads.
Adopt an acceptable-use policy. Write down which tools are approved, what they may be used for and which data they may see. The AI acceptable-use policy template gives you wording to adapt.
Give people a way to report mistakes. Someone who pasted the wrong file into a chatbot should be able to say so quickly and without fear. Early reports turn incidents into small fixes.

Incidents and review

Keep an incident card and a log. The card is one page: who to call, how to revoke keys and sessions, and how to cut off a tool’s connections. The log records what happened, when it happened and what you did about it.
Hold a quarterly review. Walk through this checklist again, update the inventory and note what changed. The quarterly review lesson takes you through it step by step.

How to decide what to fix first

Your first pass will probably produce a long to-fix list, especially in the self-hosted group. Two public tools help you sort it: CVSS scores tell you how severe a flaw is, and the CISA KEV catalog tells you whether attackers are already using it.

Severity: CVSS scores

CVSS, the Common Vulnerability Scoring System, is published by FIRST. It rates a vulnerability’s severity with a base score from 0.0 to 10.0, and the v3.1 specification sorts scores into these bands:

Rating	Score range
None	0.0
Low	0.1 to 3.9
Medium	4.0 to 6.9
High	7.0 to 8.9
Critical	9.0 to 10.0

The base score describes the flaw itself. It is usually set by the product’s vendor or by a third party, so it knows nothing about your setup. The specification advises you to add temporal and environmental scores that reflect your own situation. In practice, that means asking a few questions. Is the vulnerable feature turned on? Can someone reach it from the internet? Does it hold restricted data?

The v3.1 specification now sits in FIRST’s archive, and CVSS v4.0 is the current version, so you will see scores from both versions in advisories. For more, see the CVSS glossary entry and how to read a CVSS score.

Known exploitation: the CISA KEV catalog

The US Cybersecurity and Infrastructure Security Agency (CISA) publishes the Known Exploited Vulnerabilities catalog. CISA describes it as the authoritative source of vulnerabilities that have been exploited in the wild, and says organizations should use it as an input when deciding what to patch first.

Each entry lists:

the vendor and product
the CVE id
a short description
the date it was added
a due date
a required action

A high CVSS score tells you a flaw could do serious damage. A KEV listing tells you attackers are already using it. See the CISA KEV glossary entry for more.

A practical order

Anything you run that is on the KEV list. Follow the required action in the entry, which is usually to apply the vendor’s fix.
Critical and High severity issues. Raise their priority further if the affected software is reachable from the internet or handles restricted data.
Everything else, on a schedule. Fold Medium and Low issues into your regular update cycle.

Securaity’s advisories and vulnerability listings show the severity of each issue and mark the ones known to be exploited, so you can match them against your inventory.

How often to run it

Run the full checklist every quarter. Also run it when anyone adds a new AI tool or turns on an AI feature: add the tool to the inventory, then work through the accounts, data, connections and self-hosted items for that tool alone.

Between reviews, keep two habits. Watch the advisories for the products in your inventory, and remove leavers’ access the day they go.

Frequently asked questions

We only use cloud AI tools. Which items apply to us?

Everything except the self-hosted software group. Inventory, accounts, data, connections, people and incidents all still apply, and accounts and data settings matter most for cloud tools. Check your inventory carefully, though, because someone may be running AI software on a laptop without telling you.

What does a CVSS score of 9.8 mean for us?

A score of 9.8 falls in the Critical band, so the flaw itself is very serious. If you don’t run the affected product, it means nothing for you. If you do run it, treat the fix as urgent, check whether the issue is also on the KEV list, and patch first anything that is reachable from the internet.

What is the CISA KEV catalog?

It is a list, published by the US Cybersecurity and Infrastructure Security Agency, of vulnerabilities known to have been exploited in the wild. Each entry names the product and CVE id and gives a short description, a date added, a due date and a required action. Use it to decide what to fix first.

How long does the checklist take?

The first run takes the longest, mostly because building the inventory means asking around and checking settings in each tool. Later quarterly runs are much quicker, since you are updating a list rather than starting from scratch. Running the checklist for a single new tool is usually a short task.