ISO/IEC 42001 AI management system implementation and certification readiness checklist

Structure (9 sections)

1. 1. Context of the organization and scope of the AIMS (Clause 4)

   Determine and document the internal and external issues relevant to the AI management system, the interested parties and their requirements, and the boundaries and applicability of the system. The scope statement must be specific about which AI systems, which organisational units and which life-cycle stages, and must state the organisation’s role in the AI value chain (developer, provider, deployer, or a combination). The role determination is critical: it drives which controls apply and how you answer customer due diligence. The common Chinese configuration — an in-house model plus third-party foundation models plus deployment support for customers — puts you in all three roles at once, so list them separately in the scope statement rather than writing "AI-related business" in the abstract.

   Evidence to attach

   • · Analysis of internal and external issues and the interested party requirements register
   • · Scope statement (AI system inventory, organisational units, life-cycle stages, geography)
   • · Role determination in the AI value chain, assessed per product line
   • · Note on integration with existing management systems (27001, 9001)

   Common pitfalls

   • · Scoping too broadly, so the certification audit reaches experimental products that are not yet governed
   • · A vague role determination, which undermines the applicability judgements on the Annex A controls
   • · Building a separate document set from the existing ISO/IEC 27001 system, doubling maintenance cost and creating contradictions

2. 2. AI policy, roles and responsibilities, and objectives (Clause 5 and 6.2)

   The AI policy is approved by top management, states the organisation’s commitment to responsible AI, its relationship to business strategy and a commitment to continual improvement, and is communicated internally and made available externally as needed. Responsibilities must land on named people: the AI governance lead, model and system owners, data owners, those who perform risk assessments, and the internal auditors, each with authority and reporting line. Objectives must be measurable (the proportion of high-risk models with a completed impact assessment before launch, the on-time closure rate of high-risk findings) with an owner and a review frequency. For companies also under PRC supervision, the policy should point the "comply with applicable legal requirements" commitment at specific internal procedures — algorithm filing, security assessment, content labelling — so the policy and local compliance are not two separate worlds.

   Evidence to attach

   • · AI policy text, top management approval, and evidence of publication and communication
   • · Responsibility matrix (role, authority, reporting line, appointment letters)
   • · AI objectives with measurement method, owners and review records
   • · Mapping from policy clauses to local compliance procedures

   Common pitfalls

   • · An AI policy copied from the standard text, showing no connection to your own products
   • · Responsibility assigned to a notional "AI governance committee", leaving nobody to name when the auditor asks
   • · Unmeasurable objectives ("improve AI safety"), which management review cannot assess

3. 3. AI risk assessment, risk treatment and the Statement of Applicability (6.1.2, 6.1.3)

   Establish and document the AI risk assessment process: risk criteria (the acceptable level), the identification method, the analysis and evaluation method, and the triggers for assessment (new system launch, significant model update, change of purpose, external events). At the treatment stage, determine the necessary controls and compile the Statement of Applicability: each Annex A control, whether it applies, the justification for inclusion or exclusion, and its implementation status. The SoA is the core document in the certification audit and the single material that best demonstrates maturity in customer due diligence — the more specific the exclusion justification, the more credible it is, while a bare "not applicable" draws follow-up questions. Annex B gives implementation guidance for the controls and Annex C lists potential AI-related organisational objectives and risk sources, useful as an identification checklist.

   Evidence to attach

   • · AI risk assessment process document (criteria, method, triggers)
   • · Risk register (risk, source, analysis, evaluation, treatment decision, owner, review date)
   • · Statement of Applicability (control by control: applicability, justification, implementation status)
   • · Risk treatment plan and management acceptance of residual risk

   Common pitfalls

   • · Marking every Annex A control applicable to save effort, then showing "planned" as the implementation status across the board
   • · A single risk assessment that was never repeated despite several significant model updates
   • · Residual risk formally accepted by nobody, leaving no approval record at audit

4. 4. AI system impact assessment (6.1.4 / 8.4)

   Establish a process to assess the potential impacts of AI systems on individuals, groups and society, and operate it at both the planning and operational stages: when it is mandatory, who performs it, what method is used, how the conclusion affects the launch decision, and when it must be redone. The assessment typically covers intended use and foreseeable misuse, affected populations, the types of potential harm (safety, health, fundamental rights, discrimination, privacy), mitigations and residual impact. ISO/IEC 42005 provides dedicated guidance and can be cited directly as the methodology. In practice, write the impact assessment trigger into the product launch process as a release gate, and reuse the same input materials as the personal information protection impact assessment and the security assessment so that three processes do not each demand the same evidence.

   Evidence to attach

   • · Impact assessment procedure (triggers, method, owners, approval path)
   • · Impact assessment reports and conclusions for each AI system
   • · Process evidence that the impact assessment gates release (for example a checklist item in the release ticket)
   • · Note on input reuse with the personal information protection impact assessment and security assessment

   Common pitfalls

   • · Performing the impact assessment after launch, which turns it into paperwork
   • · Covering intended use only and ignoring foreseeable misuse
   • · Concluding "moderate risk" without stating the mitigations or who accepted the residual impact

5. 5. AI system life-cycle and data governance controls (Annex A.4 / A.6 / A.7)

   Push three Annex A control groups into the engineering process. Resources (A.4): identify and document compute, data, tooling and people resources. Life cycle (A.6): objective setting, verifiable requirements in design and development, verification and validation, deployment, operational monitoring, change and retirement — each with a retrievable record. Data (A.7): data provenance and rights, data quality and representativeness, data preparation and labelling standards, data lineage and versioning, and the split and isolation of training, validation and test sets. Chinese AI companies have both an advantage and a clear weakness here: existing algorithm filing and security assessment materials can be reused directly as life-cycle evidence, but the provenance and rights status of data usually lacks a systematic register — and that is exactly what overseas customers and certification auditors press hardest on, so it should be closed first.

   Evidence to attach

   • · AI system inventory and life-cycle stage records (requirements, design, verification, deployment, monitoring, retirement)
   • · Data provenance and rights register (how collected, authorisation documents, licence scope, use restrictions)
   • · Dataset split and isolation standard, with data versioning and lineage records
   • · Labelling standard, labelling quality sampling and labeller training records
   • · Model evaluation and validation reports including test set and metric definitions
   • · Change management and model retirement records

   Common pitfalls

   • · A data provenance register that says only "public dataset", with no licence document or scope
   • · Leakage between training and test sets, which invalidates the evaluation metrics
   • · Undocumented model updates, so a problem cannot be traced to a version
   • · No quality or labour records at all for outsourced labelling

6. 6. Third-party and customer relationships, information for interested parties (Annex A.8 / A.10)

   Both control groups concern the information and responsibility boundary with the outside world. Third parties (A.10): assessment and management of suppliers of third-party models, data, compute and tooling, and the allocation of responsibility with customers — where a third-party foundation model is used, record its terms of use, the technical information available to you, and the limits of what you can therefore commit to customers. Information for interested parties (A.8): the system documentation you provide externally, instructions for use, known limitations and boundaries of applicability, the channel for reporting problems, and information for affected individuals. Done properly, this section directly produces the pack customer due diligence asks for, feeding and being fed by the AI section of tmpl-customer-security-privacy-answer-bank.

   Evidence to attach

   • · Third-party AI supplier list and assessment records (models, data, compute, tooling)
   • · Extracts of third-party model terms of use and the technical information available
   • · Responsibility allocation note with customers (the AI part of the shared responsibility matrix)
   • · External system documentation and instructions for use, including known limitations and boundaries
   • · Problem reporting and feedback channel description with the handling log

   Common pitfalls

   • · Making commitments about model behaviour that exceed the information the third-party provider actually gives you
   • · External documentation consisting of marketing material with no statement of known limitations
   • · Third-party model terms prohibiting a use case that sales nonetheless promotes as available

7. 7. Competence, awareness and documented information (Clause 7)

   Competence and awareness: identify the competence needed for AI-related roles, assess the current state, close gaps through training or hiring and keep the evidence; awareness training should reach everyone connected to AI systems, including sales and support who are the front line for external statements about AI capability. Documented information: establish rules for creation, update and control — identification and description, format and media, review and approval, distribution and access control, change control and retention. A practical note: the most common easy losses in a certification audit are version confusion (the effective version differs from the one in circulation) and missing records (a procedure exists with no evidence of execution), so unify the document library and record storage at the start of the build rather than in a pre-audit scramble.

   Evidence to attach

   • · Role competence requirements and competence assessment records
   • · Training plan, attendance and assessment records, including AI awareness training for sales and support
   • · Document control procedure and document library version records
   • · Record retention schedule and storage location list

   Common pitfalls

   • · Training that reaches engineering only, while sales describes model capability in ways the technical facts do not support
   • · Copies of documents in personal drives, so the version the auditor picks differs from the effective one
   • · Procedures with no records, leaving no proof that the process actually runs

8. 8. Internal audit, management review and continual improvement (Clauses 9–10)

   Internal audit: define the audit programme (frequency, methods, responsibilities, planning requirements and reporting), ensure auditor independence from the area audited, cover all clauses and controls to plan, and report results to relevant management. Management review: at planned intervals, review the suitability, adequacy and effectiveness of the system, with inputs including at minimum the status of actions from the previous review, changes in internal and external issues, performance against objectives, nonconformities and corrective actions, audit results, interested party feedback and improvement opportunities, and with outputs as decisions and resource allocation. Nonconformity and corrective action: record the nonconformity, take control and correct it, evaluate whether the cause needs elimination, implement the action and review its effectiveness. Practical certification advice: complete at least one full-coverage internal audit cycle with findings closed before the formal certification audit, or the stage 1 audit will raise documentation nonconformities.

   Evidence to attach

   • · Internal audit programme, audit plans, checklists and audit reports
   • · Evidence of auditor independence and competence
   • · Management review minutes covering the required inputs and outputs
   • · Nonconformity and corrective action log including effectiveness review
   • · Improvement opportunity list and implementation records

   Common pitfalls

   • · The internal audit performed by the person who built the system, so independence fails
   • · Management review minutes missing required inputs, raised as a documentation nonconformity
   • · Corrective actions that say only "management has been strengthened", with no root cause analysis or effectiveness check

9. 9. Certification audit preparation: selecting the body, audit stages and certificate maintenance

   Choose the certification body on its accreditation and the AI competence of its auditors — ISO/IEC 42006 sets requirements for bodies providing audit and certification of AI management systems (audit time, audit team competence, scope definition and so on) and is a useful benchmark for judging whether a body is running properly. Preparation points: the stage 1 audit checks documentation completeness and readiness while stage 2 checks the effectiveness of the operating system, so there must be enough operating history before stage 2; the audit scope statement must match what you claim publicly; and because customers compare the scope wording on the certificate word for word, agree that wording with the body before the audit. After certification, maintain a calendar for surveillance audits and recertification, and watch for standard version changes (Europe has published an EN adoption identical in text to ISO/IEC 42001:2023, so the reference number may change while the requirements do not).

   Evidence to attach

   • · Check on the body’s accreditation and scope, and confirmation of auditor competence
   • · Stage 1 audit report and evidence that nonconformities were closed
   • · Pre-stage-2 operating record inventory with a coverage and completeness check
   • · Correspondence confirming the scope wording on the certificate
   • · Surveillance and recertification calendar, and the standard version change tracking record

   Common pitfalls

   • · Choosing a body without the relevant accreditation, so overseas customers do not recognise the certificate
   • · A certificate scoped to one subsidiary while sales advertises "group certified to 42001"
   • · The system going dormant after certification, leading to suspension or withdrawal at surveillance
   • · Scheduling stage 2 before a full operating cycle of records exists