Jira progress: loading…

ISO 42001 Mapping

note

Can our constitutional framework be linked to ISO 42001?

Yes — it can be used as supporting assurance evidence for an ISO/IEC 42001 application, but it should not be represented as ISO 42001 certification, equivalence, or a substitute for an accredited certification assessment.

The strongest value is that the constitutional framework can provide a structured, traceable evidence base for an AI management-system assessment:

• Governed definitions and accountability: The Constitutional Metadata Dictionary establishes an authoritative, versioned vocabulary for metadata meaning, constraints, relationships, governance, lifecycle, and traceability. This can help demonstrate that AI-related controls, evidence, risks, decisions, and system records are consistently defined rather than implementation-specific. (/standards/cdf/specialised-constitutional-registries)
• Traceable assurance evidence: Stakeholder interfaces support drill-down from high-level readiness indicators to disclosure-level citations, computation logs, assurance contracts, and verifier attestations. They also support audit-ready exports and change history. (/general-information/stakeholder-interfaces)
• AI governance operational evidence: The AI Governance Dashboard is intended to expose AI SLO compliance, promotion and rollback history, go/no-go decisions, and changes in AI adapters or behaviour packs. This is potentially useful evidence of operational oversight, monitoring, and controlled change. (/general-information/stakeholder-interfaces)
• Evidence integrity, scope, and provenance: The conformance framework’s trust packages/passports preserve subject identity, applicable scope, baseline, source evidence, status, conditions, effective dates, signatures, and provenance. That makes evidence more reviewable and less dependent on unsupported assertions. (/cdf/core-conformance-and-certification-framework-4)

However, before relying on it in an ISO 42001 application, ZAYAZ should create an explicit ISO 42001 crosswalk and evidence package. The CDF specifically requires cross-scheme mappings to compare requirements, scope, assessment methods, evidence, decision rules, surveillance, lifecycle, authority, and version—not merely claim similarity based on a framework name or badge. (/cdf/core-conformance-and-certification-framework-4)

A defensible application package would therefore include:

1. The exact ISO/IEC 42001 version and the intended certification scope.
2. A requirement-by-requirement mapping from ISO requirements to ZAYAZ constitutional controls, records, and operating evidence.
3. Identified gaps, owners, compensating controls, and remediation status.
4. Evidence exports for governance decisions, AI change history, monitoring, validation, incidents/findings where applicable, and retained provenance.
5. Clear separation between:
   • ZAYAZ internal assurance/conformance evidence;
   • external auditor findings; and
   • the eventual certification decision made by the appropriate certification body.

The key claim should be: “ZAYAZ provides governed, traceable evidence that supports ISO/IEC 42001 assessment readiness.” It should not be: “ZAYAZ’s constitutional framework is ISO 42001 compliant/certified” unless an authorized external assessment has established that for the defined scope.

The indexed material does not include an existing ISO/IEC 42001-specific mapping, so equivalence or coverage cannot yet be claimed.

note

The CDF specifically requires cross-scheme mappings to compare requirements, scope, assessment methods, evidence, decision rules, surveillance, lifecycle, authority, and version—not merely claim similarity based on a framework name or badge. (/cdf/core-conformance-and-certification-framework-4). As I will apply for ISO 42001, we need to make a crosswalk and evidence package. How would we go ahead and do this (We don't need to do it now, but to know the process would be great!

Yes. The best approach is to treat this as a governed ISO/IEC 42001 certification-readiness programme, not merely a spreadsheet mapping “ZAYAZ” to “ISO 42001.”

A critical distinction comes first:

• ISO/IEC 42001:2023 is the AIMS requirements standard against which Viroway Ltd would be certified.
• The selected certification body will apply its certification programme and audit methodology.
• ISO/IEC 42006:2025 now supplies AI-specific requirements for bodies auditing and certifying ISO/IEC 42001 AIMS and supplements ISO/IEC 17021-1:2015, which governs competence, consistency and impartiality for management-system certification bodies.
• The ZAYAZ CCCF is Viroway’s internal constitutional conformance architecture. It provides the machinery for traceability, evidence, assessment, Findings and certification-readiness, but it does not replace the ISO standard or the certification body’s decision.

Therefore, the project would have three governed layers:

ISO/IEC 42001:2023 requirements
        │
        ├── Certification-body audit and scheme requirements
        │     ├── ISO/IEC 42006:2025
        │     └── ISO/IEC 17021-1:2015
        │
        ▼
Viroway AIMS implementation
        │
        ├── Governance
        ├── AI policies
        ├── AI risk and impact management
        ├── AI lifecycle controls
        ├── Supplier and model controls
        ├── Monitoring and internal audit
        └── Management review and improvement
        │
        ▼
ZAYAZ CCCF traceability and evidence layer

1. Establish the certification subject and scope

This must happen before clause mapping.

The first controlled document would be an AIMS Certification Scope Statement specifying:

Scope element	Likely Viroway decision
Certified legal entity	Viroway Ltd
Management system	Artificial Intelligence Management System
Products/services	ZAYAZ platform and associated AI-enabled services
Roles	AI system developer, provider, deployer and user, as applicable
Organisational units	Architecture, engineering, operations, security, governance, support
Locations	Registered and operational locations, including remote operations
AI systems	Exact governed inventory of production and material internal AI systems
Supporting systems	Data, models, agents, tools, infrastructure, suppliers and monitoring
Exclusions	Only justified, non-misleading exclusions
Certification claim	Exact wording to be agreed with the certification body

The scope must not simply say “ZAYAZ.” It should define the organisational AIMS boundary around the design, development, provision, operation and governance of the AI systems involved. ISO/IEC 42001 applies to organisations that provide or use AI-based products or services and specifies requirements for establishing, implementing, maintaining and continually improving an AIMS.

This produces:

• AIMS-SCOPE-001
• AIMS-ORGANISATIONAL-BOUNDARY-001
• AIMS-AI-SYSTEM-INVENTORY-001
• AIMS-APPLICABILITY-CONTEXT-001

2. Obtain the authoritative source package

The crosswalk must use authoritative, version-locked sources:

1. Licensed copy of ISO/IEC 42001:2023.
2. Any amendments, corrigenda or official interpretations applicable at the assessment date.
3. Certification-body Scheme Rulebook or certification programme.
4. Certification-body application and scope guidance.
5. Audit-stage requirements and evidence expectations.
6. Certification-body accreditation scope and current status.
7. ISO/IEC 42006:2025 as relevant to the certification body.
8. ISO/IEC 17021-1:2015 as the general management-system certification-body foundation. ISO states that ISO/IEC 42006 supplements rather than replaces ISO/IEC 17021-1.

Because the ISO text is copyrighted, our repository should normally store:

• clause identifiers;
• controlled paraphrases;
• internal interpretations;
• implementation mappings;
• evidence references;
• licensed-source metadata;

rather than reproducing the full standard text.

Each source receives a governed identifier:

source_id: EXT-ISO-IEC-42001-2023
source_type: external_standard
publisher: ISO/IEC
edition: 1
publication_date: 2023-12
status: active
licensed_copy_location: restricted://standards/iso-iec-42001-2023
content_digest: sha256:...
access_classification: restricted-copyright

3. Build the ISO requirement register

Each auditable requirement would become a versioned CCCF ConformanceRequirement.

A record would look conceptually like:

requirement_id: ISO42001-REQ-0001
source_id: EXT-ISO-IEC-42001-2023
source_clause: "<licensed clause reference>"
requirement_class:
  - management_system
  - governance
normative_force: SHALL
subject_classes:
  - organisation
  - aims
applicability:
  organisation: Viroway Ltd
  products:
    - ZAYAZ
effective_from: 2023-12
interpretation_status: approved
owner: aims-governance-owner

The register should separately classify:

• mandatory management-system requirements;
• applicable Annex A controls;
• documented-information requirements;
• records expected as evidence;
• recurring operational requirements;
• management-review requirements;
• internal-audit requirements;
• improvement and corrective-action requirements.

Do not begin by asking “Which ZAYAZ document resembles this clause?” Begin with:

What exact organisational state does this requirement expect, and what evidence would demonstrate design and operating effectiveness?

4. Create the crosswalk as a multidimensional mapping

The crosswalk should not be a simple two-column clause comparison.

Each row should include at least:

Field	Purpose
ISO requirement ID	Exact external source requirement
ISO version	Prevents stale mapping
Requirement interpretation	Controlled Viroway interpretation
Applicability	Applicable, conditional, not applicable or unresolved
Applicability rationale	Why the decision was made
AIMS process	Organisational process satisfying the requirement
Control objective	Intended governed result
Control ID	Specific implemented control
Control owner	Accountable person or Role
Module	ZAYAZ top-level domain involved
Component	Implementing engine, service, registry, agent or workflow
Evidence requirement	Evidence needed
Evidence object IDs	Actual evidence
Assessment method	Inspection, observation, reperformance, sampling or automated test
Operating period	Period over which effectiveness must be shown
Finding status	Open, conformant, deficient or indeterminate
Gap classification	Design, implementation, operation, evidence or scope
Remediation	Action, owner and date
Certification effect	Informational, major or certification-blocking
Provenance	Source, reviewer, time and version

A representative structure:

ISO Requirement
   ├── Applicability Decision
   ├── Viroway AIMS Process
   ├── Control Objective
   ├── Control
   │     ├── Accountable Role
   │     ├── Module
   │     └── Component
   ├── Assessment Method
   ├── Evidence Requirement
   ├── Evidence Objects
   ├── Test or Inspection
   ├── Finding
   └── Readiness Outcome

5. Keep two mappings separate

We should create two related but distinct crosswalks.

A. ISO implementation crosswalk

This answers:

How does Viroway’s AIMS satisfy each ISO/IEC 42001 requirement?

ISO requirement
    → Viroway process
    → control
    → owner
    → evidence
    → assessment
    → Finding

B. Certification-scheme crosswalk

This answers:

How will the certification body assess that requirement, and what procedural rules govern the audit and Decision?

ISO requirement
    → certification-body audit method
    → evidence expectation
    → sampling or interview expectation
    → audit-stage treatment
    → nonconformity classification
    → certification consequence
    → surveillance treatment

This second mapping is where the CCCF requirements concerning assessment method, evidence, decision rules, surveillance, authority, lifecycle and version become especially important.

6. Establish the AIMS control architecture

The ISO requirements would then be implemented through a governed Viroway AIMS control library.

Likely control domains include:

• organisational context and interested parties;
• AIMS scope and boundaries;
• leadership and accountability;
• AI policy;
• AI Roles, responsibilities and delegated authority;
• AI risk and opportunity management;
• AI impact assessment;
• AI system inventory and classification;
• AI lifecycle governance;
• data governance;
• model and provider governance;
• human oversight;
• transparency and information provision;
• AI competence and awareness;
• controlled documentation;
• operational planning;
• supplier and third-party controls;
• incident management;
• monitoring and measurement;
• internal audit;
• management review;
• nonconformity and corrective action;
• continual improvement.

For ZAYAZ, each control should preserve both Module and Component lineage.

Example:

control_id: AIMS-CTRL-AI-INVENTORY-001
control_objective: >
  Ensure that all material AI systems within the AIMS scope are
  identified, classified, owned and lifecycle-governed.

accountable_role: Head of AIMS Governance

module_lineage:
  - constitutional-governance
  - artificial-intelligence-governance

component_lineage:
  - ai-system-registry
  - agent-registry
  - model-registry
  - runtime-manifest-service

control_type: preventive_and_detective
frequency: continuous
evidence:
  - AI system inventory export
  - Registry integrity receipt
  - quarterly ownership review
  - unregistered-system detection report

7. Build the evidence catalogue before collecting files

Evidence should not be gathered as an uncontrolled folder of policies and screenshots.

Create an Evidence Requirement Catalogue first.

Each evidence requirement should specify:

• evidence class;
• source system;
• owner;
• required content;
• relevant period;
• freshness;
• integrity requirements;
• approval state;
• confidentiality;
• retention;
• related ISO requirements;
• related controls;
• expected audit method.

Example evidence classes:

Evidence class	Typical contents
Governance evidence	AIMS Charter, policy, committee mandates, delegated authority
Scope evidence	AIMS boundary, legal entity, locations, AI inventory
Risk evidence	Risk methodology, risk register, treatment plans, acceptance records
Impact evidence	AI impact assessments and review decisions
Operational evidence	Workflow receipts, approvals, model releases, monitoring records
Competence evidence	Role requirements, training, evaluations and authorisations
Supplier evidence	Due diligence, contracts, monitoring and service reviews
Internal-audit evidence	Audit programme, plans, Findings and closure
Management-review evidence	Inputs, decisions, actions and follow-up
Improvement evidence	Incidents, corrective actions, root-cause analysis and validation
Technical evidence	Registries, logs, Runtime Manifests, model cards and test receipts

8. Produce clause-level Evidence Packages

Rather than one enormous audit folder, create modular Evidence Packages.

A package might be:

EP-ISO42001-AI-RISK-001/
├── manifest.yaml
├── scope.md
├── requirement-map.yaml
├── control-map.yaml
├── evidence-index.yaml
├── policies/
├── procedures/
├── records/
├── runtime-receipts/
├── samples/
├── test-results/
├── findings/
├── limitations.md
└── signatures/

The Manifest would identify:

• Package ID and version;
• ISO source version;
• mapped clause IDs;
• AIMS scope;
• subject period;
• evidence inventory;
• content digests;
• evidence owners;
• redactions;
• known limitations;
• reviewer;
• approval;
• provenance.

Evidence Package integrity can be protected using hashes, immutable repository history and signed release records.

9. Run readiness assessment in three passes

Pass 1 — Design adequacy

Determine whether the AIMS has:

• the required processes;
• appropriate policies;
• defined Controls;
• accountable owners;
• defined evidence;
• appropriate governance.

Outcome examples:

• Designed;
• Partially Designed;
• Missing;
• Applicability Unresolved.

Pass 2 — Implementation

Determine whether the designed processes and Controls have actually been deployed across the stated scope.

Outcome examples:

• Implemented;
• Partially Implemented;
• Not Implemented;
• Scope Mismatch.

Pass 3 — Operating effectiveness

Determine whether the Controls have operated over an adequate period and produced reliable records.

Outcome examples:

• Operating Effectively;
• Operating with Exceptions;
• Ineffective;
• Insufficient Operating Period;
• Insufficient Evidence.

This separation is essential. A well-written policy demonstrates design intent; it does not prove that the Control has operated.

10. Create the certification-readiness finding model

Every gap should become a governed CCCF Finding, not a comment in a spreadsheet.

finding_id: AIMS-FND-0042
iso_requirement_id: ISO42001-REQ-...
subject: AIMS-CTRL-...
finding_class: operating_effectiveness_deficiency
severity: major_readiness_gap
observed_state: >
  Supplier AI model reviews were documented for only part of the
  assessment population.
expected_state: >
  Reviews completed and retained for the full applicable supplier
  population.
evidence:
  - EP-SUPPLIER-003
affected_scope:
  - zayaz-production
  - external-model-providers
root_cause: incomplete supplier onboarding workflow
remediation_owner: supplier-governance-owner
target_date: ...
certification_effect: potentially_blocking

The readiness outcome should distinguish:

• Ready;
• Ready with controlled actions;
• Partially ready;
• Not ready;
• Indeterminate.

“Evidence not found” must not become “not applicable.”

11. Conduct an internal audit independently

The ISO-readiness implementation team should not be the sole internal-audit team.

The internal audit should evaluate:

• requirement applicability;
• scope completeness;
• implementation;
• operating effectiveness;
• evidence integrity;
• nonconformities;
• prior remediation;
• management-system effectiveness.

The internal audit package should include:

• approved audit programme;
• audit plan;
• auditor competence;
• independence statement;
• sampling plan;
• audit evidence;
• Findings;
• responses;
• corrective actions;
• closure validation.

12. Hold a formal management review

Before certification audit, Viroway leadership should conduct a documented AIMS management review based on controlled inputs such as:

• internal-audit results;
• status of actions;
• changes affecting the AIMS;
• AI risk and opportunity state;
• incidents;
• monitoring results;
• objectives;
• resource adequacy;
• supplier issues;
• stakeholder concerns;
• improvement opportunities.

The outputs should include identifiable Decisions, owners, dates and follow-up—not merely meeting minutes.

13. Select the certification body early

The certification body should be engaged before the Evidence Package is finalised.

Viroway should verify:

• whether the body certifies ISO/IEC 42001;
• its certification and accreditation scope;
• which accreditation body stands behind it;
• how it has implemented ISO/IEC 42006:2025;
• auditor competence in AI and software platforms;
• experience with SaaS, multi-tenant systems and AI providers;
• expected scope wording;
• audit methodology;
• audit duration assumptions;
• remote and on-site expectations;
• treatment of integrated management systems;
• surveillance cadence;
• Certificate and public-Registry model.

ISO/IEC 42006:2025 is specifically intended for bodies auditing and certifying ISO/IEC 42001 AIMS and addresses the specialised competence and rigour needed for AI management-system audits.

The selected body’s Scheme details then become part of the controlled crosswalk.

14. Assemble the final certification Evidence Package

The final package should include:

ISO-42001-CERTIFICATION-PACKAGE/
├── 00-manifest/
├── 01-scope-and-context/
├── 02-requirement-register/
├── 03-applicability-register/
├── 04-crosswalk/
├── 05-aims-control-library/
├── 06-ai-system-inventory/
├── 07-risk-and-impact/
├── 08-policies-and-procedures/
├── 09-operational-records/
├── 10-monitoring-and-measurement/
├── 11-internal-audit/
├── 12-management-review/
├── 13-findings-and-remediation/
├── 14-certification-body-requirements/
├── 15-readiness-assessment/
├── 16-evidence-index/
└── 17-provenance-and-signatures/

The core deliverables would be:

1. AIMS Scope and Boundary Statement
2. AI System and Role Inventory
3. ISO/IEC 42001 Requirement Register
4. Applicability Register
5. ISO-to-Viroway Control Crosswalk
6. Certification-Scheme Crosswalk
7. AIMS Control Library
8. Conformance Traceability Matrix
9. Evidence Requirement Catalogue
10. Evidence Package Set
11. Gap and Remediation Register
12. Internal Audit Package
13. Management Review Package
14. Certification Readiness Assessment Package

What we should claim—and not claim

Before the external Certification Decision, the mapping may support statements such as:

• “ISO/IEC 42001 implementation crosswalk completed.”
• “Internal readiness assessment completed.”
• “Evidence Package prepared for certification assessment.”
• “Viroway’s AIMS has been internally assessed against ISO/IEC 42001:2023.”

It should not support:

• “ISO 42001 certified.”
• “Equivalent to ISO 42001 certification.”
• “ISO approved.”
• “Fully compliant,” unless the exact scope, assessment authority and limitations justify that language.

The strategic ZAYAZ advantage

This work should not be treated as a one-off compliance exercise. It can become the first production deployment of the CCCF:

ISO source ingestion
    → Requirement Registry
    → Applicability resolution
    → Control mapping
    → Module and Component lineage
    → Evidence collection
    → HECATE validation
    → Findings and remediation
    → Assessment Package
    → External certification
    → Surveillance
    → Continuous Trust State

That gives Viroway two outcomes simultaneously:

1. A regulator-grade ISO/IEC 42001 AIMS certification programme.
2. A reference implementation showing how ZAYAZ can manage external standards, evidence, audit readiness and certification lifecycles for customers.

The practical starting point later should be a four-artifact foundation: the Certification Scope Statement, ISO Requirement Register, AI System Inventory and multidimensional Crosswalk schema. Everything else can then be generated and governed from those objects.

---