ISO 27001 on AWS: AWS certificates vs your own controls

Does AWS's ISO 27001 certificate cover your ISMS on AWS?

AWS holds ISO/IEC 27001:2022, ISO/IEC 27017:2015 and ISO/IEC 27018:2019 certificates that cover AWS's own information security management system over a stated scope of services and data centers. Running your workloads on AWS does not certify your organization. If a customer or contract now asks for ISO 27001 and your systems run on AWS, the certificate you will be assessed against is your own, and it must be issued by an independent certification body after an audit of your ISMS. AWS's certificate can make that audit easier, but it does not replace it.

Your ISMS on AWS remains yours to define and operate. That includes the scope, the risk assessment, the Statement of Applicability and the controls you run in your accounts, such as identity configuration, logging, network rules, encryption and backups. Annex A control A.5.23 asks you to establish processes for acquiring, using, managing and exiting cloud services in line with your information security requirements, and that process is yours even when the platform is AWS. Clause 1 of the standard also means you cannot drop clauses 4 to 10 from scope, so the management system work applies to the AWS environment in full.

Before you rely on the AWS certificate in your own scope statement, confirm two things. First, check the in-scope regions in the certificate and the in-scope services on AWS's ISO Certified page, because a service or region outside those lists is not covered by AWS's certification. Second, confirm the certificate's current status and verify the EY CertifyPoint attestation through the certificate's details. Read the AWS ISO 27001 FAQs before drafting your scope, and ask your certification body how it will treat inherited AWS evidence in its audit plan.

How to confirm in-scope services and regions before you rely on the certificate

AWS's ISO certificate covers a defined set of services and regions, not your workloads. The checks below compare the two AWS sources of scope and turn the result into dated evidence for your own ISMS. Each card is a step you own, and each one needs confirmation from current AWS documents at the time you assess.

Read the in-scope regions on the certificate

Open the ISO/IEC 27001:2022 certificate that AWS publishes and note every region it lists as in scope. Record the regions exactly as the certificate names them. If a region you run workloads in is missing, the certificate does not cover the data centers that serve it, and you cannot treat that region as certified by association. Keep a dated copy of the certificate in your evidence folder.

Read the in-scope services on AWS's ISO page

AWS's ISO Certified page lists the services that fall inside the certification scope. Compare every service your ISMS depends on, including managed databases, identity, logging, key management and container platforms, against that list. Services that are absent from the list are not covered by the AWS certificate, even when they run in a covered region.

Match your regions and services to both sources

Build a simple matrix with your chosen services on one axis and your regions on the other. A cell is covered only when the service appears in the in-scope services list and the region appears in the certificate. Mark any cell that fails either test as needing your own assessment. Review the matrix whenever you add a region or a service, since the scope can change over time.

Record the certificate version and validity dates

Note the standard version named on the certificate, the issuing certification body, the certificate number and its validity period. ISO/IEC 27001:2022 is the version AWS holds, and your own auditor will ask which edition of the standard the cloud evidence supports. Store these details with the date you checked them so an assessor can see when the evidence was current.

Assess services and regions outside scope

Any service or region missing from AWS's lists needs its own assessment under your ISMS. This includes services you have adopted recently, preview features and workloads placed in new regions. Document the risk treatment decision and the controls you apply to those components, and reflect them in your Statement of Applicability. Do not describe them as covered by AWS's certificate.

Confirm current lists directly with AWS

AWS updates its scope over time, so a list you saved last year may no longer be accurate. Confirm the current in-scope regions and services with AWS before each internal audit and before you present the evidence to your certification body. Record who confirmed the lists, the date and where the confirmation came from, and keep the same record for your review cycle.

Why you are not certified by association and what that means for your audit

Your certification is granted to your organization, for the scope you define, by an accredited certification body. AWS states that customers are not automatically certified because they use AWS. What AWS's certificate can do is make your own certification easier to prepare for, because the auditor can see the provider's evidence for the controls AWS operates. Your audit still examines your ISMS as a whole, and that work stays with you.

Scope of your ISMS: The auditor will test the boundary you set, including which AWS accounts, regions and services sit inside it and why. Clause 4.3 requires you to determine that scope.
Risk assessment and treatment: Expect questions on how you identified risks to your cloud workloads and how you chose treatments. Clause 6.1.2 and 6.1.3 cover this work.
Statement of Applicability: Each Annex A control must be marked as applicable or excluded, with reasons. Your SoA must reflect your cloud configuration, not AWS's certificate.
Controls you run in your accounts: Identity, logging, backup and change management are operated by you. The auditor will ask for samples and records from your environment.
Evidence trail: Keep dated outputs from your own tools, such as access reviews and configuration checks, so you can show operation over time.

Confirm with your certification body how it wants AWS's documents referenced in your audit file and which AWS items it will accept as inherited evidence.

The cloud services control you still own: A.5.23 in practice

A.5.23 asks your organization to set up and run processes for acquiring, using, managing and exiting cloud services, aligned with your own information security requirements. AWS's certificates cover AWS's security management over its scoped services and data centers. They do not cover how your organization chooses which AWS services to use, how those services are configured, who may administer them or how you would leave. An assessor will look for that second layer, and it is yours to document. Start by writing down the security requirements each AWS service must meet for the data it will hold, then record which accounts, regions and services you actually use and check them against the in-scope lists in AWS's ISO documentation.

The evidence an auditor usually asks for is concrete. Expect a register of the AWS services in use, each with a documented requirement, an owner and a data classification. Expect configuration baselines for accounts and services, such as an AWS Organizations structure with separate accounts for production, development and security tooling, and service control policies that stop teams from enabling services or regions outside the approved list. Keep the infrastructure as code or configuration exports that prove those baselines were applied, not only the written standard. The assessor will also want a tested exit procedure: how data is exported or deleted, how keys and backups are handled, and how the service is decommissioned without losing records you must retain.

Finally, the control is not a one-time setup. Schedule a periodic review of AWS's assurance reports, including the certificates and any audit reports you can access through AWS, and record what you concluded and what you changed as a result. Confirm with AWS which documents your account team can provide under your agreement, because the list of available reports and how you obtain them may change. Assign the review to a named role, set its frequency in your ISMS, and keep the minutes. Where a gap appears, such as a service you use that is outside the certificate's scope, the review record is the proof that you identified it and decided how to handle it.

How the AWS-based ISMS moves from scope to certification

This sequence turns AWS's inherited certificates into an ISMS that belongs to your organization. Each phase ends with a document or record that an independent certification body can test, from the scope statement through to the audit that decides whether the certificate is issued.

Define the scope and the AWS footprint
Write the ISMS scope statement covering the business units, products, locations and services the certificate should describe. Then list every AWS account, service and region your organization uses for that scope, and check each one against the in-scope services and regions published in AWS's ISO/IEC 27001:2022 certificate and its ISO Certified page. Mark any service that AWS does not list as one you must control and evidence yourself. The step is done when the scope statement and the AWS inventory agree and each gap has an owner.
Assess information security risks
The risk owner, usually the CISO or a delegate, works with engineering and platform leads to identify assets, threats and vulnerabilities across the in-scope AWS environment. Each risk is rated using a method the organization documents and applied consistently, as the risk assessment process in ISO/IEC 27005:2022 describes. The output is a risk register with an owner and an agreed treatment for every risk. The step is complete when the register covers each in-scope account and each risk has a recorded decision.
Write the Statement of Applicability
For each Annex A control, record whether it applies, why, and how it is implemented, with a reference to the policy, procedure or technical setting that carries it out. Mark controls that AWS covers under its shared responsibility split as inherited, and state what your organization still does on top, including the cloud services control A.5.23. Clause 6.1.3 requires this document. It is complete when every control has a decision, a justification and a named owner, and the document has been approved by management.
Implement and evidence the Annex A controls in your accounts
Engineering and security teams configure identity, logging, encryption, backup, network, change and vendor controls in your own AWS accounts and tooling, then collect the evidence that shows each control operates. Evidence often includes configuration exports, access review records, change tickets, log retention settings and supplier reviews. Keep the evidence in a location with a named owner and a retention rule. The step is done when each applicable control has a documented implementation and at least one evidence record that a reviewer can trace back to the Statement of Applicability.
Run the internal audit and management review
An internal auditor who is independent of the teams running the controls samples the Statement of Applicability against the evidence and records any nonconformities with a corrective action and a due date. Management then reviews the ISMS's performance, risk treatment and open actions and records its decisions. The output is an internal audit report and minutes of the management review, both retained as documented information. The step is complete when every nonconformity has a corrective action with an owner and the review decisions are recorded.
Book an accredited certification audit
Select an accredited certification body that issues ISO/IEC 27001 certificates and confirm its accreditation before signing anything. Provide the scope statement, Statement of Applicability and evidence index for a stage 1 review of documentation, then a stage 2 audit of implementation in your accounts. Confirm with the body how it will sample AWS-hosted systems and how it will treat AWS's certificate and audit reports in its assessment. The step is complete when the certification body has agreed the audit plan in writing.
Maintain the certificate across the cycle
Under ISO/IEC 17021-1, a certification cycle lasts three years with at least one audit, either surveillance or recertification, in every calendar year. Between audits, the organization keeps the scope, risk register and Statement of Applicability current as AWS services, regions and accounts change, and records each change through change management. The output is a current evidence set that the next audit can sample without rebuilding it. The step is ongoing and is confirmed at each surveillance audit.

What must be in place before the certification audit

A certification body will test whether your scope, Statement of Applicability and evidence line up with how you actually run AWS. The cards below cover the items that most often stall an audit, with a practical way to check each one before you book it. Each check is something your team can run internally before any auditor is involved.

Define scope by accounts and services

Your ISMS scope must name the AWS accounts, organizational units, regions and services that hold or process in-scope information. AWS's certificate covers AWS's own security management, not your workloads, so your scope is the part you own. Check it by listing every account in AWS Organizations and tagging each as in scope or excluded, with a written reason for each exclusion. Confirm that every in-scope service appears on AWS's ISO Certified page and that the regions match the in-scope regions on its certificate.

Tie the Statement of Applicability to clause 6.1.3 d)

The Statement of Applicability is the document required by clause 6.1.3 d) that records which Annex A controls apply, which do not, and why. For AWS, each cloud-relevant control should point to the AWS shared responsibility split and to your own evidence. Check it by sampling five cloud controls, such as A.5.23 on cloud services, and confirming each has a justification, an owner and a named evidence source. A control marked as inherited from AWS still needs your own evidence that the inheritance applies.

Produce configuration evidence from AWS Config and CloudTrail

Auditors will ask you to show that cloud configuration and account activity are recorded, retained and reviewed. AWS Config records resource configuration history and CloudTrail records API activity, and either can be replaced by equivalent self-hosted tooling if you prefer. Check that both are enabled in every in-scope account and region, that logs are delivered to a central, access-restricted location, and that you can produce a dated sample of configuration changes on request. Confirm the retention period in writing, since it is a decision you set.

Run and record access reviews

Auditors test whether access to AWS accounts, roles and administrative consoles is granted on need, reviewed on a set schedule and removed when people leave. Check that IAM Identity Center or your federated identity provider is the source for human access, that root account use is restricted and logged, and that the last review has a dated record with the reviewer, the decisions taken and the removals made. Sample three leavers from the past quarter and confirm their access was removed on the recorded date.

Document cloud exit procedures

Control A.5.23 asks you to establish processes for acquiring, using, managing and exiting cloud services. An exit procedure should cover how data is exported or deleted, how keys and accounts are closed, how backups are handled and who approves the decision. Check it by writing a short runbook and walking it through once against a non-production account, recording the steps that failed or took longer than expected. The runbook should name the owner and link to the supplier terms that govern data return.

Confirm vendor and shared responsibility evidence

Before booking, confirm that you can retrieve the AWS certificate and the scope documents an auditor will ask for, and that you have a record of how the AWS certificate was checked. AWS states that customers are not certified automatically because they use AWS, so the auditor will want to see your own control evidence alongside AWS's. Check that you hold a current copy of the certificate, that the certifying body is recorded, and that the verification was done on the issuing body's register. Keep the verification record with the scope documents.

Who owns controls, who prepares evidence, and who certifies

The organization owns the information security management system. Its leadership sets the scope, decides which risks to accept, mitigate or transfer, approves the Statement of Applicability, and is accountable for every Annex A control it claims to meet. Those decisions cannot be delegated to a consultant or an AWS account team, because the certification body will test whether management actually runs the ISMS.

Scope and boundary: Decide which AWS accounts, regions, workloads and business units fall inside the ISMS, and which AWS services the organization relies on.
Risk decisions: Own the risk assessment and risk treatment under clause 6.1, including the choices made in the Statement of Applicability.
Cloud services control: Define how cloud services are acquired, used, managed and exited under A.5.23, including the shared responsibility split with AWS.
Daily operation: Staff the people who review access, respond to alerts, approve changes and run internal audits.
Policies and records: Approve and maintain the policies, procedures and management review minutes that the auditor samples.

Before engaging anyone, confirm internally who holds each of these roles and how much time they can give to the project.

What usually delays AWS-based ISO 27001 projects

Most delays on AWS-based ISO 27001 projects come from a few avoidable misunderstandings about scope, certificates and evidence. Each card below names one common cause, why it slows the certification audit, and the check that prevents it.

Unclear scope across accounts

Teams often define the ISMS as "our AWS environment" without listing which accounts, workloads and unrelated environments, such as sandboxes or personal test accounts, belong inside it. An auditor cannot confirm the Statement of Applicability or the certificate scope until the boundary is written down. Map every in-scope account and its owner before writing the risk treatment plan, and record which environments are excluded and why.

Assuming AWS certification covers workloads

AWS's ISO/IEC 27001:2022 certificate covers AWS's own security management process over a defined set of services and data centers. It does not certify the applications, databases, configurations or access decisions the organization builds on top. Treat AWS's certificate as inherited evidence for the provider's controls only, and assess your own controls separately.

Missing region and service checks

AWS lists in-scope regions in its certificate and in-scope services on its ISO Certified page. Teams that deploy into a region or use a service absent from those lists can find gaps late in the audit. Compare every region and service in your architecture against both AWS lists before the scope is approved, and recheck when new services are adopted.

Unchecked certificate versions and dates

AWS's ISO/IEC 27001:2022 certificate is the version that matters for a 2022-based ISMS, and the 2013 edition certifications had to expire or be withdrawn by 31 October 2025. Relying on an old certificate or an expired version can weaken your audit file. Confirm the certificate version, issuing body and validity dates in the IAF CertSearch database and keep a dated copy in your evidence folder.

Weak evidence for cloud services controls

Control A.5.23 asks for established processes for acquiring, using, managing and exiting cloud services. Teams often have no record of how AWS accounts were approved, how exit or data return would work, or who reviews service configuration. Document cloud service selection, configuration baselines, periodic reviews and an exit procedure, and keep dated records that show each one ran.

Questions buyers ask about AWS and ISO 27001

Does AWS's ISO 27001 certificate make our organization certified?

No. AWS states that customers are not automatically certified because they use AWS. Your organization needs its own ISO/IEC 27001:2022 certificate, issued after an accredited certification body audits your information security management system, including your own people, processes and controls. What AWS's certificate gives you is evidence for the part it covers: the security management process over the services and data centers in its specified scope. AWS says that its certification may make your own certification easier, but it does not replace your audit. Your scope, risk assessment and Statement of Applicability still have to show how you treat each risk, including the controls that sit with you in your AWS accounts, and the auditor will test those directly.

Your own scope and risk assessment
Your identity, configuration and logging controls
Your supplier and cloud service decisions

How do we check AWS's current ISO certificates, regions and services?

Start with AWS's ISO/IEC 27001:2022 compliance FAQs, which describe the certificate, the certifying body and where current documents are published. AWS lists the in-scope regions in its ISO/IEC 27001:2022 certificate and the in-scope services on its ISO Certified page. Confirm three things before you rely on it: the certificate is current, every region you deploy in appears in it, and every service you use is listed. A service missing from the list is a gap you must assess yourself. The certificate is verified by EY CertifyPoint, an ISO certifying agent accredited by the Dutch Accreditation Council and an IAF member. Record the date you checked and the version you saved, because lists change and your auditor will ask which version you relied on.

What does ISO 27001 control A.5.23 require for cloud services in practice?

Control A.5.23 asks the organization to establish processes for acquiring, using, managing and exiting cloud services, aligned with its own information security requirements. In practice, an auditor looks for a documented cloud service policy and a process that runs from selection to closure. Typical evidence includes:

A supplier assessment before adoption, covering the provider's certificates and data locations
A shared responsibility matrix that lists which controls AWS operates and which ones your team configures and monitors
Approved account, region and service standards, enforced through configuration baselines
Periodic reviews of cloud use, spending and access
A documented exit plan covering data return, deletion and account closure

The control concerns the organization's processes, so the evidence is records of decisions and reviews, not only console screenshots. Assign each service an owner, and show in your Statement of Applicability how A.5.23 applies to your AWS estate.

Can an implementation partner run our ISO 27001 project on AWS?

Yes, an implementation partner can prepare systems, controls and evidence and run the project to a written scope, but it cannot own the controls, make your risk decisions or issue the certificate. Those stay with your organization, and the certificate comes from the accredited certification body. Your leadership still approves the scope, the risk treatment decisions and the Statement of Applicability required by clause 6.1.3 d) of ISO/IEC 27001:2022. A partner can help with account structure, configuration baselines, logging, access reviews and evidence collection. Confirm that the certification body is independent of the firm that helped you build the system before you contract. Ask for a written scope that lists AWS accounts, regions, services and deliverables, along with named responsibilities for your staff. DeployOpen plans and implements self-hosted open-source platforms inside client infrastructure and prepares evidence for assessments, but it does not issue audit reports or certificates.

How long and how costly is ISO 27001 on AWS, and what drives it?

No duration or price is supplied for this work, so the answer depends on the scope you set. Costs fall into four groups: your internal staff time for the risk assessment, policies and evidence; partner fees under a written scope; the certification body's audit fees; and the tools you run. Some costs are one-time, such as the initial implementation and the first certification audit. Others recur, including surveillance audits and internal audits. Under ISO/IEC 17021-1, a management system certification cycle lasts three years, with at least one audit in every calendar year, as the European Accreditation FAQs explain. Drivers include the number of AWS accounts, regions and services in scope, how much evidence already exists in infrastructure as code and logs, the size of your team, and how many sites or entities the management system covers. When you request quotes, ask each provider for the scope it assumes, the staff time it expects from you, the audit days it plans and the recurring items after the first audit.

How do we check a certification body's accreditation in IAF CertSearch?

Search the IAF CertSearch database for the certification body's name and the certificate number, then confirm that the listing shows its accreditation, the accredited scope and the validity dates. ISO still points buyers to IAF CertSearch for checking accredited certificates, although Global ACI has assumed the IAF and ILAC roles since 1 January 2026. In the listing, check that:

The certification body is accredited for ISO/IEC 27001 by an accreditation body
The accredited scope matches the services and regions you will certify
The certificate is valid, and any suspension or withdrawal is shown

Also ask whether the body applies ISO/IEC 27006-1:2024 to your audit. IAF MD 29:2024 required accredited ISMS certification bodies to apply it to all clients by 31 March 2026. Request written confirmation, and keep a copy of the accreditation details in your audit file.

How DeployOpen prepares an AWS-based ISMS for assessment

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own AWS accounts. For an AWS-based ISMS, that work sits alongside the controls the organization owns: the platforms that run identity, logging, configuration management and backup are built in the client's accounts, under the client's governance. DeployOpen does not issue reports, attestations or certificates. Independent auditors and certification bodies do that, and the organization's own certification depends on their work, not on DeployOpen's.

Work starts with a written scope. Before any build begins, the agreement names the accounts, regions, services and self-hosted platforms in scope, the deliverables and the timeline, and it states which controls the client keeps. That scope has to match the boundary the client plans to claim in its Statement of Applicability and its own ISMS scope, so the first decision to confirm is whether the platforms in the plan are the ones the client actually runs. Changes to scope are agreed in writing too, so the evidence trail stays tied to a documented boundary.

Once the scope is agreed, DeployOpen prepares systems and evidence against it: hardened configurations, access and logging setups, backup and recovery records, and infrastructure as code that the auditor can trace. At handover, the client receives documentation that explains how each platform maps to the controls it supports, who owns each recurring evidence task and how it is run. The client should confirm with its auditor, before the build, which evidence formats and sampling approach that auditor expects, since those choices shape what the documentation has to contain.

ISO 27001 on AWS: using AWS certificates and your own controls