A.6.2.4 AI system verification and validation

What A.6.2.4 AI system verification and validation asks for

When an auditor or customer asks how an AI system was tested before release, A.6.2.4 is the control that answers the question. It requires the organization to define and document verification and validation measures for the AI system and to specify the criteria for using them. In practice, that means a written record showing what was checked (verification: was the system built as specified?), what was checked for fitness of purpose (validation: does it do what it is meant to do, reliably and safely?), and the rules that decide whether the system is allowed to move forward. The risk this addresses is a system released with no evidence that it works as intended or that it is safe, so the release decision rests on opinion rather than records.

A.6.2.4 sits between the neighboring controls for a reason. A.6.2.2 fixes what the system must do, and A.6.2.3 records how it was designed and built. A.6.2.4 asks whether the built system meets those requirements, and it must be settled before the release controls in A.6.2.5 are applied. Auditors usually look for three things: a documented test plan, metrics that were agreed in advance and tied to the requirements, and acceptance criteria that name who can approve a release when a result falls short. Three problems make this control hard to meet. Test sets often do not represent production inputs. Metrics are chosen after results come in. And red teaming is run once before launch and never repeated as the model, prompts or data change. The NIST AI RMF to ISO/IEC FDIS 42001 crosswalk, contributed by Microsoft, maps 12 AI RMF subcategories to this control, including MEASURE 2.1 (test sets, metrics and tools documented), MEASURE 2.5 (valid and reliable), MEASURE 2.6 (safety) and MEASURE 2.13 (TEVV effectiveness). NIST states that posting the crosswalk is not an endorsement, so treat it as a starting map to confirm against your own control design. ISO does not certify organizations. Your own controls must be in place, and an accredited certification body makes the independent determination.

Which AI systems and test assets A.6.2.4 applies to

The verification and validation work under A.6.2.4 changes with the kind of AI system in scope and with who owns the test assets. The cards below cover the decisions that set the scope, the ownership questions to settle before testing starts, and how the statement of applicability records the result.

In-house models versus third-party foundation models

When the organization trains its own model, it controls the training data, the evaluation approach and the acceptance thresholds, so it can define verification and validation measures from the start. When it builds on a third-party foundation model, many of the properties that matter, such as behavior on edge cases, are fixed by the supplier. The organization still needs validation measures for its own use case, and it should record which supplier evidence it relies on and which tests it runs itself. Confirm with the supplier what evaluation data and documentation are available.

Fine-tuned systems need their own test sets

A fine-tuned model inherits the evaluation behavior of its base model but changes it in ways the base model's published results do not show. Verification should compare the tuned model against the untuned baseline on a test set that reflects the target task, and validation should check that the tuned behavior still fits the intended purpose. Record which test sets were built for the tuning, who approved them, and whether they overlap with the training data.

Retrieval-based systems test the whole pipeline

In a retrieval-based system, output quality depends on the documents retrieved, the ranking, the prompt that combines them and the model that generates the answer. Testing only the model misses failures that come from stale or unauthorized documents. Define test cases for each component and for the end-to-end system, including cases where retrieval returns nothing or returns conflicting sources. Decide which retrieval failures stop a release.

Materially enhanced systems trigger new verification

A system that is only operated as before may not need new verification, but a material enhancement such as a new model version, a new data source, an added tool or a changed prompt can alter behavior in ways earlier results do not cover. Define in the organization's procedure what counts as material for each system, and link that definition to re-running the affected test sets before release approval. Keep a record of which change triggered each re-test.

Ownership of test sets, prompts and harnesses

Test sets, adversarial prompts and evaluation harnesses are assets that must be controlled. Settle whether the organization owns them outright, licenses them from a supplier, or relies on a supplier's own evaluation suite. Owned assets should be version controlled and kept under the organization's change process. Where a supplier controls the harness, ask for access to results, the test definitions and notice of changes, so the organization can show what was tested.

Separation of test data and release authority

The team that builds the AI system should not be the only team that defines its test sets and approves its release. Name the team that holds the test data and maintains the acceptance criteria, and the separate role with authority to approve release or stop it. Record both roles in the organization's responsibility assignments. Where a small team must hold both roles, document the compensating review and who performs it.

Recording inclusion or exclusion in the statement of applicability

Clause 6.1.3 requires a statement of applicability that lists the Annex A controls the organization needs and justifies including or excluding each one. A.6.2.4 is normally included for any AI system the organization develops or materially changes. If the organization only deploys third-party AI without changes, the justification for exclusion should state that, and it should still cover how the organization checks supplier evidence. Have the auditor confirm that the justification is acceptable.

How an assessor tests verification and validation

This table walks through what an assessor reviews for A.6.2.4, the evidence requested at each step, and the findings that most often appear. Read it as a sequence: the documented measures come first, then the sampled release decisions, then whether changes triggered re-testing. The main takeaway is that an assessor checks whether test criteria were set before results existed and whether each release decision traces back to them.

Assessment step	What the assessor checks	Evidence requested
1. Review documented measures	Verification and validation measures are defined and documented for each in-scope AI system, with criteria for when they apply	Test strategy or evaluation policy, scope statement per AI system, criteria for use
2. Check test sets, metrics and tools	Test sets, metrics and tooling are named, justified and linked to the system's stated requirements	Test set documentation, metric definitions, tool versions, mapping from requirements to tests
3. Sample releases	For sampled systems, the criteria were applied before release, not reshaped afterward	Test plan with dates, evaluation results, signed release acceptance decision for each sampled release
4. Confirm safety and misuse coverage	Evaluation extends beyond accuracy to safety, robustness and misuse scenarios appropriate to the system	Red teaming reports or adversarial test results, misuse case list, documented disposition of findings
5. Check re-testing on change	Material model, data, prompt, or configuration changes trigger defined re-verification before the change is accepted	Change records linked to test runs, re-test results, approval entries for each material change
Finding: criteria set after results	Pass thresholds or metrics appear to have been chosen once results were known	Document metadata and version history showing when criteria were written, compared with test run dates
Finding: no link to release decision	Test results exist, but no record shows how they informed the go or no-go decision	Release records that cite specific test runs and name the accountable approver
Finding: accuracy-only evaluation	Evaluation measures performance but omits safety, misuse and failure behavior	Test catalogue showing which risk categories were covered and which were excluded with reasons
Assessor role	The assessor samples evidence, tests whether it is consistent and reports findings with the organization's response	Assessor report and findings. The organization writes the test plan; the assessor does not

Steps to implement verification and validation for an AI system

This sequence turns A.6.2.4 into a repeatable engineering workflow: verification checks the system against its specification, validation checks it against its intended purpose, and each step leaves a record an assessor can trace from requirement to release decision.

Trace requirements into verification and validation scope
Start from the requirements and specification approved under A.6.2.2 and list each one that the system must meet. Mark which items are verification measures (does the system meet its specification, such as accuracy, latency or output format) and which are validation measures (does it fit its intended purpose for the users and context it is deployed in). The owner is usually the product owner with the engineering lead, and the output is a versioned verification and validation scope document that maps every requirement to at least one measure or states why none applies.
Define and document test sets and their provenance
For each measure, specify the test set that will exercise it, including its source, how it was collected or generated, what personal or sensitive data it contains, and how it differs from training and tuning data. Record who approved the set and when. Done means each test set has a documented provenance entry and a version identifier, so an assessor can see what the system was tested against. The NIST AI RMF crosswalk to ISO/IEC 42001 links test sets, metrics and tools to the related control, so the same record can serve both reviews.
Choose metrics and thresholds tied to requirements
Select the metrics that show whether each requirement is met, such as error rates, groundedness, fairness measures or safety refusal rates, and set the threshold each must reach. Each threshold should trace back to a requirement from the A.6.2.2 specification, not to a number chosen after results are known. The data science or ML lead proposes the metrics and a risk or product owner signs off. The output is a metrics register listing metric, definition, requirement reference, threshold, measurement tool and approver.
Schedule evaluation and red teaming runs
Set when evaluations run: on every candidate build, before each release, and after material changes such as a new model version, prompt or retrieval source. Add adversarial testing to the plan, including red teaming for prompt injection, jailbreaks, data leakage and harmful output. Tools such as garak can produce a JSONL report of every attempt and a hit log of successful attacks, which become raw evidence. Confirm the tool's coverage against your threat model rather than assuming it, and record the schedule and the test owner in the test plan.
Run tests and retain results with their configuration
Execute the evaluations exactly as planned and store results alongside the system version, model identifier, test set version, configuration and tool version used. Keep traces of test runs where the platform supports them, for example Langfuse traces that record inputs, outputs, tool calls and token usage. Investigate every failed threshold and log the finding, whether it leads to a fix, a documented limitation or a risk acceptance. Done means each run can be reproduced from its stored record.
Set release acceptance criteria
Write the conditions a release must satisfy before it proceeds: all verification measures pass their thresholds, validation results are accepted by the business owner, open high-severity findings are resolved or formally accepted, and known limitations are documented for the users under A.6.2.7. The criteria should be agreed before the test run so that they cannot be adjusted to fit the outcome. The output is an approved acceptance criteria document referenced by the deployment plan under A.6.2.5.
Record the go or no-go decision and its approvers
At the release gate, compare the stored results against the acceptance criteria and record a go or no-go decision. The record should name each approver, their role, the date, the system and model version, the evidence reviewed and any conditions attached to a go decision. Approvers should have the authority to stop a release and should be independent of the people who built the system where your governance requires it. The signed record is the primary evidence that A.6.2.4 operated for that release, so keep it linked to the test results and the deployment plan.
Review and update the process over the life cycle
Feed production monitoring findings, incidents and drift signals back into the test sets, metrics and schedule, so that verification and validation keep pace with the system as it changes. Each update should be versioned and approved in the same way as the original plan. Confirm with your assessor which review frequency and triggers they expect for your scope, since the standard does not set a fixed interval. Done means the change history shows how the measures evolved and why.

Evidence that passes A.6.2.4 and how to keep it current

An assessor testing A.6.2.4 looks for a documented verification and validation approach and proof that it was followed for each AI system release. The artifacts below connect to one another, so the most reliable approach is to keep them in the same repository as the release and tie every record to a specific model or code version.

Verification and validation plan

The plan states what is verified and validated for each AI system, which test types apply, who approves changes to the plan, and which criteria trigger a re-test. Check that it names the AI system version it covers and that the approval date and approver are recorded. Keep the plan in version control next to the system code so that changes show up in the history an assessor will review. Review it when the intended purpose, data sources or deployment context changes, and record that review even when the plan is unchanged.

Test set records with provenance

Each test set needs a record of its contents, version, source, collection method and the date it was frozen. Assessors look for evidence that test data was kept separate from training and tuning data, so record the split rationale and who created it. Tie every evaluation run to a test set version identifier so a result can be reproduced later. Confirm with your data owners how personal or licensed data in test sets is handled, since that handling may bring other controls into scope.

Metric definitions and results per release

Define each metric before the evaluation runs, including the threshold that counts as a pass and the reason the metric fits the intended purpose. Store results per release with the model or code version, the test set version and the tool used to produce them. A dashboard alone is not enough, so export or log the raw results. Langfuse traces can hold inputs, outputs and token usage for LLM operations, which supports this record when the trace identifiers are linked to a release.

Red teaming scope and findings

Record the scope of each red teaming exercise, the attack categories tested, the tools and people involved, and the findings with severity and remediation status. For language model systems, garak writes a JSONL report of every attempt and evaluation plus a hit log of attempts that found a vulnerability, and both files can be archived with the release. Keep open findings visible in the release decision, and retain evidence that each remediated finding was re-tested before closure.

Acceptance criteria and signed release decisions

Acceptance criteria link the metric thresholds and red teaming results to a go or no-go decision for each release. The signed decision should name the approver with authority over the AI system, list any accepted residual risks, and reference the evidence it relied on. Protect the approval path in the code platform so that the release cannot ship without the approval recorded. GitLab protected branches can block direct pushes and restrict which roles can merge, which helps show that release decisions were not bypassed.

Re-testing records after material change

Material changes such as a new model version, a changed training data source, a new tool integration or a new deployment context should trigger re-testing against the plan. Record what changed, which tests were repeated, and whether the earlier results still hold. Assessors often sample a change and ask for its re-test, so make the trigger criteria explicit in the plan. Semgrep can run in CI/CD pipelines to scan repositories continuously, which provides an additional record that code changes were checked between formal evaluations.

Open-source tools that produce verification and validation evidence

Self-hosted open-source tools can generate much of the raw evidence for A.6.2.4, but each one covers a different layer, and none of them decides whether the AI system is fit for release. The organization owns the test plan, the metrics and the acceptance criteria. The tools produce records that show those criteria were run. Before relying on any tool, confirm its coverage against your own test plan, because a tool that scans code or probes a model only evidences the tests it actually performs. For model behavior, garak (Apache-2.0) is the closest fit. It probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. Its JSONL report records every attempt and evaluation, and its hit log lists the attempts that found a vulnerability. Keep both files with the release record for the tested version, and confirm that the probes and thresholds it uses match the risk categories and acceptance criteria your test plan names. Probes are a sample of attacks, not a proof of safety, so document what was not covered.

Langfuse (MIT) supports evaluation records and post-release review. Its traces capture each operation in a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. Traces let a reviewer reconstruct how a response was produced during a test run and during production use, which helps when comparing live behavior against the pre-release evaluation. Confirm that the fields you need, such as evaluation scores and model version identifiers, are captured in your configuration, and set retention in line with your records policy. For the code and configuration around the model, GitLab Community Edition (MIT) and Semgrep Community Edition (LGPL-2.1-only) help keep the tested version fixed. Protected branches can restrict which roles push or merge, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. Semgrep scans code in languages including Python, JavaScript, TypeScript and Terraform, and can run in CI/CD pipelines. Neither tool tests model behavior, so they cover the software and infrastructure side of verification and must be paired with the behavioral tests above.

What meeting A.6.2.4 costs in money and effort

This table breaks down the cost components of meeting A.6.2.4, showing who is paid for each, whether it is one-time or recurring, what pushes it up, and what keeps it down. Use it to scope a quote, since no price or duration is stated here and the figures depend on your own AI systems and environment.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Test set construction and curation	Internal AI or data science staff, or an implementation partner	One-time build, recurring refresh	Up: number of AI systems and use cases. Down: reusable test sets shared across similar systems
Evaluation engineering time	Internal platform or ML engineers, or a partner preparing the harness	One-time setup, recurring runs	Up: model changes per quarter and manual evaluation steps. Down: automated pipelines that run on every change
Tooling and licensing	Hosting provider or your own infrastructure. The named open-source tools (garak under Apache-2.0, Langfuse under MIT, Semgrep Community Edition under LGPL-2.1-only) carry no license fee	Recurring hosting, storage and staff time for upkeep	Up: trace volume and log retention periods. Down: scoped logging and defined retention rules
External red teaming or independent review	Specialist testing firm, billed by written scope	Usually per engagement, with retests as separate items	Up: regulated domain, third-party models and agent tool access. Down: a clearly bounded scope and prior internal testing
Evidence upkeep	Internal governance owners, with partner support if retained	Recurring, tied to each release and model change	Up: frequent releases and many undocumented criteria. Down: acceptance criteria written once and linked to each release record
Auditor sampling effort	The certification body or independent auditor, not DeployOpen	Recurring at each audit cycle	Up: missing test records or unclear release decisions. Down: a consistent evidence trail per system, sampled easily
Third-party model evaluation	Your team, plus vendor documentation requests	Recurring whenever a supplier model changes	Up: opaque vendor test results and frequent version changes. Down: contract terms requiring notice of model updates

Who owns A.6.2.4 and what can be outsourced

Your organization owns the decisions that give verification and validation their meaning. A.6.2.4 asks you to define the measures and the criteria for using them, so the thresholds that decide whether a system is fit for release must come from your objectives, your risk assessment and your intended use. An outside party can suggest metrics, but it cannot decide what level of error your customers or regulators will tolerate.

Acceptance criteria: Set the metrics, thresholds and pass or fail conditions for each system, and record why each threshold was chosen.
Release decision: Make and sign the go or no-go decision, including conditions attached to a release.
Risk acceptance: Decide which residual failures, such as known hallucination or bias limits, are accepted, by whom and until when.
Test scope and sign-off: Approve which test sets, red team scenarios and evaluation runs count as the verification record for each system.
Ongoing ownership: Own re-validation when models, prompts, data or use change.

Check that each acceptance criterion traces to a documented objective and that a named role, not a vendor, signs every release decision.

Where verification and validation programs fall short

Assessors reviewing A.6.2.4 rarely fail a program for lacking tests. They fail it when the tests cannot be trusted, traced or repeated. The five gaps below share one root cause: evaluation is not tied to documented criteria, current data and the exact system released.

Acceptance criteria set after results

Thresholds written after a team has seen the scores prove nothing about fitness for purpose. Assessors look for criteria dated and approved before the evaluation runs, tied to the requirements in A.6.2.2. Close the gap by committing acceptance thresholds to version control with an approval record, and by recording any later change with a reason and an approver. Ask whether the criteria file's history predates the first test run.

Test sets drifting from production

A test set frozen at launch can stop representing the inputs the system actually receives. Assessors check whether the test data was sampled from production, how often it is refreshed, and whether known failure cases from incidents are added. Close the gap by scheduling a documented review of the test set, keeping a log of sources and sampling dates, and adding every production incident that exposed a defect as a regression case.

Red teaming done once

A red team exercise before launch says little about a system changed by new prompts, models, tools or retrieval sources. Assessors look for triggers that repeat testing after material change. Close the gap by defining in the verification plan which changes require a new red team round, and by running automated probes such as garak in the pipeline between formal exercises. Keep the JSONL reports and hit logs as evidence.

No link from test runs to released versions

When a test result cannot be tied to the model, prompt, configuration and code that shipped, the evidence describes a system nobody deployed. Close the gap by recording the commit hash, model version, configuration and dataset identifier in every test report, and by requiring the release record to cite the test run that approved it. Protected branches in GitLab can ensure that only reviewed changes reach the release branch.

Accuracy measured, safety ignored

A system can score well on accuracy while still producing harmful output, leaking data or following injected instructions. The NIST crosswalk maps B.6.2.4 to measures for safety and validity, not accuracy alone. Close the gap by defining metrics for toxicity, data leakage, prompt injection and misuse alongside accuracy, and by recording which metric failed a release. Confirm with the team which of these categories their tooling actually covers before stating it in the evidence.

Questions buyers ask about A.6.2.4 cost, effort and outside help

How much effort does A.6.2.4 take for one AI system?

The effort depends on how much the system does, how many release paths it has and how much verification and validation evidence already exists. No effort figure is supplied for this control, so treat any number you hear with caution and ask for it to be built from a written scope. The main drivers are the number of intended use cases, the size and maintenance cost of the test sets, whether the system is a traditional model, a generative system or an agent with tools, and how many metrics your acceptance criteria require. A system with one narrow purpose and a documented test set needs far less work than a customer-facing assistant that calls external tools. Ask any provider to break the effort into defining criteria, building test sets, running evaluations, documenting results and setting up repeat runs, because the repeat runs are what keep the control working after release.

Can self-hosted open-source tools replace paid testing platforms for A.6.2.4?

In many cases yes, but only for the parts of the control that you can show with recorded results. Open-source tools can cover parts of the evidence trail: garak probes language models for categories such as prompt injection, data leakage and jailbreaks and writes a JSONL report of every attempt and a hit log of successful attempts. Langfuse records traces of model calls, retrieval steps and tool executions with inputs, outputs and token usage, which helps you show how the system behaved in evaluation and operation. Semgrep Community Edition and GitLab Community Edition can keep code and configuration changes under review. Confirm each tool's capability against your own environment before you commit to it, because none of these tools decides your acceptance criteria or replaces human judgment on whether a result is acceptable. Paid platforms may still be useful if your organization needs vendor support, managed dashboards or features you have not verified in the open-source options.

What do our engineers and product owners need to provide?

Your engineers provide the technical knowledge the tests depend on, and your product owners provide the decisions the tests cannot make. Engineers need to supply the system architecture, the model or service versions under test, access to staging environments that match production, and the data handling rules that govern test sets. Product owners need to define the intended purpose, the failure modes that matter to the business, and the thresholds that count as acceptable performance or safety. Someone accountable for AI risk should sign the release acceptance criteria. Expect to name a recurring owner for the test sets, because they drift as the product, the data and the threat landscape change. An implementation partner can build the test harness and write the documentation, but the organization still decides what good enough means for its own users.

How long does a first pass usually take?

The duration depends on scope, and no timeline is supplied for this control. A first pass usually covers defining the criteria, selecting or building test sets, configuring tools, running the first evaluations, reviewing findings and writing the documentation. The time is driven by how many systems are in scope, how mature your existing test data is, how quickly your staff can review results, and whether the first run exposes defects that need fixing before the criteria can be met. Ask for a written schedule with milestones that show when criteria are agreed, when the test environment is ready, when the first full evaluation runs and when results are signed off. Engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts, which lets you compare proposals on the same basis.

Can an implementation partner also red team the system?

Yes, DeployOpen runs security testing that includes AI systems and agents, and red teaming is one of the services it offers. Red teaming and the verification and validation required by A.6.2.4 are related but not identical. Verification and validation measures are the documented tests and criteria your organization uses to decide whether a release is acceptable, while red teaming is adversarial testing designed to find ways the system fails or can be abused. Keeping the two distinct matters for evidence, because an auditor will expect the criteria, the test results and the decisions to be traceable. Ask the partner to state in writing which red team activities feed into your acceptance criteria and who signs off the results. Be aware that a provider who builds your controls and also tests them may create an independence question that your own risk function should review.

Can the same partner prepare evidence for the auditor?

An implementation partner can prepare systems, controls and evidence for a compliance assessment, but it cannot issue the audit report or certificate. Only an independent auditor or certification body does that. For A.6.2.4, prepared evidence typically includes the documented verification and validation measures, the test sets and their rationale, the metrics and tools used, the criteria for release, the recorded results and the records of decisions taken on failures. Ask the partner to show how evidence is stored, how it is versioned against each release and how it can be reproduced for an auditor. Keep the auditor independent from the team that built the controls, and confirm with your certification body how it wants this evidence presented before the engagement starts. Any statement about how a specific certification body will treat your evidence should come from that body, not from the implementation partner.

How DeployOpen scopes and prepares A.6.2.4 evidence

DeployOpen helps organizations prepare the verification and validation records that A.6.2.4 expects: the documented measures, test sets, metrics and release criteria. DeployOpen plans and implements the self-hosted tooling inside the client's own infrastructure, while the organization owns its controls and an independent auditor or certification body issues any report or certificate.

How we scope

Agree in writing which AI systems fall under the A.6.2.4 verification and validation measures.
Confirm which test sets, metrics, red teaming activities and release criteria the written scope covers.
Name who inside the organization approves release criteria and owns the documented measures.

How we build

Set up self-hosted evaluation and security testing tools inside the client's cloud accounts or data centers.
Configure versioned test sets, recorded metrics and documented pass or fail thresholds for each system.
Run AI security testing, including red teaming, and record results against the agreed release criteria.

How we hand over

Deliver a written record of the verification and validation measures and the criteria for using them.
Provide raw test outputs, reports and logs so the organization and its assessor can trace each release decision.
Document how the process is repeated when a system changes, with ownership and approval steps named.

How we support

Fixed-scope engagements agree deliverables and timelines in writing before work begins.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Ask any implementation partner to confirm in writing which parts of the evidence remain with the organization.