Five mapping points to ISO/IEC 42001 that ISO/IEC 22989 alone won't surface
When you prepare for ISO/IEC 42001 certification with a machine-learning-based AI system, there are five mapping points that ISO/IEC 22989 alone does not reveal. ISO/IEC 23053 defines the components and pipeline of an ML system, and it is the standard that meshes most tightly with ISO/IEC 42001's Annex A controls. This page reads ISO/IEC 23053 from an ISO/IEC 42001 audit perspective and sets out five places where the mapping is easy to leave incomplete in practice.
Scope note
This overview is based on the published text of ISO/IEC 23053:2022, read alongside ISO/IEC 22989:2022 and ISO/IEC 42001:2023. Where a term could be ambiguous, the standard's wording is used. For formal citation or document submission, refer to the official standard text.
What is ISO/IEC 23053?
If ISO/IEC 22989 is the concept map of AI systems as a whole, ISO/IEC 23053:2022 — Framework for Artificial Intelligence (AI) Systems Using Machine Learning (ML) — makes the components, approaches, and pipeline concrete for ML systems specifically. It takes ISO/IEC 22989 as a normative reference and layers ML-specific terminology and structure on top.
It matters in ISO/IEC 42001 practice because, for an organization running ML-based AI, many Annex A controls — A.6.2.3 (design and development documentation), A.6.2.4 (verification and validation), A.6.2.6 (operation and monitoring), A.7 (data for AI systems), and A.10 (third-party relationships) — use ML pipeline artifacts as their core evidence. ISO/IEC 42001 preparation documents written from ISO/IEC 22989 alone often lack the per-stage ML detail; ISO/IEC 23053 supplies it.
At a glance — the five mappings
| ISO/IEC 23053 clause | ISO/IEC 42001 Annex A | The point easy to miss |
|---|---|---|
| 8.3 Data preparation | A.7.4 / A.7.5 / A.7.6 | The decision rationale for the eight sub-steps, and de-identification evidence |
| 8.4 Modeling | A.6.2.2 / A.6.2.3 | The reason for the algorithm choice, and the hyperparameter tuning history |
| 6.5.5 / 8.5 Verification & validation | A.6.2.4 | Justifying the choice of metric; keeping test and validation data separate |
| 6.3 / 8.7 Operation | A.6.2.6 | Drift-monitoring thresholds and the retraining trigger |
| 6.1 / 7.7 Pre-trained & transfer learning | A.10 | Provenance and license tracking for external pre-trained models and datasets |
Key point 1 — Data preparation: all eight steps are evidence (A.7)
In 8.3, ISO/IEC 23053 spells out data preparation as eight sub-processes: exploring → data wrangling → cleaning → imputation → normalization and scaling → dataset composition → dataset splitting → labeling. The standard is clear that the order is not fixed and varies by use case.
Two gaps can surface in an audit.
First, a sentence that says "we preprocessed the data," with no evidence of which of the eight steps were done and on what basis. Imputation, for example, splits into single and multiple imputation, and single imputation again into hot-deck, cold-deck, regression, mean-value, and other options. Documentation showing which method was applied to which missing data — and whether its assumptions hold — is the heart of A.7.4 (data quality) evidence.
Second, de-identification evidence. ISO/IEC 23053 names the need to de-identify PII and PHI during data preparation, citing ISO/IEC 20889. "De-identification" is not the same concept as "anonymization": anonymization means a state that cannot be re-identified, while de-identification is the broader process of severing the link between identifying attributes and the data subject. A document that uses the two interchangeably — common with health or financial data — can draw a re-check at audit.
In addition, the disjointness and distributional similarity of training, validation, and test data is direct A.7.4 evidence. ISO/IEC 23053 calls for keeping training, validation, and test data separate from each other for trustworthy ML. Where they are split from one source, documenting the split method and comparing the resulting distributions is worthwhile.
Key point 2 — The rationale for algorithm selection and hyperparameter tuning (A.6.2.2 / A.6.2.3)
In modeling (8.4), ISO/IEC 23053 clearly separates feature engineering → algorithm selection → model training → model selection. "Model selection" specifically means hyperparameter tuning — evaluating and optimizing hyperparameter combinations using validation data.
The biggest gap you can meet at audit is the absence of documentation for "why this algorithm was chosen." The code repository may show a neural network was used, but the record of whether the task is regression, classification, or clustering — and why an NN rather than a decision tree or SVM — is easy to leave out. ISO/IEC 42001 A.6.2.2 (system requirements and specification) and A.6.2.3 (design and development documentation) require this decision to be traceable.
The second gap is the hyperparameter tuning history. ISO/IEC 23053 names concrete techniques in model selection: exhaustive grid search, random parameter optimization, k-fold cross-validation, leave-one-out. The strongest evidence is the log from an experiment-tracking tool (MLflow, Weights & Biases) attached directly. Without a log, at least the final hyperparameters adopted, the candidate ranges, and the selection criteria should be on record.
Key point 3 — Justifying the evaluation metric (A.6.2.4)
Clause 6.5.5.1 of ISO/IEC 23053 carries a clear caution: leaning on a single aggregate metric — even one like the F1 score — is risky without close inspection of the detailed results, and class imbalance in the training data is a confounder that can distort various metrics. From an audit perspective this is the starting point for building A.6.2.4 (verification and validation) evidence. Three gaps to check:
(1) Using accuracy alone on imbalanced data. On tasks where the positive class is rare — medical diagnosis, fraud detection, anomaly detection — accuracy comes out high almost by default. ISO/IEC 23053 explains the danger of single-metric reliance and the class-imbalance problem, and stresses reviewing a combination of metrics as the situation requires. Which combination was chosen, and why, belongs on the first page of the validation document.
(2) Confusing test data and validation data. ISO/IEC 23053 distinguishes the two strictly: validation data is used for hyperparameter tuning, test data for final model evaluation. The standard explicitly warns in 8.5 that model selection must not be performed against the test data. The moment you select a model on test data, you are effectively overfitting hyperparameters to it, and the generalization estimate collapses.
(3) Using Cohen's kappa as a standalone performance metric. ISO/IEC 23053 notes that the kappa coefficient is sometimes reported as a model-performance metric but was not designed for that purpose, and that the scientific literature does not recommend the practice. Kappa measures inter-rater reliability; a document reporting it as a model-performance KPI can prompt further questions about the whole validation methodology. (It can serve as a secondary metric in specific contexts where chance agreement needs correcting on an imbalanced dataset.)
Key point 4 — Drift monitoring and the retraining trigger (A.6.2.6)
In 6.3 and 8.7, ISO/IEC 23053 defines two key operational phenomena. Data drift is when the statistical properties of production data change over time, degrading prediction accuracy; concept drift is when the relationship between inputs and the target variable, or the data-generating mechanism, changes over time. The two generally call for different responses — data drift often by retraining on new data, concept drift often by re-labeling or changing the model structure.
A gap that can surface in an audit is monitoring system uptime but not the time series of model-performance metrics. ISO/IEC 42001 A.6.2.6 (operation and monitoring) explicitly requires monitoring the model's own performance. Yet many organizations' operational dashboards carry API response time and error rate while the daily trend of model precision and recall is missing.
Another is the absence of documented drift-detection thresholds and retraining triggers. Where the only statement is "we retrain when performance drops," an audit looks for how that "drop" is quantitatively defined. For example: alert when the daily F1 falls 10% or more below its 7-day moving average; trigger retraining when the decline persists 30 days. Thresholds and procedures like these should be defined in a document.
Systems using continuous learning carry extra risk. ISO/IEC 23053 notes that because such a model's performance keeps evolving, guard-rails may need implementing. For a model that learns in operation, the acceptable behavior range, automatic-rollback criteria, and the point of human oversight have to be defined separately — which connects to ISO/IEC 42001's impact assessment (A.5) controls too.
Key point 5 — Pre-trained models and transfer learning (the A.10 gap)
Clauses 6.1 and 7.7 of ISO/IEC 23053 treat pre-trained models and transfer learning as first-class ML components. Its example — a commercially available machine-translation model being retrained for legal-document translation — points at every case of integrating an externally sourced ML asset into your own system.
Most AI systems today depend in some form on external ML assets: HuggingFace models, the OpenAI/Anthropic API, vision models pre-trained on ImageNet, BERT/GPT-family foundation models. ISO/IEC 42001 A.10 (third-party and customer relationships) requires controls over these dependencies, and a 42001 preparation document that skips ISO/IEC 23053 can show these gaps:
(1) Treating an external asset as "our own AI" and excluding it from A.10 scope. Classifying a model as in-house simply because you fine-tuned it is risky — if the base model is an external asset, its license, performance assurances, and vulnerability liability still sit in third-party territory.
(2) Provenance tracking and use-policy alignment for the pre-training dataset. A.7.5 (data provenance) requires documenting the source of training data, but with an external pre-trained model the organization often cannot directly control that source. The audit point is whether a document acknowledges this limit and compensates with separate risk controls (stronger output monitoring, post-hoc bias checks), and whether the API provider's use-policy changes — especially restrictions in high-risk domains such as health, legal, or hiring — flow into the impact assessment (A.5) and operational controls. This is also where the EU AI Act's obligations on general-purpose AI (GPAI) providers and your obligations as a deployer interact: a foundation-model dependency means both sets of duties are in play.
ISO/IEC 23053 notes in 6.3 that some models may be provided ready to use, to be retrained and optimized for a specific use case or used as-is. That sentence marks exactly where A.10 controls have to apply.
Putting it into practice
To fold these five mappings into ISO/IEC 42001 preparation, the most efficient start is a checklist for the 8.3 data-preparation steps. Mapping each of the eight steps to where your current system's artifacts and decision rationale live fills a large part of the A.7 control evidence quickly.
Next, writing a model card turns the key items of 8.4/8.5 (task definition, algorithm, hyperparameters, evaluation metrics, test results, limitations) into combined evidence for A.6.2.2, A.6.2.3, and A.6.2.4, and keeping a separate operational monitoring policy (metrics, thresholds, alerts, retraining, guard-rails) makes the A.6.2.6 audit go smoothly.
This is not work to finish all at once. Because every organization starts somewhere different, prioritizing the emptiest area first and filling it in quarterly increments is realistic. To see where ISO/IEC 23053 sits in the wider portfolio, the ISO/IEC AI Standards Map lays out the SC 42 standards on a single page.
Key terms at a glance
ISO/IEC 23053 is more technical than ISO/IEC 22989. A few terms are easy to confuse and worth fixing before you write certification evidence:
| Term | What to watch |
|---|---|
| validation vs test data | Validation data tunes hyperparameters; test data evaluates the final model. Do not select on test data. |
| regularization vs normalization | Different concepts: normalization rescales data; regularization adds a penalty term to the loss. Keep them distinct in writing. |
| de-identification vs anonymization | Anonymization = cannot be re-identified; de-identification = the broader process of severing the identity link. |
| data drift vs concept drift | A change in input data distribution vs a change in the input–target relationship; usually different responses. |
| pre-trained model | An externally sourced base model remains a third-party asset even after fine-tuning (A.10). |
| ground truth | The reference labels against which model output is measured. |
The bottom line
ISO/IEC 42001 is a management-system standard covering AI systems as a whole, but for ML-based systems the practical evidence of its controls often takes the form of ML pipeline artifacts. So for an organization running ML-based AI, ISO/IEC 23053 is not just a reference standard but a core reference framework for ISO/IEC 42001 preparation.
Next in this series: ISO/IEC 42001:2023 — The AI Management System Standard. If ISO/IEC 22989 is the dictionary of abstract concepts and ISO/IEC 23053 is the structural blueprint of an ML system, ISO/IEC 42001 is the operating manual for how management-system controls are layered on top.
📚 SC 42 AI Standards Series
← Previous: ISO/IEC 22989:2022 — AI Concepts and Terminology
📍 Current: ISO/IEC 23053:2022 — Framework for ML-based AI Systems
→ Next: ISO/IEC 42001:2023 — The AI Management System Standard