Mapping AI Controls to Existing Taxonomies

Introduction
Within the ISACA Advanced in AI Risk (AAIR) body of knowledge, the domain of AI Risk Program Management emphasizes building a sustainable, repeatable program rather than a series of one-off assessments. One of the most practical skills in this domain is mapping AI controls to existing taxonomies, that is, aligning the safeguards an organization uses for AI systems with established control frameworks, risk categories, and regulatory structures that the enterprise already uses. This guide explains why the topic matters, what it means, how the mapping process works in practice, and how to approach exam questions on it.

Why It Is Important
Organizations rarely start from a blank slate when AI arrives. They already operate under frameworks such as COBIT, ISO/IEC 27001 and 27002, the NIST Cybersecurity Framework, SOC 2 criteria, PCI DSS, HIPAA, SOX, or COSO ERM. If AI controls are designed and tracked in isolation, several problems emerge:
• Duplication and inefficiency: The same control (for example, access management for a model repository) gets tested twice under two different programs.
• Fragmented accountability: Control owners are unclear whether the AI control is theirs or belongs to a separate AI team.
• Blind spots: Truly novel AI risks, such as model drift, prompt injection, hallucination, algorithmic bias, or lack of explainability, may fall between the cracks of traditional frameworks that never anticipated them.
• Regulatory exposure: Emerging requirements such as the EU AI Act, ISO/IEC 42001, and sector-specific model risk guidance (e.g., SR 11-7 in banking) must be demonstrably satisfied, and mapping provides the evidence trail.
• Board-level reporting: Executives and boards understand risk in the language of the existing enterprise risk taxonomy. Mapping lets AI risk be reported consistently alongside cyber, operational, compliance, and strategic risk.
The guiding principle ISACA promotes is integrate, do not isolate. AI risk management should be an extension of enterprise risk management (ERM) and governance, not a parallel universe.

What It Is
A taxonomy is a structured classification scheme. In this context it may refer to a risk taxonomy (how an organization categorizes risks, e.g., strategic, operational, financial, compliance, technology), a control taxonomy (how controls are grouped, e.g., preventive, detective, corrective; or by domain such as access control, change management, data protection), or a framework structure (e.g., the NIST AI RMF functions of Govern, Map, Measure, Manage; the ISO/IEC 42001 Annex A controls; COBIT governance and management objectives).
Control mapping (often called a crosswalk) is the documented relationship between a control in one framework and the equivalent or related control objective in another. Mapping AI controls to existing taxonomies therefore means taking the specific safeguards needed for AI systems and showing where they fit, fully or partially, within the structures the organization already uses, and identifying where no existing structure applies so new controls or categories must be created.
Key reference frameworks you should recognize for the exam include:
• NIST AI RMF 1.0 (Govern, Map, Measure, Manage) and its Playbook.
• ISO/IEC 42001 (AI Management System) and ISO/IEC 23894 (AI risk management guidance, which extends ISO 31000).
• ISO/IEC 27001/27002 for information security controls that AI inherits.
• COBIT 2019 for governance and management objectives.
• NIST CSF 2.0 with its added Govern function.
• COSO ERM for enterprise risk integration.
• EU AI Act risk tiers (unacceptable, high, limited, minimal) and obligations for high-risk systems.
• OWASP Top 10 for LLM Applications and MITRE ATLAS for AI-specific threat taxonomies.

How It Works: The Mapping Process
1. Establish scope and objectives. Decide which AI systems, use cases, and lifecycle stages are in scope, and which target frameworks matter (regulatory drivers usually dictate this). Obtain governance sponsorship so the mapping has authority.
2. Inventory existing controls and taxonomies. Pull the current control library, risk register categories, and policy hierarchy. Understand how controls are identified, owned, tested, and reported today, ideally from the GRC platform.
3. Identify AI-specific risks and required controls. Using NIST AI RMF, ISO/IEC 23894, or a threat model, enumerate AI risks across the lifecycle: data sourcing and provenance, training data bias, model development, validation, deployment, monitoring, and decommissioning. Derive the controls needed, such as bias testing, model documentation (model cards), human oversight, explainability requirements, drift monitoring, adversarial robustness testing, and third-party model due diligence.
4. Map at the control objective level. Mapping works best when done against the intent of a control rather than its literal wording. Ask: does an existing control objective, if applied to the AI system, achieve the desired outcome? Classify each mapping as:
• Full coverage: the existing control satisfies the AI requirement (e.g., logical access to the model registry is covered by existing identity and access management controls).
• Partial coverage: the existing control applies but needs AI-specific enhancement (e.g., change management exists but does not address model retraining or hyperparameter changes).
• No coverage: a genuine gap requiring a new control (e.g., fairness metric thresholds, or monitoring for hallucination rates).
Recognize that mappings are often many-to-many: one AI control may support several framework requirements, and one requirement may need several controls.
5. Perform gap analysis and rationalization. Consolidate overlapping controls into a common control framework (sometimes called a unified or harmonized control set) so that one control is tested once and evidence is reused across frameworks. This is the test once, comply many approach.
6. Assign ownership and accountability. Using the three lines model, confirm that first-line owners (data scientists, product owners, IT) own the control, second-line risk and compliance functions oversee and challenge, and internal audit provides independent assurance. Document in a RACI.
7. Document rationale and maintain traceability. Record why each mapping decision was made, the source references, and the date. This supports auditability and regulatory inquiries.
8. Validate and integrate. Review with stakeholders, load the mapping into the GRC tool, link it to the risk register and key risk indicators, and incorporate it into control testing schedules.
9. Maintain continuously. Taxonomies and regulations evolve (ISO/IEC 42001 is new, the EU AI Act has phased applicability, NIST releases profiles). Establish a review cadence and change triggers, such as a new AI use case, a new vendor model, or a new law.

Common Challenges
• Over-literal mapping that marks a control as covered because the words match, when the AI context changes the risk entirely.
• Treating generative AI as just another application and ignoring novel risk categories.
• Forgetting third-party and foundation model dependencies, where controls are inherited from a provider and must be verified rather than assumed.
• Allowing the mapping to become a static spreadsheet rather than a living component of the risk program.
• Creating an entirely new AI control framework when 60 to 80 percent of needed controls already exist in information security and IT general controls.

How to Answer Exam Questions on This Topic
AAIR questions are scenario-based and typically ask for the best, most important, first, or primary answer. When a question involves mapping AI controls to existing taxonomies, apply this reasoning sequence:
1. Identify what the question is really testing: efficiency (avoid duplication), coverage (find gaps), accountability (ownership), or integration (align with ERM and governance).
2. Favor answers that leverage and extend existing frameworks over answers that build something new and separate.
3. Favor answers that map at the control objective or risk outcome level rather than at the literal text level.
4. If asked what to do first, think governance and scope: understand the existing taxonomy and obtain stakeholder alignment before mapping or designing controls.
5. If asked what is most important for sustainability, think documentation, ownership, and periodic review.
6. Remember the risk practitioner advises and facilitates; the business owns the risk and controls. Avoid answers where the risk function unilaterally designs or owns operational AI controls.
7. Eliminate answers that ignore AI-specific risks (bias, explainability, drift, data provenance) or that assume traditional controls are automatically sufficient.

Exam Tips: Answering Questions on Mapping AI Controls to Existing Taxonomies
• Integration beats isolation. When one option integrates AI controls into the enterprise control library or ERM framework and another creates a standalone AI framework, the integrated option is almost always correct.
• Gap analysis follows inventory. You cannot identify gaps until you know what you have. If the sequence matters, inventory and understand existing controls first, then map, then analyze gaps, then design new controls.
• Watch for partial coverage. The exam likes scenarios where a traditional control exists but does not fully address the AI risk. The best answer enhances the existing control rather than ignoring the gap or duplicating the control.
• Know the framework structures. Be able to recognize NIST AI RMF functions (Govern, Map, Measure, Manage), ISO/IEC 42001 as a management system standard, ISO/IEC 23894 as risk guidance built on ISO 31000, and COBIT as governance of enterprise IT. Questions may describe a function without naming it.
• Third-party and inherited controls must be verified. If a scenario involves a vendor-supplied model or API, the correct answer typically includes obtaining assurance (attestations, contractual clauses, testing) rather than assuming the provider's controls are adequate.
• Documentation and traceability are frequent correct answers. When asked how to support audit, regulatory review, or board reporting, documented mapping rationale with traceability to source requirements is a strong choice.
• Risk-based prioritization. When resources are limited, prioritize mapping and gap closure for high-risk AI systems (e.g., those affecting individuals' rights, safety, or regulated decisions) rather than treating all systems equally.
• Beware of absolutes. Answers claiming existing controls are always sufficient, or that AI requires an entirely separate program, are usually distractors.
• Think lifecycle. Good mappings cover the full AI lifecycle from data acquisition through retirement; an answer that covers only deployment or only development is incomplete.
• Role clarity. If asked who should own a mapped AI control, lean toward the first-line business or technical owner, with the risk function in an oversight and advisory capacity.

Summary
Mapping AI controls to existing taxonomies is the discipline of fitting new AI safeguards into the organization's established risk and control architecture, identifying where traditional controls suffice, where they need enhancement, and where genuinely new controls are required. Done well, it reduces duplication, clarifies accountability, provides regulatory traceability, and allows AI risk to be governed and reported as a natural part of enterprise risk management. For the AAIR exam, remember the core message: build on what exists, map by intent, close genuine gaps, document everything, assign clear ownership, and keep the mapping alive as frameworks and regulations evolve.