# The ISO 42102 method and capability matrix

Home / The matrix

Clause 7 and the crosswalk

# The method and capability matrix

The draft arranges the description as a matrix: method families on one axis, capability groups on the other. This page explains the geometry, shows the crosswalk to three AI standards we used for the crosswalk, and links every cell to the page that governs it.

## The geometry

A method is how the system does something. A capability is what it can do. The matrix pairs them, so a reader can find a fact in a known place rather than reading a narrative and guessing. The draft states that a system can hold several methods and switch between them while performing a task, which is why a single row is rarely enough.

The grid below is empty on purpose. A filled grid without an evidence rule is a colouring exercise. Use the free check to build the grid your answers create, then fill each claimed cell with an evidence pointer and a review date.

The two axes, before any claim is made
Method familySensory input processingKnowledge processingAction control processingCommunication processingEmergent behaviour
Traditional AI
Symbolic AI
Machine learning
Hybrid AI

## How a cell is filled

- Name the method. Use one of the four families, or say which families a hybrid combines.

- Name the capability. Use the five groups and write the claim as a testable sentence with a population, a condition and a measure.

- Attach the evidence. A test, a benchmark, a review or a monitoring record that a stranger could open.

- Say why a cell is empty. Not applicable, not yet evidenced, or outside scope. Those are three different states.

- Date it and version it. A method change moves the grid, and the previous version is part of the evidence.

## The crosswalk

The draft sets no requirements of its own, so the evidence discipline has to come from somewhere. We draw on three AI standards and have exported 167 requirement rows: ISO/IEC 42001:2023 for the management system, ISO/IEC 23894:2023 for risk and ISO/IEC 42005:2025 for impact assessment. The table below pairs each part of the 42102 matrix with the rules that make the claim checkable.

The three standards are read for the crosswalk and exported at build time. ISO/IEC DIS 42102 is not covered in full: only its public preview is read. The crosswalk maps the framework's structure to those controls; it does not claim that 42102 requires them.

Where each part of the matrix meets a rule behind it
42102 unitRuleWhat the control asksWhy it matters here

5 The methods dimension How the system does what it does
5 The methods dimension
ISO/IEC 42001:2023 A.6.2.2
AI system requirements and specification
Write down the requirements for any new AI system and for any material enhancement of an existing one.A written requirement and specification for the system and any material enhancement.
5 The methods dimension
ISO/IEC 42001:2023 A.6.2.3
Documentation of AI system design and development
Document the AI system's design and development, grounded in the organization's objectives, the documented requirements and the specification criteria.The design and development decisions, recorded so a reviewer can follow them.
5 The methods dimension
ISO/IEC 42001:2023 A.7.2
Data for development and enhancement of AI system
Set up, write down and operate processes for managing the data used to develop AI systems.The data used to develop and enhance the system, and where it came from.
5 The methods dimension
ISO/IEC 23894:2023 B.5
Machine learning
AI-related risk source: Learning from data brings risks of its own: data quality and bias, overfitting, concept drift, behaviour that changes with retraining, and outputs that cannot be fully specified in advance.The risk that a machine learning approach brings, including data and model dependence.
5.2 Traditional AI Rules, search and optimisation written by people
5.2 Traditional AI
ISO/IEC 42001:2023 A.6.2.2
AI system requirements and specification
Write down the requirements for any new AI system and for any material enhancement of an existing one.The requirements record, which should name the rule source and the owner.
5.2 Traditional AI
ISO/IEC 42001:2023 A.6.2.4
AI system verification and validation
Set out in writing how the AI system will be verified and validated and the criteria that govern when each measure is used.The verification plan and the boundary tests for each rule set.
5.2 Traditional AI
ISO/IEC 23894:2023 A.7
Maintainability
AI-related objective: The AI system can be maintained, updated and corrected over its life, including retraining, without losing the properties it was assessed for. Used when establishing risk criteria (6.3.4), identifying consequences (6.4.2.6) and evaluating risk (6.4.4).Maintainability, which a rule base needs as much as a model does.
5.3 Symbolic AI Knowledge representation and reasoning
5.3 Symbolic AI
ISO/IEC 42001:2023 A.7.5
Data provenance
Set out a documented way of keeping a record of where data used in AI systems come from and how they change, over the life of both the data and the system.Data and knowledge provenance, so an assertion can be traced to its source.
5.3 Symbolic AI
ISO/IEC 42001:2023 A.6.2.7
AI system technical documentation
Decide what technical documentation each relevant category of interested party (such as users, partners and supervisory authorities) needs, and provide it in a suitable form.Technical documentation of the knowledge structures and the inference.
5.3 Symbolic AI
ISO/IEC 23894:2023 A.12
Transparency and explainability
AI-related objective: Appropriate information about the AI system and the reasons for its outputs is available to the stakeholders who need it, at the level and in the form they need. Used when establishing risk criteria (6.3.4), identifying consequences (6.4.2.6) and evaluating risk (6.4.4).Transparency and explainability of the reasoning a user is given.
5.4 Machine learning Behaviour fitted from data
5.4 Machine learning
ISO/IEC 42001:2023 A.7.4
Quality of data for AI systems
Define and document data quality requirements and check that data used in building and running the AI system satisfy them.Data quality requirements and the check that training and production data meet them.
5.4 Machine learning
ISO/IEC 42001:2023 A.6.2.6
AI system operation and monitoring
Define and document what the AI system needs for ongoing operation, which at a minimum means monitoring of the system and its performance, repair, updating and support.Operation and monitoring of the model in use, including drift and performance.
5.4 Machine learning
ISO/IEC 23894:2023 A.4
Availability and quality of training and test data
AI-related objective: Training, validation and test data are available, representative of the intended use, of adequate quality and provenance, and managed so that their limitations are known. Used when establishing risk criteria (6.3.4), identifying consequences (6.4.2.6) and evaluating risk (6.4.4).Availability and quality of training and test data as a risk source.
5.4 Machine learning
ISO/IEC 23894:2023 A.9
Robustness
AI-related objective: The AI system keeps performing as intended under perturbation, unexpected input, distribution shift and adversarial conditions, and degrades in a controlled way. Used when establishing risk criteria (6.3.4), identifying consequences (6.4.2.6) and evaluating risk (6.4.4).Robustness of the model under change and adversarial conditions.
5.5 Hybrid AI More than one method combined
5.5 Hybrid AI
ISO/IEC 42001:2023 A.6.2.3
Documentation of AI system design and development
Document the AI system's design and development, grounded in the organization's objectives, the documented requirements and the specification criteria.The design record for the combination and the interfaces between components.
5.5 Hybrid AI
ISO/IEC 42001:2023 A.6.2.4
AI system verification and validation
Set out in writing how the AI system will be verified and validated and the criteria that govern when each measure is used.Verification of the whole system, not only its parts.
5.5 Hybrid AI
ISO/IEC 23894:2023 B.3
Lack of transparency and explainability
AI-related risk source: Where the system's workings or the reasons for its outputs cannot be understood, errors go undetected, accountability weakens and stakeholders lose trust.The risk that the combination is less transparent than any single component.
6 The capabilities dimension What the system can do
6 The capabilities dimension
ISO/IEC 42001:2023 A.8.2
System documentation and information for users
Determine what information users of the AI system need and provide it.The information users need to understand the capability and its limits.
6 The capabilities dimension
ISO/IEC 42001:2023 A.9.4
Intended use of the AI system
Make sure the AI system is used in line with its intended uses and its accompanying documentation.The intended use of the system, stated and respected.
6 The capabilities dimension
ISO/IEC 42005:2025 5.5
Scope of the AI system impact assessment
The organization should set the scope of each assessment, its applicability and its boundaries, taking into account the internal and external factors of 5.1, what relevant interested parties expect, and the impacts on individuals, groups and societies that can reasonably be foreseen. The scope can take in the whole AI system or a component that provides functions users can directly use (as when one or more components change), and a statement of the organization's role in the AI ecosystem (for example provider of data, of a model, of a service or of a product). Where a system is built from several connected AI systems, the organization should weigh whether one assessment should cover them together, since a change in one component can alter the effect of the whole on interested parties.The scope of the impact assessment, which follows the capability claimed.
6.2 Sensory input processing What the system takes in
6.2 Sensory input processing
ISO/IEC 42001:2023 A.7.4
Quality of data for AI systems
Define and document data quality requirements and check that data used in building and running the AI system satisfy them.Data quality requirements covering the input the system actually receives.
6.2 Sensory input processing
ISO/IEC 42001:2023 A.6.2.2
AI system requirements and specification
Write down the requirements for any new AI system and for any material enhancement of an existing one.The input envelope written into the system specification.
6.2 Sensory input processing
ISO/IEC 23894:2023 B.2
Complexity of environment
AI-related risk source: AI systems that operate in complex, open or changing environments face situations their design and training did not cover, so the environment's complexity is itself a source of risk.The complexity of the environment as a risk source for input handling.
6.3 Knowledge processing Where the knowledge lives and how current it is
6.3 Knowledge processing
ISO/IEC 42001:2023 A.7.5
Data provenance
Set out a documented way of keeping a record of where data used in AI systems come from and how they change, over the life of both the data and the system.Provenance of the data and knowledge the system relies on.
6.3 Knowledge processing
ISO/IEC 42001:2023 A.7.6
Data preparation
Define and document the criteria for choosing data preparation methods and the preparation methods to be used.Preparation of the knowledge and data before use.
6.3 Knowledge processing
ISO/IEC 42001:2023 A.8.2
System documentation and information for users
Determine what information users of the AI system need and provide it.User information on the limits of what the system knows.
6.4 Action control processing What the system can change
6.4 Action control processing
ISO/IEC 42001:2023 A.6.2.5
AI system deployment
Document a deployment plan and make sure the appropriate requirements are met before deployment.Deployment controls, including the permission boundary.
6.4 Action control processing
ISO/IEC 42001:2023 A.6.2.6
AI system operation and monitoring
Define and document what the AI system needs for ongoing operation, which at a minimum means monitoring of the system and its performance, repair, updating and support.Operation and monitoring of actions taken in use.
6.4 Action control processing
ISO/IEC 42001:2023 A.9.4
Intended use of the AI system
Make sure the AI system is used in line with its intended uses and its accompanying documentation.Intended use, which bounds the action the system is allowed to take.
6.4 Action control processing
ISO/IEC 23894:2023 B.4
Level of automation
AI-related risk source: The degree to which the system acts without human involvement determines how far a wrong output can propagate before anyone intervenes, so the level of automation and the human oversight around it are a source of risk.The level of automation as a risk source.
6.5 Communication processing What the system says and how
6.5 Communication processing
ISO/IEC 42001:2023 A.8.2
System documentation and information for users
Determine what information users of the AI system need and provide it.The user information that accompanies generated output.
6.5 Communication processing
ISO/IEC 42001:2023 A.8.5
Information for interested parties
Identify and record what the organization is obliged to tell interested parties about the AI system.Information for interested parties, including the limits of the output.
6.5 Communication processing
ISO/IEC 23894:2023 A.12
Transparency and explainability
AI-related objective: Appropriate information about the AI system and the reasons for its outputs is available to the stakeholders who need it, at the level and in the form they need. Used when establishing risk criteria (6.3.4), identifying consequences (6.4.2.6) and evaluating risk (6.4.4).Transparency and explainability of what the system communicates.
6.6 Emergent behaviour What appears when components coordinate
6.6 Emergent behaviour
ISO/IEC 42001:2023 A.6.2.6
AI system operation and monitoring
Define and document what the AI system needs for ongoing operation, which at a minimum means monitoring of the system and its performance, repair, updating and support.Monitoring at the system level, where emergent behaviour appears.
6.6 Emergent behaviour
ISO/IEC 42001:2023 A.8.4
Communication of incidents
Work out and write down how incidents will be communicated to the people using the AI system.Communication of incidents, including a combination-level event.
6.6 Emergent behaviour
ISO/IEC 42005:2025 5.7
Establishing thresholds for sensitive uses, restricted uses and impact scales
Documented thresholds, above all for how an AI system is used, are central to the process: the organization should set them for its own context, taking into account applicable law, the expectations of relevant interested parties, the current state of the art, the benefits the AI system brings, cultural, labour and societal norms, and the ethical frameworks for AI that apply. Depending on the kinds and number of thresholds it can add processes such as reviews and approvals; it may decide, for instance, that some uses, or some misuses that can reasonably be foreseen, count as sensitive or are forbidden by its policy, and law and other external requirements can also make a use sensitive. Where an assessment shows that a planned use is sensitive or restricted, the organization should record what the next steps in the overall process are. Automated credit decisions are given as an example of sensitive use because of their potential financial harm to individuals, and a system with a significant effect on human rights, particularly children's rights, whose harms cannot be removed by technical changes alone is given as a case to escalate to higher management, including on whether to redesign it. The organization should also decide how the overall scale of impact is set and how foreseeable impacts are measured, because a use that is not sensitive can still reach a very large population; it should weigh scale when shaping the assessment's components and set criteria for the types of impact an AI system can cause, for example ranking an impact as very severe when it can lead to significant adverse consequences for the organization, groups or societies.Thresholds for sensitive and restricted uses, which emergent behaviour can cross.
7 The matrix and the record How the description is kept
7 The matrix and the record
ISO/IEC 42001:2023 6.1.4
AI system impact assessment
Set out how the organization will assess the possible consequences that developing, providing or using AI systems can have for individuals, groups of individuals and societies. The assessment must cover what could follow from deploying the system, from its intended use and from misuse that can reasonably be foreseen, take account of its technical and societal context and applicable jurisdictions, and be documented (results can be shared with interested parties where appropriate). Its results must feed the risk assessment of 6.1.2; the A.5 controls apply.The impact assessment that the characterization should feed.
7 The matrix and the record
ISO/IEC 42001:2023 A.5.2
AI system impact assessment process
Put in place a way of assessing what an AI system could mean for individuals, groups of individuals and societies across its life cycle.A repeatable impact assessment process with triggers.
7 The matrix and the record
ISO/IEC 42001:2023 A.5.3
Documentation of AI system impact assessments
Record what each AI system impact assessment finds and retain those records for a set period.Documentation of each impact assessment.
7 The matrix and the record
ISO/IEC 42005:2025 5.10
Recording and reporting
The organization should set and document its record-keeping requirements for AI system impact assessments and how results and the responses to identified impacts are documented, whether through templates, system features or another suitable means. Reporting can be internal, to top management, to workers and contracted staff or their representatives, to AI producers and to AI partners, and external, to competent authorities including policymakers and regulators, to AI customers, to AI partners and to the individuals, groups and societies the system affects. External reporting should suit who the audience is and what transparency it expects, while leaving out disclosures that would be inappropriate for security, confidentiality or the protection of personal data. Reports can cover the actual or foreseeable impacts of the intended uses and, at least in general terms, of other beneficial uses and foreseeable unintended uses (omitting details that could help malicious actors), a reasonable range of the impact types described for impacts in clause 6, and the measures taken in response. Reports should give interested parties what they need to judge, where relevant, whether the system meets legal requirements on impact assessment, and should stay understandable when parts are withheld to protect intellectual property or security.Recording and reporting of the assessment and its limits.

## What the crosswalk is for

An AI governance lead who already runs ISO/IEC 42001 does not need a second management system. They need the descriptor set to land inside the system they have: the inventory, the impact assessment, the verification plan and the user information. The crosswalk is the shortest path from a 42102 cell to an artefact an auditor will accept.

## What it is not

It is not a certification mapping, not a claim of equivalence and not a substitute for the published texts. The control wording is our reading of the standard behind it, cited by clause, and the 42102 side is the public preview. Check both before you rely on a line.

Build your matrixRules by market

Every rule above is read from the three standards used for the crosswalk: ISO/IEC 42001:2023, ISO/IEC 23894:2023 and ISO/IEC 42005:2025. The 42102 side comes from the public preview. How the record is built.

Last updated: 2026-10-22

Source: https://iso-42102-revision-checker.theartofservice.com/matrix/