A.6.2.2 AI system requirements: evidence and audit guide

What A.6.2.2 AI system requirements and specification asks for

A.6.2.2 expects the organization to write down what each new AI system, or each material change to an existing one, is supposed to do before it is built or changed. If you are a compliance lead or engineering manager, the practical question is simple: for every AI system in scope, can you point to a document that states its business purpose, its performance expectations, its trustworthiness needs and its socio-technical requirements, and show who approved that document? The control does not ask for a particular template or tool. It asks that the requirements exist, are specific enough to test against, and are approved before the design work hardens around them.

The risk behind this control is drift. A system built against a vague goal such as "help recruiters" or "speed up claims" has no fixed point against which to judge its behavior. Teams make reasonable local decisions about accuracy thresholds, data use and human review, and nobody can say later whether the system still matches its intended use. Impacts on people are also easier to miss when the requirements never named affected groups, acceptable error rates or the situations in which a person must stay in the loop. Those gaps often surface only after an incident or an assessor's question.

This control is hard in practice because requirements tend to live in tickets, slide decks, meeting notes and the heads of a few product owners. None of those is a controlled record with an owner, a version and an approval. A useful first step is to inventory where requirements for each AI system currently sit, then consolidate them into one approved specification per system or material change. The NIST AI RMF to ISO/IEC FDIS 42001 crosswalk, a document published by the NIST AI Resource Center and contributed by Microsoft, links the guidance for this control to MAP 1.4 (business value or context of use defined) and MAP 1.6 (system requirements elicited and socio-technical implications considered), which gives you a recognized vocabulary for the review. Confirm the crosswalk's current wording and its status with NIST before you cite it to an assessor.

Which AI systems and changes fall under A.6.2.2

A.6.2.2 applies to new AI systems and to material enhancements of existing ones, so the first decision is whether a given change counts. The cards below cover the system types and change types that usually trigger the requirement, the teams that must agree on the scope, and the third-party components whose requirements still have to be documented in the organization's own records.

New AI systems built in house

Any AI system the organization designs and builds from scratch falls under A.6.2.2 from the start. Product owns the business purpose, data science proposes the performance targets, and risk and legal set the constraints the system must respect. Security should confirm access, logging and misuse requirements before design begins. Check that the requirements record exists before the first model is trained, since later design and testing controls depend on it.

Material enhancements: new models

Swapping or upgrading the underlying model is usually a material change because performance, failure modes and fairness characteristics can shift. Data science should document why the new model is needed and which requirements it must meet, while risk reviews whether the previous requirements still hold. Ask whether the change alters outputs in ways users or affected people would notice, and record the decision even when the answer is that the change is not material.

Material enhancements: new data sources

Adding a data source to training, fine-tuning or retrieval changes what the system knows and how it behaves. Data governance, data science and legal should review the source for provenance, personal data and licensing before the requirement set is updated. The updated specification should state what the new data may and may not be used to decide, since this is where unintended scope often appears.

Material enhancements: new user populations

Extending an existing system to new customers, regions, languages or employee groups can make it operate in a context its requirements never covered. Product and risk should record the new intended users and their vulnerabilities, and legal should confirm the local obligations. Treat expansion into a new population as a change that needs its own requirement review, even when the model itself is unchanged.

Material enhancements: new decision authority

Moving a system from advisory output to automated decisions, or letting it trigger actions without human review, changes the consequences of errors. Risk, legal and security should define the new level of autonomy, the human oversight expected, and the boundaries on actions. This is the change type most likely to need explicit approval and an updated record of socio-technical requirements.

Third-party models and hosted APIs

Vendor models and hosted AI APIs are components the organization uses, but the requirements for how it uses them still belong to the organization. Procurement, security and product should document what the component must do, what data it may receive, and what performance and availability it must provide, even when the vendor's documentation covers its own internals. Keep the record current when the vendor changes the model version behind the same API name.

How an assessor tests AI system requirements under A.6.2.2

This table compares six assessor test approaches for A.6.2.2 against the evidence each one requests and the findings that commonly follow. Read each row as a question the assessor will try to answer, and use the findings column to check your own records before an audit starts.

Test area	Test approach and evidence requested	Common findings
Sampling of AI systems and changes	Assessor selects AI systems and material changes from the period and asks for the requirements record for each. Expect a register of AI systems, a change log and the sample selection rationale.	Register omits systems in use, or material enhancements have no entry in the change log.
Tracing from business purpose to approved record	Assessor follows one requirement from the stated business purpose through to the approved specification. Expect the business case, the requirement statement and the linked approval record.	Business purpose is vague or missing, so the specification cannot be traced to any stated need.
Measurable performance and trustworthiness requirements	Assessor checks that each performance and trustworthiness requirement has a defined measure, threshold and test method. Expect acceptance criteria and the metrics chosen for them.	Criteria such as accurate or fair are untestable because no metric, threshold or test method is recorded.
Socio-technical requirements considered	Assessor asks how user, operator and affected-group considerations were captured and where they were decided. Expect stakeholder input records and documented trade-off decisions.	Specification covers only technical features, with no record that human, organizational or affected-group factors were considered.
Approval by the right roles before build	Assessor compares approval dates against the start of development and checks that approvers hold the roles defined in the AI governance model. Expect signed or recorded approvals with dates.	Requirements written or approved after build began, or approved by someone without the authority set in the governance model.
Fresh requirements record for material enhancements	Assessor reviews the change history for material enhancements and checks that each triggered a new or revised requirements record before work started. Expect a definition of what counts as material and linked change tickets.	Model retraining, new data sources or changed use cases shipped without any requirements update, or with an update dated after release.

Specifying requirements for a new AI system, step by step

This sequence turns a business need into an approved, versioned requirements record that the later A.6.2 life cycle controls can test against. Each step names the output an assessor would look for.

Define the business purpose and context of use
The product or business owner writes a short statement of why the AI system exists, which decision or task it supports, who uses it and where it runs. Include the settings it must not be used in, since those boundaries drive later risk and impact work. Done means a one-page purpose statement and context-of-use record exist, are dated, and name an accountable owner. Assessors commonly ask for this first because every later requirement traces back to it.
Elicit functional and performance requirements
The product, engineering and domain teams list what the system must do and how well it must do it, such as accuracy expectations, response behavior, input types, integration points and failure handling. Each requirement gets a unique identifier and a note on its source, whether a stakeholder interview, a regulation or a contract. Done means a numbered requirements list where every item traces to a business purpose statement. Gaps show up here when a requirement cannot be traced to a stated purpose.
Record trustworthiness requirements with measurable criteria
Translate trustworthiness goals such as fairness, security, transparency and robustness into requirements with measurable acceptance criteria, such as the metric, the test population and the threshold the organization chooses. Where a criterion cannot yet be measured, record how it will be measured and who decides the threshold. Done means each trustworthiness requirement has a criterion, a measurement method and an owner. Confirm with the team which metrics their verification tooling can actually produce before committing to thresholds.
Capture socio-technical requirements from affected users and operators
Interview or survey the people who will use the system, the people it affects and the staff who will operate and oversee it. Record needs such as explanations users must receive, when a human must review or override an output, training needed for operators and complaint routes for affected people. Done means a socio-technical requirements section with the source group named for each item and any unresolved conflicts logged. This step is where the requirement for socio-technical implications is most often thin, so document who was consulted and who was not.
Define the approval gate and approvers
Set the approval gate that the requirements must pass before design begins. Name the approvers by role, such as the business owner, a risk or compliance function, a privacy lead and a security lead, and state what each one is confirming. Record the approval rule, for example whether every approver must sign or whether a quorum is enough, and what happens when approvers disagree. Done means an approval record exists with named roles, dates and decisions, and the organization can show the approval came before design work started.
Obtain approval and record decisions
Circulate the complete requirements document to the named approvers and collect their decisions in writing. Record any conditions, rejected items and open questions with an owner and a closure route. Done means an approved requirements document with a decision log, showing which requirements were approved as written, which were changed and which were deferred. Keep the approved version separate from drafts so an assessor can see exactly what the team agreed to.
Version the requirements record and link it to later evidence
Store the requirements in a version-controlled location and assign a version number to each approved change. Add a traceability list that maps each requirement to the design, verification and validation items that will test it, which later A.6.2 controls depend on. Changes after approval go through the same gate, and the change record states the reason and the approver. Done means a versioned requirements record with a traceability list and a change history. Confirm with your tooling vendor how version history, access control and approval records are kept, since the answer determines how easily an assessor can reconstruct past decisions.

Evidence that satisfies A.6.2.2 and how to keep it current

An auditor testing A.6.2.2 looks for a documented requirements record for each AI system, traceable to business purpose and approved by named people. The cards below cover the artifacts that make up that record and how each one stays accurate between audits, so the evidence reflects the system as it is today rather than as it was at launch.

Requirements specification per AI system

This is the core document: one specification for each new AI system or material enhancement, listing functional requirements, data inputs, user groups, integration points and the conditions under which the system must not be used. Auditors check that every AI system in scope has one, that it is dated, and that it names the version of the system it describes. Keep it in a versioned wiki or document repository, and review it at each release gate so the specification never drifts behind the deployed behavior.

Business purpose and context-of-use statement

This short statement records why the AI system exists, which decision or process it supports, who relies on its output and where it is out of bounds. It is the anchor for the requirements that follow, and it is the point an assessor compares against actual use. Assign an owner in the business function, not only in engineering, and re-confirm the statement whenever the user population or decision scope changes, since a changed context of use is a common trigger for a new requirements review.

Performance and trustworthiness criteria with thresholds

Each measurable requirement needs a stated threshold, the metric used to measure it, the test set or data source behind it, and the decision taken if the threshold is missed. Typical areas include accuracy, error rates across user groups, robustness to unexpected input, and explainability for affected people. Auditors look for thresholds that were agreed before testing, not adjusted afterward. Record each change to a threshold with a reason, and link the criteria to the verification evidence held under A.6.2.4.

Socio-technical requirements record

This record covers the human and organizational side that a purely technical specification misses: who oversees the system, how users are trained, how affected groups can contest outcomes, and what happens when people over-rely on the output. It draws on the NIST AI RMF mapping that links requirement elicitation to socio-technical implications, which is a useful reference when building the record. Review it with the people who will operate the system, because the controls described here are only evidence if staff can actually perform them.

Approval record with named approvers and dates

The approval record shows who accepted each requirements specification, in what role, on what date, and against which version. Names alone are not enough: the record should show that approvers had the authority to accept the risk, such as a business owner and a risk or compliance representative. Store approvals in the same system as the specification so the two cannot be separated. Reconfirm approvals when the owner changes, because an approval granted by someone who has left the organization is hard to defend in an assessment.

Change log for material enhancements

A change log records each material enhancement after go-live, what changed in the requirements, why, who approved it and when it was deployed. Source-control tools help here: protected branches prevent direct pushes to release branches, so every change to requirement-linked code or configuration passes through a reviewed merge that can be tied back to a requirement. Confirm with your own engineering team which changes count as material under your criteria, and keep a link from each change to the system inventory entry it affects.

What meeting A.6.2.2 costs in money and effort

This table lists the cost components of specifying AI system requirements under A.6.2.2, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Read the recurring rows as the ongoing load, since most of the effort sits in keeping requirement records current as systems change. Figures are not given here because they depend on the number of systems in scope and how often they change, so use the quote questions below to compare offers.

Cost component	One-time or recurring	Cost drivers	How to reduce it
Internal requirements analysis time	One-time per system, then recurring for each material enhancement	Number of AI systems in scope, depth of business purpose and socio-technical analysis, number of product owners involved	Start with a requirements template that covers business purpose, performance, trustworthiness and socio-technical fields, and reuse it across similar systems
Tooling and licenses for the requirements record	Recurring	Number of users editing records, need for version history and approval workflows, hosting model	Self-hosted open-source wiki or documentation platforms can remove license fees, but staff time to configure, host and back up remains
Workshops with affected stakeholders	One-time per system, plus recurring for material change	Number of affected groups (users, operators, staff whose work changes), facilitator time, preparation material	Limit sessions to the groups whose requirements shape the system, and capture outputs in a shared template so later changes need shorter reviews
External review by risk or legal specialists	Recurring when triggered by high-impact use or regulated sectors	Regulatory exposure of the use case, depth of review requested, number of review cycles	Set internal review criteria so external specialists see only systems that cross defined risk thresholds
Evidence upkeep per change	Recurring for the life of each system	Frequency of model, data or scope changes, number of approvers, how many linked documents must be updated	Use version control and change logs so approvals and past versions can be shown without rebuilding the record
Auditor sampling effort	Recurring at each audit cycle	Number of AI systems selected for sampling, how quickly records can be produced, completeness of approval evidence	Keep one current requirements record per system with dated approvals so sampled items can be retrieved quickly
Independent auditor fees	Recurring at each audit cycle	Scope of the management system, number of sites and systems, certification body rates	Ask certification bodies for an itemized quote and confirm which systems the audit will sample before the engagement starts
Outside readiness help	One-time, with optional retainer for upkeep	Gap between current records and required evidence, number of systems in scope, fixed-scope versus retainer terms	Agree a written scope with deliverables and timelines, and separate preparation work from the auditor's independent assessment

Self-hosted tools that keep AI requirement records

The tools below can hold requirement records, enforce who may change them and show how they changed over time. Each one produces evidence that supports A.6.2.2, but none satisfies the control on its own, because the organization still has to decide what the requirements are and who approves them.

Protected branches for requirement files

Keep requirement files in a Git repository in GitLab Community Edition and protect the branch that holds approved versions. Protected branches let maintainers limit which roles can push or merge, set push access to no one to block direct pushes, and keep force pushes disabled unless explicitly allowed. The result is an approval trail: each merge into the protected branch shows who approved a requirement change. Confirm the protection settings in your own instance, because they are only as strong as the roles assigned.

Code checks that enforce criteria

Semgrep Community Edition scans source code, not requirement documents, so its role here is narrow. Where a requirement states a technical criterion, such as no hard-coded credentials or mandatory input validation for a model interface, a matching rule can run in CI/CD and show the criterion is enforced in code. It supports languages including Python, Java, JavaScript, TypeScript, Go and Terraform, among others. Ask your engineering team which requirement criteria can be expressed as rules and which must be checked by review or testing instead.

Version history for requirement pages

XWiki keeps every change to a page under version control, recording what changed, when and by whom. Reviewers can compare any two versions of a requirement specification, and owners can roll back to an earlier version if a change was approved in error. This history answers the question an assessor is likely to ask: how did this requirement reach its current wording, and who agreed to it. Confirm that edit permissions and version retention in your deployment match the change approval process you document.

Role-based approval of baselines

BookStack assigns user abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. Set the approved requirement baseline as a locked page that only the approver role can edit, and let requirement authors work in draft chapters beside it. This separation makes it clear which version of a requirement is in force. Test the permission overrides with a non-admin account before relying on them, since an inherited permission can allow edits you did not intend.

Keeping requirement approval in-house or with a partner

Your organization owns the substance of A.6.2.2. Someone accountable inside the organization must decide why the AI system exists, which business outcome it serves and in what context it will be used. Approval decisions, risk acceptance and the wording of trustworthiness and socio-technical requirements belong here, because they express management's judgment about acceptable impact on users, staff and affected groups. An outside partner can help draft options, but it cannot accept risk on your behalf.

Business purpose: A named business owner records the intended purpose, the users and the context of use, and signs off on them.
Approval decisions: Named approvers, with defined authority, decide whether a requirement set is accepted and whether a material change needs fresh approval.
Risk acceptance: Residual risks left after requirements are set are accepted by an identified role, with the reasoning written down.
Trustworthiness and socio-technical content: Your subject matter experts decide what fairness, transparency, human oversight and affected-group concerns mean for this system.

Before you commit to a partner, check that your own owners and approvers are named in writing.

Where organizations fall short on AI system requirements

Most gaps under A.6.2.2 come from requirements that are written too late, stated too vaguely to test, or kept in places no assessor can baseline. The cards below pair each gap with a closure step and the evidence that shows it closed, so the requirements record can survive an independent audit.

Requirements written after the build

Teams often document requirements once a model is already trained, which turns the specification into a description of what was built rather than a basis for building it. A.6.2.2 expects requirements to exist for new systems and material enhancements before design work proceeds. Close the gap by gating design start on an approved requirements record. Evidence: a dated requirements document with an approval entry that predates the first design or training record.

Criteria that cannot be tested

Requirements such as "the system must be fair" or "outputs must be accurate" give verification no pass or fail line. Each requirement should name a measurable acceptance criterion, the metric, the test population and the threshold that triggers rework. Evidence: a traceability table linking each requirement to a test case, metric and recorded result under the verification controls that follow in the life cycle.

Socio-technical needs missing from the record

Requirements often cover accuracy and latency but omit who the system affects, how users will oversee it, and where its outputs could harm people. The guidance for this control links requirement elicitation to socio-technical implications, so the record should name affected groups, human oversight points and misuse scenarios. Evidence: a requirements section listing stakeholders, oversight roles and identified harms, cross-referenced to the impact assessment.

Material enhancements treated as routine changes

A retrained model, a new data source or a changed decision threshold can alter behavior as much as a new system does, yet it often moves through a standard ticket. Define in writing what counts as material, such as a change in intended purpose, data population or affected users, and route those changes back through requirements review. Evidence: a change classification procedure and a sample of tickets showing material changes received a requirements update.

No named approver

A requirements record without an accountable approver cannot show that the organization decided what the system was for. Name the role that approves business purpose and the role that approves trustworthiness requirements, and record their sign-off with a date and version. Evidence: an approval record with the approver's role, the approved version and the date, retained alongside the requirements baseline.

Requirements scattered across tickets

When requirements live in chat threads, tickets and slide decks, no one can show which version was in force at build time. Keep one controlled document per system with version history, and link each change to a reason and approver. Evidence: a version history showing each revision, who made it and what changed, which lets an assessor reconstruct the baseline at any date.

Questions buyers ask about A.6.2.2 cost, effort and scope

How much effort does a first AI system requirements baseline take?

No researched figure exists for the effort, so confirm it with your own environment rather than a published number. The effort is driven by how many AI systems are in scope, how many of them are new or materially changed, how many stakeholders must agree on purpose and performance targets, and whether requirements already exist in product documents. A team with one bounded system and written product specs will usually finish far sooner than a team reconciling requirements across several systems with no shared template. Ask any partner for a written scope listing the systems, the requirement categories and the approval steps before accepting a fixed-scope quote.

Can our team write A.6.2.2 requirements without outside help?

Yes, the organization owns its controls and an internal team can produce the requirements, provided it has the right people and a clear approval path. Outside help is useful when the team lacks experience with trustworthiness or socio-technical requirements, or when no one has mapped the requirements to a risk process. An implementation partner can prepare templates, versioned documentation and review workflows, but it cannot approve requirements or issue any report. Independent auditors test the result later, so the requirements must make sense to someone who did not write them.

What do product, risk and legal staff need to contribute?

Product owners define the business purpose, intended users and the performance a system must reach in its context of use. Risk staff translate those purposes into acceptance criteria for fairness, security, transparency and reliability, and link them to the organization's AI risk process. Legal and privacy staff identify obligations that constrain the design, such as data protection limits or sector rules, and flag requirements that cannot be met without a decision from leadership. Each group should sign off on the part it owns, and the sign-off record becomes audit evidence.

How is a material change to an AI system defined, and who decides?

ISO/IEC 42001 requires requirements for new systems and for material enhancements, but the organization sets its own definition of material. A practical definition covers changes to the intended purpose, the user population, the data sources, the model or its performance thresholds, or the risk level of the context of use. The accountable owner named in your AI governance roles should decide whether a change is material, and the decision should be recorded with its reasoning. Confirm your definition with your own policy owners and, where a regulator applies, with its guidance.

Can A.6.2.2 be excluded from the statement of applicability?

An exclusion is possible in principle, but it must be justified under clause 6.1.3, which requires a statement of applicability listing the necessary Annex A controls and the reasons for including or excluding each one. A justification that says the organization builds no AI systems is weak if it also provides or deploys AI that changed recently. Assessors will check the justification against your actual AI inventory, so the exclusion must hold up when they compare it with real system records. Confirm the wording with your certification body before relying on it.

How does A.6.2.2 link to NIST AI RMF MAP 1.4 and MAP 1.6?

A NIST AI Resource Center crosswalk, contributed by Microsoft and posted with a NIST statement that posting is not an endorsement, maps the AI RMF subcategories MAP 1.4 and MAP 1.6 to the implementation guidance for this control. MAP 1.4 concerns defining the business value or context of use, and MAP 1.6 concerns eliciting system requirements and considering socio-technical implications. Using the crosswalk lets one set of requirement records serve both the ISO/IEC 42001 audit and an AI RMF assessment. Check the crosswalk yourself for the current wording, because the mapping is a reference, not a conformity claim.

Which open-source tools can keep requirement records under version control?

Requirements are documents first, so a wiki or documentation platform with version history is a natural home. XWiki keeps every change to a page with what changed, when and by whom, and lets users compare versions and roll back. BookStack lets you assign permissions by role and override them at shelf, book, chapter or page level, which helps restrict who can approve. Store the approval decisions alongside requirements, and confirm the retention and export needs of your own auditors before choosing a platform.

How DeployOpen scopes and prepares A.6.2.2 evidence

DeployOpen helps organizations prepare the requirements records, design controls and evidence behind A.6.2.2 AI system requirements and specification, inside their own infrastructure. The organization keeps ownership of its AI requirements and approval decisions, and an independent certification body is the only party that issues a certificate.

How we scope

Agree in writing which AI systems and material enhancements fall under the A.6.2.2 requirements process.
Confirm which named owners approve business purpose, performance and socio-technical requirements before work starts.
Define deliverables, timelines and exclusions in a fixed-scope statement that the organization signs before work begins.

How we build

Set up a versioned requirements template in the organization's own wiki or document system with approval fields.
Configure protected branches and review gates so requirement changes need recorded sign-off before they take effect.
Connect requirement IDs to design and test artifacts so an assessor can trace each requirement to its evidence.

How we hand over

Deliver the requirements records, approval history and version logs in formats the organization's staff can maintain.
Document the process owner, review cadence and change procedure so the organization can run it without outside help.
Provide a readiness summary listing gaps, but leave assessment conclusions and any certification decision to the independent auditor.

How we support

Offer ongoing support as a retainer for updates to requirements when a system is materially changed.
Review new or enhanced AI systems against the documented requirements process on a schedule agreed in the retainer.
Ask any partner for written confirmation of which tasks are included, who approves each record and what recurs after handover.