You're three weeks into ISO/IEC 42001 planning when someone from product engineering asks: "Do we need to certify the whole platform or just the models we built?" It's a fair question. If you're a compliance manager looking at Clause 4.3's scoping requirement, you've probably realized this standard works differently than ISO/IEC 27001.
These questions come from real implementation teams trying to figure out what ISO 42001 actually demands. The standard requires you to formally declare your organizational role before you can even finish scoping, and that decision affects every control in Annex A. Here's what practitioners are asking and what the standard actually says.
Do We Have to Pick Just One Role, or Can We Be Both Provider and User?
You can occupy multiple roles simultaneously. If your organization builds machine learning models internally and also licenses third-party AI tools for customer support or analytics, you're both an AI Provider and an AI User under ISO/IEC 22989's definitions.
Clause 4.3 requires your scope to reflect every role you hold. That means your Artificial Intelligence Management System must address both sets of obligations. For the models you build, you'll need lifecycle controls covering design, training data provenance, model drift monitoring, and adversarial input defenses. For the third-party tools you deploy, you'll need human oversight procedures, supplier contracts with audit rights and incident notification clauses, and evidence that you've assessed the specific use case for discriminatory outcomes.
The Statement of Applicability becomes your primary scoping document. If you're only a User, you can justify excluding controls in Annex A.5 (AI System Lifecycle) that apply to model development. If you're only a Provider, you might exclude certain operational use controls in A.8. But if you hold both roles, expect auditors to look for evidence across the full 38-control set.
What's the Difference Between What Providers Document and What Users Document?
The clause structure looks identical, but the content diverges completely. Both roles must produce an AI Policy (Clause 5.2), conduct risk assessments (6.1), and maintain performance monitoring (9.1). The difference is what those activities address.
For Providers, the AI System Impact Assessment under Clause 6.1.4 evaluates potential harm from the system itself: algorithmic bias in training data, explainability gaps, model drift over time, and adversarial manipulation risks. Your risk register will include technical threats like data poisoning and concept drift. Lifecycle documentation (A.5) becomes the operational core: design specifications, training dataset lineage, validation test results, retraining schedules, and decommissioning procedures.
For Users, the Impact Assessment scopes to your specific deployment context. If you're using an AI tool for loan underwriting, hiring decisions, or medical triage, the assessment targets discriminatory outcomes in that application. Your risk register focuses on over-reliance on AI outputs, supplier opacity, and the consequences of model failure in your operational environment. Human oversight logs (A.8.4) and supplier agreements (A.9) are the evidence auditors request first.
Can We Reuse Our ISO/IEC 27001 Documentation, or Do We Start From Scratch?
You don't start from scratch. Annex D explicitly supports integrated implementation with ISO/IEC 27001, ISO 9001, and ISO 22301. The harmonized structure means your existing risk assessment methodology, internal audit program, management review process, and control of documented information procedures apply directly to ISO 42001.
Extend your ISO/IEC 27001 risk register with AI-specific threat categories: bias, model drift, adversarial inputs, data provenance failures. Your incident response plan can accommodate AI incidents by adding model failure scenarios and escalation paths for algorithmic harm. The two Statements of Applicability can cross-reference shared controls to avoid duplication.
The practical integration point is your Information Security Management System's documented information controls. ISO/IEC 27001's Clause 7.5 already governs how you create, update, and retain documents. Apply that same process to your AI Policy, Impact Assessments, and lifecycle records. You'll need AI-specific content, but the management structure already exists.
What Does the Statement of Applicability Actually Need to Say?
Your SoA must list all 38 Annex A controls and justify inclusion or exclusion for each one. Auditors treat this document as the primary lens for assessing your control landscape. It's not a checkbox exercise.
For included controls, state how you've implemented them and where the evidence lives. For example: "A.8.4 Human Oversight: Implemented via documented review procedures for all AI-generated underwriting decisions. Evidence: oversight logs, escalation records, quarterly training completion reports."
For excluded controls, justify why they don't apply based on your role. If you're a User, you might write: "A.5.3 AI System Development: Not applicable. Organization does not develop AI models. All AI systems are acquired from third-party providers and governed under A.9 supplier controls."
The SoA is where your role declaration becomes operationally binding. If you claim to be only a User but can't justify excluding Provider-specific lifecycle controls, auditors will challenge your scope.
Where Do Auditors Actually Look Beyond the Mandatory Documents?
Human oversight evidence is the most operationally visible gap. A policy stating "staff will review AI decisions" isn't sufficient. Auditors want logs showing which decisions were reviewed, who performed the review, what action was taken, and evidence that staff have been trained to recognize when to override the system.
Data governance (A.6) trips up Providers who can't produce documented bias analysis or a data lineage trail for training datasets. If you're using publicly scraped data or third-party datasets, you need documented provenance and a record of how you assessed the data for representational bias before training.
Supplier agreements (A.9) for Users are frequently missing three provisions auditors expect: audit rights allowing you to assess the provider's controls, incident notification timelines requiring the provider to alert you of model failures or security events, and exit clauses specifying data return or deletion obligations if you terminate the relationship.
Do We Really Need Separate Impact Assessments for Every AI System?
Clause 6.1.4 requires an AI System Impact Assessment, but the standard doesn't mandate one per system. You can assess systems in groups if they share similar risk profiles and use cases.
If you're deploying five chatbots across different departments but they all use the same underlying model, have similar human oversight procedures, and present comparable risks, a single Impact Assessment covering that chatbot deployment pattern is defensible. Document the commonalities and note any context-specific variations.
If you're using AI for both internal process automation and customer-facing credit decisions, those require separate assessments. The potential harm to interested parties differs significantly, and your risk treatment will diverge.
What Happens After Certification?
ISO 42001 certification isn't a project endpoint. Once certified, you're expected to maintain and improve the AIMS annually. That means ongoing performance monitoring (Clause 9.1), internal audits (9.2), management reviews (9.3), and corrective actions when nonconformities arise.
Surveillance audits typically occur annually, with recertification every three years. Auditors will review changes to your AI system inventory, new Impact Assessments for systems deployed since the last audit, incident records, and evidence that you've acted on opportunities for improvement identified in prior audits.
If your role changes (you start building models internally after certifying as a User), you must update your scope, revise your SoA to include previously excluded controls, and notify your certification body.
Where to Go for More
ISO/IEC 22989 defines the normative AI roles and provides the terminology foundation for ISO 42001. ISO/IEC 27001 practitioners should review Annex D for integration guidance. If you're also pursuing business continuity certification, ISO 22301's business impact analysis maps cleanly onto AI system criticality assessments.
Your certification body's lead auditor can clarify scope questions specific to your organization's structure. Get that conversation started during the initial certification planning phase, not three weeks before the audit.
