How to set ISO 42001 AI objectives before a certification audit
A customer questionnaire, contract or regulator now expects an AI management system, and the auditor will ask to see documented AI objectives. Under clause 6.2 of ISO/IEC 42001:2023, the organization sets its own AI objectives and plans how to achieve them. Annex C is informative, so it is a non-mandatory list of potential AI-related organizational objectives and risk sources you can draw on, not a list you must adopt. Two Annex A controls require specific objective records: A.6.1.2 asks for documented objectives that guide responsible development, integrated into the life cycle, and A.9.3 asks for documented objectives that guide responsible use of AI systems. Your objectives should cover both areas where your organization builds or provides AI and where it uses AI.
Each objective needs to be specific enough to measure, have a named owner, a target, a method of measurement, a timeline and a defined way of reporting progress. Record how the objective is monitored under clause 9.1, how the results are reviewed at management review under clause 9.3, and what happens when an objective is missed, which links to the corrective action process in clause 10.2. The organization owns these objectives and the decisions behind them. An implementation partner can help draft the objective register, link it to the statement of applicability and assemble the monitoring records. An independent certification body decides whether the system conforms. The standard does not set a cost or duration for this work, so ask any partner for a written scope that lists the objective records, the review cycle and who signs off each deliverable before work starts.
Which Annex C objectives and risk sources to draw from
Annex C of ISO/IEC 42001 lists potential AI-related organizational objectives and risk sources that you can draw on when setting AI objectives under clause 6.2. It is a starting point to tailor to your own AI systems, not a list to adopt in full. Pull the exact Annex C wording from your licensed copy of the standard before you adopt any category.
Trust and transparency
Ask whether people affected by your AI systems can tell when AI is involved and understand, at a useful level, how outputs are produced. Check which AI systems need user-facing disclosure, which need internal explanation records for reviewers, and who answers questions about them. Turn the answers into a measurable objective, such as the share of high-impact systems with current documentation, and assign an owner to track it. Confirm the wording of the relevant Annex C entries in your licensed copy.
Fairness and non-discrimination
Ask which groups could be treated unequally by each AI system, including through training data gaps, proxy variables or uneven error rates. Check whether you measure outcomes across relevant groups before and after deployment, and who decides when a disparity is acceptable. An objective here should name the population, the metric and the review cadence, so that it can be monitored under clause 9.1. Tailor the risk sources to your sector and the decisions the system influences.
Security and resilience of AI systems
Ask how an attacker, a faulty integration or a supplier failure could cause an AI system to leak data, take unintended actions or stop working. Check whether models, prompts, training data and inference endpoints sit inside your existing access control and logging, and whether AI-specific threats such as data poisoning or prompt injection appear in your risk register. Objectives can cover tested mitigations and time to restore a failed service, with evidence kept for the internal audit.
Safety and human oversight
Ask where an AI output could cause physical, financial or psychological harm if it is wrong, and whether a person can detect and override it in time. Check that oversight roles are defined, that the people in them are competent for the task, and that the system can be stopped or rolled back. An objective might require a documented override path and a recorded review of every incident where the oversight step was bypassed.
Privacy and personal data
Ask what personal data enters training, fine-tuning, prompts and outputs, and whether each use has a lawful basis and a stated purpose. Check retention of prompts and logs, data minimization, and whether impact assessments cover privacy risks alongside AI system impact assessment under clause 6.1.4. Objectives should tie to measurable controls, such as the proportion of AI systems with a completed privacy review before release. Confirm any GDPR overlap with counsel.
Business value and stakeholder trust
Ask which business outcomes an AI system must deliver, and which customer, regulator or contract commitments depend on demonstrating responsible AI. Check whether the objective is realistic for the system's risk level and whether it conflicts with any safety, fairness or privacy objective. Objectives should show how responsible AI supports the business goal, not replace it, and should be reviewed when the system's purpose or the market changes.
Objectives for responsible development (A.6.1.2) and responsible use (A.9.3)
A.6.1.2 asks the organization to identify and document objectives that guide the responsible development of AI systems, then to take those objectives into account and integrate measures to achieve them across the life cycle. Objectives set early can shape design, data and verification decisions before those decisions are locked in. Clause 6.2 and Annex C of the standard offer starting points for the objectives themselves.
- Objective register entries: each objective states its purpose, owner, linked AI system and the measure that shows progress.
- Design integration: requirements and design records show which objectives drove choices such as feature selection or human override points.
- Data measures: acquisition and quality checks trace back to the objective, for example representativeness checks on training sets.
- Verification evidence: test plans and results cite the objective each test confirms.
- Change control: when a model is retrained or its architecture changes, the objective and its measures are checked again before release.
Illustrative example: a lender building a credit scoring model sets an objective that each model version shows measured error rates across applicant groups before release. Check that every objective names the life cycle stage where it is met and that linked records exist for each AI system in scope.
A.9.3 asks the organization to identify and document objectives that guide the responsible use of AI systems. These objectives sit with the people and teams operating the system, so they must describe permitted users, permitted tasks and the limits that keep use within the system's intended purpose. The objectives link directly to the Annex A use controls on processes for responsible use and on keeping use within intended purpose.
- Purpose-bound objectives: each use objective states the permitted task, the authorized users and the boundaries of use.
- Operational enforcement: access rules and platform configuration put the objective into practice, and the configuration files serve as evidence.
- Usage monitoring: logs or usage reports show whether use stays within the intended purpose.
- Feedback and incidents: misuse, drift or user complaints trigger a review of the objective and its controls.
- New use cases: a proposed use outside the documented purpose triggers an impact assessment and an updated objective before go-live.
Illustrative example: a hospital triage team uses a summarization tool with an objective that staff use it only to draft internal notes, with clinician review before anything enters the patient record. Confirm that each use objective can be tested against logs or configuration, because auditors will ask how the organization knows use has stayed within purpose.
An auditor testing A.6.1.2 and A.9.3 will start with the objective register, then follow each objective into the records that show it was acted on. The register alone does not satisfy the requirement, because the evidence must show that the objectives guided development and use in practice. Ask the certification body which record format it accepts and how it chooses which AI systems to sample.
- Objective register: a dated, versioned list with owners, approval records and links to each AI system in scope.
- Linked life cycle records: design, data and verification records that cite the objective identifiers they support.
- Use evidence: configuration baselines, access logs and monitoring reports for each use objective.
- Measurement results: metrics with their data sources, thresholds and the dates they were recorded.
- Review history: management review entries and corrective actions raised when an objective was missed or changed.
Illustrative example: a team stores objectives in a Git repository as objectives.yaml, with each record referencing the same identifiers used in test reports and monitoring dashboards. Check that a sampled objective can be traced in both directions, from the register to the evidence and from the evidence back to the register.
How AI objectives are set, monitored and reviewed
This sequence turns the AI policy, Annex C sources and risk and impact outputs into a recorded set of owned, measured objectives that management reviews and updates over time.
Confirm the AI policy and scope
Before any objective is written, check that the AI policy under clause 5.2 exists, is approved by top management, and names the AI systems and business units inside the scope set under clause 4.3. Objectives must point at the policy's commitments, so a reader can trace each objective back to a stated intent. The output is a short reference sheet listing the policy version, the in-scope AI systems and the people who approved them. Confirm with your own leadership how the policy and scope were approved, because that record is what an auditor will ask to see first.
Gather Annex C sources and assessment outputs
Collect the inputs the objectives will draw from. Annex C is informative and lists potential AI-related organizational objectives and risk sources, which the team reviews against its own business context. Pull in the outputs of AI risk assessment and treatment under clauses 6.1.2 and 6.1.3, and the AI system impact assessment results under clause 6.1.4. The output is a working register that maps each candidate source to the AI system or process it concerns. Note where a source is not relevant and why, since that reasoning becomes part of the record.
Draft objectives with owners and measures
Write candidate objectives in plain language, each tied to a source from the register. Each objective needs a named owner, a measure that can show whether it is met, and a link to the AI system it governs. Include the responsible development objectives expected under A.6.1.2 and the responsible use objectives expected under A.9.3 where they apply to your role. The output is a draft objectives table with columns for objective, owner, measure, source and affected system. Ask the owner to confirm the measure is something their team can actually collect.
Approve objectives at the right level
Send the draft to the people who hold authority over AI decisions, typically the accountable executive or AI governance body named in the roles under clause 5.3. Approval should confirm that objectives are consistent with the AI policy, reflect the risks found in assessment, and have owners with the authority to act. Record the approver, the date and any conditions attached. The output is an approved objectives record that a reader can trace from the policy to each owner. Confirm the approval route in your own governance documents, since ISO 42001 requires documented decisions but leaves the body to the organization.
Plan actions and resources for each objective
For each approved objective, define the actions needed to achieve it, the resources required and the dependencies on other teams or suppliers. Planning covers the changes that may affect the AI management system, which connects to the planning of changes under clause 6.3. Where an objective depends on data, tooling or people, link it to the resource records under A.4. The output is an action plan per objective with named responsibilities and identified resource needs. Ask the owner to state what must be in place before work starts, so gaps surface early.
Record objectives as documented information
Store the approved objectives, plans and measures as controlled documented information under clause 7.5, with version history and a clear owner for the register. Each record should show the objective, its rationale, its measure, its target condition and the review date set by the organization. The output is a controlled objectives register that auditors and interested parties can access and that the team updates only through its approval route. Check that the register is referenced in the statement of applicability where the related controls are included.
Monitor and measure progress against objectives
Collect the agreed measures at the intervals the organization defines and record the results against each objective. Monitoring under clause 9.1 is where a team learns whether an objective is on track, whether a measure still reflects the objective, and whether a new risk has appeared. Where a result falls short, log a nonconformity or corrective action under clause 10.2. The output is a dated measurement log per objective showing actual results, trends and any corrective actions opened. Confirm the collection method for each measure in advance, so the data can be trusted when auditors sample it.
Report results and update objectives after review
Present objective performance, internal audit findings and changes in AI risk to management review under clause 9.3. Management decides whether each objective should continue, change, close or be replaced, and records those decisions. Updates then flow back into the register, the action plans and, where needed, the risk and impact assessments. The output is minuted management review decisions and a revised objectives register with a new version number. Ask your own governance lead to confirm the review cycle, since the cadence is set by the organization and should appear in the written scope of any implementation support.
Choosing how to build the objective set
This table compares three ways to draft and maintain AI objectives under clause 6.2 and the Annex A objective controls. Read each row against your own governance capacity, because no option moves ownership of the objectives away from your organization.
| Option | When it fits | Who owns the decisions | Evidence the auditor still expects | Main risk |
|---|---|---|---|---|
| Own AI governance team | Mature AI governance with named owners, existing risk committee and enough time to document objectives in full | The organization, through its AI governance lead and executive sponsor who approve each objective | Dated objective records, linked AI policy, measurable targets, owners, monitoring results and management review minutes | Objectives written as generic principles with no measures, so monitoring shows nothing useful |
| Internal team with an implementation partner for records and evidence | Internal staff understand the AI systems but need help structuring registers, traceability and monitoring data | Internal team decides which objectives apply and signs them off; the partner prepares templates, records and evidence | Same records as the first option, plus proof that internal staff reviewed and approved what the partner prepared | Partner-drafted wording that staff accept without challenge, leaving the objectives untested against real AI use |
| External consultant workshop, scoped in writing | Organization is new to ISO 42001 and needs a facilitated start, with a defined deliverable and end date | Still the organization; the workshop informs choices, and leaders must confirm each objective after the session | Workshop agenda and attendee list, the draft set with reasoning, leadership approval and the organization's own later monitoring | Workshop output treated as finished, with no internal owner for reviewing objectives after the engagement closes |
| Consultant or partner as sole author | Rarely appropriate; sometimes requested to speed up a deadline | Nominally the organization, but decisions sit with an outside party who may not run the AI systems | Still required: approval records, owner assignments and ongoing monitoring data held by the organization | Auditor questions whether the organization truly directs its AI objectives, creating a nonconformity risk |
| Certification body involvement | Never as a design party | Not applicable; the certification body audits and does not draft objectives | Auditor reviews the organization's records during stage 1 and stage 2 | Consulting the certification body on design can weaken its independence, so keep the roles separate |
Who owns the objectives, who prepares evidence and who decides conformity
Your organization owns every AI objective it sets under clause 6.2, and it is accountable for whether those objectives are met. Leadership must approve the objectives and make sure they fit the AI policy and the scope of the AI management system. Objectives drawn from Annex C and from the responsible development and use objectives in A.6.1.2 and A.9.3 should reflect the organization's own AI systems and risks, not a generic list copied from a template.
- Ownership: Name an accountable owner for each objective, usually a business or product leader, with a clear deputy.
- Approval: Record leadership approval, the date and the basis for each objective, including why it was chosen over alternatives you considered.
- Monitoring: Decide the measures, targets, data sources and review frequency, and assign who reviews the results.
- Action: Act on results that miss target, through corrective action under clause 10.2 or changes to the objective itself.
- Management review: Bring objective performance to management review under clause 9.3 so leadership decides on resources and priorities.
Before certification, confirm that the people named as owners can explain their objectives and results without relying on the consultant or the auditor.
An implementation partner prepares the working material that makes objectives visible and checkable. Its role is to build and maintain the records, not to decide what the organization wants to achieve. The partner does not set the objectives, does not approve them, and does not issue any report or certificate. Its output is evidence prepared for the organization and, later, for the certification body.
- Objective register: Prepare a register that records each objective, its owner, its linked AI systems and its approval history.
- Control and record links: Map each objective to the relevant Annex A controls, the statement of applicability entries and the records that show progress.
- Monitoring dashboards: Build dashboards and reports from the measures the organization has chosen, with the data pipelines and access controls needed to keep them trustworthy.
- Change tracking: Keep version history so changes to objectives can be traced to a decision by the owner.
- Handover: Document the setup so the organization's own staff can run and update the register after the engagement ends.
The scope of such work should be written down before it starts. Ask the partner to confirm in writing that it will not set objectives or sign off on conformity.
The certification body or independent auditor tests the management system and decides conformity. It checks whether AI objectives exist, whether they are measured against defined criteria, and whether they are reviewed and updated when results or AI systems change. It does not design the objectives or prepare the monitoring tools for the client. ISO does not certify organizations, so a decision is valid only when it comes from a certification body that is accredited to certify ISO/IEC 42001, and accreditation of those bodies is voluntary. ISO/IEC 42006:2025 sets additional requirements for bodies certifying AI management systems.
- Existence: Sample the objectives and check that they are documented, owned and approved by leadership.
- Measurement: Check that each objective has measures, data sources and results that can be traced.
- Review: Check that objectives are reviewed in management review and changed when needed.
- Accreditation: Confirm that the body holds accreditation for ISO/IEC 42001 before you rely on its decision.
- Independence: Confirm that the certification body is not the same firm that helped build the objectives or the dashboards.
Ask the certification body for its accreditation scope in writing and check it against the accreditation body's public listing.
Objective mistakes that cause audit findings and rework
Auditors testing clause 6.2 usually find the same few gaps: objectives that cannot be measured, objectives copied from Annex C without tailoring, and objectives that never reach the life cycle, use records or management review. Each card below names one gap, how to close it, and the record that shows the fix.
Objectives with no measure or owner
An objective such as "use AI responsibly" cannot be checked, so it cannot be shown as met. For each objective, record a measurable indicator, a target, a named owner, a data source and a review date. Ask whether a second person could collect the same measurement and reach the same result. The record that proves the fix is the objectives register with indicator, target, owner and measurement history for each entry.
Annex C copied without tailoring
Annex C lists potential AI-related objectives and risk sources as a starting point, not a finished list. Objectives pasted in unchanged rarely match the AI systems in scope, their users or their impacts. Walk through each Annex C item, keep the ones that apply to a named AI system, rewrite them in the organization's terms and record why others were not adopted. The record is a mapping from each Annex C item to the adopted, adapted or rejected objective, with the reason.
Development objectives with no life cycle link
Objectives for responsible development, which the organization must identify and document under A.6.1.2, often stay on a policy page while engineers work from a separate backlog. An auditor will ask where the objective was taken into account in design, testing and release. Link each development objective to specific life cycle stages, design records, verification and validation results and deployment approvals. The record is a traceability table from objective to life cycle evidence.
Use objectives detached from operations
Objectives for responsible use, documented under A.9.3, need to reach the teams that run AI systems day to day. When they exist only at the policy level, operators never see them and no operational record shows them. Assign each use objective to the operating team, add a check to the operating procedure and capture results in the monitoring output. The record is the operational procedure with the objective referenced, plus monitoring reports for the period.
Objectives never reviewed by management
Clause 6.2 objectives must be monitored and updated, and clause 9.3 expects management review to consider performance. Objectives set during certification preparation and then left unchanged create a finding at the next review cycle. Put the objectives register on the management review agenda, record the performance decision for each objective and update targets when the AI system or its risks change. The record is management review minutes showing each objective, its status and the decision taken.
Objectives that conflict with risk treatment
An objective to deploy a system quickly can contradict a risk treatment decision to delay release until a bias test is complete. Auditors check that objectives and the AI risk treatment plan agree, because both come from the same risk picture. Cross-check each objective against the risk register and the statement of applicability before approval, and resolve any conflict in writing. The record is a consistency review showing each objective linked to the risks and treatments it depends on.
Questions buyers ask about AI objectives under ISO 42001
Must we adopt every objective listed in Annex C?
No. Annex C is informative, so it lists potential AI-related organizational objectives and risk sources that you can draw on, not a checklist you must complete. Clause 6.2 requires you to set AI objectives that fit your context, your AI systems and the risks you identified under clause 6.1. Your auditor will look for a reasoned link between the objectives you chose and your AI risk picture, and for a note explaining why any relevant Annex C item was left out. Expect the selection to change as your AI portfolio changes.
Do our AI objectives have to be published?
ISO/IEC 42001 requires you to document the objectives and to make them available where the standard requires it, but it does not oblige you to publish them on a website. Many organizations share a summary with customers or in their trust materials and keep the full record internal. Decide the level of disclosure with legal and communications teams, and check how the objectives will be presented in customer questionnaires and procurement reviews. Your auditor will test the documented version, so keep that version complete even if the public summary is shorter.
How many AI objectives should we set?
The standard asks for a number that matches your scope, not a fixed count. Set enough objectives to cover the responsible development objectives in A.6.1.2 and the responsible use objectives in A.9.3 for the AI systems in scope, and enough to show progress toward your AI policy. Too few objectives usually signals that risks went unaddressed, while too many become impossible to monitor. Each objective should have a named owner, a measure, a target and a review date, so the list you keep is one you can actually run.
Can a consultant write our AI objectives for us?
A consultant can help draft objectives, compare them with Annex C and show how they connect to your AI risks. The objectives must still be owned and approved by your organization, because they commit your leadership to outcomes they will be held to. An implementation partner prepares the drafting, the traceability and the monitoring records, while your staff decide what the organization is willing to measure and fund. Any independent review is performed by an auditor or certification body, which issues the certificate. ISO does not certify organizations, so the certification body is the one that confirms conformity.
Who has to approve the AI objectives?
Top management must approve the objectives, consistent with the leadership role in clause 5 and the AI policy. In practice, the AI governance lead or committee proposes them, and an executive with authority over the AI systems in scope signs them off. Record the approval, the version and the date in your documented information so the auditor can trace who accepted responsibility. Objectives that change materially should go back through the same approval path, and management review under clause 9.3 is a natural checkpoint for that.
How do AI objectives link to the statement of applicability?
The link is traceability. Each objective should point to the risks in your AI risk treatment plan and to the Annex A controls that support it, and the statement of applicability should show which controls you included and why. If an objective depends on a control you excluded, the justification must explain how the objective is still met. Auditors often test this chain by picking an objective and following it to the risk, the control, the evidence and the monitoring result. Build the matrix once and update it whenever either document changes.
How long will it take to set up our AI objectives?
The time depends on how many AI systems are in scope, how mature your AI inventory and risk assessments already are, and how many owners must agree on targets. Setup is usually faster when the risk register and impact assessments exist, and slower when AI use is spread across teams with no central record. Ask any implementation partner for a written schedule tied to a defined scope and deliverables, and confirm which dependencies, such as data owners or measurement tooling, sit on your side. ISO does not certify organizations, so also confirm the certification body's timeline separately.
How DeployOpen prepares objective records and monitoring for the audit
DeployOpen helps organizations set up the objective records, monitoring and review routines that clause 6.2 and the objective areas in Annex A expect. We prepare systems and evidence inside your own infrastructure, while your organization owns its objectives and an independent certification body decides certification.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which AI systems, teams and objectives are covered, and which Annex C sources are considered.
- Your organization confirms who approves each objective, its owner and the measures that show progress.
How we build
- We configure the systems that hold objective records, owners, target dates and monitoring data in your environment.
- We set up measurement and reporting so each objective has a defined indicator, a data source and a review cadence.
- We link objectives to the responsible development and responsible use objectives in A.6.1.2 and A.9.3 through documented records.
How we hand over
- You receive documented objective records, monitoring procedures and review logs that your own staff can maintain.
- Each record shows the objective, its rationale, the Annex C source considered and the evidence that supports it.
- Handover includes a walkthrough so your team can explain objectives and their monitoring to an assessor.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer work can add periodic objective reviews that feed into your management review and internal audit cycle.
- Ask any certification body or auditor to confirm which evidence they will accept before the scope is finalized.
