GAISSF to CRO 021 Crosswalk

Methodology Note

This brief summarizes the coordinated CRO-021 Technical Report. ISO/IEC 23894:2023 document identity and structure were confirmed from official metadata and an authorized preview. Detailed mappings are analytical and require revalidation when licensed full text becomes available. ISO/IEC 23894 is guidance, not a certifiable requirements standard.

Executive Decision

Adopt ISO/IEC 23894-aligned risk documentation as the common governance layer, but do not substitute it for GAISSF technical validation. Risk records explain why a treatment was selected; GAISSF VTS evidence demonstrates whether the treatment operates effectively.

Decision Boundaries

1. Evidence Reuse and Assurance Boundary

Evidence that can be reused

• AI risk policy, scope, context and risk criteria.
• Risk registers, scenario analysis, treatment plans and residual-risk approvals.
• Roles, consultation records, monitoring results and management reporting.
• Lifecycle and change-review records that remain current and within the same assessment boundary.

Evidence that still requires GAISSF validation

• Runtime adversarial, prompt-injection, jailbreak and tool-abuse testing.
• Model-integrity, provenance, drift, extraction and cryptographic testing.
• Agent authority, memory, inter-agent trust and exfiltration safeguards.
• Content-safety, privacy, supply-chain and regulatory evidence checks.
• Physical-AI HIL or certified-simulator tests and signed evidence.

Acceptance test for reused evidence

2. Coverage and Lifecycle Implications

The mapping covers all 59 GAISSF controls. Governance and regulatory controls align most strongly with ISO/IEC 23894 risk processes; technical runtime, agentic and physical controls retain the largest validation gap.

Notably absent from risk guidance alone

• Attack corpora and technical thresholds.
• Agent memory isolation and least-agency enforcement.
• Content, privacy and watermark robustness criteria.
• Actuator interlocks, safe-state timing and emergency-stop latency.
• Universal acceptable-risk, fairness, safety or legal-compliance thresholds.

3. Financial and Governance Framing

Evidence-Reuse Economics

Use a transparent planning formula rather than a generic savings claim:

Estimated Audit Efficiency Gain = (hours of redundant risk documentation avoided × blended hourly rate) - incremental GAISSF VTS execution cost.

Illustrative planning example only: 80 avoided hours × $120/hour - $4,000 VTS execution = $5,600 estimated net efficiency gain. Confidence range: ±15%. Actual results depend on evidence quality, scope overlap, assessor acceptance, automation and test complexity.

Governance controls

• Approve reuse only after scope, authenticity, currency, completeness and effectiveness checks.
• Maintain one risk-to-control-to-VTS traceability chain.
• Assign owners for treatment, residual-risk approval and revalidation.
• Treat demo or mock HIL output as engineering evidence only.
• Record expiry dates and trigger-based review conditions for reused evidence.

Incident response maturity

D6-CTL-04 retains its normative tabletop/readiness validation. More mature organizations may add an automated playbook profile for detection, containment, rollback, evidence capture and escalation. This is supplementary assurance and does not create a new GAISSF control.

4. Risks, Review Triggers and Recommended Action

Primary limitations

• The mapping is not full-text verified against a licensed ISO/IEC 23894 copy.
• Alignment does not establish certification, conformity, legal compliance or technical effectiveness.
• ISO risk guidance does not define GAISSF pass criteria or universal acceptable-risk thresholds.
• System, threat, regulatory or source changes can invalidate earlier evidence-reuse decisions.

Mandatory review triggers

Recommended operating action

Use CRO-021 as the common risk-alignment and evidence-reuse layer. Require GAISSF VTS or equivalent independent verification before claiming that a technical control is operating effectively. Revalidate annually, after material changes and when a licensed ISO/IEC 23894 text becomes available.

Full technical mapping — GAISSF to ISO/IEC 23894

The summary above is the Executive Brief companion. The complete source-bounded technical mapping — methodology, evidence-tier model, the full 59-control mapping register, reverse process index and practitioner annexes — follows in full below.

Executive Summary

CRO-021 maps the 59-control GAISSF v1.0 baseline to the publicly verifiable structure of ISO/IEC 23894:2023. It supports risk-register integration, evidence reuse and treatment traceability while preserving a strict distinction between risk-management process evidence and technical control-effectiveness evidence.

This edition is source-bounded. The clause structure is confirmed from official and authorized sources; detailed semantic alignments are ODA3 analytical inferences pending access to the complete licensed standard. The mapping therefore does not claim full-text verification, conformity, certification or equivalence.

1. Purpose and Intended Use

This report provides a controlled crosswalk for aligning GAISSF control implementation with AI risk-management activities, reusing qualified risk evidence, identifying residual technical validation and planning future full-text re-verification.

2. Source Boundary and Authority

The external source baseline is ISO/IEC 23894:2023. The exact external sources used are the ISO official standard record and abstract, together with the ANSI-authorized five-page preview. The complete licensed text was not available. GAISSF-NOR-001, GAISSF-NOR-004, the GAISSF evidence schema and the actual GAISSF VTS v1.0.1 release package are the primary controlled GAISSF sources.

3. Evidence-Tier Model

The report uses inline evidence-tier tags in Sections 4-8 so readers can distinguish controlled evidence from source-bounded inference and recommendations.

4. Mapping Methodology

[T1] GAISSF control identifiers, titles, VTS identifiers, test paths, test designs, pass criteria and evidence artifacts were derived from the controlled GAISSF v1.0 normative and VTS release materials.

[T2] The ISO/IEC 23894 document identity, clause hierarchy and annex headings were confirmed using the ISO official record and the ANSI-authorized five-page preview.

[T3] Each semantic mapping compares risk objective, scope, affected lifecycle stage, evidence, treatment and review purpose. Keyword similarity alone is not treated as alignment.

[T3] Relationship ratings are Strong partial, Partial, Supporting or Contextual. No rating means equivalence, conformity, certification or automatic evidence acceptance.

[T4] Every record includes a re-validation trigger and an ODA3-derived risk extension to operationalize GAISSF evidence needs without presenting those fields as ISO requirements.

5. Why the ODA3-Derived Risk Extension Is Necessary

[T2] ISO/IEC 23894 provides risk-management guidance and a process structure for identifying, analysing, evaluating, treating, monitoring and recording AI risk.

[T3] GAISSF additionally requires control-specific, testable and auditable technical outcomes. The ODA3-derived extension therefore specifies the data fields needed to connect a risk-treatment decision to a GAISSF control, its VTS, its acceptance criteria and its signed evidence.

[T4] In practical terms: the ISO-aligned process establishes that a treatment plan should exist; the ODA3 extension records the system boundary, scenario, stakeholder, owner, treatment, measurable acceptance criterion, VTS evidence, residual risk and review trigger needed for GAISSF assurance.

6. Evidence Reuse and Validation Rules

[T1] Reusable GAISSF evidence must remain relevant, authentic, traceable, complete, current and linked to the assessed scope. Certification-grade evidence must demonstrate implementation and operating effectiveness, not policy intent alone.

[T3] ISO-aligned risk registers, treatment plans, approvals, consultation records, monitoring results and review records can be reused only after scope, authenticity, currency, completeness and effectiveness qualification.

[T1] The exact VTS package path is recorded as oda3-gaissf-vts/tests/...; the shorter tests/... path remains the repository-relative test location. Demo or mock HIL output is not certification evidence.

[T4] For D6-CTL-04, organizations may add a supplementary automated incident-response validation profile for detection, containment, rollback, evidence capture and escalation. This is a recommended extension, not a new GAISSF control.

7. Relationship and Confidence Interpretation

[T3] Governance and regulatory controls generally receive Strong partial / Medium-High ratings because ISO/IEC 23894 structurally addresses governance, ownership, assessment, treatment, monitoring and reporting, while GAISSF adds precise technical mechanisms and test evidence.

[T3] Runtime, adversarial, agentic and physical-AI controls generally receive Supporting / Medium ratings because risk-management guidance can justify and monitor treatment but does not define attack corpora, technical thresholds, memory isolation, actuator interlocks or HIL pass criteria.

[T3] Shadow AI receives stronger alignment where discovery, ownership, context, treatment and monitoring form the primary control outcome, but GAISSF still requires explicit discovery coverage and evidence.

8. Coverage Summary and Lifecycle View

[T3] The complete 59-control register is placed in Annex B to preserve the narrative flow of the Technical Report. Annex C provides the reverse ISO-process index.

9. Operational Use Model

• Use the risk register to identify the AI asset, scenario, affected stakeholders, uncertainty, likelihood, consequence and owner.

• Link each selected treatment to the relevant GAISSF control and VTS record.

• Qualify existing evidence before reuse and record any scope or freshness limitation.

• Execute the VTS or an independently equivalent test where process evidence does not demonstrate the technical outcome.

• Record residual risk, acceptance authority, expiry and review trigger.

• Revalidate at least annually and whenever the control-specific trigger in Annex B occurs.

10. Regulatory and Standards Evolution

Regulatory and standards references evolve. D8 evidence and mappings shall be reviewed at least annually and whenever authoritative legislation, regulatory guidance, enforcement practice, ISO publications or GAISSF controlled sources change. A revision that materially affects scope, interpretation, evidence or technical validation shall trigger controlled downstream impact analysis.

11. Notably Absent from ISO/IEC 23894 Risk Guidance

The following capabilities are not demonstrated merely by following a risk-management process and remain subject to GAISSF-specific implementation and VTS evidence:

• Runtime adversarial-defense thresholds for prompt injection, jailbreaks, multimodal attacks, tool-call abuse and cross-context hijacking.

• Model-integrity pass criteria for poisoning, extraction, drift, federated learning, embeddings, adapters, merges, quantization and cryptographic hardening.

• Agentic enforcement mechanisms for least agency, inter-agent trust, chained prompts, memory isolation, exfiltration prevention and secure memory lifecycle.

• Control-specific supply-chain test procedures for AI BOMs, model scanning, registry vetting, MCP behavior, external APIs, shadow AI and dependency analysis.

• Content-safety and privacy evaluation thresholds for harmful content, PII leakage, copyright, watermarking and privacy-preserving ML.

• Control-specific operating-effectiveness evidence for human intervention, audit trails, model cards, incident readiness, decommissioning, vendor governance and resilience.

• Physical-AI HIL pass criteria for harm boundaries, safe states, emergency stops, cyber-physical detection, sensor integrity, actuator commands and incident evidence preservation.

• Universal legal compliance, sector approval, fairness, safety or acceptable residual-risk thresholds.

12. Publication, Claims and Change-Control Rules

• Publish CRO-021 as informative, source-bounded and version-controlled.

• Do not claim full-text verification until a licensed ISO/IEC 23894:2023 copy has been reviewed.

• Do not describe ISO/IEC 23894 as a certifiable requirements standard or claim that alignment demonstrates certification.

• Do not redistribute protected ISO/IEC text or the preview.

• Publish the Technical Report, Executive Brief, XLSX register, JSON register, version history and checksum manifest as one coordinated package.

• Record every mapping, source, VTS, schema or claims change in version_history.md.

Annex A - Register Field Definitions

Annex B - 59-Control Mapping Register

Annex C - Reverse ISO/IEC 23894 Process Index

Annex D - GAISSF Domain to AI Lifecycle Map

Annex E - Domain-Level Practitioner Interpretation

D1 - Model Integrity & Adversarial Robustness

ISO/IEC 23894 can structure the identification, analysis, treatment and monitoring of model-integrity risks, but the risk process does not establish poisoning-detection thresholds, extraction resistance, drift tolerances, embedding robustness or cryptographic acceptance criteria. Reuse context, risk-owner, treatment and monitoring records; retain GAISSF VTS results as the operating-effectiveness evidence.

D2 - Runtime Security & Adversarial Defense

The ISO risk process helps define misuse scenarios, affected stakeholders, likelihood, consequence, treatment priority and monitoring. It does not prescribe prompt-injection corpora, jailbreak success thresholds, multimodal attack coverage, tool-call restrictions or cross-context isolation. Runtime tests should be repeated after prompt, model, tool, retrieval or interface changes.

D3 - Agentic Risk & Autonomous System Security

Agentic risks require explicit authority boundaries, action inventories, tool permissions, trust relationships, memory controls and human intervention points. ISO-aligned risk records can justify those decisions, while GAISSF VTS evidence demonstrates whether least agency, inter-agent security, prompt-chain detection, memory isolation and embodied safeguards operate as intended.

D4 - Supply Chain & Third-Party AI Security

Supplier and dependency risks align well with context, communication, treatment, monitoring and review. However, evidence reuse is valid only where the same supplier, model, API, MCP server, artifact, version and deployment context remain in scope. AI BOM, scanning, registry-vetting, behavioral-monitoring and SCA evidence should be refreshed after supplier or component change.

D5 - Content Safety & Output Integrity

Risk-management records can document harmful-output, privacy, copyright and transparency scenarios and treatment choices. They do not define universal content thresholds, leakage tolerances, watermark robustness or privacy-preserving ML acceptance criteria. Evaluation datasets, policies and legal assumptions should be versioned with each VTS result.

D6 - Governance, Accountability & Human Oversight

This domain has the strongest process alignment because ISO/IEC 23894 emphasizes governance, accountability, resources, communication, evaluation and improvement. The remaining gap is operating-effectiveness evidence: intervention timing, audit completeness, model-card sufficiency, incident exercise performance, decommissioning closure, vendor oversight and resilience test results.

D7 - Human & Societal Harms

The ISO risk structure supports stakeholder identification, consultation, harm scenarios, treatment and monitoring. GAISSF adds concrete simulation, training, authentication and response evidence. Organizations should reassess these controls when threat tactics, user populations, communication channels or societal impact assumptions change.

D8 - Regulatory Alignment & Compliance

Risk and governance records can support regulatory mapping and evidence traceability, but legal applicability and authoritative guidance change over time. D8 evidence should be reviewed at least annually and whenever a jurisdiction, sector, intended use, model classification, reporting rule or enforcement position changes.

D9 - Physical AI Safety

Physical-AI controls require system-specific safety envelopes and HIL or certified-simulator evidence. ISO risk guidance can support hazard scenarios, risk criteria, treatment selection and monitoring, but it does not establish stopping distances, emergency-stop latency, sensor-failure response, actuator-command limits or incident-evidence timing. Mock-mode CI output is not physical certification evidence.

Annex F - Re-validation Decision Workflow

A mapping or evidence-reuse decision should be reopened when any of the following events occurs. The record-level trigger in Annex B is controlling where it is more specific.

Evidence Reuse Decision Record

• Identify the original evidence owner, source system, collection date and assessed scope.

• Confirm that the current AI system, model, data, environment, supplier and intended use remain materially equivalent.

• Verify authenticity, integrity, completeness, retention and chain of custody.

• Determine whether the evidence demonstrates process completion, implementation or operating effectiveness.

• Record accepted limitations, compensating tests, residual gaps, approval and expiry date.

• Link the decision to the GAISSF control, VTS ID and re-validation trigger.