ISO 42001 Annex A Control Mapping

The organization's uploaded AI policy, versioned and dated, is stored as compliance evidence and linked to this control. The platform stores and links the policy; it does not author it.

Cross-references between the AI policy and existing security, privacy and risk policies, recorded as linked evidence.

The compliance calendar schedules the recurring policy review as an internal milestone; the reviewed policy, with its review date, is uploaded as evidence.

RBAC role assignments and the RACI roles recorded on each governance review request.

Review request submission and the governance review board's escalation path give staff a route to raise a concern about an AI system.

Model cards record a system's training data and architecture. The wider resource catalogue (compute, tooling, people) is documented by the organization and uploaded as evidence.

Data lineage tracing and the prediction/feature inputs recorded for a model.

The model card's architecture and model-type fields record what a model was built with. The tooling inventory itself (libraries, frameworks, pipeline) is maintained by the organization and uploaded as evidence.

The platform does not track a model's infrastructure or hosting. Compute and hosting are evidenced by cloud-provider records the organization uploads.

Competence records for the people who build, review and approve AI systems.

The model register's governance dossier brings a system's risk classification and fairness audit results together as inputs to its impact assessment. The assessment process itself is documented by the organization and stored as evidence.

Impact assessment documents are stored as evidence with a sign-off workflow (approval status, approver and timestamp), and the audit trail records each change to them.

Fairness audits across protected attributes using the supported fairness metrics, with a severity rating and recommended mitigation for any disparity found.

Model cards record each system's ethical considerations and its social, environmental and human-life impact. The organization's own societal-impact assessment (economic, democratic and labor effects included) is uploaded and linked as evidence; the platform does not compute societal impact.

Trust score component weights and per-model performance thresholds recorded as measurable development objectives.

The organization's model-development process documentation, covering how risk, ethics and safety checks are embedded before a model reaches the register.

Model registration records a system's declared features, model type and description, and the model card adds its intended use, together forming the specification record.

The model card's architecture, training approach and parameter documentation.

Baseline metrics recorded at registration and the model comparison view evidence validation before promotion. WhiteBox archives adversarial red teaming evidence; customers provide test reports from tools like Promptfoo or Mindgard.

The lifecycle-stage transition to production, gated by a review board decision where one is required.

Drift detection and performance monitoring, alerting when a threshold is breached.

The model card, and regulatory documentation records (each with a requirement reference such as Annex IV or Article 11) for EU AI Act systems.

The immutable audit trail's event log for every action taken against a model or its governance records.

Datasheets record each dataset's purpose, composition, splits and recommended uses, and the model card records a system's training data description and sources.

Datasheets record each dataset's acquisition method, sampling strategy, collection timeframe, licence and ethical review. Whether sourcing was lawful is attested by the organization, not checked by the platform.

Data lineage nodes carry a quality status, datasheets record missing-data characteristics, and drift monitoring flags shifts in input distributions. The platform does not compute feature-level data-quality metrics; the organization's data-quality reports are uploaded as evidence.

Data lineage records each dataset's source and the transformations applied to it, and a prediction can be traced back to the input record that produced it.

Datasheets record cleaning and preprocessing steps and the labeling process, and the model card records a system's data preprocessing.

Published model cards give downstream users a system's intended use, limitations and performance, and explainability outputs (SHAP/LIME) show what drove an individual prediction.

The breach register records whether and when a supervisory authority was notified. Other external disclosures (regulator filings, customer or public reports) are made by the organization, and their records are uploaded as evidence.

The breach register (with its authority-notification history) and the security-incident log record what happened and who was told.

Model cards can be published with a public URL, and compliance reports can be exported for regulators, auditors and customers; the organization decides who receives them.

Acceptable-use guidance for internal consumers of a model, recorded as a policy document.

Governance review decisions and the RACI roles on each review request record who holds decision authority over a model's release. The organization's human-oversight objectives (human-in-the-loop review, override authority) are documented by the organization and uploaded as evidence; the platform has no per-model human-oversight field.

The model card's stated intended uses, intended users and out-of-scope uses. The platform records the documented scope; it does not itself detect use outside it.

Vendor and foundation-model-provider agreements, uploaded as evidence and linked to the systems that depend on them.

The organization's vendor assessments for any third-party model, dataset or API a system depends on, uploaded as evidence. The platform has no vendor-assessment workflow of its own.

The model card and terms-of-use documentation given to customers who consume a model's predictions or API.