AI Risk in the Risk Register and Control Taxonomies

1. Why This Topic Matters

Artificial intelligence does not create risk in a vacuum. Every AI system an organization deploys, buys, or embeds into a vendor product generates exposures that must be seen, measured, owned, and treated alongside every other enterprise risk. The mechanism by which organizations do this is the enterprise risk register and the control taxonomy that maps treatments to those risks. If AI risk lives only in a data science team's slide deck, it is invisible to the board, the audit committee, and the regulators who increasingly expect evidence that AI is governed with the same discipline as financial, operational, and cyber risk.

For the ISACA Advanced in AI Risk (AAIR) exam, this topic sits inside the domain of AI Risk Governance and Framework Integration. The examiners want to know whether you can take a novel category of risk and integrate it into the structures the organization already uses, rather than inventing a parallel universe of AI-only governance that nobody reconciles. Integration is the recurring theme: AI risk should extend and enrich existing registers and taxonomies, not fragment them.

Practically, this matters because:
• Boards and executives make resource and risk-appetite decisions based on the aggregated register. If AI risk is missing or mis-scored, decisions are made on incomplete information.
• Regulators (EU AI Act, sectoral supervisors, privacy authorities) expect demonstrable, documented risk management for AI systems, including classification, controls, and residual-risk acceptance.
• Auditors test whether controls exist and operate. Without a taxonomy that links AI risks to specific controls, there is nothing to test and no way to prove assurance.
• AI risks interact with other risks: a biased model is simultaneously a compliance, reputational, and operational risk. Only a unified register exposes these dependencies.

2. What Is a Risk Register and What Is a Control Taxonomy?

The risk register is the organization's authoritative, structured inventory of identified risks. Each entry typically records: a unique identifier, a description of the risk event and its cause, the risk category, the business process or asset affected, inherent likelihood and impact, the risk owner, existing controls, residual likelihood and impact, the treatment decision (mitigate, transfer, avoid, accept), key risk indicators (KRIs), and review dates. It is a living document that feeds risk reporting, risk appetite monitoring, and audit planning.

A control taxonomy is a structured classification scheme for controls. It groups controls by domain (for example, access management, data governance, change management, monitoring), by type (preventive, detective, corrective), by nature (administrative, technical, physical), and often by the framework they originate from. Well-known taxonomies and control catalogs include ISO/IEC 27001 Annex A, the NIST Cybersecurity Framework functions and categories, COBIT governance and management objectives, and, specifically for AI, the NIST AI Risk Management Framework (Govern, Map, Measure, Manage), ISO/IEC 42001 Annex A AI controls, and ISO/IEC 23894 guidance on AI risk management.

The relationship between the two is fundamental: the register tells you what could go wrong; the taxonomy tells you what you are doing about it and lets you prove it. A risk entry without mapped controls is unmanaged. A control without a linked risk is unjustified overhead.

3. What Makes AI Risk Different Inside the Register

AI risk fits the register structure but strains several of its assumptions. Candidates should understand these distinctions because exam questions frequently test whether you recognize that traditional entries need adaptation.

New risk categories. AI introduces risk types that legacy registers rarely contain: algorithmic bias and discrimination, lack of explainability and transparency, model drift and performance decay, hallucination and factual unreliability in generative systems, adversarial attacks (prompt injection, data poisoning, model extraction, evasion), training-data provenance and intellectual property exposure, over-reliance and automation bias in human users, and misalignment between model behavior and intended purpose.

Different assets. The register must reference AI-specific assets: models, training and validation datasets, prompts and system instructions, feature pipelines, vector stores, foundation-model APIs from third parties, and the AI inventory itself. Many organizations maintain an AI system inventory that becomes the asset backbone for register entries.

Dynamic risk profiles. Traditional risks change slowly. AI risks change as data shifts, models are retrained, vendors update foundation models, and use cases expand. Register entries therefore require more frequent review cycles and KRIs tied to live monitoring (accuracy, fairness metrics, drift scores, incident rates).

Probabilistic and emergent behavior. Likelihood estimates for AI harms are harder to defend because outputs are non-deterministic and failure modes may be unknown until deployment. Registers must accommodate uncertainty explicitly, sometimes using qualitative confidence ratings alongside scores.

Multi-dimensional impact. AI harm extends beyond financial and operational loss to individuals (rights, safety, dignity), society (misinformation, discrimination at scale), and the environment (compute energy). Impact scales may need new dimensions or explicit ethical and human-rights criteria.

Shared and third-party exposure. Most organizations consume AI from vendors. The register must capture supply-chain risk where the organization has limited visibility into training data, model changes, and controls, and must document reliance on vendor attestations.

4. How It Works: Integrating AI Risk Into the Register

Step 1: Establish or extend the taxonomy of AI risk categories. Before populating the register, governance must agree on how AI risks will be classified. Good practice is to extend the existing enterprise risk taxonomy with an AI layer rather than create a separate scheme. For example, under the existing category of Compliance Risk, add sub-categories for AI regulatory non-compliance and algorithmic discrimination; under Operational Risk, add model failure and drift; under Information Security, add adversarial machine learning. Aligning these sub-categories to the NIST AI RMF trustworthiness characteristics (valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, fair with harmful bias managed) gives a defensible, recognized structure.

Step 2: Identify AI risks through the AI inventory and use-case assessment. Each AI system in the inventory undergoes a risk assessment (often an AI impact assessment or algorithmic impact assessment) that considers intended purpose, affected stakeholders, data sensitivity, autonomy level, and regulatory classification. The outputs become candidate register entries. Risk identification should also draw on threat modeling, red-teaming, incident history, and external sources such as the MIT AI Risk Repository or OWASP Top 10 for LLM Applications.

Step 3: Write register entries with AI-aware fields. A mature AI risk entry includes, beyond the standard fields: the AI system identifier and inventory reference, the lifecycle stage (design, development, validation, deployment, monitoring, retirement), the regulatory risk tier (for example, high-risk under the EU AI Act), the affected stakeholder groups including external individuals, the trustworthiness characteristic impaired, the model or data component at fault, and the monitoring metric and threshold that serves as the KRI. Risk descriptions should follow a cause-event-consequence structure, for instance: Because training data under-represents a demographic group (cause), the credit model may systematically assign lower scores to that group (event), resulting in discriminatory outcomes, regulatory penalties, and reputational damage (consequence).

Step 4: Assess inherent and residual risk. Apply the enterprise scoring methodology but adapt impact criteria to include harm to individuals and societal effects. Where likelihood is highly uncertain, document assumptions and confidence. Scoring consistency across AI and non-AI risks is essential so that aggregation and prioritization remain meaningful at the enterprise level.

Step 5: Assign ownership. AI risk ownership must sit with an accountable business owner of the AI system's outcome, not solely with data scientists or IT. The register should also record control owners, which may differ (for example, the data governance team owns data-quality controls while the business owns human-oversight controls). Clear ownership satisfies the Govern function of the NIST AI RMF and the leadership requirements of ISO/IEC 42001.

Step 6: Map controls using the control taxonomy. For each AI risk, link existing and new controls. Where possible, reuse enterprise controls (access management, change management, vendor due diligence, logging) and extend them to AI assets. Add AI-specific controls where gaps exist: bias testing before release, fairness monitoring in production, model documentation (model cards, datasheets), human-in-the-loop review for high-impact decisions, prompt-injection filtering, output monitoring, model versioning and rollback, data lineage and provenance records, adversarial robustness testing, and explainability tooling. Classify each control as preventive, detective, or corrective and record its design and operating effectiveness.

Step 7: Decide on treatment and record acceptance. If residual risk exceeds appetite, define additional treatment with timelines. If the organization accepts residual risk, the acceptance must be documented and approved at the appropriate authority level. For high-risk AI, acceptance typically requires senior or committee-level sign-off.

Step 8: Monitor, report, and review. Connect KRIs to automated model-monitoring pipelines where possible so drift, accuracy decay, or fairness degradation trigger register review. Report AI risk within the enterprise risk dashboard, with roll-ups by category, system, and regulatory tier. Schedule reviews aligned to model retraining, vendor model updates, and regulatory changes, not just the annual cycle.

5. Common Taxonomies and How They Map

NIST AI RMF organizes activities into Govern, Map, Measure, and Manage. The Map function supports risk identification for the register; Measure supports scoring and KRIs; Manage supports treatment and control mapping; Govern supports ownership, policy, and accountability. Its Playbook offers suggested actions that can serve as control statements.

ISO/IEC 42001 is a certifiable AI management system standard. Its Annex A lists controls across areas such as AI policies, internal organization, resources for AI systems, impact assessment, AI system lifecycle, data for AI systems, information for interested parties, use of AI systems, and third-party relationships. Annex B provides implementation guidance. These controls map naturally into an enterprise control taxonomy as a dedicated AI domain or as extensions to existing domains.

ISO/IEC 23894 adapts ISO 31000 risk management principles to AI, giving guidance on integrating AI risk into existing risk processes, which is precisely the register-integration philosophy the AAIR exam emphasizes.

ISO/IEC 27001 and NIST CSF remain relevant because many AI risks are security risks. Adversarial attacks, data leakage through prompts, and unauthorized model access map onto existing security control domains, which should be extended to cover AI assets rather than duplicated.

COBIT supports the governance layer: aligning AI risk with enterprise goals, defining roles via RACI-style accountability, and ensuring the risk register feeds performance and conformance monitoring.

A crucial principle: use crosswalks. A single AI control such as bias testing may satisfy a NIST AI RMF Measure subcategory, an ISO/IEC 42001 Annex A control, and an EU AI Act Article requirement simultaneously. Recording these mappings in the taxonomy reduces audit effort and proves compliance efficiently.

6. Common Pitfalls

• Creating a standalone AI risk register disconnected from the enterprise register, leading to inconsistent scoring and invisible aggregation.
• Treating AI as a single risk line item rather than decomposing it by system and failure mode.
• Assigning ownership to technical teams who cannot make business trade-off decisions.
• Using impact scales that ignore harm to individuals and society.
• Failing to link KRIs to live monitoring, so register entries go stale between annual reviews.
• Mapping controls that exist on paper but have never been tested for operating effectiveness.
• Ignoring third-party AI embedded in SaaS tools because it was never procured as AI.
• Omitting lifecycle stage, so pre-deployment risks are confused with production risks.

7. Exam Tips: Answering Questions on AI Risk in the Risk Register and Control Taxonomies

Tip 1: Favor integration over separation. When a question asks how to treat AI risk relative to existing governance, the ISACA-preferred answer almost always involves integrating AI risk into the existing enterprise risk register and extending the existing control taxonomy, rather than building a separate, parallel structure. Distractors often describe an isolated AI risk framework managed by the data science team.

Tip 2: Identify the BEST or MOST appropriate answer, not a merely correct one. ISACA questions commonly present several plausible actions. Ask which action addresses root cause and governance accountability. For example, when a model shows drift, documenting the incident is correct but updating the register entry, reassessing residual risk, and notifying the risk owner is the more complete governance response.

Tip 3: Remember what belongs in a register entry. If a question describes a register entry missing something, look for the absent element: risk owner, inherent versus residual scoring, linked controls, KRI, treatment decision, or review date. For AI specifically, look for missing AI system identifier, lifecycle stage, regulatory tier, affected stakeholders, or trustworthiness characteristic.

Tip 4: Ownership questions have a pattern. The accountable risk owner is the business executive responsible for the outcome the AI system produces. Technical teams are control owners or implementers. The board and risk committee oversee and approve risk appetite and high-risk acceptance. Second-line risk functions facilitate and challenge; they do not own the risk.

Tip 5: Know the control types. Expect questions asking you to classify a control. Bias testing before release is preventive. Fairness monitoring in production is detective. Model rollback after a failure is corrective. Human-in-the-loop review can be preventive (before action) or detective (after output) depending on placement; read the scenario carefully.

Tip 6: Recognize framework roles. If a question references identifying context and stakeholders, think NIST AI RMF Map. If it references metrics and testing, think Measure. If it references treatment and controls, think Manage. If it references policy, culture, and accountability, think Govern. For certifiable management-system controls, think ISO/IEC 42001 Annex A. For aligning AI with ISO 31000 processes, think ISO/IEC 23894.

Tip 7: Residual risk and appetite drive decisions. Questions about whether to proceed with deployment hinge on whether residual risk is within appetite after controls. If it is not, the answer is additional treatment or escalation for formal acceptance at an appropriate level, never silent acceptance by the project team.

Tip 8: Watch for third-party AI. Scenarios involving vendor models test whether you recognize that the organization still owns the risk and must register it, obtain assurance (contracts, attestations, testing), and map compensating controls where vendor transparency is limited.

Tip 9: Dynamic monitoring beats periodic review. If options contrast an annual register review with KRIs tied to continuous model monitoring, the latter reflects AI risk best practice because AI risk profiles change with data and retraining.

Tip 10: Eliminate distractors that skip governance steps. Options that jump directly to a technical fix without updating the register, reassessing risk, or informing the owner are usually wrong in a governance-domain question, even if the technical fix itself is sensible.

Tip 11: Read for the lifecycle stage. Pre-deployment scenarios call for impact assessment, classification, and preventive controls. Production scenarios call for monitoring, KRIs, incident response, and corrective controls. Retirement scenarios call for data disposal, model decommissioning, and register closure.

Tip 12: Think like an auditor. The exam often asks what provides the best evidence or assurance. Answers involving documented mappings between risks and tested controls, approved risk acceptances, and traceable KRIs are stronger than answers relying on policies alone or verbal assurances.

8. Quick Review Summary

• The risk register is the authoritative inventory of risks; the control taxonomy classifies the controls that treat them; AI risk must be integrated into both.
• AI introduces new categories (bias, explainability, drift, adversarial attack, hallucination, provenance), new assets (models, data, prompts, vendor APIs), and more dynamic profiles.
• Register entries for AI should add system identifier, lifecycle stage, regulatory tier, affected stakeholders, trustworthiness characteristic, and monitoring-based KRIs.
• Ownership sits with the accountable business owner; controls are mapped to owners and classified as preventive, detective, or corrective.
• Key frameworks: NIST AI RMF (Govern, Map, Measure, Manage), ISO/IEC 42001 Annex A, ISO/IEC 23894, plus extensions of ISO/IEC 27001, NIST CSF, and COBIT.
• Use crosswalks so one control satisfies multiple frameworks and regulations.
• On the exam, choose integration, accountability, complete governance steps, residual-risk-versus-appetite logic, and continuous monitoring.