A.6.2.2·high·Component: Technological controlsWhat this control requires
Functional, non-functional, risk, and control requirements for AI systems shall be defined and maintained as formal specifications.
In plain English
Functional, non-functional, risk, and control requirements for AI systems shall be defined and maintained as formal specifications. In practice, this means you can prove you define ai systems-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.2) 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
- Define. Document the trigger, the owner and the cadence.
- Scope: ai systems, risk.
Evidence to collect
- Code Repo Scan. Source-control evidence — branch protection, required reviewers, CI status, SCA / SAST reports.
- Ticketing Workflow.
ticketing_workflowevidence
Repository and workflow evidence should demonstrate that functional, non-functional, risk, and control requirements are formally specified, reviewed, versioned, and maintained throughout the AI lifecycle. Focus: AI system requirements and specification.
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.
Related controls in ISO/IEC 42001:2023
- Annex A A.6.1.2 — Objectives for responsible development of AI systems
- Annex A A.6.1.3 — AI system design and development process
- Annex A A.6.2.3 — AI system design and system architecture
- Annex A A.6.2.5 — Quality of data for AI systems
- Annex A A.6.2.7 — Preparation of data
- Annex A A.6.2.8 — Development of AI system
References
- ISO/IEC JTC 1/SC 42 — ISO/IEC 42001:2023
- Catalogue identifier:
Annex A A.6.2.2
Topics: secure developmentrequirements managementai lifecycleconfiguration management