A.6.2.8·high·Component: Technological controlsWhat this control requires
AI system development activities shall include controlled build, test, validation, and release practices with risk-based gates.
In plain English
AI system development activities shall include controlled build, test, validation, and release practices with risk-based gates. In practice, this means you can prove you develop risk-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.8) 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.
Vulnerability Management
Scanners. Pair an unauthenticated scanner (Nessus / Qualys / Tenable.io) for external surface with an authenticated agent for OS/library CVEs on every host.
SLA. Document remediation SLAs by CVSS / EPSS: critical 7 days, high 30 days, medium 90 days; report monthly trend to leadership.
Containers. Scan images in CI (Trivy / Grype / Snyk Container) AND at runtime; block deploys on critical findings without exception.
Operational checklist
- Develop. Document the trigger, the owner and the cadence.
- Scope: risk.
Evidence to collect
- Code Repo Scan. Source-control evidence — branch protection, required reviewers, CI status, SCA / SAST reports.
- Vapt Scan.
vapt_scanevidence
Repository and security testing evidence should demonstrate controlled build, test, validation, and release practices for AI systems, including defect handling and risk-based quality gates. Focus: Development of AI system.
Common pitfalls
- CI security checks set to warn-only; the merge button is faster than the security feedback.
- Scans that hit only the perimeter; missing authenticated scans of OS, runtime libs and base images so most CVEs are invisible.
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.
- CIS Controls v8 16.13 — Conduct Application Penetration Testing
- ISO/IEC 27001:2022 A.8.28 — Secure coding
- GDPR Article 97 — Commission reports
- SOC 2 (2017 TSC) P5.2 — Correction and Amendment of Personal Information
- BSI C5:2020 PSS-02 — Identification of Vulnerabilities of the Cloud Service
Related controls in ISO/IEC 42001:2023
- 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.2 — AI system requirements and specification
References
- ISO/IEC JTC 1/SC 42 — ISO/IEC 42001:2023
- Catalogue identifier:
Annex A A.6.2.8
Topics: secure developmentdevsecopsapplication securityvulnerability management