Search every question across sub-FAQs

Top management must establish the AI policy. It must fit the organisation's purpose, provide a framework for AI objectives, commit to applicable requirements and continual improvement of the AIMS, refer to other organisational policies where relevant, be documented and communicated internally, and be available to interested parties as appropriate. Availability does not always mean public posting; record which parties need access, in what form, and why.

Annex B guidance says the policy should reflect business strategy, values and culture, risk tolerance, AI-system risk, legal and contractual requirements, the risk environment, and impacts on interested parties. It should also set guiding principles and a process for deviations and exceptions. It can cross-reference topic policies instead of repeating security, privacy, safety, quality, procurement, data, or product rules.

Keep the current approved policy, version history, review record, communication evidence, and records showing that people under the organisation's control know the policy and understand their contribution and the consequences of nonconformity. Trace commitments to AI objectives, responsible-development or use processes, risk-treatment decisions, and any affected topic policies. For an exception, retain the request, affected commitment, rationale, risk or impact review, approving authority, conditions, expiry date, and closure or renewal decision.

Top management establishes the policy and remains responsible for leadership and commitment. Management may approve a role to develop, review, and evaluate it, but assigning maintenance does not transfer top management's accountability.

Owners of affected security, privacy, safety, quality, procurement, data, product, legal, or risk policies should review proposed changes within their authority. Route changes in organisational direction, risk tolerance, commitments, or resources back to top management.

Review the policy at planned intervals and additionally when needed to ensure continuing suitability, adequacy, and effectiveness. ISO/IEC 42001 does not set one universal review frequency. Relevant triggers can include changes to the AIMS scope, organisational environment, business circumstances, legal or contractual conditions, technical environment, AI objectives, risk tolerance, AI uses, material impact findings, or management-review results.

Record the review result even when no change is needed; when the policy changes, update affected objectives, procedures, communications, awareness material, control ownership, and operating evidence rather than treating approval as the final step.

Choose the assurance outcome first: self-assessment, a customer-requested second-party review, or independent third-party certification. Only the third option can produce an independent ISO/IEC 42001 management-system certificate, and accreditation is a separate attestation of the certification body's competence for a stated certification scope.

Define the exact AIMS boundary before requesting proposals. Record the legal entity, organisational units, locations, products, services, AI activities, shared processes, outsourced work, and interfaces included in or excluded from the scope. ISO/IEC 42001 applies to organisations of any size or type that provide or use products or services involving AI systems, but a certificate reaches only the documented and audited boundary.

Operate the AIMS long enough to produce representative evidence. Readiness requires more than approved policies: auditors need records showing risk and impact assessment, treatment, competence, operational controls, monitoring, internal audit, management review, and correction of nonconformities in practice.

Build a traceable evidence set for the complete audited boundary. It should cover context and scope, interested-party requirements, policy and roles, objectives, AI risk criteria, system inventory, risk and impact assessments, the statement of applicability, approved treatment plans and residual risks, competence, controlled documents, operational samples, supplier controls, monitoring results, internal audits, management reviews, nonconformities, and corrective-action effectiveness.

For each sample, retain the system or process covered, owner, version, period, criteria, result, exception, approval, and follow-up. Evidence from outside the proposed scope may provide context, but it cannot substitute for records from the sites and activities the certificate will name.

Top management should approve the scope and assurance objective because it is accountable for the AIMS, resources, integration into business processes, and intended results. An AIMS owner can coordinate readiness, while process, system, risk, and control owners provide evidence and correct gaps.

Internal auditors must remain objective and impartial. Procurement or assurance teams can check the external body's proposed scope, competence, impartiality, and credentials, but the organisation should verify accreditation with the named accreditation body or authoritative register rather than relying on a proposal, sales statement, or logo.

The external body makes the certification decision. Consultants, internal auditors, customers, and the organisation's management can assess readiness or conformity, but they do not issue the independent certificate.

Review the certified scope whenever organisational boundaries, legal entities, sites, AI activities, products, services, outsourced processes, major suppliers, or interested-party requirements change. Assess planned changes before representing the new activity as certified, and tell the certification body when the certification agreement requires notification.

Follow the audit and certificate cycle stated by the certification body, including any surveillance, recertification, special-audit, suspension, or withdrawal conditions. ISO/IEC 42001 itself requires internal audits and management reviews at planned intervals but does not prescribe one universal external audit frequency or certificate term.

Before making a public claim, verify that certificate wording, legal entity, sites, activities, exclusions, standard edition, validity dates, certificate status, and certification-body details match the current certificate and actual AIMS boundary. Do not wait for an external audit to address a known nonconformity or ineffective control.

Treat each generative AI use as a system in context, not as a model name or vendor account. Document the intended purpose, users and affected parties, prohibited or foreseeable misuse, decisions influenced by outputs, deployment environment, model and service versions, system prompts, retrieval sources, connected tools, input and output data, and supplier-imposed limits.

Classify the relationship before selecting controls. An organisation that trains or fine-tunes a model controls different lifecycle evidence from one that calls an external API, adds retrieval and tools to a supplied model, enables a feature inside business software, or permits staff to use a public service. For each case, record which controls the organisation operates, which evidence the supplier provides, which evidence is unavailable, and whether the remaining limitation is accepted, mitigated, or blocks the use.

Use the AI system impact assessment and risk assessment to select evaluation and oversight. Examples can include testing grounded answers against approved sources for a retrieval assistant, checking whether a coding assistant introduces insecure dependencies, testing demographic and language performance for a customer service tool, and preventing a content generator from exposing confidential prompts or producing prohibited impersonation. These are examples; the intended use and affected parties determine the actual tests.

Generative AI is not a separate ISO/IEC 42001 certification class, and it is not automatically a general-purpose AI model under the EU AI Act. Where EU law applies, assess the model, downstream system, operator role, and Chapter V or other obligations separately. ISO/IEC 42001:2023 is voluntary unless a contract, policy, or law requires its use. The standard has no universal statutory implementation deadline.

Evidence should match the selected controls and the released use case. Keep an inventory record; owner and approved users; model, service, prompt, retrieval, data, tool, and hosting versions; supplier documentation and accepted limitations; risk and impact assessments; test sets and acceptance criteria; release decision; user instructions; human-review samples; event logs; monitoring results; complaints and incidents; provider change notices; and reassessment decisions.

Preserve enough detail to reproduce the conclusion. Record the evaluation date, system configuration, sample source and limits, relevant user or affected group, metric and threshold, result, reviewer, exceptions, and approval. A vendor benchmark or model card may support the record but does not prove that the configured application works for the organisation's data, users, tools, and decisions.

Assign a business owner for the use and its outcomes, technical owners for integration and monitoring, data and security owners where relevant, procurement for supplier commitments, and an authority able to restrict, suspend, or retire the use when controls fail.

The designated management authority approves the risk-treatment plan and residual AI risk. Legal, privacy, security, safety, employment, intellectual-property, records, or sector owners should decide issues within their own authority; AIMS approval cannot waive a binding requirement or replace those decisions.

For supplier services, assign who reviews terms and documentation, approves data sent to the service, receives model or policy changes, controls accounts and integrations, monitors the configured use, reports incidents, and executes exit or data-return arrangements.

Review at planned intervals and when the model or service version, terms, data sources, system prompt, retrieval design, tools, moderation, intended use, user population, deployment context, output reliance, supplier evidence, incidents, or applicable requirements change.

A supplier's model update can change behaviour without an application-code release. Route provider notices, silent evaluation drift, new limitations, changed usage, and unexpected tool behaviour through the same risk, impact, approval, and monitoring controls as an internal significant change.

Reassess before a pilot becomes production, a low-consequence drafting aid begins influencing decisions about people, an internal tool becomes customer-facing, new data categories are entered, or a component gains access to external actions. Restrict or retire the use when required evidence is unavailable or residual risk no longer meets the approved criteria.

Run two separate decisions. For the AIMS decision, apply documented criteria that distinguish acceptable from unacceptable risk. Identify consequences for the organisation, individuals, and societies; assess realistic likelihood where applicable; determine the risk level; compare it with the criteria; and prioritise treatment. Use the AI system impact assessment to account for intended use, foreseeable misuse, affected people, deployment context, and applicable jurisdictions.

For an EU AI Act decision, first confirm territorial and material scope under Article 2 and determine the operator role. The Act can reach providers placing systems on the Union market, EU deployers, and certain third-country providers or deployers where output is used in the Union. It excludes specified military, defence, national-security, scientific-research, pre-market research and testing, purely personal non-professional, and some free and open-source circumstances; each exclusion has conditions.

Then test Article 6. The product route requires both an Annex I product or safety-component link and a third-party conformity assessment under the listed product law. The listed-use route requires an intended purpose in Annex III, such as recruiting or filtering job applicants, evaluating students, credit scoring of natural persons other than fraud detection, emergency healthcare triage, or specified remote biometric identification. These are examples, and the exact Annex wording and facts control.

For an Annex III use, test the limited Article 6(3) derogation. The system must not pose a significant risk of harm to health, safety, or fundamental rights, including by not materially influencing decision-making, and must perform a narrow procedural task, improve a completed human activity, detect patterns without replacing or influencing the completed assessment without proper review, or perform a preparatory task. Profiling of natural persons remains high-risk. A provider relying on the derogation must document the assessment before placing the system on the market or putting it into service and must register it.

The published AI Act text sets 2 August 2026 for the Annex III route and 2 August 2027 for the Article 6(1) product route. The Council gave final approval to the Digital Omnibus on AI on 29 June 2026; the adopted amendment moves those dates to 2 December 2027 and 2 August 2028 respectively. The amending act must still be published in the Official Journal and enter into force, so record which legal text and effective date support the classification plan. Article 111 has separate transition rules for systems already placed on the market or put into service, including rules for specified large-scale IT systems and high-risk systems intended for public-authority use. None of these dates delays ISO/IEC 42001 risk and impact work or other applicable law.

For the AIMS record, keep the system's intended purpose, functionality, deployment context, affected population, risk criteria, risk assessment, impact assessment, treatment plan, statement of applicability, control results, residual-risk approval, monitoring, incidents, and change history. Show how each material consequence and selected control connects to the actual use.

For the EU record, keep the AI system definition analysis, Article 2 scope facts and exclusions, provider and deployer roles, intended purpose, product-law or Annex III route, exact Annex entry, decision influence and profiling facts, Article 6(3) assessment if used, registration evidence, applicable date, approver, and source version. If the product route applies, retain the product classification and third-party conformity-assessment basis under the relevant Annex I law.

A provider relying on Article 6(3) needs a system-specific assessment before market placement or putting into service. A generic statement that the tool is administrative, assistive, low-risk, or subject to human review does not establish the derogation.

Designated management must approve the AIMS risk-treatment plan and acceptance of residual AI risks. A legal or regulatory owner should approve the separate statutory classification within the organisation's governance model; neither approval substitutes for the other.

The provider owns the Article 6 classification and any pre-market Article 6(3) documentation. Deployers should still verify that the provider's classification and instructions fit their actual use, because a changed intended purpose or substantial modification can shift provider obligations under Article 25.

Security, privacy, safety, employment, product, supplier, and business owners should contribute when their requirements or evidence affect the decision. Escalate any proposed residual-risk acceptance that conflicts with binding law rather than recording it as an accepted exception.