The heart of the AI RMF is its Core, organized into four functions, each broken into categories and subcategories of outcomes. GOVERN is cross-cutting — it cultivates a risk-management culture and underpins the other three. MAP establishes context and frames the risks. MEASURE analyzes, benchmarks, and monitors them. MANAGE prioritizes and acts. MAP, MEASURE, and MANAGE form an iterative cycle that runs throughout the AI lifecycle, not a one-time waterfall.

Auditor's angle: the four functions map almost one-to-one onto the control areas of an AI audit program. The risk is that organizations cherry-pick MEASURE (model testing) while skipping GOVERN (accountability) and MANAGE (treatment), so a model is well-tested but no one owns its residual risk. Look for an AI policy and accountable roles (GOVERN), use-case and impact documentation (MAP), test/monitoring evidence (MEASURE), and risk-treatment plans with sign-off (MANAGE).

• GOVERN — policy, roles, accountability, risk appetite, third-party/supply-chain processes; it is the backbone the others hang from.
• MAP — intended use, stakeholders, impacts, system categorization and risk framing in context.
• MEASURE — quantitative/qualitative analysis: bias, robustness, performance, security; the TEVV (test, evaluation, verification & validation) evidence.
• MANAGE — prioritize, treat, respond, recover, communicate; allocate resources to the highest risks.

The AI RMF is meant to be tailored. A Profile is an instantiation of the framework's functions for a specific use case, sector, or technology — describing a current ("as-is") state and a target ("to-be") state so an organization can prioritize. In July 2024 NIST published the Generative AI Profile (NIST AI 600-1), a companion that names risks unique to or amplified by generative AI — confabulation/hallucination, dangerous or violent content, data privacy, information integrity, IP infringement, and CBRN/cyber misuse — and suggests hundreds of actions mapped back to the four functions.

Auditor's angle: a Profile is effectively a pre-built control catalogue you can lift straight into your audit criteria. The risk is that an organization runs a generative-AI system against the generic RMF and never addresses confabulation or training-data IP. Look for evidence the right Profile was selected and that a current-vs-target gap analysis drove a remediation roadmap.

• Profiles give a priority order — the current-vs-target gap shows what to fix first.
• The GenAI Profile maps named risks to concrete actions under each function, so it doubles as a checklist.
• Use-case and sector Profiles let the auditor justify which controls to expect for the system in scope.

NIST defines seven characteristics that together describe trustworthy AI. The exam tests these as a checklist and asks you to recognize which characteristic a failing control threatens.

Auditor's angle: the characteristics are the outcomes your controls must deliver, so they make a natural mapping target — every control should trace to at least one characteristic, and every characteristic should be covered by at least one control. The risk is uneven coverage (heavy on fairness, blind on security/resilience). Use them as a completeness check over the control set.

• Valid & reliable — accurate and consistent; the foundation the others rest on.
• Safe — does not, under defined conditions, endanger life, health, property, or environment.
• Secure & resilient — withstands attack (poisoning, evasion, extraction) and degrades/recovers gracefully.
• Accountable & transparent — design, data, decisions, and owners are documented so responsibility can be assigned.
• Explainable & interpretable — mechanisms and the meaning of outputs can be conveyed to the right audience.
• Privacy-enhanced — safeguards autonomy, identity, dignity; minimization, de-identification, PETs.
• Fair — harmful bias managed — addresses equality/equity; manages systemic, computational, and human-cognitive bias.

Because the RMF is structured and outcome-based, it makes excellent audit criteria even where it is not legally required. But it is voluntary — conforming to it is not evidence of legal compliance, and the auditor must say so.

Auditor's angle: the trap is treating "we use NIST" as a compliance answer to a legal question. Use the RMF to structure how you audit, but always overlay the binding instruments (EU AI Act, GDPR) that the use case triggers. State explicitly in scope that the RMF is being used as criteria, not as proof of compliance.

• Functions become control areas; characteristics become the outcomes you test for.
• A relevant Profile pre-populates the expected controls.
• Always pair voluntary criteria with the applicable binding law in the scope statement.

An AI Management System (AIMS) is the set of interrelated policies, objectives, processes, roles, and controls an organization uses to govern AI responsibly and consistently. ISO/IEC 42001 specifies the requirements to establish, implement, maintain, and continually improve one. Like every ISO management-system standard it runs on the Plan-Do-Check-Act (PDCA) cycle: Plan (context, policy, objectives, risk and AI-system impact assessment), Do (operational controls, lifecycle, data, third parties), Check (monitoring, internal audit, management review), Act (correct nonconformities and improve).

Auditor's angle: the value of a management system is that responsible AI becomes systemic, not ad hoc. The risk is "paper conformance" — a policy exists but the PDCA loop never closes (no internal audit, no management review, no corrective action). Test that the cycle actually turns: pick a nonconformity and trace it to a corrective action and an improved control.

• Plan — context, interested parties, AI policy, objectives, risk and impact assessment.
• Do — implement selected Annex A controls; manage lifecycle, data, suppliers.
• Check — monitor/measure, internal audit, management review.
• Act — corrective action and continual improvement.

ISO/IEC 42001 includes an Annex A catalogue of reference controls and control objectives (with implementation guidance in Annex B). They span AI policies, internal organization and roles, resources for AI systems, impact assessment of AI on individuals and society, the AI system lifecycle, data for AI systems, information for interested parties, use of AI systems, and third-party/supplier relationships. As with ISO 27001, an organization selects applicable controls via a Statement of Applicability (SoA) — recording which controls apply, which are excluded, and why.

Auditor's angle: the SoA is the master map between the standard and the implementation, and a prime piece of audit evidence. The risk is convenient exclusions — controls dropped to dodge work, with weak or no justification. Sample applicable controls for real implementation, and challenge every exclusion's rationale.

• The SoA lists each control's applicability, justification, and implementation status.
• Excluded controls need a documented reason that holds up against the actual scope.
• Annex A is a reference set — organizations may add controls; absence from Annex A is not an excuse to ignore a real risk.

ISO/IEC 42001 uses the same Harmonized Structure (Annex SL) as ISO/IEC 27001, so the two integrate cleanly. An organization with a mature ISMS can extend it to an AIMS, reusing the risk process, internal-audit machinery, and management review rather than building a parallel system. Both are certifiable by accredited bodies.

Auditor's angle: reuse is good, but the controls differ — 27001 secures information; 42001 governs AI-specific risks (bias, impact on people, lifecycle, data quality). The risk is an organization claiming "our 27001 covers AI." Confirm that AI-specific controls and impact assessments exist, not just security controls relabeled.

• Shared Annex SL clauses (context, leadership, planning, support, operation, evaluation, improvement) integrate the two.
• An ISMS can host an AIMS, sharing audit and review cadence.
• 27001 conformance does not imply 42001 conformance — different control objectives.

ISO/IEC 23894:2023 is AI risk-management guidance — not certifiable. It adapts the ISO 31000 principles, framework, and process to AI, with AI-specific risk sources and examples; think of it as the "how to do AI risk management" companion that feeds the risk requirements of 42001. ISO/IEC 22989:2022 is the standardized AI concepts and terminology — the vocabulary the other standards rely on.

Auditor's angle: 23894 gives you criteria to judge the maturity of an AI risk process even outside a certification; 22989 grounds scope and findings in shared definitions so "AI system," "model," and "training data" mean the same thing to everyone. The risk: an organization runs a generic enterprise risk process that never identifies AI-specific risk sources. Use 23894 to check the risk process actually surfaces AI risks.

• 23894 = ISO 31000 adapted to AI; guidance, not certifiable.
• 22989 = vocabulary; underpins consistent scope and criteria.
• 42001 = the certifiable management system that the other two support.

The defining feature of 42001 is that it is certifiable by an accredited body, so an organization can hold a certificate — strong but not conclusive third-party evidence. A certificate's value depends entirely on its scope and currency.

Auditor's angle: a certificate that excludes the system you are auditing, or that has lapsed, proves little. The risk is over-reliance on a certificate as a blanket assurance. Verify the accreditation, the scope statement, the validity dates, and the SoA behind it; then test live controls rather than accepting the certificate at face value.

• Check the certificate is from an accredited body, not a self-declaration.
• Read the scope — does it actually include the model in question?
• Confirm currency and any surveillance-audit results; certificates expire and can carry open findings.

The Act's central design scales obligations to the risk an AI system poses to health, safety, and fundamental rights, across four tiers: unacceptable/prohibited, high-risk, limited/transparency, and minimal.

Auditor's angle: tier classification drives everything downstream — get the tier wrong and the entire obligation set is wrong. The risk is systematic under-classification to avoid the high-risk burden. The auditor independently re-derives the tier from the use case rather than accepting management's label.

High-risk systems carry the bulk of the compliance burden. Providers (and, in defined ways, deployers) must implement and evidence a continuous risk-management system; data and data governance (relevant, representative, error-checked data); technical documentation and automatic logging; transparency and instructions for use; effective human oversight; and appropriate accuracy, robustness, and cybersecurity. Before market placement the system must pass a conformity assessment, bear CE marking where applicable, and be registered in the EU database. Deployers have their own duties, including using the system per instructions, ensuring oversight, and (for many high-impact/public-sector uses) a fundamental-rights impact assessment.

Auditor's angle: each obligation is an audit criterion with a named evidence artifact. The risk is that one or two obligations are met (testing accuracy) while others are absent (no human oversight, no conformity assessment). Walk the full list and demand the artifact for each.

• Provider vs deployer duties differ — confirm which role your auditee holds.
• Conformity assessment + CE marking + EU-database registration are gating steps before placement.
• Human oversight must be effective, not nominal — a person able to override, not a rubber stamp.

The Act adds a dedicated regime for general-purpose AI (GPAI) models. All GPAI providers face transparency and documentation duties, must publish a summary of training-data content, and must have a policy to respect EU copyright law. GPAI models judged to carry systemic risk (very capable models above a compute threshold) face additional duties: model evaluation and adversarial testing, systemic-risk assessment and mitigation, serious-incident reporting, and cybersecurity protections.

Auditor's angle: obligations sit on the model and flow downstream to deployers who build on it. The risk is a deployer assuming "the foundation-model provider handles compliance" while its own high-risk application duties go unmet. Identify whether a GPAI model is involved, whether it is systemic-risk, and where each duty lands.

• Baseline GPAI duties: documentation, training-data summary, copyright policy.
• Systemic-risk GPAI: evaluation/adversarial testing, risk mitigation, incident reporting, cybersecurity.
• Building a high-risk app on a GPAI model does not transfer the app's own obligations to the model provider.

The Act entered into force on 1 August 2024 and applies in phases: prohibitions and AI-literacy duties from Feb 2025; GPAI obligations and governance from Aug 2025; the bulk of high-risk obligations from Aug 2026; high-risk systems embedded in regulated products from Aug 2027. It has broad extraterritorial reach — like GDPR, it can apply to providers and deployers outside the EU when the system's output is used in the EU. Penalties are tiered: up to €35m or 7% of global turnover for prohibited breaches; up to €15m or 3% for most other obligations; up to €7.5m or 1% for supplying incorrect information (whichever is higher).

Auditor's angle: the phased dates mean compliance deadlines differ by tier — auditing a high-risk system in early 2026 means assessing readiness before the obligation bites. The risk is "we're not an EU company" used as a blanket defence. Test where outputs are used, not just where the company sits.

• Map each system's tier to its applicable phase date.
• Extraterritorial: output used in the EU can pull a non-EU org into scope.
• Penalty band tracks severity — prohibited practices carry the 7% maximum.

Tiering is the first and most consequential step in any AI Act assessment. It is a decision procedure, not a guess: check prohibited practices first, then the high-risk list and annexes, then transparency triggers, then default to minimal.

Auditor's angle: a reproducible classification method is itself an audit finding — if the organization cannot show how it tiered its systems, the classifications are unreliable. Look for a documented, repeatable tiering procedure and challenge any tier that lowers obligations without justification.

• Order matters: prohibited → high-risk → limited → minimal.
• Use the intended purpose and context, not the technology label.
• Document the rationale so the classification is auditable and repeatable.

The OECD AI Principles (2019, updated 2024) were the first intergovernmental AI standard, adopted by OECD members and beyond and the basis of the G20 AI principles. Five values-based principles: inclusive growth/sustainable development/well-being; human rights and democratic values (incl. fairness and privacy); transparency and explainability; robustness, security and safety; and accountability. The OECD's definition of an "AI system" was also adopted as the reference definition in the EU AI Act.

Auditor's angle: the principles are not a compliance test — but they explain why the trustworthy-AI characteristics look so alike across frameworks, and they can be turned into testable controls. The risk is an organization citing "we follow OECD principles" as if it were compliance. Treat them as the rationale layer, and convert each principle into a concrete, evidenced control before relying on it.

• Five principles; values-based, voluntary, intergovernmental.
• Source of the EU AI Act's "AI system" definition.
• Influential but unenforceable — soft law.

The G7 Hiroshima AI Process (2023) produced international Guiding Principles and a voluntary Code of Conduct for organizations developing advanced AI systems, focused on safety, transparency, and accountability for frontier/foundation models.

Auditor's angle: aimed squarely at frontier-model developers, the Code of Conduct is a useful checklist for organizations building or fine-tuning very capable models — but it is voluntary. The risk is conflating Code-of-Conduct adherence with EU AI Act GPAI obligations, which overlap but are legally distinct. Use it as good-practice criteria, never as proof of legal compliance.

• Voluntary, targeted at advanced/frontier AI developers.
• Themes: safety, transparency, accountability — echoing the systemic-risk concerns in the AI Act.
• Overlaps with, but does not satisfy, binding GPAI duties.

The UNESCO Recommendation on the Ethics of AI (2021) was the first global standard-setting instrument on AI ethics, adopted by all UNESCO member states. It is values- and principles-based (human dignity, human rights, fairness, sustainability) with practical policy action areas — but it is a recommendation, not law.

Auditor's angle: its breadth (nearly universal adoption) makes it the strongest signal of globally shared AI-ethics expectations, useful where an organization operates across many jurisdictions. The risk is treating its near-universal adoption as binding force. Use it to inform ethics criteria, especially around human-rights impact, while anchoring the compliance verdict in actual law.

• First global AI-ethics instrument; adopted by all member states.
• Includes practical policy action areas and a readiness/impact-assessment emphasis.
• A recommendation — influential, not enforceable.

The recurring skill across all soft-law instruments is conversion: a principle ("accountability," "transparency") is not auditable until it becomes an outcome, a control, and an evidence artifact. The method is the same regardless of the source instrument.

Auditor's angle: the risk is "principle-washing" — high-minded policy language with nothing testable behind it. The auditor's contribution is forcing each principle through the outcome→control→evidence pipeline and then testing the evidence. If a principle cannot be converted, it is decoration.

• Restate principle as a measurable outcome.
• Define the control that produces the outcome.
• Name the evidence and test it.

Under GDPR Article 22, individuals have the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects, unless an exception applies (contract, explicit consent, or authorizing law) — and even then safeguards are required: human intervention, the right to express a view, and the right to contest the decision, plus meaningful information about the logic.

Auditor's angle: Article 22 is the legal backbone of "human oversight" for high-impact AI. The risk is fully automated significant decisions with no genuine human review or recourse. Confirm a lawful exception exists and that the safeguards are real — a human who can actually override, not a rubber stamp.

• Triggers on solely automated + significant effect.
• Needs a lawful exception (contract / explicit consent / law) plus safeguards.
• Meaningful human review must be able to change the outcome.

A DPIA is required for processing likely to result in high risk to individuals — which covers many AI use cases (large-scale profiling, sensitive data, systematic monitoring). It describes the processing, assesses necessity and proportionality, identifies risks to individuals, and sets mitigations. A completed DPIA is a primary piece of audit evidence.

Auditor's angle: a DPIA is both a legal requirement and a ready-made risk artifact you can rely on. The risk is a DPIA done as a tick-box at project start and never updated, or skipped entirely for a high-risk model. Check it exists, was done before processing, covers the actual model, and was revisited on material change.

• Triggered by high-risk processing — much AI qualifies.
• Must precede processing and be kept current.
• Where it overlaps an AI Act fundamental-rights assessment, reuse rather than duplicate.

Every processing of personal data needs a valid lawful basis (consent, contract, legitimate interest, etc.). Reusing data collected for one purpose to train a model usually needs a fresh basis — purpose limitation. Data minimization requires collecting and retaining only what is necessary. These bite hard on AI because training appetite pushes against both.

Auditor's angle: possessing data is not the same as having the right to use it for training. The classic AI failure mode is repurposing existing customer data for model training with no fresh lawful basis. Test the chain from original collection purpose to the training use, and confirm minimization was applied to the training set.

• Repurposing data for training typically needs a new lawful basis.
• Minimization and retention limits apply to training data too.
• Special-category (sensitive) data needs an additional condition.

AI pipelines often move personal data across borders (cloud training, offshore labeling, third-party APIs). GDPR restricts international transfers to countries without adequate protection, requiring safeguards such as adequacy decisions or Standard Contractual Clauses. Separately, sectoral and regional rules apply existing law to AI: financial supervisors enforce model-risk-management and fair-lending rules; health authorities regulate AI in medical devices; the US has a patchwork of state laws (e.g., bias-audit requirements for automated employment tools) and sectoral rules (HIPAA, FCRA).

Auditor's angle: AI data flows are easy to overlook because they hide inside vendor and infrastructure choices. The risk is training or inference routed through a jurisdiction with no transfer safeguard, and applicable sectoral rules ignored in favour of the headline AI law. Map the full data flow and confirm every applicable regime was identified.

• Transfers to non-adequate countries need a valid mechanism (adequacy/SCCs).
• Sectoral rules (finance, health, employment) stack on top of GDPR and the AI Act.
• The auditor confirms all regimes are identified per use case — not just the obvious one.

The instruments converge on the same trustworthy-AI outcomes (fairness, transparency, safety, accountability) but differ sharply in type and force: NIST and OECD are voluntary; ISO is a (certifiable) standard; the EU AI Act and GDPR are binding law. They also differ in object — NIST/23894 govern a risk process, 42001 governs a management system, the AI Act governs product/use safety, GDPR governs personal data.

Auditor's angle: overlap is an opportunity (one control can satisfy several criteria) and a trap (conforming to one is mistaken for all). Map controls to multiple instruments at once, but keep separate conclusions for voluntary maturity and legal compliance.

• Shared outcomes, different legal force.
• One control (e.g., human oversight) can map to NIST MANAGE, AI Act oversight, and GDPR Art. 22 simultaneously.
• Never let conformance to a voluntary instrument answer a legal-compliance question.

When multiple instruments touch a system, the auditor selects criteria by a clear hierarchy: binding law first (must be met), then certifiable/standard criteria (where adopted or claimed), then voluntary frameworks (for structure and rigor), then principles (rationale). The scope statement records which criteria apply and why.

Auditor's angle: the risk is choosing comfortable criteria (a voluntary framework) and ignoring the binding ones, or auditing against everything and producing an unfocused report. Anchor on the binding obligations the use case triggers, then add voluntary criteria for depth.

• Binding law sets the floor — it is non-negotiable.
• Voluntary frameworks add structure and completeness above the floor.
• Document criteria selection so findings are defensible.

A crosswalk is a matrix mapping each control to every framework requirement it helps satisfy. It is the artifact that makes multi-framework auditing efficient: test a control once, then read off which obligations it supports across NIST, ISO, the AI Act, and GDPR.

Auditor's angle: the crosswalk both drives efficient testing and exposes coverage gaps — any framework requirement with no control mapped to it is an immediate finding. The risk is a crosswalk that maps controls optimistically (claiming a weak control satisfies a requirement it does not). Validate each mapping against the requirement's real intent.

• Rows = controls; columns = framework requirements.
• Empty cells in a requirement column = coverage gaps.
• Test once, report against many — but verify each claimed mapping.

One comparison to keep for final review: type, scope, certifiability, and primary audit use for every instrument the exam names.

Auditor's angle: this table is the answer key to the most common exam trap — confusing a voluntary framework or standard with binding law. Memorize the type and certifiable? columns; they resolve a large share of questions on their own.