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

An AI risk assessment is the document that tells your organization exactly where AI creates risk and what to do about it. Without one, governance decisions are based on assumptions instead of evidence. Auditors ask for the risk assessment first because it demonstrates that you understand your AI risk landscape before you start building controls. Organizations that skip the assessment end up either over-governing low-risk tools (wasting resources) or under-governing high-risk tools (creating exposure).

This guide is for compliance officers, risk managers, CISOs, and IT leaders who need to conduct a formal AI risk assessment. By the end, you will have a complete, auditor-ready risk register covering every AI tool in your organization with risk scores, control requirements, and a review schedule. You need access to your organization's IT systems for tool discovery and at least one stakeholder from IT security who can assess data sensitivity classifications.

For context on how the risk assessment fits into a broader governance program, see our AI risk management framework. For the compliance framework that builds on this assessment, see our AI compliance framework guide.

Before You Start

Complete these preparations before beginning the risk assessment:

• Scope definition: Decide whether this assessment covers all AI tools organization-wide or a specific business unit. Organization-wide is recommended for the first assessment because auditors expect complete coverage.
• Data classification scheme: Your organization should already have a data classification scheme (public, internal, confidential, regulated). If not, work with IT security to define one before starting. The risk assessment depends on consistent data classification.
• Stakeholder availability: You will need input from IT security (data sensitivity), business unit leaders (decision impact), and legal (regulatory requirements). Schedule their time in advance.
• Time estimate: The full process takes 5-9 business days manually, or 3-5 days with PolicyGuard. The largest variable is tool inventory completeness, which depends on how well your organization tracks IT assets.

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

Step 1: Build a Complete AI Tool Inventory

The AI tool inventory is the raw data that feeds every subsequent step. An incomplete inventory means an incomplete risk assessment, which means unidentified risks and uncontrolled tools. This step requires going beyond what IT knows about and discovering the AI tools employees have adopted on their own. Shadow AI, meaning AI tools used without IT knowledge or approval, represents the highest risk category precisely because no one is monitoring how data flows through those tools.

Gather data from four sources. First, IT procurement and licensing records for tools that were formally purchased and approved. Second, SSO and identity provider logs that show which AI-related applications employees authenticate into. Third, network traffic analysis or DNS logs that reveal connections to AI service domains like openai.com, anthropic.com, midjourney.com, and dozens of smaller AI vendors. Fourth, a department-level survey asking team leads to report AI tools their teams use, including free tools, browser extensions, plugins, and AI features within existing platforms. For each tool, record: tool name, vendor, primary function, department or team using it, approximate number of users, types of data processed, whether it was formally approved, and the contract or terms of service status.

You will need access to IT procurement records, SSO or identity provider admin console, network monitoring or DNS logs, and a survey tool for department outreach. PolicyGuard automates discovery through continuous shadow AI detection that identifies new tools within hours of first employee use. This step is done when you have a comprehensive spreadsheet or database listing every AI tool with the eight data points listed above. The most common mistake is accepting the IT procurement list as complete. That list typically represents only 20-30% of actual AI tool usage because it misses free tools, browser extensions, and individually adopted cloud services.

Step 2: Classify Each Tool by Data Sensitivity and Decision Impact

Classification creates a structured way to differentiate between tools that pose serious risk and tools that pose minimal risk. Without classification, you either treat every tool the same (which wastes resources on low-risk tools) or rely on gut feelings about which tools are dangerous (which misses risks that are not obvious). The two-axis classification model, using data sensitivity on one axis and decision impact on the other, is what auditors expect because it separates data risk from operational risk.

For data sensitivity, assign each tool a rating based on the most sensitive category of data it processes: Level 1 (Public) for tools that only process publicly available data with no confidential input; Level 2 (Internal) for tools that process internal business data like meeting notes, project plans, and non-sensitive communications; Level 3 (Confidential) for tools that process trade secrets, financial projections, competitive intelligence, or employee personal data; Level 4 (Regulated) for tools that process data subject to specific regulations like HIPAA, GDPR, PCI DSS, or SOX. For decision impact, assign each tool a rating based on the significance of decisions it influences: Low for tools used for convenience with no meaningful decision impact; Medium for tools that inform business decisions but with human review; High for tools that directly influence decisions affecting customers, employees, finances, or legal obligations. Multiply the two ratings to create a composite risk score, or use a matrix to assign each combination to a risk tier.

You will need the completed tool inventory from Step 1, input from IT security on data classification for each tool, and input from business unit leaders on decision impact. This step is done when every tool in the inventory has both a data sensitivity rating and a decision impact rating, with documented justification for each. The most common mistake is classifying based on the tool's intended use rather than its actual use. A tool marketed for internal brainstorming might actually be used to process customer data if employees paste customer information into it. Classify based on what employees actually do, not what the tool was designed for.

Step 3: Identify Top 3 Risks Per Tool

Identifying specific risks per tool moves the assessment from abstract classification to concrete threats. Classification tells you which tools need the most attention. Risk identification tells you exactly what can go wrong with each tool and what the consequences are. Auditors expect to see specific, documented risks for each high and medium-risk tool, not generic risk statements that could apply to any technology. This specificity is what makes the assessment actionable for the teams responsible for managing those risks.

For each tool classified as medium or high risk in Step 2, identify the top three risks using this framework. First, consider data exposure risks: what happens if data entered into the tool is leaked, accessed by unauthorized parties, or used to train the vendor's models? Second, consider output reliability risks: what happens if the tool produces incorrect, biased, or misleading outputs that influence decisions? Third, consider dependency and availability risks: what happens if the tool becomes unavailable, changes its terms of service, or discontinues a feature your organization relies on? For each identified risk, document: a specific risk description (not generic), the potential business impact if the risk materializes, the affected stakeholders, and any existing controls that partially mitigate the risk. For low-risk tools, document a brief risk summary without requiring the full three-risk analysis.

You will need the classified tool inventory from Step 2, input from tool users on how they actually use each tool, and input from IT security on data flow and vulnerability analysis. This step is done when every medium and high-risk tool has three documented risks with impact descriptions and affected stakeholders identified. The most common mistake is writing generic risks like "data breach" that apply to every tool. Each risk should be specific enough that a reader understands the unique threat that particular tool creates in your specific environment.

Step 4: Rate Likelihood and Impact Using a Risk Matrix

The risk matrix converts qualitative risk descriptions into quantitative scores that enable prioritization. Without scoring, you have a list of risks but no way to determine which ones demand immediate action and which ones can be addressed later. The matrix also provides a consistent methodology that auditors can verify and that produces comparable scores across different assessors. This consistency is critical when multiple people contribute to the assessment or when comparing risk levels across different assessments over time.

Build a 5x5 risk matrix with likelihood on one axis (Rare, Unlikely, Possible, Likely, Almost Certain) and impact on the other axis (Negligible, Minor, Moderate, Major, Severe). Define each level with specific criteria relevant to your organization. For likelihood: Rare means less than 5% chance within 12 months; Unlikely means 5-20%; Possible means 20-50%; Likely means 50-80%; Almost Certain means above 80%. For impact: Negligible means no financial loss and no regulatory consequence; Minor means under $10,000 financial impact and no regulatory consequence; Moderate means $10,000-$100,000 impact or a minor regulatory finding; Major means $100,000-$1M impact or a significant regulatory violation; Severe means over $1M impact or a critical regulatory violation with enforcement action. Score each risk identified in Step 3 by plotting it on the matrix. The cell where likelihood meets impact gives you the risk score. Group scores into three action categories: Accept (low scores), Mitigate (medium scores), and Remediate Immediately (high scores).

You will need the risk list from Step 3, the risk matrix template, and input from stakeholders to calibrate likelihood and impact ratings. This step is done when every identified risk has a likelihood rating, an impact rating, and a composite score plotted on the matrix with an assigned action category. The most common mistake is rating all risks as high likelihood and high impact to be conservative. This eliminates the prioritization value of the matrix because everything scores the same. Use the defined criteria for each level and accept that some risks genuinely are low likelihood or low impact.

Step 5: Determine Control Requirements

Controls are the specific actions, policies, or technologies that reduce risk to an acceptable level. Without defined controls, the risk assessment identifies problems but does not solve them. Auditors look for a clear mapping between identified risks and the controls that address them because this demonstrates that governance is operational, not just documentary. Each control should directly address one or more specific risks, and each high-risk finding should have at least one control assigned.

For each risk in the Mitigate or Remediate Immediately category from Step 4, define one or more controls from these categories. Preventive controls stop the risk from occurring: access restrictions, data loss prevention rules, tool blocking, mandatory approval workflows, and input validation. Detective controls identify when a risk event occurs: monitoring, logging, anomaly detection, periodic reviews, and usage audits. Corrective controls reduce impact after a risk event: incident response procedures, data breach notification processes, backup and recovery procedures, and vendor communication protocols. For each control, document: control description, control type (preventive, detective, or corrective), responsible owner, implementation timeline, and how effectiveness will be measured. Map every Remediate Immediately risk to at least one preventive control and one detective control. Map every Mitigate risk to at least one control of any type.

You will need the scored risk list from Step 4, input from IT security on available technical controls, and input from compliance on procedural controls already in place. This step is done when every medium and high-risk finding has at least one mapped control with an assigned owner and implementation timeline. The most common mistake is defining controls without assigning ownership. A control without an owner is a control that never gets implemented. Every control needs a specific person who is accountable for implementation and ongoing effectiveness.

Step 6: Document the Assessment and Schedule Review

Documentation transforms your working analysis into a formal audit artifact. Without proper documentation, the work you did in Steps 1 through 5 exists only in spreadsheets and notes that an auditor cannot efficiently review. The documented assessment should tell a complete story: what tools exist, what risks they create, how severe those risks are, and what controls are in place to manage them. The review schedule ensures the assessment stays current as your AI landscape changes, which is the specific evidence of ongoing governance that auditors seek.

Create a formal risk assessment document with these sections: Executive Summary (one page summarizing the scope, methodology, key findings, and top risks), Methodology (the classification scheme, risk matrix, and scoring criteria used), AI Tool Inventory (the complete inventory from Step 1), Risk Classification Results (the data sensitivity and decision impact classifications from Step 2), Risk Register (every identified risk from Steps 3 and 4 with descriptions, scores, and action categories), Control Requirements (the control mapping from Step 5 with owners and timelines), and Review Schedule (the next review date and triggers for out-of-cycle reviews). Set the next review date for no later than 12 months from completion. Define out-of-cycle review triggers: adoption of a new high-risk AI tool, a regulatory change affecting AI governance, an AI-related incident at your organization, or a significant change in the number of AI tools in use.

You will need a document template or assessment management platform, all working data from Steps 1 through 5, and executive sponsor review for the final document. PolicyGuard generates assessment documentation automatically from your tool inventory and risk classifications. This step is done when the formal assessment document is complete, approved by your executive sponsor, stored in your document management system, and the review date is calendared with assigned ownership. The most common mistake is documenting the assessment but not scheduling the review. Auditors specifically check for evidence of scheduled reviews because a risk assessment without a review date signals that governance is a one-time activity rather than an ongoing program.

Common Mistakes When Conducting an AI Risk Assessment

• Treating the tool inventory as complete after one round. The first inventory attempt typically captures 30-50% of actual AI tools in use. Shadow AI tools adopted by individual employees or teams are invisible without technical discovery methods. The cost is an assessment that misses the highest-risk tools. Avoid this by combining survey data with SSO logs, network logs, and continuous monitoring.
• Using generic risk descriptions. Risks described as "data breach" or "compliance violation" without specifics are useless for prioritization and control design. The cost is controls that do not address the actual threat. Avoid this by writing risk descriptions specific to each tool and your organization's context.
• Skipping the review schedule. An assessment without a review date becomes stale within months as employees adopt new AI tools and regulations change. The cost is an audit finding for lack of ongoing governance and a risk register that does not reflect reality. Avoid this by setting the review date as part of the documentation step and assigning a specific owner for the review.
• Classifying tools based on vendor marketing instead of actual usage. A tool marketed for internal brainstorming might be used to process customer data. Classification based on marketing materials underestimates the true risk. The cost is inadequate controls for tools that handle sensitive data. Avoid this by interviewing actual users and reviewing data flow logs.

How Long This Takes

Frequently Asked Questions

How often should we update the AI risk assessment?

At minimum annually, with out-of-cycle updates triggered by significant changes. Significant changes include adopting a new AI tool that processes regulated data, a regulatory change affecting AI governance requirements, an AI-related incident at your organization or a peer, or a material increase in the number of AI tools in use. Many organizations review quarterly during the first year of their governance program and then shift to annual reviews once the AI landscape stabilizes.

Do we need to assess AI features embedded in existing software?

Yes. AI features within Microsoft 365 Copilot, Salesforce Einstein, Notion AI, and similar tools process the same sensitive data as standalone AI tools. Embedded AI features often fly under the radar because organizations think of them as part of existing approved software. However, these features may send data to external AI models, generate outputs that influence decisions, and create risks that did not exist before the AI feature was added. Assess them like any other AI tool.

What is the minimum documentation an auditor expects from an AI risk assessment?

At minimum, auditors expect: a complete AI tool inventory with risk classifications, a risk register with likelihood and impact scores for each identified risk, evidence of a defined methodology (the risk matrix and scoring criteria), control mappings showing how each significant risk is addressed, and a scheduled review date. Missing any of these components typically results in an audit finding. The more mature your documentation, the smoother the audit process.

Can we use our existing IT risk assessment process for AI risks?

Partially. Your existing risk assessment methodology (risk matrix, scoring criteria, documentation standards) can be reused. However, AI-specific risks require additional assessment dimensions that traditional IT risk assessments do not cover: model output reliability, training data bias, vendor model training practices, and the distinction between AI tools that process data versus AI tools that make or influence decisions. Extend your existing process with these AI-specific dimensions rather than replacing it entirely.

Who should sign off on the final AI risk assessment?

The risk assessment should be reviewed and approved by at least three roles: the CISO or IT security leader (for data and technology risks), the compliance officer or risk manager (for regulatory and governance risks), and an executive sponsor at VP level or above (for organizational accountability). Some organizations also include legal review when the assessment covers AI tools that process regulated data or AI tools used in regulated industries like healthcare or financial services.