Does ISO 42001 make sense for an organization that only uses AI?
A customer, contract or regulator is asking for ISO 42001, and your organization buys AI rather than builds it. ISO/IEC 42001 applies to any organization that provides or uses products or services that use AI systems, so a pure user can be in scope. Whether it makes sense depends on two things: how your organization defines its scope, and which Annex A controls it can justify including or excluding. The controls most relevant to a user sit in A.9 (use of AI systems), which asks you to document the processes for responsible use, set objectives that guide that use, and keep each system within its intended uses and accompanying documentation. Supplier controls in A.10.3 also apply where the AI products you buy come from third parties.
Before you commit, confirm three things. First, which AI systems fall inside the scope boundary, including AI features embedded in tools your staff already use. Second, which Annex A controls the statement of applicability will include and which it will exclude, with a written justification for each exclusion, as clause 6.1.3 requires. Third, who in the organization owns each control. The organization owns its controls and its management system. An implementation partner can help prepare systems, documents and evidence, but only an independent certification body can issue a certificate, and it will test the evidence you actually operate. Ask any partner to confirm in writing which of these tasks stay with your staff.
Certification is not the only use of the standard. Many organizations use the clause structure and A.9 controls to answer customer questionnaires and to organize evidence for EU AI Act deployer duties. Under Article 26, deployers of high-risk AI systems must use them according to the instructions for use and assign human oversight to people with the necessary competence, training, authority and support. Evidence for those duties overlaps with A.9, but the two are not the same obligation, and ISO/IEC 42001 does not establish legal compliance. Confirm with counsel which deployer duties apply to your systems before you map them to controls.
What the A.9 use controls ask a user to show
A.9.2 asks the organization to define and document the processes it follows so that AI systems are used responsibly. For a buyer or user of AI, this means writing down how a tool gets approved for use, who may use it, what inputs staff may enter, how outputs are checked before they reach customers or decisions, and how misuse is handled. An assessor will not accept a generic acceptable use policy on its own. They will look for a process that a named owner runs and that matches how staff actually work with the tool.
- Approval steps: a documented route from request to sign-off, including who reviews the use case and the data it touches.
- Input and output rules: written limits on what data may be entered and how generated results are reviewed before use.
- Human review points: where a person checks or overrides an output, and the record kept when they do.
- Exception handling: how a request outside the approved process is escalated, decided and logged.
- Process ownership: the role responsible for keeping the process current and the date it was last reviewed.
Check that the documented process matches what staff do. Ask a sample of users to walk you through a recent use, then compare their steps with the written procedure.",
A.9.3 asks the organization to identify and document objectives that guide the responsible use of AI systems. Objectives give the processes in A.9.2 a purpose to measure against. A user organization should be able to say what it expects an AI system to achieve, which harms it wants to avoid, and how it will know whether use is staying on course. Objectives are most useful when they are specific enough to check, and when someone records progress against them.
- Stated purpose: a short record of why each AI system is used and the business outcome it supports.
- Risk-linked objectives: targets for accuracy, fairness, privacy or error rates, tied to the risks in the organization's impact assessment.
- Measurement records: periodic results against each objective, such as review sample findings or incident counts.
- Ownership and review: the person accountable for each objective and the cycle on which it is reviewed.
- Changes to objectives: a dated record when an objective is revised after a problem or a change in use.
Check whether objectives are measurable and whether the results have been reviewed by management. Objectives that never change and never get measured are a common finding.",
A.9.4 asks the organization to ensure that an AI system is used according to its intended uses and its accompanying documentation. The provider's documentation defines what the system was designed and tested to do, along with its limits and any conditions for safe operation. A user must keep that documentation and show that its own use stays within it. Where a user repurposes a tool, the assessor will expect evidence that the change was assessed, not that staff simply began using it for a new task.
- Intended-use statement: a record for each AI system stating the approved purposes, drawn from the vendor documentation and the organization's own assessment.
- Vendor documentation on file: instructions for use, limitations and known failure modes, retained with a version or date.
- Use-case register: a list of actual uses, compared against the intended-use statement to show any gaps.
- Change control for new uses: a decision record, with a re-assessment, before a system is applied to a purpose outside its intended use.
- Configuration evidence: settings or access rules that restrict the system to approved functions, where the platform supports them.
Check the register against real activity. Confirm with the vendor which capabilities their documentation covers and which fall outside it, since this determines what a user is allowed to do with the tool.
How A.10.3 supplier controls apply to a buyer of AI
A.10.3 asks the organization to confirm that AI products and services it obtains from suppliers align with its own approach to responsible development and use. The cards below set out the components a buyer should be able to show an assessor, and they make clear that the process stays with the buyer even when the vendor holds its own certificate.
Supplier inventory and intended use
Start with a register of every AI product or service the organization buys, including features embedded in tools staff already use. For each entry, record the supplier, the business purpose, the data the system receives and the decisions it informs. Without this inventory, the buyer cannot show which suppliers fall under A.10.3 or which uses fall under A.9.4 intended-use checks.
Due diligence on responsible AI practices
Before purchase, ask the supplier how it governs its AI, how it assesses impacts, how it tests models, and how it handles incidents. Compare the answers with the organization's own AI policy and objectives. Record the questions, the responses and the decision to proceed or decline, because the assessor will ask to see that the check happened for each supplier, not only for the largest ones.
Contract terms for documentation
Contracts should require the supplier to provide documentation the buyer needs to use the system as intended, such as instructions for use, known limitations and information on training data sources where relevant. Confirm with legal and procurement which clauses are standard and which need negotiation. The buyer should keep signed copies with the supplier record.
Change notice and model updates
AI systems change when vendors retrain, swap underlying models or alter safety filters. Agree in writing how and how far in advance the supplier notifies the buyer of material changes, and set a internal step that reviews each notice before the change reaches production users. Ask the vendor to confirm the notice channel and the named contact in the agreement.
Ongoing review of vendor documentation
Review supplier documentation on a schedule the buyer sets and again when a change notice arrives. Look for updated limitations, new incident disclosures and changes to data handling. Record the review date, the reviewer and any follow-up actions. Treat a missing or outdated document as a finding in the buyer's own process, not as the vendor's problem alone.
Vendor certificates do not replace the process
A supplier's ISO/IEC 42001 certificate, if it holds one, shows that the vendor operates its own management system. It does not show that the vendor's AI fits the buyer's policy, use cases or risk tolerance, and it does not clear the buyer's statement of applicability. Ask the vendor for the certificate scope and the statement of applicability, then document how the buyer's own A.10.3 process uses that evidence.
Justifying excluded development controls in the statement of applicability
An organization that only uses AI can exclude many development controls, but it must write down why for each one. Clause 6.1.3 of ISO/IEC 42001 requires a statement of applicability that lists the Annex A controls the organization needs and justifies including or excluding each control. Annex A holds 38 reference controls, and the standard does not expect every one to be implemented. For a buyer of AI, the A.6 life cycle controls on design, requirements, verification and validation, and technical documentation for a system the organization never builds are often not applicable. The A.7 data controls on acquisition, provenance, data preparation and data quality for training or tuning data are frequently in the same position. The justification must rest on the organization's actual role, not on a general statement that it is a user.
A defensible exclusion names the control, states that the organization does not design, train, fine-tune or release the system, and points to where the development responsibility sits. Often that is the vendor, identified in the supplier records that A.10.3 requires. The rationale should also cover what the organization still does. If it configures a model, adds its own data at inference time, or changes prompts or retrieval sources for a business purpose, some A.6 or A.7 controls may apply after all. Check each excluded control against the way the system is actually deployed, and confirm the role with the vendor's contract and documentation, not just the internal assumption. Review the statement of applicability whenever the use case changes.
Weak justifications are a common source of audit findings. Typical problems are exclusions that repeat the control title, reasons that cite company size instead of role, and rationales that were written once and never revisited after a new AI feature or a fine-tuning project. An assessor will test each exclusion against evidence such as system inventories, vendor agreements and configuration records. Before the audit, ask the team that runs the AI system to confirm each exclusion line by line, and ask the certification body which review method it expects for the statement of applicability.
Which EU AI Act deployer duties the controls can help evidence
ISO/IEC 42001 can help an organization organize evidence for some EU AI Act deployer duties, but it does not satisfy the AI Act and does not replace its obligations. Under Article 3(4) of Regulation (EU) 2024/1689, a deployer is anyone using an AI system under its authority, except where the use is a personal non-professional activity. Article 3(8) groups deployers with providers, product manufacturers, authorised representatives, importers and distributors as operators. If your organization uses an AI system for professional purposes, you are probably a deployer, and the first task is to list each system and confirm which role applies to it. The AI Act text on EUR-Lex sets out the definitions you will need to test against.
For high-risk systems, Article 26(1) and (2) are the duties to plan around. Article 26(1) requires deployers to use the system in line with its instructions for use, supported by technical and organizational measures. Article 26(2) requires human oversight to be assigned to people with the necessary competence, training, authority and support. In ISO 42001 terms, the closest controls are A.9.4, which asks that the system be used according to its intended uses and accompanying documentation, and A.9.2 and A.9.3, which ask for documented processes and objectives for responsible use. Your evidence might include a register of vendor instructions for use, a named oversight role with a written competence record, and logs showing that use stayed within the documented purpose. These are starting points to confirm against the regulation, not a compliance checklist.
The European Commission states that ISO/IEC 42001 helps set up an AI management system but does not match the AI Act's quality management system, which is a separate requirement tied to harmonized standards. Do not present an ISO 42001 certificate to a regulator or customer as proof of AI Act conformity. Ask a legal adviser to confirm which Article 26 duties apply to each system, and ask your certification body and any implementation partner to state in writing which evidence they prepared and which obligations remain your own. The Commission's standardisation FAQ explains the distinction.
Questions AI users ask before buying outside help
Can a company that only uses AI get ISO 42001 certified?
Yes. ISO/IEC 42001 applies to any organization, regardless of size, type or nature, that provides or uses products or services that use AI systems, so a pure user is inside its scope. ISO does not certify organizations. An external certification body issues the certificate, and that body's accreditation is voluntary, so check that it is accredited for ISO/IEC 42001. Certification bodies certifying AI management systems also apply ISO/IEC 42006:2025, which sets requirements on top of ISO/IEC 17021-1. Start with the standard itself: ISO/IEC 42001 on iso.org. Auditors read your scope statement first, so define it around the AI tools you buy, the teams that use them and the decisions they support, and make sure staff practice matches what the scope says.
Is ISO 42001 mostly documentation or technical change for AI users?
For most pure users, the larger share is governance and documentation, with technical change concentrated where a documented process cannot be enforced by people alone. The controls that matter most to users are A.9 on responsible use, A.10.3 on supplier alignment and the impact assessment controls in A.5. These ask for written processes, documented objectives, records of intended use and evidence that suppliers align with your approach. Technical work usually appears in a few places:
- restricting who can switch on an AI feature in a business tool
- keeping records of configuration changes or outputs where your process requires them
- monitoring that shows use stays within the documented purpose
Ask any partner to split its estimate into documentation, technical change and internal time, and to name the control each item supports.
What does an ISO 42001 project need from our internal team?
The most constraining input is time from people who own decisions, not only from engineers. You need an accountable owner for AI governance, since A.3 asks for defined AI roles and responsibilities. Each AI use case needs a business owner who can state its intended purpose and objectives, and procurement and legal staff must handle supplier terms and vendor documentation. You also need someone who runs the process for raising concerns about AI systems. The management system clauses require leaders to take part in management review and to act on internal audit findings. Effort continues after certification, because surveillance audits check that the processes still operate. Ask the partner to name which internal roles each deliverable depends on before work starts.
Can we do ISO 42001 ourselves or do we need outside help?
Yes, a user can run the work in house if it has people with time, authority and audit experience. Outside help is a decision about capacity and speed, not about who holds the certificate. Costs fall into three groups. Internal staff time is largely unavoidable. External preparation, such as gap analysis, document drafting, technical changes and evidence collection, is paid to the partner. Certification audit fees are paid to the certification body, which sets them. Recurring costs cover surveillance audits and upkeep. DeployOpen plans, implements, documents and prepares evidence for compliance assessments under a written, fixed scope, but it does not issue audit reports or certificates. DeployOpen does not publish a price list, so ask for a quote that separates these items and states what remains with your team.
How should we review AI exclusions in the statement of applicability?
Review each excluded Annex A control against its written justification, and repeat the review whenever your AI use changes. Clause 6.1.3 requires a statement of applicability that lists the controls you need and justifies including or excluding each Annex A control. The weak point for many pure users is excluding the controls in A.6 on the life cycle and A.7 on data on the grounds that they do not build AI. That reasoning can be sound, but the justification must describe what you do not develop, and it must still cover any control that a use case needs, such as the information flows in A.8. Assign a review owner, tie the review to the impact assessment and management review, and have internal audit sample the exclusions. Keep dated versions so an auditor can see what changed and why.
What changes if we later build or fine-tune an AI model?
The scope and control set change materially, so treat it as a formal change rather than a routine update. Building or fine-tuning brings activity into the life cycle and data areas, A.6 and A.7, which a pure user can usually exclude. Those controls then need documented processes for design, verification, deployment, technical documentation and data management. Exclusions you recorded earlier must be withdrawn or justified again. Whether building or fine-tuning also makes you a provider under the EU AI Act depends on the definitions in Article 3, so confirm your role with counsel before changing the scope. Fine-tuning a third-party model may or may not change that role, so resolve the question early. Plan the change through the same statement of applicability and management review cycle, and ask any partner to quote it as a separate change to the written scope.
Which EU AI Act deployer duties can ISO 42001 help evidence?
ISO/IEC 42001 can help you build processes and records that support deployer duties, but it does not replace legal obligations. The European Commission notes that ISO/IEC 42001 helps set up an AI management system and does not match the quality management system the AI Act calls for. Article 3(4) defines a deployer as anyone using an AI system under its authority, except in a personal non-professional activity. Article 26(1) asks deployers of high-risk systems to use them in line with the instructions for use, through technical and organizational measures. A.9.4 asks you to keep use within intended uses and accompanying documentation, so one set of records can serve both. Article 26(2) asks you to assign human oversight to people with the necessary competence, training, authority and support, which connects to the roles you define under A.3 and A.9.3. Whether a system is high-risk is a legal question, so confirm it against the AI Act Article 26 text on EUR-Lex.
How to check an implementation partner and a certification body
Organizations that only use AI still need an outside certification body to issue any ISO/IEC 42001 certificate, and they may also bring in a partner to prepare evidence. These checks separate the two roles so that the certificate, the evidence and the statement of applicability each have a clear owner before you sign anything.
Confirm accreditation and ISO/IEC 42001 scope
Ask the certification body whether its accreditation covers ISO/IEC 42001 specifically, not only ISO 9001 or ISO/IEC 27001. ISO does not certify organizations, and accreditation of certification bodies is voluntary, so an uncovered body can issue a certificate that your customers or regulators may not recognize. Ask for the accreditation body's certificate and scope document, and check the listed standard before you commit.
Check for ISO/IEC 42006:2025 requirements
ISO/IEC 42006:2025, published 7 July 2025, sets requirements on top of ISO/IEC 17021-1 for bodies certifying AI management systems. Ask the certification body how its audit team, competence and processes meet this standard. A body that cannot describe its approach to ISO/IEC 42006 has not yet shown it is ready to audit AI management systems in your scope.
Confirm the partner does not certify
An implementation partner prepares systems, controls and evidence, but only an independent certification body issues a certificate. If a consultant offers to certify you, offers its own certificate, or implies it can guarantee a result, treat that as a conflict of interest. Put the division of roles in writing so the auditor can rely on the evidence without any question of independence.
Require a written scope
Ask for a written scope that states which AI systems you use, which teams and locations are in scope, which Annex A controls apply, and which are excluded with reasons. For a user organization, the scope should focus on A.9 use, A.10 supplier relationships and the parts of A.5 impact assessment that cover systems you deploy. A vague scope lets the partner add work and the certification body define the boundary later.
Ask who owns the statement of applicability
Clause 6.1.3 requires a statement of applicability that lists the controls you need and justifies including or excluding each Annex A control. Your organization should own this document and sign off its justifications, even when a partner drafts it. Ask the partner to confirm in writing that you approve every inclusion and exclusion, and that you keep the final version when the engagement ends.
How DeployOpen works on this
DeployOpen helps organizations that buy and use AI systems set up the evidence an ISO 42001 assessment would ask about. We scope the AI systems in use, prepare the operating controls and records, and hand over documentation your team can maintain, while the organization owns its controls and an independent certification body issues any certificate.
How we scope
- We agree a written scope listing which AI systems, business units and suppliers the AI management system covers.
- We help you draft the statement of applicability with a justification for each included or excluded Annex A control.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.
How we build
- We help define the documented processes for responsible use of each AI system within its intended purpose.
- We prepare supplier review records covering the AI products and services you obtain and how they align with your use approach.
- We configure logging, access and review records on self-hosted open-source platforms inside your own infrastructure.
How we hand over
- You receive documented procedures, records templates and evidence listings mapped to the controls in your statement of applicability.
- We walk your owners through where each record lives and how often it must be updated before an assessment.
- Ownership of controls, approvals and sign-off stays with your organization throughout the handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- Retainers can cover periodic evidence reviews ahead of stage 1 and stage 2 assessments run by your certification body.
- Ask us to confirm in writing what a retainer covers, how often reviews occur and who approves changes.
