How to Conduct an AI Risk Assessment: A Step-by-Step Guide

Answer box

An AI risk assessment inventories the AI systems running inside your organization, classifies them by risk tier, maps the data and decisions flowing through them, identifies control gaps, and quantifies the financial exposure tied to each gap. The output is a risk register, a remediation plan, and an evidence map an auditor can walk through without you in the room.

Run a full assessment annually, and a targeted one after any high-risk system change — a new model in production, a new agent with tool access, a vendor swap, or a material change to training data. Anything less and the register goes stale inside a quarter.

Here are the seven steps we walk through in this playbook:

1. Build the AI inventory.
2. Classify each system by risk tier.
3. Map data flows for the high-risk tier.
4. Identify control gaps against a fixed library.
5. Quantify exposure in dollars.
6. Prioritize remediation by score, impact, and ease.
7. Document for auditors.

First pass takes four to eight weeks. Second cycle takes about a third of that — most of the work is inventory, and once discovery is automated you stop rebuilding it.

Before you start — three prerequisites

Skip these and the assessment turns into a months-long swamp. We refuse to start an engagement until all three are in place.

• Name a single owner. One person is accountable for shipping on a date. Not a committee. Not "GRC and security jointly." Co-ownership is non-ownership. Security owns it about 70% of the time, GRC about 25%, and the remaining 5% sits with a dedicated AI governance lead — usually at organizations past 2,000 employees.
• Set the scope explicitly. Org-wide, or one business unit? An org-wide first pass is right when leadership wants a baseline number for the board. A business-unit pass is right when one team (often HR, legal, or customer support) has gone furthest with AI and is creating the most exposure. Don't try both at once.
• Pick a framework anchor. NIST AI RMF or ISO 42001. Pick NIST if you're US-headquartered, sell to the federal government, or already run security against NIST CSF — the vocabulary will rhyme. Pick ISO 42001 if you operate internationally, hold ISO 27001, or your buyers are asking for AI certification specifically. EU AI Act compliance layers on top of either; it isn't a substitute. If you're subject to both, anchor on ISO and crosswalk to NIST.

The seven-step process

Step 1: Build the AI inventory

Every assessment lives or dies here. If the inventory is wrong, every downstream step is wrong. We've seen teams spend six weeks scoring controls against an inventory missing 60% of their actual AI footprint — pure wasted motion.

The surfaces are the same every time:

• Browser — ChatGPT, Claude, Gemini, Copilot tabs in employee browsers, plus AI features embedded in SaaS.
• SaaS — every vendor in your stack shipped AI features in the last 18 months. Half didn't tell you. Pull SSO logs and your vendor list; assume each has an AI surface until proven otherwise.
• Network — calls to model provider APIs from application servers, batch jobs, and developer machines.
• Endpoint — locally installed AI tools, IDE extensions, desktop assistants, on-device models.
• MCP servers — the connectors that give models access to internal systems. Highest-leverage and least-inventoried surface in most environments.
• Agents — anything autonomous: scheduled, triggered, or looping with tool access.

Do not run this as a one-time spreadsheet exercise. Self-reported inventories miss roughly half of what's deployed — employees don't volunteer shadow tools and developers forget scripts they wrote six months ago. Use continuous discovery (network telemetry, browser telemetry, SaaS posture, IdP logs) and treat the spreadsheet as a derived artifact.

Step 2: Classify by risk tier

Don't bother with step 2 until step 1 is genuinely complete. Tiering an incomplete inventory produces a confident-looking artifact that's wrong.

The cleanest taxonomy is EU AI Act Annex III. Use it even if you're not subject to the EU AI Act — the categories are well-defined, defensible, and your auditor will recognize them. Map each system to one of:

• Prohibited — social scoring, manipulative systems, real-time biometric ID in public spaces. Should be zero; if not, stop and fix that first.
• High-risk — employment (resume screening, performance scoring), essential services (credit, insurance, benefits), critical infrastructure, education evaluation, law enforcement.
• Limited-risk — user-facing systems that aren't making consequential decisions (chatbots, summarizers, drafters).
• Minimal-risk — internal productivity tools with no decision authority (spam filters, autocomplete).

Two examples we hit constantly: HR resume screening that ranks candidates is high-risk. A meeting transcription tool that produces a summary is limited-risk. The distinction is whether the output drives a decision about a person.

About 40% of organizations try to classify everything as high-risk on the first pass. That's analysis paralysis dressed up as caution. The high-risk bucket is where you concentrate effort; inflating it dilutes attention.

Step 3: Map data flows

For every high-risk system (and only those), diagram three things:

1. What goes in. Data categories, sources, sensitivity classification, regulated flags (PII, PHI, payment, IP).
2. Where it lives during processing. Which model, provider, region; retention; training-data usage; what logs exist.
3. Who or what receives the output. Human reviewer, downstream system, customer, regulator. And — critically for agents — what tools the system can call, and what data those tools touch.

Diagram it, don't prose it. Swim-lanes work fine; what matters is that someone can trace a record end-to-end without asking questions. The "model + tool + data" decomposition is the part most teams skip — they map the model and stop. For agents, the tool surface is where the risk actually concentrates.

Step 4: Identify control gaps

Score each high-risk system against a fixed control library. We use a 20-control library; the exact contents matter less than picking one and applying it consistently. Representative controls we score every time:

• Inline inspection — can you see prompts and responses in real time, or only after the fact?
• Kill switches — can you stop a specific agent, model, or vendor without taking the stack down? How fast?
• Audit trail — every prompt, response, and tool invocation logged with the identity that triggered it.
• A2A signing — when one agent calls another, is the call signed and verifiable?
• Data egress controls — can you block regulated data from reaching an unapproved vendor?
• Identity binding — every agent action traces back to a human identity.

Score each control 0–4: 0 = not in place, 1 = ad hoc, 2 = documented, 3 = enforced, 4 = continuously monitored. Most organizations land around a 1.4 average on their first pass. That's the baseline; the assessment exists to move it. The AI Governance Maturity Assessment walks through the full library.

Step 5: Quantify exposure

For each gap, estimate annualized loss expectancy: probability × impact, in dollars. Boards think in dollars, not Likert scores.

Don't try to be actuarial. Order-of-magnitude is enough — is this a $50k, $500k, or $5M problem? The AccuroAI Risk Calculator handles the math; the harder part is sourcing probability estimates. We recommend a quick internal Delphi with three security engineers rather than chasing external benchmarks that don't exist yet for AI-specific incidents.

Most teams conflate likelihood with severity here. A high-severity, low-likelihood event (training data leak) and a low-severity, high-likelihood event (employees pasting confidential text into a public chatbot) are managed differently. Keep the two axes separate.

Step 6: Prioritize remediation

Rank every gap by score × impact × ease of fix. The "ease of fix" multiplier is what most teams omit, and it's why their assessments stall.

The instinct is to start with the highest-impact gaps. Wrong for cycle one. Fix the easy wins first — the ones you can close in two weeks — to build momentum and show the board a measurable delta. Save the hardest gaps for cycle two, when you have institutional buy-in. Roughly 60% of organizations get this wrong the first time; a register that goes from 47 open gaps to 31 in a quarter buys the political capital to attack the hard ones.

Step 7: Document for auditors

The deliverable is three artifacts:

• Risk register — one row per system, columns for tier, data classification, gaps identified, ALE, owner, target close date.
• Remediation plan — gaps in priority order, with owner, milestone, and evidence required to close.
• Evidence map — each control scored, mapped to NIST AI RMF (GOVERN, MAP, MEASURE, MANAGE), ISO 42001 §6.1.2, and EU AI Act Annex III articles. The unified compliance crosswalk handles the mapping mechanically.

An auditor should be able to pick any system, ask "what controls are in place and where is the evidence?" and get an answer in under five minutes. If that round-trip takes longer, the evidence map needs work.

Common mistakes to avoid

• Relying on self-reports for inventory. Employees don't tell you about shadow tools; developers forget. Use telemetry.
• Classifying everything as high-risk. Analysis paralysis. Use Annex III honestly.
• Conflating likelihood with severity. A 1% chance of a $10M loss is not the same as a 90% chance of $100k.
• Skipping the model + tool + data decomposition. The model is the obvious surface. The tools the agent can call are the real one.
• Not assigning a single owner per system. Every row needs a name, not a team.
• Treating the assessment as a one-time project. It's a cycle, not a deliverable.

Cadence — how often to re-run

Put this in the program charter so nobody has to ask later:

• Annually — full org-wide assessment, all tiers, complete control library, fresh risk register.
• Quarterly — focused reassessment of every high-risk system. Re-score, refresh ALE, update remediation.
• Ad hoc — within 30 days of any major model upgrade, new agent deployment, vendor change, or material training-data change. Within 7 days if the change touches a high-risk system.

The quarterly cycle is what separates programs that improve from programs that get audited once a year and forgotten. Put it on the calendar before the first pass ships.

Tools and templates

We maintain a kit you can lift directly into your program — the templates we wish we'd had on our first assessment:

• AI Agent Risk Calculator — quantify ALE per system. Use it in step 5.
• AI Governance Maturity Assessment — score your program against the 20-control library. Use it in step 4.
• AI Incident Tabletop Kit — rehearse the response so the kill switches actually work when you need them.
• Vendor Security Questionnaire — 50 questions for the third-party piece of the inventory.
• AI Governance Committee Reference — who sits on the committee, what they own, how often they meet.

FAQ

Who should run the assessment? A cross-functional team — security, GRC, legal, data, and at least one rep from the business unit deploying AI heaviest. Security owns the deliverable. Legal owns regulatory mapping. The business unit owns context. Don't run it out of GRC alone; you'll miss the technical surfaces. Don't run it out of security alone; you'll miss the legal exposure.

How long does the first one take? Four to eight weeks for an organization between 500 and 5,000 employees. Inventory and classification eat about half the time. Subsequent cycles run in two to three weeks because the discovery pipeline is already in place.

Can we outsource it? Parts. Discovery and inventory are commodity work and fine for an external partner with the right tooling. Classification can be outsourced if the partner understands your business. Control gap assessment should stay internal — the gaps are tightly coupled to how your organization actually operates, and an outsider produces a generic register. The risk register itself stays in your hands.

What if we pick NIST and later switch to ISO 42001? The inventory ports cleanly. The risk register ports cleanly. Control scores get re-mapped — a one-week exercise, not a re-do. This is why we run both mappings in parallel from day one, even when anchored on one.

How does this integrate with our existing GRC program? It doesn't replace anything. The AI risk register feeds into the enterprise risk register as a category, the same way third-party or cyber risk does. ISO 31000 is the general frame; AI risk is one stream inside it.

What's the difference from a SOC 2 audit? Different scope and cadence. SOC 2 examines defined trust criteria against your controls at a point in time, conducted by an external auditor for a customer-facing report. An AI risk assessment is internal, broader in scope (covers exposure and remediation, not just control existence), and runs on a cadence you set. SOC 2 evidence can feed into your AI assessment; the inverse isn't true.