SekitCrosswalk
ENES
Start now
ISO/IEC 42001:2023 — Annex A · derived mapping target

A.6.2.4AI system verification and validation

Verify specified requirements and validate performance, robustness, safety and responsible-use outcomes before release.

Mapping at a glance
A.6.2.4AI system verification and validationISO/IEC 42001:2023 — Annex A
RCF-0031Control testing programGovernance & Risk · PolicyRCF-0032Control testing programGovernance & Risk · ProcessRCF-0124SAST/DASTApplication Security · PolicyRCF-0125SAST/DASTApplication Security · Process

A.6.2.4 is covered by 4 Sekit CSF controls. Open in the full graph →

Mapped from the Sekit CSF

The Sekit controls that cover this requirement, lens by lens.

RCF-0031Control testing program · PolicysupportsDefining which controls get tested and how often gives AI validation its planning structure, though it is not written with AI performance or robustness in mind.RCF-0032Control testing program · ProcesssupportsRunning tests on schedule and tracking failures to remediation is the operating loop AI validation needs, applied here to general controls rather than model behavior.RCF-0124SAST/DAST · PolicysupportsRequiring automated security testing before release covers the application security leg of AI verification but not model-specific performance or safety checks.RCF-0125SAST/DAST · ProcesssupportsRunning static and dynamic tests as part of every build gives AI systems a testing pipeline to extend, though it does not test for drift, bias or robustness.

ISO/IEC 27001:2022 counterparts

Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.

A.8.29 Security testing in development and acceptanceA.5.36 Compliance with policies, rules and standards for information securityA.5.35 Independent review of information securityA.5.1 Policies for information securityA.8.25 Secure development life cycleA.5.27 Learning from information security incidents

NIST CSF 2.0 counterparts

PR.PS-01 Configuration management appliedDE.CM-01 Networks monitoredPR.PS-04 Logs generated for monitoringGV.RM-05 Lines of communication for risk establishedID.IM-03 Improvements from operationsID.IM-02 Improvements from tests and exercisesID.IM-01 Improvements from evaluations

Evidence that proves this control

What an auditor, or Sekit's evidence engine, asks for.

AI testing and validation records
The proof that an AI system was tested before going live and that the results were used to decide: what was tested, with what data, what results it gave against the defined criteria, and who approved the release.
From the Sekit evidence catalog

In practice

Verification checks the AI system does what it was specified to do; validation checks it performs well and safely in the conditions it will genuinely meet. The AI testing and validation records show what was tested, with what data, against what criteria, and who approved the release. A common failure is testing that only covers functional correctness, does the button work, while skipping robustness or safety checks specific to AI, such as how the system behaves on edge-case or adversarial inputs. Auditors ask what happens when a test fails: is there a real gate, or does the release ship anyway.

Common gaps

Testing confirms the AI feature works functionally but never checks robustness against unexpected or adversarial inputs.
Test results are recorded but a failed test did not block the release it was meant to gate.
Validation criteria were defined for the initial launch but never reapplied after a vendor model update.

Questions your auditor will ask

What is tested before an AI system goes live?
Functional correctness against the specification, plus robustness and safety checks, recorded in the AI testing and validation records.
Who approves the release based on the test results?
A named approver reviews results against the acceptance criteria and signs off before deployment, on record.
What happens when a test fails?
The release is held until the failure is remediated and retested, tracked the same way as any other control testing finding.
Are vendor model updates re-tested, or only the initial launch?
Re-tested, since a model version change is treated as a material change requiring a fresh validation pass.

Where regulation demands it

GDPR Article 32.1.d requires regular testing of security measures, which for an AI system extends to robustness and validation before release.
Ask Sekura: “What evidence proves A.6.2.4?”
Also via MCP, free with account