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

A.6.2.3Documentation of AI system design and development

Maintain versioned design and development records that explain architecture, data, model choices, assumptions and decisions.

Mapping at a glance

A.6.2.3 is covered by 3 Sekit CSF controls. Open in the full graph

Mapped from the Sekit CSF

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

ISO/IEC 27001:2022 counterparts

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

NIST CSF 2.0 counterparts

Evidence that proves this control

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

AI system technical documentation
The versioned documentation pack for a specific AI system: the requirements it must meet, how it is designed or configured (model, architecture or vendor, data used, decisions made), and the technical detail needed to operate, assess, change and retire it safely.
From the Sekit evidence catalog

In practice

The AI system technical documentation has to explain, in enough detail that a new hire or an auditor can follow it, what model or vendor was chosen, what data it was trained or configured with, and why. A common gap is documentation that describes the system as it was originally built but was never updated after a model version change or a new data source was added. Auditors ask to see the documentation for a live system and compare its stated data sources and model version against what is currently running.

Common gaps

The technical documentation describes the AI system's original configuration but was never updated after a vendor model upgrade.
Design decisions, such as why a particular model or data source was chosen, were made verbally and never written down.
Documentation exists for the system overall but does not record what changed at each version.

Questions your auditor will ask

Does the documentation reflect the AI system as it runs today?
Yes, the technical documentation is updated at each material change, with the current model, vendor and data sources named.
Why was this particular model or vendor chosen?
The design rationale is recorded in the technical documentation alongside the alternatives considered, if any.
How do you track documentation changes over time?
Through the same change management process used for production changes, so each documentation update is tied to an approved change.
Where is the evidence that this documentation is kept current, not only written once?
Version history and change records are retained as control evidence, dated and attributable to a specific update.

Where regulation demands it

NIS2 art. 7.1 (Assessment of implementation and maintenance) requires it, which depends on documentation that reflects the system's current state.

Related controls

Via the shared Sekit CSF topic, not the framework's own index.

Ask Sekura: “What evidence proves A.6.2.3?”
Also via MCP, free with account