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

A.6.2.7AI system technical documentation

Maintain technical documentation sufficient to understand, operate, assess, change and retire the AI system safely.

Mapping at a glance

A.6.2.7 is covered by 2 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

In practice this means keeping one versioned file per AI system: the model or vendor in use, the data it was trained or configured on, the architecture or integration decisions made, and the steps to change or retire it safely. A vendor chatbot needs the same rigor as a custom model: which API version, what prompt or fine-tuning changes were made, who approved them. An auditor pulls the AI system technical documentation for a live tool and checks whether it matches what is running in production right now, not what was true at rollout. The common failure is a doc written once at launch and never touched again.

Common gaps

A consultant licenses a new AI writing tool for marketing and nobody records which vendor, which data feeds it, or how to turn it off.
The technical documentation gets written at go-live and never updated after a model upgrade, a new integration, or a prompt change.
Nobody can say which AI systems are running because the inventory only covers systems IT deployed, missing tools teams adopted directly.

Questions your auditor will ask

What AI systems does the company run, and where is each one documented?
Point to the AI system technical documentation pack: one file per system naming the model or vendor, the data it uses, and who owns it.
How would you retire or change this AI system safely?
The documentation records the configuration and integration points, so a change or shutdown plan can reference exactly what needs to be updated or unwound.
Is this documentation still accurate for what is running today?
Documentation is reviewed alongside the evidence retention process, not written once and left; each update is dated and attributed.
Who approved the current version of this AI system's configuration?
The documentation records the decisions made, including approvals, so a configuration change can be traced back to the person who signed it off.

Where regulation demands it

GDPR accountability (5.2) means you must be able to show how an AI system processes data, not only declare that it does; technical documentation is that evidence.
NIS2 art. 7.1 (Assessment of implementation and maintenance) applies to AI systems too: without documentation, there is nothing to assess against.

Related controls

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

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