AI Risk Identification Techniques and Taxonomies

1. Why This Topic Matters

Risk identification is the foundation of every risk management activity that follows. If an AI risk is never identified, it is never assessed, never treated, never monitored and never reported to the board. In the ISACA Advanced in AI Risk (AAIR) body of knowledge, AI Risk Identification Techniques and Taxonomies sits inside the AI Risk Program Management domain because a mature program must be able to discover risks systematically and repeatably, not just when an incident occurs.

AI systems introduce risks that traditional IT risk practices often miss: training-data bias, model drift, hallucination, prompt injection, model inversion, lack of explainability, emergent behaviour, over-reliance by users, and regulatory exposure (for example EU AI Act risk tiers). Because these risks span data science, cybersecurity, legal, ethics and business operations, the organization needs structured techniques to surface them and shared taxonomies to name and categorize them consistently. Without a taxonomy, two teams may describe the same risk with different words, creating gaps and duplication in the risk register and making aggregation and reporting to leadership almost impossible.

For the exam, this topic is heavily tested because ISACA wants candidates to demonstrate that they can select the most appropriate technique for a given situation, apply recognized frameworks, and keep identification distinct from assessment and response.

2. What It Is

AI risk identification is the process of discovering, recognizing and documenting risks that could prevent an AI system (or the AI program as a whole) from achieving its objectives, or that could cause harm to individuals, the organization or society. The output is normally a set of risk scenarios recorded in an AI risk register, linked to the AI system inventory and the organization's risk universe.

An AI risk taxonomy is a structured classification scheme that organizes AI risks into categories and sub-categories. Taxonomies provide a common language, promote completeness (acting as a checklist against blind spots), enable aggregation and trend analysis, and support mapping to controls, regulations and standards.

Key terms you must be able to distinguish:
• Threat – a potential cause of an unwanted event (e.g., a malicious actor crafting adversarial inputs).
• Vulnerability – a weakness that can be exploited (e.g., an unvalidated prompt interface).
• Risk – the effect of uncertainty on objectives, usually expressed as likelihood and impact of a scenario.
• Risk scenario – a narrative describing actor, threat type, event, asset/resource, time and consequence (ISACA Risk IT / COBIT style).
• Risk universe – the full set of risk areas within scope of the program.
• Inherent risk – risk before controls; residual risk – risk after controls. Identification generally captures inherent risk scenarios first.

3. Common AI Risk Identification Techniques

a) Facilitated techniques (people-driven)
• Brainstorming and risk workshops – cross-functional sessions (data scientists, product owners, security, legal, ethics, affected business users). Best for broad discovery early in the lifecycle.
• Structured interviews and surveys – useful when stakeholders are dispersed or when sensitive topics (e.g., ethical concerns) need confidential input.
• Delphi technique – iterative, anonymous expert consensus; good for novel AI risks with little historical data.
• Pre-mortem analysis – imagine the AI project has failed and work backward to identify causes; effective against optimism bias.

b) Analytical and structured techniques
• Checklists and taxonomy-based review – walk through a recognized taxonomy (NIST AI RMF, ISO/IEC 23894, OWASP Top 10 for LLM Applications) to ensure coverage. Strength: completeness; weakness: may miss novel risks outside the list.
• Scenario analysis – build plausible stories of how harm could occur (e.g., model drift causing credit decisions to become discriminatory over time).
• Failure Mode and Effects Analysis (FMEA) – systematically list ways each component (data pipeline, model, API, human-in-the-loop) can fail, with effects and causes.
• Fault tree analysis (top-down from an undesired outcome) and event tree analysis (bottom-up from an initiating event).
• Bow-tie analysis – links causes, the central risk event, and consequences, showing where preventive and mitigating controls sit.
• Cause-and-effect (Ishikawa) diagrams – group causes by category such as data, model, people, process, technology, environment.

c) AI- and security-specific techniques
• Threat modeling – STRIDE adapted for ML, or MITRE ATLAS (Adversarial Threat Landscape for AI Systems) to enumerate adversarial tactics such as data poisoning, evasion, model extraction and prompt injection.
• AI red teaming and adversarial testing – deliberately attack or stress the model to reveal unknown weaknesses, jailbreaks, harmful outputs or bias. Primarily a discovery technique for risks that cannot be found on paper.
• Data lineage and data quality review – trace provenance, consent, representativeness and labelling quality to identify data-sourced risks.
• Review of model documentation – model cards, datasheets for datasets, system cards and impact assessments often reveal limitations and intended-use boundaries.
• Algorithmic impact assessments (AIA), fundamental rights impact assessments and DPIAs – structured assessments that surface risks to individuals and society, often required by regulation.
• Incident and near-miss analysis – internal incident logs plus external sources such as the AI Incident Database, vendor advisories and regulatory enforcement actions.
• Third-party and supply-chain review – vendor questionnaires, contract review and SBOM/AI-BOM analysis to identify risks from foundation models, APIs, open-source libraries and training data suppliers.
• Monitoring and telemetry analysis – performance, drift, fairness and usage metrics in production surface risks that emerge after deployment.

4. Common AI Risk Taxonomies and Classification Schemes

No single taxonomy is mandatory; a mature program typically adopts or tailors one and maps others to it. Be familiar with the following:

• NIST AI RMF (AI 100-1) – organizes risk around the seven characteristics of trustworthy AI: valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; fair with harmful bias managed. Its functions are Govern, Map, Measure, Manage – and Map is the function most associated with identification and context setting. The Generative AI Profile (NIST AI 600-1) adds GenAI-specific risk categories (e.g., confabulation, information integrity, harmful content, data privacy, intellectual property, environmental impact).
• ISO/IEC 23894 – AI risk management guidance built on ISO 31000; it lists AI-related objectives and risk sources (e.g., level of automation, lack of transparency, complexity of environment, system hardware issues, technology readiness).
• ISO/IEC 42001 – AI management system; requires AI risk assessment and AI system impact assessment, encouraging organizations to define their own classification criteria.
• EU AI Act risk tiers – unacceptable (prohibited), high-risk, limited risk (transparency obligations), minimal risk; plus general-purpose AI model obligations. This is a regulatory classification that drives which obligations apply.
• OWASP Top 10 for LLM Applications – prompt injection, insecure output handling, training data poisoning, model denial of service, supply chain vulnerabilities, sensitive information disclosure, insecure plugin design, excessive agency, overreliance, model theft.
• MITRE ATLAS – adversary tactics and techniques against ML systems, analogous to ATT&CK.
• ISACA / COBIT / Risk IT lens – IT risk categories (strategic, operational/delivery, benefit realization), risk scenario components, and the practice of linking AI risk to enterprise risk management (ERM).

Common organizing dimensions used in enterprise taxonomies:
• By source – data risks, model/algorithm risks, infrastructure risks, human/usage risks, process/governance risks, third-party risks.
• By lifecycle stage – problem definition, data collection and preparation, model development, validation, deployment, operation and monitoring, retirement.
• By harm or impact – harm to individuals (discrimination, privacy, safety), to the organization (financial, legal, reputational, operational), to society (misinformation, environmental, democratic processes).
• By trustworthiness property – fairness, transparency, robustness, security, privacy, accountability, safety.

5. How It Works in Practice (Process View)

1. Establish context and scope – define objectives, risk appetite, regulatory environment, and which AI systems and use cases are in scope.
2. Build or refresh the AI system inventory – you cannot identify risks for systems you do not know exist (including shadow AI and embedded AI in vendor products).
3. Select the taxonomy – adopt or tailor a framework-aligned taxonomy approved by governance; ensure it maps to the enterprise risk taxonomy for aggregation.
4. Choose techniques based on context – early lifecycle: workshops, pre-mortems, impact assessments; development: FMEA, threat modeling, documentation review; pre-deployment: red teaming, adversarial testing; operation: monitoring and incident analysis. Use a combination; no single technique is sufficient.
5. Engage the right stakeholders – cross-functional participation plus, where appropriate, affected communities or end users.
6. Develop risk scenarios – document actor, event, asset, cause, consequence and lifecycle stage; classify each using the taxonomy.
7. Record in the AI risk register – assign a risk owner, link to the system inventory, controls and regulatory obligations.
8. Validate and iterate – review with risk owners, update after significant changes (new data, model retraining, new use case, new regulation, incidents). Identification is continuous, not one-time.
9. Hand off to assessment – likelihood and impact analysis, prioritization and treatment follow identification; keep them distinct phases.

6. Common Pitfalls

• Treating AI risk purely as cybersecurity risk and ignoring fairness, transparency and societal harm.
• Relying only on checklists, which miss novel or emergent risks.
• Identifying risks only at project kickoff and never after deployment.
• Excluding business and ethics stakeholders, resulting in technically framed but incomplete risk scenarios.
• Using inconsistent terminology across teams because no taxonomy was formally adopted.
• Confusing a control weakness or an audit finding with a risk scenario.

7. Exam Tips: Answering Questions on AI Risk Identification Techniques and Taxonomies

Tip 1 – Respect the sequence. ISACA tests process order. Identification comes after establishing context, scope and the AI inventory, and before analysis, evaluation and treatment. If a question asks what should be done FIRST before identifying risks, the answer is usually to define scope and objectives or to inventory AI systems. If it asks what to do NEXT after identification, the answer is to assess (analyze and evaluate), not to implement controls.

Tip 2 – Know the purpose of a taxonomy. When asked for the PRIMARY benefit of a taxonomy, favor answers about consistency, completeness, common language and aggregation/reporting. Taxonomies do not quantify risk, do not eliminate risk and are not a substitute for assessment.

Tip 3 – Match technique to situation.
• Novel technology, little historical data, expert judgement needed → Delphi or scenario analysis.
• Need to find unknown adversarial or harmful behaviours in a deployed or near-deployed model → red teaming / adversarial testing.
• Need systematic component-level failure review → FMEA.
• Need to visualize causes, event and consequences with controls → bow-tie.
• Need to ensure coverage against known risk categories → checklist / framework-based review.
• Need to understand attacker tactics against ML → MITRE ATLAS or threat modeling.
• Risks to individuals and rights → algorithmic impact assessment / DPIA.
• Third-party foundation model → vendor due diligence, documentation (model cards) review, contractual review.

Tip 4 – Prefer comprehensive, cross-functional and iterative answers. When choices include a single technique versus a combination, or a one-time exercise versus ongoing identification, ISACA generally prefers the combined, continuous, multi-stakeholder approach. Watch for words like only, solely, once and exclusively – they usually signal a wrong answer.

Tip 5 – Distinguish threat, vulnerability, risk and control. If a question asks you to identify the risk, do not pick the answer that describes a control failure or an attacker. The risk is the potential adverse effect on objectives (e.g., discriminatory lending decisions causing regulatory penalties), not the data bias itself (cause) nor the missing fairness testing (control gap).

Tip 6 – Framework recognition. Be ready to associate NIST AI RMF Map with context and identification, Measure with assessment, Manage with response and Govern with the overarching program. Associate ISO/IEC 23894 with ISO 31000-based AI risk management, ISO/IEC 42001 with the AI management system, OWASP Top 10 for LLM with application-level GenAI risks, and the EU AI Act with risk-tier classification driving legal obligations.

Tip 7 – The risk register and ownership. Identified AI risks must be documented in a register with an accountable risk owner, typically the business owner of the AI use case rather than the data scientist or the risk function. When a question asks who is BEST placed to own an identified AI risk, lean toward the business or product owner accountable for outcomes.

Tip 8 – Lifecycle thinking. Many questions describe a stage (e.g., model has been in production for a year and performance is degrading). Recognize that operational monitoring, drift detection and incident analysis are identification techniques for post-deployment risks, and that significant changes (retraining, new data, new jurisdiction) should trigger re-identification.

Tip 9 – Read for the qualifier. ISACA questions hinge on BEST, MOST, PRIMARY, FIRST, GREATEST. Several answers may be true; choose the one that most directly fulfils the qualifier and aligns with governance-level thinking (objectives, stakeholders, completeness, consistency) rather than narrow technical detail.

Tip 10 – Eliminate the technical trap. Answers that jump straight to a specific technical fix (e.g., add input filtering, retrain the model) are rarely correct for identification questions. Identification is about discovery and documentation; treatment comes later.

8. Practice Scenarios

Scenario A: An organization is launching its first generative AI chatbot built on a third-party foundation model. Which approach BEST ensures comprehensive identification of risks before go-live?
Best answer: A combination of a cross-functional risk workshop using a recognized taxonomy (e.g., NIST AI RMF GenAI Profile / OWASP LLM Top 10), vendor documentation and contract review, and pre-deployment red teaming. Why: it is multi-technique, multi-stakeholder, framework-aligned and covers third-party risk. A single penetration test or a vendor questionnaire alone would be incomplete.

Scenario B: Two business units describe the same model-drift issue using different terms, and the board report shows it as two unrelated risks. What is the MOST effective corrective action?
Best answer: Adopt and enforce an enterprise AI risk taxonomy with standardized definitions mapped to the ERM taxonomy. Why: the root cause is inconsistent classification, which a taxonomy directly addresses.

Scenario C: A risk practitioner wants to identify risks associated with a new high-stakes AI recruitment tool but there is little historical incident data. Which technique is MOST appropriate?
Best answer: Scenario analysis supported by expert input (Delphi) and an algorithmic impact assessment. Why: these techniques work without historical data and address harm to individuals, which is central for hiring systems.

Scenario D: After identifying 60 AI risk scenarios, what should the practitioner do NEXT?
Best answer: Analyze and evaluate the scenarios (likelihood and impact) to prioritize them. Why: assessment follows identification; selecting controls or reporting residual risk comes later.

9. Key Takeaways

• Identification is the gateway to all downstream risk activity; unidentified risk is unmanaged risk.
• Use multiple complementary techniques, chosen according to lifecycle stage, data availability and type of risk (adversarial, ethical, operational, regulatory).
• Taxonomies deliver consistency, completeness, common language and aggregation; anchor yours to a recognized framework (NIST AI RMF, ISO/IEC 23894, ISO/IEC 42001) and map to ERM.
• Document risks as structured scenarios in a register with clear ownership, and treat identification as continuous.
• In the exam, follow the process order, respect the qualifier words, prefer comprehensive governance-oriented answers, and never confuse identification with assessment or response.