An ISO 42001 technical checklist for engineers covers an AI system inventory, data quality and provenance, evaluation before release, monitoring in production, change control for models and prompts, access and security, logging, human oversight and supplier management. For each, keep a written standard, a configuration and dated proof.
What is ISO 42001 asking engineering for?
ISO/IEC 42001, published in 2023, is a management system standard for AI. The management system parts, such as scope, policy, risk assessment, internal audit and management review, are shared with other ISO standards. Its Annex A offers controls specific to AI. The ISO page returned a 403 to our fetch and the text is paid, so this checklist is organised by engineering theme and not by control number. Map each line to the Annex A controls you select in your own statement of applicability.
What does the checklist contain?
Inventory and roles. Every AI system, model and version, including third party models and AI features inside tools you buy. Owner, purpose, users affected, whether you develop, provide or deploy it. Proof: an inventory generated from repositories, cloud accounts and procurement, with a review date.
Data. Source and licence of training, tuning and retrieval data, quality checks, handling of personal data, retention, and lineage from dataset to model version. Proof: dataset records and a lineage note per release.
Evaluation before release. Test sets for accuracy, robustness, bias or fairness where relevant, and misuse. Acceptance thresholds agreed with the product owner and recorded. Proof: evaluation reports tied to a model version and test data version.
Impact and risk gates. An impact assessment required before a new system or a material change ships. Proof: assessment with sign off linked to the release.
Human oversight. Where a person can review, override or stop outputs, and how that is built into the interface or workflow. Proof: design notes and a sample of oversight logs.
Monitoring in production. Quality, drift, error rates, abuse signals and user feedback, with alert thresholds and a response path. Proof: dashboard, alert sample and the ticket it produced.
Change control. Model upgrades, prompt changes, retrieval source changes and configuration changes go through review, testing and approval, with rollback. Proof: sampled change from request to release.
Security. Access control for models, data and keys, secrets management, network separation, protection against prompt injection and data leakage in design, and dependency vulnerability management for the libraries you use. Proof: configuration exports, scan reports.
Logging and traceability. Record inputs and outputs as the privacy policy allows, model version and configuration for each response so an incident can be reconstructed. Proof: sample trace.
Supplier controls. Model and data providers assessed for terms, data use, change notice and exit options. Proof: supplier register with reviews.
Incident handling. AI incidents defined, logged and reviewed, including harmful or incorrect outputs. Proof: incident log and a post incident review.
Documentation. Instructions and limits for users, so deployers know what the system should not be used for. Proof: published user documentation.
In what order should engineers work?
Inventory first. Then evaluation and change control, because they produce evidence on every release. Then monitoring and logging. Then supplier controls and data lineage, which need cross team work. Finish with incident exercises.
What mistakes are common?
- An inventory that leaves out AI features inside SaaS tools.
- Evaluation done once, never repeated after model upgrades.
- Prompt changes made outside change control.
- Logs that capture too much personal data, or too little to investigate.
- Reliance on a provider's claims with no review.
What to do
- Build the AI system inventory from real sources.
- Define evaluation standards and thresholds per system.
- Put model, prompt and retrieval changes under review and testing.
- Set up monitoring with alerts and an owner.
- Review suppliers and record data use terms.
- Run an AI incident exercise and save the record.
Quick check
Does ISO 42001 list controls specific to AI?
Yes, its Annex A provides AI specific controls that you select and record in your statement of applicability. Check your licensed copy for the exact list.
Do prompt changes need change control?
They can change system behaviour as much as a code change, so treat them as changes with review, testing and rollback.
How Safeguard helps automate this
Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires. Control evidence is collected from connected systems and code instead of by screenshot, and monitoring runs between audits. Technical proof about the libraries and dependencies inside your AI applications comes from scans, SBOMs and reachability on your real code. Safeguard's agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically and the approval level. A certification body audits you. Safeguard helps you prepare and keep evidence ready. Book a call to see it.
Sources
- ISO/IEC 42001 page on iso.org, not retrievable on 18 October 2026, so claims are kept general
Last reviewed: 18 October 2026.
