Does AWS's ISO 42001 certificate make our AI system ISO 42001 certified?
No. AWS's ISO/IEC 42001:2023 certificate does not certify your organization or your AI system by association, and if you want your own ISO 42001 certification, you must obtain it from an accredited certification body that audits your scope. AWS owns its certificate, your organization owns its controls, and only the independent certification body issues the certificate that your customers or regulators will ask to see. AWS's own FAQ states that customers are not automatically certified this way, though AWS's certified AI management process may make your own certification easier to achieve.
The AWS certificate is verified by Schellman Compliance, LLC, which is accredited by the ANSI National Accreditation Board (ANAB). You can download it through AWS Artifact, and it lists the AWS services in scope. Read that list before you design anything. A service that is absent from the certificate is not covered by AWS's certification, and a service that is present still needs your own configuration, access and monitoring evidence for the parts of the system you run. Confirm the certificate's validity dates and scope statement directly in Artifact at the time of your audit planning, not from an older copy in a sales deck.
Your certification scope will be decided by your own boundary: the AI systems you build, the data they use, the people who operate them and the suppliers you rely on. Use the AWS certificate as one input to your statement of applicability and supplier evaluation under clause 6.1.3 and control A.10.3, then document which Annex A controls AWS covers and which remain yours. Ask your certification body early how it will treat inherited AWS evidence, because the body decides what it accepts as evidence for your management system, not AWS.
How to get AWS's certificate and in-scope services from AWS Artifact
This sequence produces a copy of AWS's ISO/IEC 42001:2023 certificate and the list of services it covers, so your team can see which AWS services you can rely on for your AI workload and which ones still need your own assessment.
Sign in to AWS Artifact
Your cloud administrator or compliance lead signs in to the AWS account that owns or governs the AI workload, then opens AWS Artifact from the AWS Management Console. Access to Artifact is controlled by IAM permissions, so confirm that the person doing this work holds a role allowed to view and download compliance reports. Done means the Artifact landing page is open under the correct account. If you run workloads across several accounts or an AWS Organizations structure, confirm with AWS which account provides the reports you need before you download anything.
Locate the ISO/IEC 42001 certificate
In the Artifact report library, search for the ISO/IEC 42001:2023 certificate and select the current version. AWS's FAQs state that Schellman Compliance, LLC, an ISO certification body accredited by the ANSI National Accreditation Board (ANAB), verifies AWS's certification, so the issuing body on the document should match that. Output of this step: you have identified the certificate and can see its issue and validity information. Note the date it was published so you can compare it against any later version AWS releases.
Download the certificate and its scope list
Download the certificate file and any accompanying scope document from Artifact, then store both in your compliance evidence repository with the download date and the account used. The certificate lists the in-scope AWS services, so treat that list as the authoritative statement of what AWS has certified. Output of this step: a saved certificate file and a saved copy of its scope list, with a version reference. Do not rely on a screenshot or a third-party copy, because the auditor will ask where the document came from.
Read the in-scope services list line by line
Read the scope list against the AWS services named in your AI system design, including model hosting, data storage, networking, logging and identity components. Mark each service as in scope, out of scope, or not listed. Do not infer coverage from a service family name or from a service's presence in AWS's general documentation. Output of this step: an annotated copy of the scope list that records your reading of each service. Ask AWS or your account team to confirm any service whose status you cannot establish from the document.
Record the services your AI workload uses
Build a register of every AWS service, region and configuration your AI workload depends on, using your architecture diagrams and infrastructure-as-code. Link each entry to the scope list result from the previous step. Output of this step: a workload service register that shows, for each service, whether AWS's certificate covers it and the region in which it runs. This register becomes the bridge between AWS's evidence and your own statement of applicability.
Assess services that fall outside the scope
For every service your workload uses that is not in the certificate's scope, plan a separate assessment. This can include a review of that provider's own assurance reports, a documented risk decision, or a change to the architecture. The scope list controls which services you can rely on, so a service outside it cannot be treated as covered by AWS's certificate. Output of this step: a documented assessment or risk decision for each uncovered service, recorded against your AI risk treatment process.
File the evidence for your supplier controls
Store the certificate, the annotated scope list and the workload register together, and link them to your supplier controls for A.10.3 and your life cycle responsibility allocation under A.10.2. Note that AWS states customers are not automatically certified by association, so this file supports your own certification effort rather than replacing it. Output of this step: an indexed evidence package that an independent auditor can follow from AWS's certificate to your own controls. Confirm with your certification body how it expects supplier certificates to be presented.
Why AWS's certification does not certify us by association
AWS holds its own ISO/IEC 42001:2023 certificate, but that certificate covers AWS's management of AI within its specified scope. Your organization still builds, governs and audits its own AI management system, and each of the following cards marks a part of that work that stays with you.
AWS certifies its scope, not your AI
The AWS certificate covers AWS's AI management process within the scope it specifies. It does not cover your models, prompts, training data, fine-tuning choices or the use cases your customers run. Read the scope statement on the certificate in AWS Artifact and map each in-scope service to the parts of your system it actually supports. Anything outside that list needs your own evidence.
Your AI management system is yours
Clauses 4 to 10 of ISO/IEC 42001 ask for your own context, scope, AI policy, roles, risk and impact assessment, objectives, competence, documented information, internal audit and management review. AWS cannot write these for you, and an auditor will test them against your operations. Confirm that each clause has an owner and a record inside your organization before you describe the system as certified or ready.
Your Annex A selection needs justification
Under clause 6.1.3, your statement of applicability must list the Annex A controls you need and justify including or excluding each one. A control that AWS supports at its layer still needs a row in your statement of applicability, with the reason it applies to your system. Expect the auditor to ask how each inherited control fits into your own risk treatment.
Supplier responsibilities need written allocation
Controls A.10.2 and A.10.3 ask you to allocate life cycle responsibilities between yourself, your suppliers and customers, and to check that what you obtain from suppliers fits your approach to responsible AI. Document which responsibilities sit with AWS, which sit with you and which are shared, and keep the supplier review records that show you tested that split.
The certification body audits your scope separately
Your certification body audits your AI management system in your own scope, and it does not rely on AWS's certificate to skip that work. The certificate from AWS may make your own audit easier to prepare for, but AWS does not guarantee it. Ask your certification body how it will treat inherited AWS evidence, and confirm that its accreditation is recognized before you commit to a timeline.
Which supplier and responsibility controls you still own on AWS
Governance owners carry the controls that AWS cannot carry for you. Annex A.10.2 asks your organization to allocate responsibilities across the AI system life cycle between itself, its partners, suppliers, customers and other third parties, so the allocation must be written down and agreed, not inferred from AWS's documentation. Annex A.10.3 asks for a process that checks whether services, products and materials obtained from suppliers align with your approach to responsible development and use of AI systems. Clause 6.1.3 also requires a statement of applicability that justifies each Annex A control you include or exclude, and that justification is yours to write.
- Responsibility matrix: Record who handles each life cycle stage, from data acquisition to monitoring, across you, AWS and any model or tooling provider.
- Supplier alignment review: Document how each AWS service and third-party model is assessed against your responsible AI approach before it enters an AI system.
- Statement of applicability entries: Justify each A.10 control with the evidence an assessor can trace.
- Customer-facing commitments: Decide which AI use statements and limits you make to customers, since AWS's certificate does not make those statements for you.
- Review cadence: Set when the matrix and supplier reviews are repeated and who signs them off.
Confirm with your certification body how it expects the responsibility matrix and supplier process to be evidenced before you build them.
Engineering and platform teams own the controls that run inside your own AWS accounts. Whatever AWS certifies, the configuration of your accounts, networks, identities and pipelines is yours, and the evidence that those controls operate comes from your logs and records. Deployment, operation and event logging controls in Annex A are satisfied by how you build and run the AI system, not by AWS's audit of its management process.
- Account and identity boundaries: Separate AI workloads into defined accounts or organizational units and control who can change model endpoints, prompts and data stores.
- Deployment records: Keep versioned infrastructure code, approval records and rollback history for each AI system release.
- Operational monitoring: Capture model performance, drift and error signals in your own logging and alerting, and retain them according to your policy.
- Event logs: Ensure logs of AI system events are retained, protected from alteration and reviewable during an incident or audit.
- Data controls: Govern training, evaluation and inference data stored in your buckets and databases, including access, retention and provenance.
Confirm which AWS logging and retention features you have enabled and whether they cover each in-scope service you use.
Procurement and legal teams decide what your organization accepts from AWS and from every other supplier in the AI chain. AWS provides its certificate and a certificate listing in-scope services through AWS Artifact, and those documents are the starting point for a supplier review, not the end of it. Your contracts, data processing terms and exit arrangements determine whether you can meet the supplier and customer expectations that Annex A sets out.
- In-scope service check: Confirm from the certificate download which services are covered, and record any service you use that is not listed.
- Contract and data terms: Review how AWS and other suppliers handle your data, model artifacts and logs, and where those terms are defined.
- Third-party models and tools: Obtain the supplier evidence you need for any model, dataset or open-source component you do not build yourself.
- Customer commitments: Check that customer contracts describe AI use accurately and do not promise coverage that AWS's certificate does not provide.
- Exit planning: Record how you would move data, models and logs if a supplier changed terms or lost a certification.
Ask AWS and each other supplier for their current certificates and the scope statements they cover, and confirm the dates and terms in writing.
AWS's certificate covers AWS's own AI management process within the specified scope. It does not cover the artifacts you create on top of AWS services. AWS states that customers are not automatically certified by association, so your prompts, fine-tuned models, training and evaluation data sets, application logic and customer-facing use remain your responsibility to manage and evidence under your own AI management system.
- Prompts and system instructions: Version, review and test them as governed artifacts, since AWS does not assess your prompt design.
- Fine-tuned models and weights: Document their provenance, evaluation results and approval for release.
- Data sets: Record acquisition, quality and permitted use for every data set that feeds training, tuning or retrieval.
- Customer-facing use: Define intended purpose, limitations and user information for each AI feature you expose to customers.
- Application behavior: Test outputs, guardrails and failure handling in your own application, which AWS does not certify.
Ask your certification body to confirm which of these artifacts it will sample and what evidence it expects for each.
How the certification body tests a customer built on AWS
The certification body tests your own AI management system, not AWS's, and it uses AWS's certificate only as far as its scope reaches. The sequence below shows what each audit phase checks and what it produces.
Agree scope and the statement of applicability
You define which AI systems, teams and environments fall inside your AI management system, and you document the Annex A controls you need, with a justification for each inclusion or exclusion. This statement of applicability is required by clause 6.1.3 of ISO/IEC 42001. The certification body reviews it before any audit work begins. The step is done when the scope statement and the statement of applicability are accepted by the certification body and match the AWS services you actually use.
Map AWS services to your scope
You list each AWS service that your AI system depends on, then compare that list with the in-scope services named on the certificate you download from AWS Artifact. Services outside the certificate's scope are not covered by AWS's certification, so your own controls must address them directly. The output is a dependency register that shows which controls rely on AWS evidence and which need your own evidence. Confirm the current certificate version and in-scope list with AWS before the audit.
Review documented information in stage 1
The certification body reviews your documented information against the requirements of clauses 4 to 10 and your chosen Annex A controls. It checks your AI policy, roles, risk and impact assessment records, and whether your documents describe the AWS shared responsibility boundary accurately. The auditor may also rely on AWS's certificate for the in-scope services, but only to the extent that the certificate's scope matches your use. The output is a stage 1 report listing gaps, open questions and readiness for the next phase. Ask the certification body for its written plan and what it expects to see.
Close stage 1 findings before operational testing
You address the gaps and questions raised in stage 1 by updating documents, clarifying the statement of applicability or changing controls. The certification body confirms whether the changes resolve each finding before it schedules the operating-evidence review. This step is complete when the open items are recorded as closed with supporting records. Ask the certification body how it handles findings that remain open, since that affects the next phase.
Test operating evidence of your controls in stage 2
The certification body samples operating evidence to confirm that your controls run as documented. For AWS-dependent controls, it looks at your configuration records, logs, access reviews, supplier assessments of AWS and records of how you handled AWS's responsibilities, such as data handling and monitoring. For controls covering AI system behavior, it examines impact assessment outcomes, model change records and incident handling. The output is a stage 2 report with any nonconformities, which you must resolve before a certification decision.
Resolve nonconformities and receive the decision
You document corrective actions for each nonconformity, with evidence that the root cause was addressed. The certification body verifies those actions and makes the certification decision, which is its decision alone. Your organization receives a certificate only if the body issues one. Confirm with the certification body whether it checks accreditation for its scope, and verify the accredited status through the national accreditation body or IAF CertSearch.
What to have in place before the auditor arrives
Certification of an AI system built on AWS depends on what your organization can show, not on AWS's certificate alone. The five items below are the records an auditor will ask for first, and each one should be checked against the auditor's stated requirements before the engagement starts.
Written scope naming AWS services and accounts
Record which AWS accounts, regions and services hold or process the AI system's data, models and outputs, and mark which of those services appear on the in-scope list in AWS Artifact. A service that is out of scope at AWS is still your responsibility to assess. Confirm with the auditor that the scope statement matches the account structure you actually run, including any shared or development accounts.
Statement of applicability with justified decisions
Clause 6.1.3 requires a statement of applicability that lists the Annex A controls you need and justifies including or excluding each one. For AWS-hosted systems, state which controls rely on AWS's certified processes and which remain with your team, such as data handling, human oversight and use. Ask the auditor whether each exclusion reason is acceptable before you treat the document as final.
Supplier records for AWS and other vendors
Keep a current register covering AWS, any foundation model provider, data labeling or data source vendors, and monitoring tools. For each supplier, record the certificate or report you hold, the services used, the date you last reviewed it and how its responsibilities are split from yours. Check the register against the supplier process your organization has written under the third-party controls before the auditor samples it.
Evidence exported from your own AWS accounts
AWS's certificate covers AWS's management system, not your configuration. Export logs from CloudTrail, access review records from IAM, change records from your deployment pipeline and model version histories from your own accounts. Confirm the retention period you set for each log source covers the audit period, and test that you can produce a sample for a given date range on request.
Named owner for AI governance
An auditor will ask who is accountable for the AI management system, who approves changes to AI systems and who receives concerns about them. Name one accountable owner and document their authority, plus the roles that operate the AWS environment. Confirm that the owner can present the policy, risk decisions and management review records without relying on an outside consultant to explain them.
Where an implementation partner fits and where it stops
DeployOpen plans, implements, configures and documents self-hosted open-source platforms inside your own cloud accounts, and prepares the systems and evidence that an assessment will examine. That work sits on your side of the shared responsibility line: the platform components you run in your AWS accounts, the logging and access settings that produce records, and the written procedures that show how those records are reviewed. DeployOpen does not issue audit reports, attestations or certificates. Only an independent certification body can decide whether your AI management system conforms to ISO/IEC 42001, and AWS's own certificate does not transfer that decision to you.
Ownership stays with your organization. You decide which Annex A controls go into your statement of applicability and why, you approve the AI policy and risk treatment decisions, and you remain accountable for supplier and customer obligations under A.10.2 and A.10.3. An implementation partner can draft the records and configure the tooling, but a control that nobody in your organization operates will not survive surveillance. Ask any partner to show which items it delivers and which items your named owner must sign off.
DeployOpen engagements are fixed-scope. The systems, accounts, controls, deliverables and timelines are agreed in writing before work starts, and the quote follows from that written scope. Ask for the scope to list the in-scope AWS services and accounts, the open-source components to be deployed, the evidence each deliverable will produce, and the handover items that remain with your team. Changes to the scope after signing should be priced through a written change request, so the cost of a new AWS account, an extra control or a re-run of evidence collection is visible before it is incurred.
Questions buyers ask about ISO 42001 on AWS
Can we cite AWS's ISO 42001 certificate in a customer questionnaire?
You can state that the AWS services you build on hold ISO/IEC 42001:2023 certification, provided the statement names the in-scope services and the certificate you downloaded. You cannot state that your own AI management system is certified, because AWS's certificate does not certify your organization. AWS says customers are not automatically certified by association, so a questionnaire answer should separate what AWS certified from what you operate. Check the exact wording with your customer's contract team and with your certification body before you reuse it in contract language. Keep a dated copy of the certificate and the scope statement with the questionnaire answer so the claim can be traced later.
Does AWS's certificate cover our fine-tuned models or our own AI application?
Not by default. The certificate covers AWS's AI management process within the scope listed on the certificate and in-scope services, so it does not cover a model or application your team trains, tunes, prompts or deploys on top of those services. Your fine-tuning data, evaluation criteria, model cards, deployment decisions and monitoring remain your responsibility under your own AI management system. Confirm with AWS which services and features appear in scope at the date you rely on them, because the list can change. Ask your certification body how it will treat AWS's certified scope when it samples your own AI systems.
How do we download the AWS certificate and check its scope?
AWS makes the ISO/IEC 42001:2023 certificate available through AWS Artifact, and the certificate lists the in-scope services. Sign in to your AWS account, open AWS Artifact, and search for the ISO/IEC 42001 report or certificate. Read the scope section line by line, because the in-scope services and the covered processes are the part that matters for your audit. The certification body that verifies AWS's certification is Schellman Compliance, LLC, accredited by ANAB, and you can check its status against the accreditation body records. Store the download, its date and the scope list as audit evidence.
Do we still need an external audit if AWS is certified?
Yes, if you need your own ISO/IEC 42001 certification or a third-party attestation. Only an independent certification body can certify your AI management system, and it will assess your clauses 4 to 10, your statement of applicability and the Annex A controls you selected. AWS's certificate can make parts of your evidence easier to present, particularly for infrastructure and supplier controls, but it does not replace your own audit. Ask the certification body how it intends to rely on the AWS certificate and whether it needs to see the AWS scope document during your stage 1 review. Your timing depends on the body's schedule and your readiness, so confirm both before you commit a date.
What does the work need from our team?
Your team owns the decisions that the AWS certificate cannot make for you. The main tasks are defining the AI systems in scope, writing the AI policy, assigning roles, completing AI impact assessments, documenting the data, models and third-party components you use, and selecting the Annex A controls in your statement of applicability with justification. Engineering staff produce the operational evidence, such as logs, evaluation results, change records and access reviews. Legal and procurement review supplier terms, and management takes part in the management review. Effort depends on how many AI systems you run, how many suppliers they depend on and how much documentation already exists, so estimate it with your own inventory and confirm it with your certification body or implementation partner.
Can an implementation partner perform the audit for us?
No. An implementation partner can help you prepare systems, controls, documentation and evidence, but only an independent certification body can audit your organization and issue a certificate. The partner should not also be your auditor, because that removes the independence the certificate depends on. Ask any partner to show which parts of the work it performs and which parts remain with your team, and get that split in writing. DeployOpen plans, implements, hardens and documents self-hosted platforms in your own infrastructure and prepares evidence for assessments, but it does not issue audit reports, attestations or certifications. Confirm the certification body's rules on consultant involvement before you sign any scope.
How DeployOpen scopes and prepares your ISO 42001 evidence on AWS
DeployOpen works on the part of ISO 42001 on AWS that stays with your organization: the AI systems you build, the suppliers and responsibilities around them, and the evidence an independent certification body will ask for. We prepare systems and evidence inside your own AWS accounts, while the certification body alone decides whether your management system conforms.
How we scope
- We confirm which AWS services and AI workloads you run, and which of them sit within the AWS ISO 42001 scope in AWS Artifact.
- We map your own Annex A controls and the statement of applicability you must justify, separating what AWS covers from what you own.
- We agree the scope, deliverables and timelines in writing before work starts, since engagements are fixed-scope.
How we build
- We configure logging, access records and supplier documentation in your AWS accounts so the evidence is produced as systems run.
- We document responsibility allocation for A.10.2 across your teams, AWS, model providers and other third parties you rely on.
- We set up supplier review records for A.10.3 showing that third-party AI services align with your responsible AI approach.
How we hand over
- You receive the documented evidence set, control records, system configuration notes and the responsibility matrix, owned by your organization.
- We walk your AI governance owner through each record so they can answer an auditor's questions without us in the room.
- Any statement that a control conforms is issued only by the independent auditor or certification body you choose, never by DeployOpen.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover, covering changes to AWS services and AI workloads.
- We help you prepare for surveillance and recertification reviews by refreshing evidence and the statement of applicability.
- Ask any partner, including us, to confirm in writing which tasks they perform and which your team must keep.
