Part IV: Assurance, Audit & Certification

Parts II and III describe controls the institution operates. This Part describes the machinery that proves (to a board, an examiner, or a counterparty) that those controls exist, function, and are independently checked. Assurance is the unglamorous end of responsible AI: nobody demos an accreditation chain at a conference. But it is the only layer that converts "we believe our agents are safe" into a claim someone outside the building has a professional obligation to verify. The evidence shows, with some satisfaction, that the standards world spent 2022–2025 quietly building exactly this chain, and, with less satisfaction, that the chain assures a technical floor it does not itself define.

IV.1 The layered assurance stack

Read as a set, five primary sources form a coherent, top-to-bottom assurance stack that maps cleanly onto the classic three-lines-of-defense model (enterprise assurance report, 2026-07-18, findings verified upstream):

Sources: https://www.iso.org/standard/56641.html; https://www.iso.org/standard/77304.html; https://www.iso.org/standard/42005; https://www.theiia.org/globalassets/site/content/tools/professional/aiframework-sept-2024-update.pdf; https://www.iso.org/standard/42006.

Three structural facts about this stack matter for a Chief AI Risk Officer.

First, the chain now closes on conformity rather than self-attestation. ISO/IEC 42006:2025 sets requirements for the bodies that audit and certify AI management systems. It accredits the certifiers. Without it, an ISO/IEC 42001 AIMS claim dead-ends at self-declaration; with it, "we say our AIMS is sound" can become "an accredited third party certifies it" (iso.org/standard/42006, T1; webstore.iec.ch/en/publication/108460, T1).

Second, AI governance is deliberately positioned as an extension of existing board-level IT governance, not a greenfield regime. ISO/IEC 38507:2022 sits in the ISO/IEC 385xx IT-governance numbering family, not the 420xx AI family, the numbering is the tell that boards are meant to govern AI through muscles they already have (verified report, verified). The board's technology-risk committee charter extends; it does not get a parallel twin.

Third, the caveat that belongs in every board pack, the stack assures a floor it does not itself define. The verified finding is blunt: this cohort is entirely management-system and organizational-audit scaffolding, with "no agentic-RAI content — no agent evaluation, no eval validity, no control, no oversight." Certification says the organization manages AI in a structured way; it says nothing about whether the agent evaluations in Part III.B are valid or the runtime controls in Part III.C actually contain an agent. Certification is necessary scaffolding, never a substitute for the control catalog in this Compendium.

Two orientation mappings from the same report are provisional interpretations, retained as such here: (a) a NIST AI RMF crosswalk, 38507→GOVERN, 42005→MAP, 23894→MEASURE/MANAGE, IIA and 42006 as assurance over GOVERN, weakest coverage on MEASURE; (b) ISO 42005/42006 as plausible harmonization candidates for the EU AI Act's impact-assessment and conformity-assessment obligations. Leads to confirm, not facts to cite externally.

IV.2 Internal audit of agentic systems

The third line is where agentic AI assurance is currently weakest, because audit universes were built around static models and periodic validation, not systems that act. Three corpus anchors help internal audit catch up:

• The IIA AI Auditing Framework (September 2024 update): the profession's own framework for auditing AI, and the one openly readable full-text source in the assurance cohort (theiia.org PDF, verified HTTP 200; net-new to the cited research with zero prior IIA holdings).
• ISACA's ITAF, 5th Edition: the IT Audit Framework updated explicitly for AI governance and continuous assurance (isaca.org, T2), relevant because most bank internal-audit methodology is ITAF- or COBIT-derived.
• ISO 19011:2026: general guidelines for auditing management systems (iso.org/standard/19011, T1), the procedural backbone for auditing an ISO/IEC 42001 AIMS internally before a certification body arrives.

For the audit methodology itself, the cited research holds the SMACTR framework ("Closing the AI Accountability Gap: Defining an End-to-End Framework for Internal Algorithmic Auditing" (dl.acm.org/doi/10.1145/3351095.3372873 and arxiv.org/abs/2001.00973, both T1)) the canonical end-to-end internal algorithmic audit design, produced before agents existed but built around exactly the artifact discipline an agentic audit needs to extend. For banking, the ECB Guide to Internal Models (revised) anchors supervisory expectations for internal-model review in the euro area (bankingsupervision.europa.eu, T2): the nearest supervisory analogue for how agent-system audits will be evidenced.

What changes when the audited object is an agent rather than a model? [practice guidance: not directly source-backed]: the audit universe entry must cover the system (model + tools + permissions + memory + orchestration); sampling shifts from "review the validation report" to "re-execute logged agent trajectories against policy"; and independence requires third-line read access to the Part III.D runtime logs without operating any of them.

IV.3 The certification chain, and what certification does and does not assure

The conformity-assessment plumbing works as a chain of accountability:

1. ISO/IEC 17021-1:2015 sets the generic requirements for bodies providing audit and certification of management systems (iso.org/standard/61651.html, T1).
2. ISO/IEC 42006:2025 layers AI-specific requirements on top, for bodies auditing and certifying AI management systems specifically (iso.org/standard/42006 and webstore.iec.ch/en/publication/108460, T1).
3. ISO/IEC 17065:2012 is the parallel lane for bodies certifying products, processes and services rather than management systems (iso.org/standard/46568.html, T1), the lane product-level AI certification schemes would ride.
4. EU AI Act Article 43 establishes the conformity-assessment obligation for high-risk AI systems under the Act (artificialintelligenceact.eu/article/43, T1): the binding regulatory endpoint that this voluntary chain may ultimately serve (the harmonization mapping remains unverified, per IV.1).

What an AIMS certificate does assure: an accredited third party examined the institution's AI management system against ISO/IEC 42001 and found it conforming, governance structures, risk process, documented controls, improvement loops.

What it does not assure, and what a Chief AI Risk Officer must say out loud before anyone laminates the certificate: that any specific agent is safe, that evaluations were valid, that runtime containment works, or that customer outcomes are fair. the cited research is explicit that the certifiable scaffolding contains no agent-evaluation content (verified report, verified finding). A certified AIMS with weak Part III controls is a well-documented way of being wrong. In SR 11-7 terms: certification is to the AIMS what a validation policy is to a model, evidence of process, not evidence of performance.

IV.4 Frontier safety frameworks as vendor-diligence objects

A regulated institution buying frontier-model capability cannot audit the lab. What it can do is treat the lab's published safety framework as a diligence object: a versioned public commitment whose scope, thresholds, and drift are inspectable. the cited research holds the full cohort:

The OpenAI entry needs its caveat spelled out. Under this provisional account, OpenAI describes the Frontier Governance Framework not as a new safety methodology but as a "regulatory translation layer" over its internal Preparedness Framework: reportedly anchored to the EU's General-Purpose AI Code of Practice under Regulation (EU) 2024/1689 and California's Transparency in Frontier AI Act, reportedly covering cyber-offense, CBRN, harmful manipulation and loss of control, with a reported systemic-risk threshold (>50 fatalities or >$1B damage from a single incident) and EU systemic-risk oversight assigned to the OpenAI Ireland Limited board. None of these specifics should be cited externally until verified against the source PDF. The structural lesson the passage draws is worth carrying regardless: statutes leave operational detail blank, labs fill it in their published frameworks, and that detail becomes the de-facto standard others inherit.

Version churn is itself diligence signal: the cited research holds DeepMind's FSF at 2.0 and 3.0 and Anthropic's RSP at v3.0 and v3.3. A vendor framework is a living commitment; track the diffs, not just the PDF (ASR-08). For internal-deployment exposure, the framing reference is "What Should Frontier AI Developers Disclose About Internal Deployments?" (arxiv.org/abs/2604.23065, T3).

IV.5 Transparency artifacts as audit evidence

Model and system cards began as ethics documentation; in an assured enterprise they are evidence. The founding artifact is Mitchell et al., "Model Cards for Model Reporting" (arxiv.org/abs/1810.03993, T2), which according to the cited paper structures a card into nine sections: Model Details; Intended Use; Factors; Metrics; Evaluation Data; Training Data; Quantitative Analyses; Ethical Considerations; Caveats and Recommendations. Its core motivating claim (paraphrase): models trained on real-world data routinely show disparate performance across demographic groups, and deployment without structured disclosure creates unaccounted harms. (This is a paraphrase; consult the cited paper for exact wording.)

The practice has scaled and mutated. A systematic analysis of 32,111 model cards characterizes real-world documentation practice at scale (arxiv.org/abs/2402.05160, T1). Hugging Face operationalizes cards as machine-readable metadata specifications for models and datasets (huggingface.co/docs/hub/model-cards; huggingface.co/docs/hub/datasets-cards, T2). Meta publishes system cards covering AI systems rather than lone models (ai.meta.com/tools/system-cards, T3). The family has speciated into Risk Cards (arxiv.org/abs/2303.18190, T2), Use Case Cards inspired by the EU AI Act (arxiv.org/abs/2306.13701, T2), AI Usage Cards (arxiv.org/abs/2303.03886, T2), Interactive Model Cards (arxiv.org/abs/2205.02894, T2), Method Cards (doi.org/10.1145/3522664.3528600, T3), and Value Cards (dl.acm.org/doi/10.1145/3442188.3445971, T2).

For agentic systems the unit of documentation must be the system card (model, tools, permissions, memory, autonomy envelope, oversight mode) because that is the unit that acts. [practice guidance: not directly source-backed]: the agent card should enumerate tool permission scopes, autonomy-ladder position, kill-switch and budget-guard settings, and trajectory-level eval results, so internal audit (IV.2) can test the card against runtime logs.

IV.6 The ASR control catalog

ASR-01: Documented layered assurance stack

Objective. Ensure the institution can show a complete, unbroken assurance chain from board oversight to independent certification for its AI estate.

Control. The institution maintains a documented map of its AI assurance layers (board governance, risk process, first-line impact assessment, independent internal audit, external certification) each with a named owner, an operating standard, and a review cadence; gaps between layers are logged as risk acceptances.

Implementation (financial enterprise). Anchor each layer to its instrument: board charter per ISO/IEC 38507; AI risk in ERM per ISO/IEC 23894; impact assessments per ISO/IEC 42005; internal audit per the IIA AI Auditing Framework; certification per ISO/IEC 42006-accredited bodies. Cross-reference the MRM framework (SR 11-7: model inventory, validation, effective challenge) so agents appear in both the assurance map and the model inventory.

Maturity. Baseline: stack documented, owners named, gaps logged. Enhanced: annual attestation per layer with board reporting. Frontier: continuous assurance dashboard tying layer artifacts to the live agent inventory.

Ownership. 1st line: operates impact assessments, produces artifacts. 2nd line: owns the stack map, risk process, gap register. 3rd line: audits the stack end-to-end and opines on completeness.

Evidence. Assurance stack map; layer-owner attestations; gap/risk-acceptance register; board minutes showing AI oversight under the extended IT-governance charter.

Mappings. NIST AI RMF GOVERN (mapping to specific subfunctions is provisional); ISO/IEC 42001 AIMS; EU AI Act (no article sourced at this layer); SR 11-7/OCC 2011-12: governance and model inventory; DORA, ICT governance aspect.

Sources. iso.org/standard/56641.html (T1), https://www.iso.org/standard/56641.html; iso.org/standard/77304.html (T1), https://www.iso.org/standard/77304.html; iso.org/standard/42005 (T1), https://www.iso.org/standard/42005; theiia.org AI Auditing Framework (T1), https://www.theiia.org/globalassets/site/content/tools/professional/aiframework-sept-2024-update.pdf; iso.org/standard/42006 (T1): https://www.iso.org/standard/42006.

ASR-02: AI impact assessment as a first-line gate

Objective. Ensure no agentic system reaches production without a documented, standards-aligned impact assessment owned by the deploying business.

Control. Every agentic AI system undergoes an impact assessment aligned to ISO/IEC 42005:2025 before deployment and after material change (new tools, expanded autonomy, new customer population); deployment approval is conditional on a completed, second-line-reviewed assessment. Cross-reference: GOV-10 is the control of record for the impact-assessment requirement; ASR-02's contribution is assurance that GOV-10 operates as a first-line gate, with instrument and methodology ownership per GOV-10.

Implementation (financial enterprise). Fold the ISO 42005-aligned assessment into existing new-product and model-approval gates so agents cannot route around it; define "material change" to include tool/permission changes and autonomy-ladder promotions, not just model swaps. Assessments feed the model-risk tiering that drives validation depth.

Maturity. Baseline: assessment template exists and is mandatory at go-live. Enhanced: re-assessment triggered automatically by change-management events. Frontier: assessment deltas computed per agent version and surfaced to the risk committee.

Ownership. 1st line: performs and owns the assessment. 2nd line: sets the methodology, reviews quality, and can veto. 3rd line: samples assessments for completeness and challenge quality.

Evidence. Completed impact assessments with second-line sign-off; gate records showing approval conditioned on assessment; change-triggered re-assessment logs.

Mappings. NIST AI RMF MAP (mapping is provisional); ISO/IEC 42001 AIMS; EU AI Act: plausible harmonization with impact-assessment obligations is a provisional interpretation; SR 11-7/OCC 2011-12, model development and use documentation; DORA, n/a.

Sources. iso.org/standard/42005 (T1), https://www.iso.org/standard/42005; iso.org/standard/77304.html (T1), https://www.iso.org/standard/77304.html.

ASR-03: Independent internal audit of agentic AI

Objective. Provide the board with third-line assurance that agentic AI controls exist and operate, using recognized audit frameworks.

Control. Internal audit carries agentic AI in its audit universe as systems (model + tools + permissions + memory + orchestration), audits them on a risk-based cycle using a methodology aligned to the IIA AI Auditing Framework and ISO 19011, and reports results to the audit committee.

Implementation (financial enterprise). Extend the ITAF/COBIT-derived audit methodology per ISACA ITAF 5th Edition's AI-governance update; for SSM-supervised banks, align with the ECB Guide to Internal Models. Audit staff get read-only access to agent action logs (Part III.D) and re-execute sampled trajectories against policy [practice guidance: not directly source-backed].

Maturity. Baseline: agentic systems in the audit universe with a first audit completed. Enhanced: annual audits with trajectory-level sampling. Frontier: continuous auditing hooks on runtime logs with exception-driven fieldwork.

Ownership. 1st line: provides access, remediates findings. 2nd line: tracks remediation. 3rd line: owns and executes the audits; never operates controls it audits.

Evidence. Audit universe extract showing agent systems; audit workpapers and reports; audit-committee minutes; remediation tracking with closure evidence.

Mappings. NIST AI RMF GOVERN (assurance layer; mapping is provisional); ISO/IEC 42001 AIMS (internal audit of the AIMS); EU AI Act (no article sourced); SR 11-7/OCC 2011-12: internal audit's role in MRM governance; DORA, ICT audit aspect.

Sources. theiia.org AI Auditing Framework (T1), https://www.theiia.org/globalassets/site/content/tools/professional/aiframework-sept-2024-update.pdf; iso.org/standard/19011 (T1), https://www.iso.org/standard/19011; isaca.org ITAF 5th Edition (T2), https://www.isaca.org/about-us/newsroom/press-releases/2026/isaca-launches-future-ready-it-audit-framework-update-to-strengthen-digital-trust; bankingsupervision.europa.eu ECB Guide to Internal Models (T2), https://www.bankingsupervision.europa.eu/ecb/pub/pdf/ssm.supervisory_guide202507.en.pdf.

ASR-04: End-to-end internal algorithmic audit methodology

Objective. Ensure internal audits of agentic systems follow a structured, artifact-producing methodology rather than ad-hoc review.

Control. Agentic AI audits follow a documented end-to-end methodology (scoping, artifact mapping and collection, testing, post-audit reflection) modeled on the SMACTR internal algorithmic auditing framework, producing a defined artifact set per audited system.

Implementation (financial enterprise). Adapt the SMACTR stage structure to the audit manual; require per-audit artifacts (scope memo, system map with tool/permission inventory, test evidence, findings log) filed in the evidence repository (ASR-10). Tie audit scope to the Part I risk taxonomy so autonomy and tool-misuse risks are explicitly in scope.

Maturity. Baseline: methodology documented and used on highest-tier agents. Enhanced: full artifact set mandatory for all agent audits. Frontier: methodology artifacts machine-indexed and reusable across audits and regulatory exams.

Ownership. 1st line: supplies system maps and artifacts. 2nd line: aligns methodology with model-validation standards to avoid duplicate, conflicting testing. 3rd line: owns the methodology and its consistent application.

Evidence. Audit methodology document; per-audit artifact sets; cross-references from audit findings to the Part III control catalog.

Mappings. NIST AI RMF MEASURE/MANAGE (analyst mapping; corpus crosswalk unverified); ISO/IEC 42001 AIMS; EU AI Act (no article sourced); SR 11-7/OCC 2011-12: effective challenge documentation; DORA, n/a.

Sources. dl.acm.org/doi/10.1145/3351095.3372873 (T1), https://dl.acm.org/doi/10.1145/3351095.3372873; arxiv.org/abs/2001.00973 (T1), https://arxiv.org/abs/2001.00973.

ASR-05: Accredited certification of the AI management system

Objective. Obtain third-party, accreditation-backed certification of the AIMS so that conformity claims do not rest on self-attestation.

Control. The institution's ISO/IEC 42001 AIMS is certified by a certification body operating under ISO/IEC 17021-1 and conforming to ISO/IEC 42006:2025; certification scope, exclusions, and surveillance-audit results are reported to the risk committee.

Implementation (financial enterprise). Verify the certifier's ISO 42006 conformity and accreditation before engagement; scope the certificate to cover the agentic estate explicitly (a certificate scoped to a chatbot pilot assures nothing about the trading-operations agent). Feed surveillance findings into second-line issue management alongside validation findings.

Maturity. Baseline: certification achieved for a defined scope. Enhanced: scope covers all material agentic systems; surveillance findings tracked to closure. Frontier: certification evidence pack cross-linked to live control telemetry.

Ownership. 1st line: hosts audits and remediates. 2nd line: owns the certification program and scope decisions. 3rd line: assesses whether certification scope matches actual AI usage.

Evidence. Certificate with scope statement; certifier accreditation evidence; surveillance and recertification audit reports; risk-committee reporting.

Mappings. NIST AI RMF GOVERN (assurance over GOVERN per corpus crosswalk: unverified); ISO/IEC 42001 AIMS; EU AI Act, harmonization of 42006 with conformity-assessment obligations is a provisional interpretation; SR 11-7/OCC 2011-12, third-party review aspect; DORA, n/a.

Sources. iso.org/standard/42006 (T1), https://www.iso.org/standard/42006; webstore.iec.ch/en/publication/108460 (T1), https://webstore.iec.ch/en/publication/108460; iso.org/standard/61651.html (T1): https://www.iso.org/standard/61651.html.

ASR-06: Conformity-assessment readiness for regulated high-risk uses

Objective. Ensure agentic systems that fall in scope of binding conformity-assessment regimes can pass them without remediation panic.

Control. For each agentic system classified high-risk under the EU AI Act (or analogous regimes), the institution maintains a conformity-assessment readiness file aligned to Article 43 and tracks whether ISO/IEC 17065-type product/process certification schemes apply in any operating jurisdiction.

Implementation (financial enterprise). Run classification through the Part V regulatory mapping; maintain the technical-documentation pack continuously (drawing on ASR-09 artifacts) rather than assembling it at assessment time; assign one accountable owner per system for conformity status. Coordinate group functions so an EU conformity file and a US SR 11-7 validation file share evidence rather than duplicating it.

Maturity. Baseline: in-scope systems identified with named owners. Enhanced: readiness files maintained continuously and internally dry-run audited. Frontier: conformity evidence generated as a by-product of the control plane, assessable on demand.

Ownership. 1st line: maintains readiness files. 2nd line: compliance owns classification and regime tracking. 3rd line: audits readiness against the binding regime.

Evidence. System classification register; Article 43 readiness files; internal dry-run assessment reports; jurisdiction scheme-tracking log.

Mappings. NIST AI RMF GOVERN/MAP (analyst mapping); ISO/IEC 42001 AIMS; EU AI Act Article 43 (sourced); SR 11-7/OCC 2011-12: validation documentation reuse; DORA, oversight-readiness analogy.

Sources. artificialintelligenceact.eu/article/43 (T1), https://artificialintelligenceact.eu/article/43/; iso.org/standard/46568.html (T1), https://www.iso.org/standard/46568.html; iso.org/standard/42006 (T1): https://www.iso.org/standard/42006.

ASR-07: Frontier-safety-framework vendor diligence

Objective. Make model providers' published safety frameworks a mandatory, structured input to third-party risk assessment of frontier-model vendors.

Control. Before onboarding or materially expanding use of a frontier-model provider, the institution obtains and reviews the provider's published safety framework (e.g., Anthropic RSP, DeepMind FSF, OpenAI Frontier/Preparedness frameworks, and the Meta, Amazon, Microsoft, and xAI equivalents), records its scope, risk thresholds, and governance commitments in the vendor file, and rates residual risk where commitments are absent or unverifiable.

Implementation (financial enterprise). Add a frontier-safety-framework section to the TPRM questionnaire; record which risk domains the framework covers and which institutional use cases fall outside them; where framework specifics are unverified in the institution's own review (as with the OpenAI Frontier Governance Framework details in this corpus, held at provisional claim), record them as unconfirmed vendor representations, not facts.

Maturity. Baseline: framework on file and reviewed at onboarding. Enhanced: framework commitments mapped to the institution's Part III controls, gaps risk-rated. Frontier: framework commitments contractually referenced with notification covenants for changes.

Ownership. 1st line: business sponsor documents intended use against framework scope. 2nd line: TPRM/model risk performs the review and rating. 3rd line: audits diligence quality.

Evidence. Vendor files with framework extracts and review memos; residual-risk ratings; contract clauses referencing framework commitments.

Mappings. NIST AI RMF GOVERN/MAP (analyst mapping); ISO/IEC 42001 AIMS (supplier processes); EU AI Act (GPAI-provider dependency; no article sourced in the sources cited here); SR 11-7/OCC 2011-12: vendor model risk; DORA, third-party ICT risk aspect.

Sources. anthropic.com/responsible-scaling-policy/rsp-v3-0 (T1), https://www.anthropic.com/responsible-scaling-policy/rsp-v3-0; storage.googleapis.com DeepMind FSF v3.0 (T1), https://storage.googleapis.com/deepmind-media/DeepMind.com/Blog/strengthening-our-frontier-safety-framework/frontier-safety-framework_3.pdf; openai.com/index/openai-frontier-governance-framework (T1, provisional claim), https://openai.com/index/openai-frontier-governance-framework/; ai.meta.com/static-resource/meta-frontier-ai-framework (T1), https://ai.meta.com/static-resource/meta-frontier-ai-framework/; assets.amazon.science Frontier Model Safety Framework (T1), https://assets.amazon.science/a7/7c/8bdade5c4eda9168f3dee6434fff/pc-amazon-frontier-model-safety-framework-2-7-final-2-9.pdf; cdn-dynmedia-1.microsoft.com Microsoft Frontier Governance Framework (T1), https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/final/en-us/microsoft-brand/documents/Microsoft-Frontier-Governance-Framework.pdf; data.x.ai xAI Risk Management Framework (T1): https://data.x.ai/2025-08-20-xai-risk-management-framework.pdf.

ASR-08: Vendor safety-framework change monitoring

Objective. Detect and assess material changes in providers' safety frameworks over the life of the relationship, not only at onboarding.

Control. The institution monitors versioned changes to each frontier provider's published safety framework (e.g., Anthropic RSP v3.0 → v3.3; DeepMind FSF 2.0 → 3.0), produces a diff-and-impact memo for each material revision, and re-rates vendor risk where commitments weaken or scope shifts.

Implementation (financial enterprise). Assign framework-watch to TPRM intelligence with a defined review SLA; treat weakened thresholds, removed commitments, or governance reassignments as risk-rating triggers routed to the model risk committee; retain superseded versions in ASR-10 so examiners can see what was relied on at each decision date.

Maturity. Baseline: annual re-review of frameworks on file. Enhanced: event-driven diff memos within the SLA of publication. Frontier: automated change detection feeding TPRM workflow with human-reviewed impact memos.

Ownership. 1st line: consumes impact memos and adjusts usage. 2nd line: operates the watch, writes memos, re-rates risk. 3rd line: audits timeliness and completeness of the watch.

Evidence. Version archive of vendor frameworks; diff-and-impact memos; risk-rating change log; committee minutes.

Mappings. NIST AI RMF GOVERN/MANAGE (analyst mapping); ISO/IEC 42001 AIMS (supplier change management); EU AI Act (no article sourced); SR 11-7/OCC 2011-12: ongoing monitoring of vendor models; DORA, third-party monitoring aspect.

Sources. anthropic.com/responsible-scaling-policy/rsp-v3-0 (T1), https://www.anthropic.com/responsible-scaling-policy/rsp-v3-0; cdn.sanity.io Anthropic RSP v3.3 (T1), https://cdn.sanity.io/files/4zrzovbb/website/c11e84981d0a7281a1b229f3fa6af0da66eaf43f.pdf; anthropic.com/rsp-updates (T2), https://www.anthropic.com/rsp-updates; deepmind.google/discover/blog/updating-the-frontier-safety-framework (T1), https://deepmind.google/discover/blog/updating-the-frontier-safety-framework/; storage.googleapis.com DeepMind FSF v3.0 (T1): https://storage.googleapis.com/deepmind-media/DeepMind.com/Blog/strengthening-our-frontier-safety-framework/frontier-safety-framework_3.pdf.

ASR-09: Transparency artifacts as mandatory audit evidence

Objective. Require standardized, current documentation artifacts for every agentic system so that audit, validation, and conformity assessment draw on the same evidence base.

Control. Every production agentic system has a system-level card: covering at minimum the nine Mitchell et al. model-card sections extended to the system level, plus dataset cards for institution-owned training/evaluation data; cards are versioned with the system and reviewed at each material change.

Implementation (financial enterprise). Store cards as machine-readable metadata per the Hugging Face model-card and dataset-card specifications where tooling permits; extend to the agent system (tool inventory and permission scopes, autonomy envelope, oversight mode, kill-switch and budget-guard settings, trajectory-level eval results) [practice guidance: not directly source-backed]; use the Meta system-card pattern as the system-level reference, with Risk Cards and Use Case Cards for deployment-risk and EU-facing documentation. Cards double as the technical-documentation core for ASR-06.

Maturity. Baseline: cards mandatory at go-live, manually maintained. Enhanced: machine-readable, versioned with releases, gaps blocking deployment. Frontier: card fields auto-populated from eval and runtime telemetry with human attestation.

Ownership. 1st line: authors and maintains cards. 2nd line: sets the template, reviews quality, enforces the deployment block. 3rd line: samples cards against actual system behavior.

Evidence. Card inventory with coverage metrics; version history tied to releases; second-line review sign-offs; audit sampling results.

Mappings. NIST AI RMF MAP/MEASURE (analyst mapping); ISO/IEC 42001 AIMS (documented information); EU AI Act: documentation overlap is a provisional interpretation; consult the primary text; SR 11-7/OCC 2011-12, model documentation standards; DORA, n/a.

Sources. arxiv.org/abs/1810.03993 (T2), https://arxiv.org/abs/1810.03993; arxiv.org/abs/2402.05160 (T1), https://arxiv.org/abs/2402.05160; huggingface.co/docs/hub/model-cards (T2), https://huggingface.co/docs/hub/model-cards; huggingface.co/docs/hub/datasets-cards (T2), https://huggingface.co/docs/hub/datasets-cards; ai.meta.com/tools/system-cards (T3), https://ai.meta.com/tools/system-cards/; arxiv.org/abs/2303.18190 (T2), https://arxiv.org/abs/2303.18190; arxiv.org/abs/2306.13701 (T2), https://arxiv.org/abs/2306.13701; arxiv.org/abs/2303.03886 (T2), https://arxiv.org/abs/2303.03886.

ASR-10: Assurance evidence repository

Objective. Preserve all assurance artifacts (assessments, audits, certificates, vendor framework versions, cards) in a trustworthy, examiner-ready repository.

Control. Assurance evidence for agentic systems is retained in a controlled repository with integrity protection, retention aligned to examination cycles, and point-in-time reconstruction (what was known and relied on at each approval date), stewarded per trustworthy-digital-repository audit principles.

Implementation (financial enterprise). Use the ISO 16363 trustworthy-digital-repository audit criteria, with ISO 16919 governing the bodies that certify such repositories, as the reference bar; integrate with books-and-records retention so AI assurance evidence inherits WORM/immutability treatment where records rules apply [practice guidance: not directly source-backed]; index artifacts by system, version, and control ID so an examiner request maps to a query, not a scramble.

Maturity. Baseline: single repository, access-controlled, retention policy applied. Enhanced: integrity verification and point-in-time reconstruction demonstrated. Frontier: repository assessed against ISO 16363-style criteria by an independent party.

Ownership. 1st line: files artifacts at defined lifecycle points. 2nd line: owns the repository, retention schedule, and indexing standard. 3rd line: tests integrity and completeness; relies on the repository for its own workpapers without controlling it.

Evidence. Repository control documentation; integrity-check logs; point-in-time reconstruction test results; examiner-request fulfillment records.

Mappings. NIST AI RMF GOVERN (analyst mapping); ISO/IEC 42001 AIMS (documented information control); EU AI Act (record-keeping obligations; no article sourced in the sources cited here); SR 11-7/OCC 2011-12: documentation and records supporting validation; DORA, ICT records aspect.

Sources. iso.org/standard/56510.html (T1), https://www.iso.org/standard/56510.html; iso.org/standard/57950.html (T2), https://www.iso.org/standard/57950.html.

IV.7 Known gaps in this Part's corpus base

Recorded for the Editor and future verification sweeps:

1. The assurance stack has no agentic-technical layer (verified headline gap): the 38507→42006 chain and the IIA framework contain no agent-evaluation, eval-validity, or oversight content. ASR controls assure process; the technical floor is Parts III.B–III.D.
2. Four of five stack standards are paywalled ISO catalog pages; only the IIA PDF is openly readable. Claims about the ISO standards' internal content are deliberately limited to scope-level statements supported by titles and the editor's verified report.
3. Unverified items respected as flagged: the NIST AI RMF crosswalk and EU AI Act harmonization mappings (findings 7–8), and all OpenAI Frontier Governance Framework specifics (threshold figures, statute anchors, Ireland board routing), remain provisional claim.
4. IIA framework scope: this report cites the framework for its existence, openness, and role; its detailed components are not established here.
5. SR 11-7 and DORA appear in Mappings as the schema requires but are not in the sources cited in this section; Part V (D8) holds the sourced regulatory text.