Home / Requirement record

The requirement record

92 pages: 35 clauses and 19 annex units from ISO/IEC 23894:2023, and 38 Annex A controls from ISO/IEC 42001:2023. Each page states the requirement in our words, cites the clause, lists the evidence an auditor samples and names the test you can run. The ISO/IEC DTS 25568 draft text is not published and is not stated.

ISO/IEC 23894:2023

54 units. The AI risk management process, its framework, its objectives, risk sources and life cycle.

ISO/IEC 42001:2023

38 Annex A controls. The certifiable AIMS control set the draft's risk treatment feeds.

How to read a page

Code, then the one answer, then what it asks, where generative AI changes the answer, the evidence, the test and the failures.

ISO/IEC 23894:2023

Principles

The eight principles that govern how AI risk is managed, and what each one means for a generative system.

1 pages in this group.
Code	Title	The answer in one line
`4`	Principles of AI risk management	AI risk management serves the organization's needs through an approach that is integrated, structured and comprehensive, looks at the whole system with every technology, function and effect on the environment and stakeholders, and accepts that AI can bring risks that are new or emergent, with good or bad consequences for objectives, or can shift the likelihood of risks already known. Read it against principles of ai risk management before the next risk review.

ISO/IEC 23894:2023

Framework: leadership, integration and improvement

The framework around the risk process: commitment, roles, resources, communication, implementation and improvement.

12 pages in this group.
Code	Title	The answer in one line
`5.1`	General	The framework's job is to build risk management into the organization's important activities and functions, and ISO 31000:2018, 5.1 applies. The artefact behind the answer is governing body's stated AI risk appetite and the delegation to management. Test it on the 5.1 question at the next framework review.
`5.2`	Leadership and commitment	ISO 31000:2018, 5.2 applies. The artefact behind the answer is published statement of commitment to AI risk management. Test it on the 5.2 question at the next framework review.
`5.3`	Integration	ISO 31000:2018, 5.3 applies with nothing AI-specific added: integration begins with understanding how the organization is structured and what surrounds it, risk is handled throughout that structure, each person has a part in it, and governance and leadership determine how deeply AI risk management shapes decisions. Test it on the 5.3 question at the next framework review.
`5.4.1`	Understanding the organization and its context	Clause 5.4.1 of ISO 31000:2018 applies, and Table 2 lists further external-context factors for an organization working with AI: legal requirements, AI-specific ones included; ethical guidance on designing and using AI and automated systems issued by governments, regulators, standards bodies, civil society, academia and industry groups; sector-specific AI guidance and frameworks; technology developments across the fields of AI; the social and political consequences of putting AI into use, informed by the social sciences; how stakeholders see AI, which opacity or bias can colour; and what stakeholders expect in the way of AI-based products. Test it on the 5.4.1 question at the next framework review.
`5.4.2`	Articulating risk management commitment	Top management and oversight bodies should demonstrate and state their continuing commitment to managing risk through a policy or statement that conveys the organization's objectives for it (ISO 31000:2018, 5.4.2), and for AI the commitment should say how the organization intends to develop and use AI responsibly, which risks it will and will not accept from AI systems, and how that commitment reaches the people who design, buy, deploy and use them. Test it on the 5.4.2 question at the next framework review.
`5.4.3`	Assigning organizational roles, authorities, responsibilities and accountabilities	Authorities, responsibilities and accountabilities for every relevant risk management role should be assigned and communicated at all levels (ISO 31000:2018, 5.4.3); for AI that means defining who is accountable for each AI system across its life cycle, including the roles that own data, models, deployment and human oversight, and making sure the people assigned have the AI-specific competence the role needs. Test it on the 5.4.3 question at the next framework review.
`5.4.4`	Allocating resources	Appropriate resources should be allocated to managing risk: people with the skills and competence needed, processes, methods and tools, documented procedures, systems for managing information and knowledge, and professional development (ISO 31000:2018, 5.4.4). In practice the record is resource plan for AI risk management naming expertise, tools and capacity. Test it on the 5.4.4 question at the next framework review.
`5.4.5`	Establishing communication and consultation	The organization settles and approves how it will communicate and consult in support of the framework (ISO 31000:2018, 5.4.5). In practice the record is communication and consultation plan naming AI-affected stakeholders. Test it on the 5.4.5 question at the next framework review.
`5.5`	Implementation	The framework should be implemented through a plan with time and resources attached, by identifying where, when, how and by whom decisions are made, by adjusting decision-making processes where necessary and by making sure the arrangements for managing risk are understood and practised (ISO 31000:2018, 5.5); for AI the plan should cover the decision points across the AI system life cycle where risk is assessed and treated, from inception through design, development, verification, deployment, operation and retirement. Test it on the 5.5 question at the next framework review.
`5.6`	Evaluation	At intervals the organization checks the framework's performance against what it is for, the plans for putting it in place, its indicators and the behaviour expected of it, and judges whether it is still fit to help reach the objectives (ISO 31000:2018, 5.6). Test it on the 5.6 question at the next framework review.
`5.7.1`	Adapting	The framework is watched and adjusted as circumstances inside and outside the organization change (ISO 31000:2018, 5.7.1). For AI the changes to track include the organization's own systems learning or being retrained, new AI techniques and uses, fast-moving customer expectations and frequently revised AI law and guidance. Test it on the 5.7.1 question at the next framework review.
`5.7.2`	Continually improving	The organization keeps making the framework, and the way the process is woven into the organization, more fit for purpose, more adequate and more effective, drawing up plans and tasks as gaps and opportunities come to light (ISO 31000:2018, 5.7.2). Test it on the 5.7.2 question at the next framework review.

ISO/IEC 23894:2023

Risk management process

The process itself, from scope and criteria through identification, analysis, evaluation, treatment, monitoring and recording.

22 pages in this group.
Code	Title	The answer in one line
`6.1`	General	The process is the systematic use of policies, procedures and practices for communication and consultation, setting the context, and for the assessment, treatment, monitoring, review, recording and reporting of risk, and belongs inside management and decision-making rather than beside it (ISO 31000:2018, 6.1). The step before 6.1 supplies its input, so run both together.
`6.2`	Communication and consultation	Communication and consultation help stakeholders understand risk, the basis for decisions and the reasons for actions, and should happen throughout the process (ISO 31000:2018, 6.2); for AI the organization should involve and inform the stakeholders an AI system affects, including those newly introduced by its use, and should communicate its policies and commitments on AI risk so that the views gathered inform fairness criteria, oversight and transparency. The step before 6.2 supplies its input, so run both together.
`6.3.1`	General	Establishing the scope, context and criteria customizes the process so that assessment is effective and treatment appropriate (ISO 31000:2018, 6.3.1); for AI this means being explicit about which AI systems, uses and life cycle stages the process covers and about the AI-related objectives (Annex A) against which risk is judged. The step before 6.3.1 supplies its input, so run both together.
`6.3.2`	Defining the scope	The organization sets out the scope of each risk management activity (ISO 31000:2018, 6.3.2): its objectives and the outcomes expected, the period and places covered, what is in and out, the tools and techniques, the resources and who is responsible, and how it connects with other projects, processes and activities. The step before 6.3.2 supplies its input, so run both together.
`6.3.3`	External and internal context	The process context comes from understanding the setting in which the organization pursues its objectives (ISO 31000:2018, 6.3.3). For an AI system that setting includes its social, legal and contractual surroundings, the stakeholders with their needs and expectations, the data it relies on, and the organization's own AI capabilities and limits. The step before 6.3.3 supplies its input, so run both together.
`6.3.4`	Defining risk criteria	The organization states how much risk, and of what kinds, it is prepared or not prepared to take, and fixes criteria for judging how significant a risk is (ISO 31000:2018, 6.3.4), considering: the kinds of uncertainty, tangible or intangible, that can affect outcomes and objectives; how consequences and likelihood are defined and measured; timing factors; whether measurement is consistent; how a level of risk is arrived at; how several risks together or in sequence are handled; and the organization's capacity. The step before 6.3.4 supplies its input, so run both together.
`6.4.1`	General	Risk assessment covers identification, analysis and evaluation together, done methodically, repeatedly and with stakeholders, using their knowledge and the best information available (ISO 31000:2018, 6.4.1). For AI it is redone whenever the system, its data or its uses change, and it draws on the AI objectives and risk sources of Annexes A and B. The step before 6.4.1 supplies its input, so run both together.
`6.4.2.1`	General	Risk identification finds, recognizes and describes the risks that might help or prevent achieving objectives, using relevant, appropriate and current information (ISO 31000:2018, 6.4.2); for AI it is broken into identifying assets and their value, risk sources, potential events and outcomes, existing controls and consequences, and should consider risks to the organization, to individuals and to society. The step before 6.4.2.1 supplies its input, so run both together.
`6.4.2.2`	Identification of assets and their value	The organization should identify the assets an AI system involves or affects and their value: assets of value to the organization, assets of value to individuals and assets of value to society, so that the harm a risk can do is judged against what is at stake for each. The step before 6.4.2.2 supplies its input, so run both together.
`6.4.2.3`	Identification of risk sources	The organization identifies where AI-related risk can come from, starting from the Annex B list: how complex the operating environment is, missing transparency or explainability, how far the system is automated, machine learning, hardware issues, life cycle issues and technology readiness. The step before 6.4.2.3 supplies its input, so run both together.
`6.4.2.4`	Identification of potential events and outcomes	The organization should identify the events that the risk sources can give rise to and the outcomes they can produce for the assets identified, including outcomes the system's designers did not intend and outcomes that emerge from its interaction with people and other systems. The step before 6.4.2.4 supplies its input, so run both together.
`6.4.2.5`	Identification of controls	The organization should identify the controls already in place that affect the AI risk, including technical measures in the system, organizational measures around it and the human oversight applied, and how effective they are. The artefact behind the answer is register of existing controls per AI system with their effectiveness. The step before 6.4.2.5 supplies its input, so run both together.
`6.4.2.6`	Identification of consequences	The organization should identify the consequences of the events for the organization, for individuals and for society, both tangible and intangible, and the AI-related objectives of Annex A they bear on. The artefact behind the answer is consequence statements per event referencing the affected objectives. The step before 6.4.2.6 supplies its input, so run both together.
`6.4.3.1`	General	Analysis aims to understand each risk, what it is and how it behaves, and where suitable its level, looking at uncertainties, sources, consequences, likelihood, events, scenarios, and the controls in place and how well they work (ISO 31000:2018, 6.4.3). The artefact behind the answer is risk analysis method and results per AI system. The step before 6.4.3.1 supplies its input, so run both together.
`6.4.3.2`	Assessment of consequences	The organization assesses what each identified risk would do: how critical the impact would be, the tangible and intangible effects on the organization, on individuals and on society, and the basis used to judge the overall impact. The artefact behind the answer is consequence assessment with criticality and tangible and intangible impacts. The step before 6.4.3.2 supplies its input, so run both together.
`6.4.3.3`	Assessment of likelihood	The organization should assess the likelihood of each event and its consequences, recognizing that for AI systems historical data can be scarce, that likelihood can change as the system learns or its context shifts, and that the assessment should state its uncertainty. The step before 6.4.3.3 supplies its input, so run both together.
`6.4.4`	Risk evaluation	Evaluation sets the analysis results against the risk criteria to decide where more needs to be done (ISO 31000:2018, 6.4.4); the outcome may be to do nothing more, to look at treatment options, to analyse further, to keep existing controls or to revisit objectives. The step before 6.4.4 supplies its input, so run both together.
`6.5.1`	General	Risk treatment selects and implements options for addressing risk in an iterative cycle of formulating and selecting options, planning and implementing treatment, assessing its effectiveness, deciding whether remaining risk is acceptable and treating further if not (ISO 31000:2018, 6.5.1); for AI the cycle should continue through operation because treatments applied to a learning system can lose effect. The step before 6.5.1 supplies its input, so run both together.
`6.5.2`	Selection of risk treatment options	Choosing treatment weighs what an option gains against its cost, effort and drawbacks, and options can be combined (ISO 31000:2018, 6.5.2). In practice the record is selected treatment options per AI risk with the rationale. The step before 6.5.2 supplies its input, so run both together.
`6.5.3`	Preparing and implementing risk treatment plans	Treatment plans set out how the chosen options will be put into effect, so that everyone involved understands the arrangements and progress can be tracked (ISO 31000:2018, 6.5.3): the reasons for the choice, who is accountable for approving and carrying it out, the actions, the resources, how performance will be measured, the constraints, what is reported and monitored, and when actions happen. The step before 6.5.3 supplies its input, so run both together.
`6.6`	Monitoring and review	Monitoring and review exist to check and raise the quality and effectiveness of the process's design, implementation and results, and are planned into it (ISO 31000:2018, 6.6), covering planning, collecting and analysing information, recording what is found and feeding it back. The step before 6.6 supplies its input, so run both together.
`6.7`	Recording and reporting	The process and what comes out of it are written down and reported (ISO 31000:2018, 6.7), so that activities and results are shared across the organization, decision-makers have information, risk management gets better, and dealings with stakeholders, including those accountable for risk, are supported. The step before 6.7 supplies its input, so run both together.

ISO/IEC 23894:2023

Annex A: AI-related objectives

The objectives an AI risk assessment protects, from accountability and expertise to safety and transparency.

11 pages in this group.
Code	Title	The answer in one line
`A.10`	Safety	AI-related objective: The AI system does not cause unacceptable harm to people, property or the environment, with hazards analysed and safe states defined where its failure can cause harm. Used when establishing risk criteria (6.3.4), identifying consequences (6.4.2.6) and evaluating risk (6.4.4). Read safety against the objective the use threatens most.
`A.11`	Security	AI-related objective: The AI system, its data and models are protected against AI-specific threats such as data poisoning, adversarial input, model extraction and inference attacks, as well as conventional threats. Used when establishing risk criteria (6.3.4), identifying consequences (6.4.2.6) and evaluating risk (6.4.4). Read security against the objective the use threatens most.
`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). Read transparency and explainability against the objective the use threatens most.
`A.2`	Accountability	AI-related objective: The organization can identify who is responsible for the AI system and its outcomes, demonstrates that it acts responsibly and can answer for decisions the system contributes to. Used when establishing risk criteria (6.3.4), identifying consequences (6.4.2.6) and evaluating risk (6.4.4). Read accountability against the objective the use threatens most.
`A.3`	AI expertise	AI-related objective: The organization has, or can obtain, the expertise in AI, data and the application domain that developing, deploying and using its AI systems responsibly requires. Used when establishing risk criteria (6.3.4), identifying consequences (6.4.2.6) and evaluating risk (6.4.4). Read ai expertise against the objective the use threatens most.
`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). Read availability and quality of training and test data against the objective the use threatens most.
`A.5`	Environmental impact	AI-related objective: The environmental footprint of developing and operating the AI system, including energy and resource use, is understood and managed. Used when establishing risk criteria (6.3.4), identifying consequences (6.4.2.6) and evaluating risk (6.4.4). The artefact behind the answer is assessment of the AI system's energy and resource use. Read environmental impact against the objective the use threatens most.
`A.6`	Fairness	AI-related objective: The AI system treats individuals and groups without inappropriate bias or discrimination, with fairness criteria defined with stakeholders and checked in data, model and outcomes. Used when establishing risk criteria (6.3.4), identifying consequences (6.4.2.6) and evaluating risk (6.4.4). Read fairness against the objective the use threatens most.
`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). The artefact behind the answer is maintenance and update procedures with re-validation. Read maintainability against the objective the use threatens most.
`A.8`	Privacy	AI-related objective: Personal data used by or inferable from the AI system is protected across collection, training, operation and query, and the system does not expose more about individuals than intended. Used when establishing risk criteria (6.3.4), identifying consequences (6.4.2.6) and evaluating risk (6.4.4). Read privacy against the objective the use threatens most.
`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). The artefact behind the answer is robustness test results. Read robustness against the objective the use threatens most.

ISO/IEC 23894:2023

Annex B: AI-related risk sources

The sources of AI risk that an identification step should consider, including complexity, opacity and life cycle issues.

7 pages in this group.
Code	Title	The answer in one line
`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 artefact behind the answer is analysis of the operating environment's complexity and coverage by design and test. Use complexity of environment as a prompt in the identification step, not as a finding.
`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 artefact behind the answer is assessment of the system's interpretability and the explanations available. Use lack of transparency and explainability as a prompt in the identification step, not as a finding.
`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. Use level of automation as a prompt in the identification step, not as a finding.
`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 artefact behind the answer is ML-specific risk register covering data, training, drift and retraining. Use machine learning as a prompt in the identification step, not as a finding.
`B.6`	System hardware issues	AI-related risk source: Faults, limits and tampering in the hardware running or feeding the AI system, including sensors and accelerators, can corrupt data and computation and so its behaviour. The artefact behind the answer is hardware fault and dependency analysis for AI platforms. Use system hardware issues as a prompt in the identification step, not as a finding.
`B.7`	System life cycle issues	AI-related risk source: Risk can arise at every stage of an AI system's life, from inception and design through development, verification, deployment, operation, monitoring and retirement, and from transitions between stages, including changes and updates. The artefact behind the answer is life cycle plan with risk activities at each stage. Use system life cycle issues as a prompt in the identification step, not as a finding.
`B.8`	Technology readiness	AI-related risk source: Using AI technologies that are immature or unproven in the intended context brings uncertainty about their behaviour, limits and side effects. The artefact behind the answer is assessment of the maturity of the AI technologies used for the intended purpose. Use technology readiness as a prompt in the identification step, not as a finding.

ISO/IEC 23894:2023

Annex C: the AI system life cycle

How the risk process runs across the life cycle of an AI system, from conception to retirement.

1 pages in this group.
Code	Title	The answer in one line
`C`	Risk management and AI system life cycle	Annex C (informative) shows, as an example, how the clause 6 process lines up with the stages of an AI system life cycle as ISO/IEC 22989 describes them: at which stages each clause 6 activity takes place (communication and consultation, setting scope and context, assessment, treatment, review and monitoring, and reporting and recording), so an organization can build the process into the way it develops and operates AI systems. Read risk management and ai system life cycle at the life cycle point the system has actually reached.

ISO/IEC 42001:2023

A.2 Policies related to AI

The AI policy, its alignment with other policies, and its review.

3 pages in this group.
Code	Title	The answer in one line
`A.2.2`	AI policy	Document a policy governing how the organization develops or uses AI systems. In practice the record is documented AI policy covering development and/or use of AI. Read it against ai policy at the next policy review.
`A.2.3`	Alignment with other organizational policies	Establish where other organizational policies may be affected by, or may apply to, the organization's objectives for AI systems. In practice the record is analysis of intersections with quality, security, safety and privacy policies. Read it against alignment with other organizational policies at the next policy review.
`A.2.4`	Review of the AI policy	Review the AI policy at planned intervals, and additionally when needed, so it stays suitable, adequate and effective. In practice the record is policy review schedule and review records. Read it against review of the ai policy at the next policy review.

ISO/IEC 42001:2023

A.3 Internal organisation

Roles, responsibilities and the reporting of concerns.

2 pages in this group.
Code	Title	The answer in one line
`A.3.2`	AI roles and responsibilities	Define and allocate AI roles and responsibilities according to the organization's needs. In practice the record is AI roles and responsibilities matrix. For ai roles and responsibilities a team name is not a person, so write the name.
`A.3.3`	Reporting of concerns	Define and operate a process for people to raise concerns about what the organization does in relation to an AI system at any point in its life cycle. In practice the record is concern reporting procedure with confidential or anonymous options. For reporting of concerns a team name is not a person, so write the name.

ISO/IEC 42001:2023

A.4 Resources for AI systems

The data, tooling, computing and human resources an AI system consumes.

5 pages in this group.
Code	Title	The answer in one line
`A.4.2`	Resource documentation	Identify and document the resources needed for the activities at each relevant AI life cycle stage and for other AI-related activities of the organization. In practice the record is resource inventory per AI system and life cycle stage (components, data, tooling, computing, people). For resource documentation the evidence is an inventory, not a statement.
`A.4.3`	Data resources	Within resource identification, document information about the data resources the AI system uses. In practice the record is data resource records covering provenance, last update date, ML data categories, labelling process, intended use, quality, retention and disposal, known bias and preparation. For data resources the evidence is an inventory, not a statement.
`A.4.4`	Tooling resources	Within resource identification, document information about the tooling resources the AI system uses. In practice the record is tooling inventory listing algorithm types and models, data conditioning tools, optimization and evaluation methods, provisioning tools, model development aids and design, development and deployment software and hardware. For tooling resources the evidence is an inventory, not a statement.
`A.4.5`	System and computing resources	As part of identifying resources, record details of the computing and system resources the AI system relies on. In practice the record is computing resource records: requirements, location (on-premises, cloud, edge), processing, network and storage. For system and computing resources the evidence is an inventory, not a statement.
`A.4.6`	Human resources	As part of identifying resources, record the people and competences used for building, deploying, running, changing, maintaining, transferring and retiring the AI system and for integrating and verifying it. In practice the record is staffing and competence records per life cycle activity. For human resources the evidence is an inventory, not a statement.

ISO/IEC 42001:2023

A.5 Assessing impacts of AI systems

The impact assessment process and its documentation, for individuals and for society.

4 pages in this group.
Code	Title	The answer in one line
`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. In practice the record is impact assessment procedure stating triggers (criticality of purpose, complexity and automation, data sensitivity, significant changes). For ai system impact assessment process the evidence is the signed assessment, not the process diagram.
`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. In practice the record is impact assessment records covering intended use and foreseeable misuse, positive and negative impacts, predictable failures and mitigations, relevant demographic groups, system complexity, the human role and oversight, and employment and skills effects. For documentation of ai system impact assessments the evidence is the signed assessment, not the process diagram.
`A.5.4`	Assessing AI system impact on individuals or groups of individuals	Evaluate and record how AI systems could affect individuals or groups of individuals over the system's life cycle. In practice the record is individual and group impact assessment covering human rights, accessibility, financial consequences, health and safety, privacy and security, explainability and transparency, accountability and fairness. For assessing ai system impact on individuals or groups of individuals the evidence is the signed assessment, not the process diagram.
`A.5.5`	Assessing societal impacts of AI systems	Evaluate and record the possible effects of the organization's AI systems on society over their life cycle. In practice the record is societal impact assessment covering environmental sustainability, economic effects, government and democratic processes, health and safety, and norms and culture. For assessing societal impacts of ai systems the evidence is the signed assessment, not the process diagram.

ISO/IEC 42001:2023

A.6 AI system life cycle

From objectives and requirements through design, verification, deployment, operation, documentation and logs.

9 pages in this group.
Code	Title	The answer in one line
`A.6.1.2`	Objectives for responsible development of AI system	Identify and document objectives that guide responsible development of AI systems, take them into account and build measures to achieve them into the development life cycle. The artefact behind the answer is documented responsible development objectives (for example fairness). For objectives for responsible development of ai system the evidence sits at the gate it belongs to.
`A.6.1.3`	Processes for responsible design and development of AI systems	Set down in writing the particular processes the organization follows to design and build the AI system responsibly. The artefact behind the answer is documented development process covering life cycle stages, testing, human oversight requirements, impact assessment points, training data rules, developer expertise, release criteria, approvals, change control, usability and controllability and stakeholder engagement. For processes for responsible design and development of ai systems the evidence sits at the gate it belongs to.
`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 artefact behind the answer is requirements specification spanning the life cycle. For ai system requirements and specification the evidence sits at the gate it belongs to.
`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 artefact behind the answer is design records covering ML approach, algorithm and model type, training approach and data quality, evaluation and refinement, hardware and software, AI-specific security threats, output interface, human interaction and interoperability. For documentation of ai system design and development the evidence sits at the gate it belongs to.
`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 artefact behind the answer is V&V plan with test methods, tools, representative test data and release criteria. For ai system verification and validation the evidence sits at the gate it belongs to.
`A.6.2.5`	AI system deployment	Document a deployment plan and make sure the appropriate requirements are met before deployment. The artefact behind the answer is deployment plan addressing development and deployment environments and separately deployed components. For ai system deployment the evidence sits at the gate it belongs to.
`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. The artefact behind the answer is operating procedures covering monitoring, repair, update and support. For ai system operation and monitoring the evidence sits at the gate it belongs to.
`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. The artefact behind the answer is documentation needs analysis per interested party category. For ai system technical documentation the evidence sits at the gate it belongs to.
`A.6.2.8`	AI system recording of event logs	Decide in which life cycle phases the AI system records event logs, and make sure it does so at least while it is in use. The artefact behind the answer is logging decision per life cycle phase. For ai system recording of event logs the evidence sits at the gate it belongs to.

ISO/IEC 42001:2023

A.7 Data for AI systems

Data for development, acquisition, quality, provenance and preparation.

5 pages in this group.
Code	Title	The answer in one line
`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. In practice the record is data management process for AI development covering privacy and security implications, data-related security and safety threats, transparency and provenance, representativeness of training data and data accuracy and integrity. For data for development and enhancement of ai system the evidence starts with the provenance record.
`A.7.3`	Acquisition of data	Determine and document the details of how the data used in AI systems are acquired and selected. In practice the record is data acquisition records: categories and quantity needed, sources (internal, purchased, shared, open, synthetic), source characteristics, data subject demographics and known biases, prior handling, data rights (PII, copyright), metadata and provenance. For acquisition of data the evidence starts with the provenance record.
`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. In practice the record is data quality requirements for training, validation, test and production data. For quality of data for ai systems the evidence starts with the provenance record.
`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. In practice the record is provenance records covering creation, update, transcription, abstraction, validation, transfer of control, sharing and transformation. For data provenance the evidence starts with the provenance record.
`A.7.6`	Data preparation	Define and document the criteria for choosing data preparation methods and the preparation methods to be used. In practice the record is documented criteria for selecting preparation methods. For data preparation the evidence starts with the provenance record.

ISO/IEC 42001:2023

A.8 Information for interested parties

Documentation for users, external reporting, incident communication and information for interested parties.

4 pages in this group.
Code	Title	The answer in one line
`A.8.2`	System documentation and information for users	Determine what information users of the AI system need and provide it. In practice the record is user information covering purpose, that the user is dealing with AI, how to interact and override, technical requirements and limitations, human oversight needs, accuracy and performance, relevant impact assessment findings, benefit claim revisions, updates, contacts and training material. For system documentation and information for users the test is what a reader outside the team understands.
`A.8.3`	External reporting	Give interested parties a way to tell the organization about harmful effects of the AI system. In practice the record is external channel for users and other parties to report adverse impacts such as unfairness. For external reporting the test is what a reader outside the team understands.
`A.8.4`	Communication of incidents	Work out and write down how incidents will be communicated to the people using the AI system. In practice the record is incident communication plan for users of the AI system. For communication of incidents the test is what a reader outside the team understands.
`A.8.5`	Information for interested parties	Identify and record what the organization is obliged to tell interested parties about the AI system. In practice the record is register of obligations to report AI system information to regulators, customers and others, with timeframes. For information for interested parties the test is what a reader outside the team understands.

ISO/IEC 42001:2023

A.9 Use of AI systems

Responsible use, its objectives, and the intended use of the system.

3 pages in this group.
Code	Title	The answer in one line
`A.9.2`	Processes for responsible use of AI systems	Set out in writing how the organization makes sure AI systems are used responsibly. In practice the record is documented responsible use process covering approvals, cost including monitoring and maintenance, approved sourcing requirements and applicable legal requirements. For processes for responsible use of ai systems the evidence is what people did, not what they were told.
`A.9.3`	Objectives for responsible use of AI system	Identify and record the objectives that steer how AI systems are used responsibly. In practice the record is responsible use objectives (for example accessibility, privacy and security, robustness, safety, reliability, explainability, transparency, accountability, fairness). For objectives for responsible use of ai system the evidence is what people did, not what they were told.
`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. In practice the record is deployment evidence following system instructions and documentation. For intended use of the ai system the evidence is what people did, not what they were told.

ISO/IEC 42001:2023

A.10 Third-party and customer relationships

Responsibility allocation, suppliers and customers.

3 pages in this group.
Code	Title	The answer in one line
`A.10.2`	Allocating responsibilities	Make sure responsibilities across the AI system life cycle are divided among the organization, its suppliers, partners, customers and other third parties. What an auditor asks for is register of all parties in the AI system life cycle with their roles and responsibilities. For allocating responsibilities the evidence is the contract and the notice it produced.
`A.10.3`	Suppliers	Set up a process so that the services, products or materials the organization obtains from suppliers fit its approach to developing and using AI systems responsibly. What an auditor asks for is supplier selection and requirements process scaled to what each supplier provides and its risk. For suppliers the evidence is the contract and the notice it produced.
`A.10.4`	Customers	Make sure the organization's responsible approach to developing and using AI systems takes account of its customers' expectations and needs. What an auditor asks for is record of customer expectations and needs (requirements, contracts, usage agreements). For customers the evidence is the contract and the notice it produced.