ISO/IEC 42001:2023·Annex A A.6.2.3·high·Component: Technological controls

What this control requires

AI system design and architecture shall be documented and reviewed to support robustness, explainability, security, and governance.
— ISO/IEC 42001:2023, Annex A A.6.2.3

In plain English

AI system design and architecture shall be documented and reviewed to support robustness, explainability, security, and governance. In practice, this means you can prove you review governance-level controls on a defined cadence.

Why it matters

ISO 42001 is the first audited evidence regulators, customers and investors can ask for that you are managing AI risk. Each Annex A control is a check-box in that audit; it is also the management system enterprises are starting to require from AI vendors before an MSA can be signed.

This control is rated high. Auditors expect a named owner, a remediation SLA, and a tooling artefact that evidences continuous operation.

What an auditor looks for

An ISO 42001 auditor verifies you have an AI policy, a risk-based system of impact assessments for each AI system, lifecycle controls from data acquisition through retirement, and third-party-AI controls that pierce the vendor's wrapper to underlying model behaviour.

Within Technological controls, the assessor will trace your implementation back to the catalogue reference (Annex A A.6.2.3) and look for objective evidence on the latest two assessment cycles.

How to implement

Secure Development

Pipeline. Require code review, SAST (Semgrep / Snyk Code), SCA (Dependabot / Renovate), secret-scanning and IaC scanning in the merge pipeline.

Branch protection. Protected branches enforce reviews, signed commits and passing CI before merge; document the protection rules as the control evidence.

Configuration Management

Policy-as-code. Codify the control as Service Control Policies (AWS), Azure Policy initiatives, or Organisation Policy (GCP) so the platform enforces what the document promises.

IaC. Gate Terraform / Pulumi / CloudFormation changes with Checkov / tfsec / OPA so misconfigurations never reach production.

Drift. Run a CSPM (Wiz / Prisma / Defender for Cloud / Security Command Center) over every account and route findings to a single risk register.

Operational checklist

  • Review. Document the trigger, the owner and the cadence.
  • Document. Document the trigger, the owner and the cadence.
  • Govern. Document the trigger, the owner and the cadence.
  • Scope: governance.

Evidence to collect

  • Code Repo Scan. Source-control evidence — branch protection, required reviewers, CI status, SCA / SAST reports.
  • Infra Scan. Continuous infrastructure-posture telemetry — AWS Config, Azure Policy compliance, GCP Organisation Policy, Wiz / Prisma findings.

Repository and architecture evidence should demonstrate that AI system design and architecture are documented, reviewed, and governed to support security, robustness, explainability, and oversight. Focus: AI system design and system architecture.

Common pitfalls

  • CI security checks set to warn-only; the merge button is faster than the security feedback.
  • Manual cloud-console changes that never make it back to Terraform — drift accumulates until the next outage forces a reconciliation.

How it maps to other frameworks

Computed from shared tags, control component and key-operation subjects — handy when you are reconciling controls across an audit.

Related controls in ISO/IEC 42001:2023

References

Topics: secure developmentarchitecture governanceapplication securityarchitecture managementconfiguration management