Does Azure's ISO 27001 certificate make us ISO 27001 certified on Azure?
No. Microsoft's Azure ISO/IEC 27001 certificate covers Microsoft's cloud services, including Azure, Azure Government and Azure China, and it does not certify your organization's information security management system. Only an accredited certification body can certify your organization, and it will audit your own scope, controls and processes. When a customer asks for ISO 27001 and your workload runs on Azure, the first decision is to accept that Microsoft's certificate is an input to your assessment, not a substitute for it. Microsoft's guidance is specific on this point. A customer pursuing certification for an implementation on in-scope services can use Azure's certifications in its assessment, but the customer remains responsible for engaging an assessor to evaluate its implementation and its own controls and processes. In practice, that means you must still define the ISMS scope, complete the risk assessment and Statement of Applicability, assign owners, and operate and record controls such as access reviews, logging, change management and supplier oversight for the workloads, identities and data you run in Azure. Azure's certificate tells the assessor that the underlying platform has been audited. It does not show that your tenant configuration, your people or your processes meet the Annex A controls. An implementation partner can help you prepare the systems and evidence the assessor will ask for, such as configuration baselines, policy exports, access records and documented procedures. That partner does not issue audit reports or certificates. Confirm early with your chosen certification body how it will treat the Azure certificate and the Service Trust Portal documents for your in-scope services, and ask it to state that in writing.
How to check that each Azure service you use is in scope
An Azure certificate only helps your assessment for the services, regions and clouds it actually covers. The cards below walk through the checks that connect your architecture to the certificate's scope, so that gaps are found before an assessor finds them.
Confirm the certificate and service list
Start from Microsoft's current ISO/IEC 27001 certificate and its listed services, not from memory or a sales deck. The certificate covers Azure, Dynamics 365, Power Platform and select Microsoft 365 cloud services, so note the exact product names and the version of the certificate you download. Ask your assessor to accept that version as the reference for your assessment.
Match each service and region to the certificate
Build a list of every Azure service in your architecture, with the region and cloud (Azure, Azure Government or Azure China) where it runs. Compare each line against the certificate's covered clouds and service list. A service that is in scope in one cloud may not be in scope in another, so the match must be made per cloud, not per product name alone.
Separate Azure DevOps and other certificates
Azure DevOps is covered by a separate certificate, so a pipeline or repository that you rely on for change management is not covered by the main Azure certificate. Check each Microsoft product you use against the certificate that names it, and keep a separate entry for each. Mixing them up is a common way to claim coverage that does not exist.
Record the certificate version and date
Record the certificate version, its issue or expiry date, and the date you downloaded the audit documents from the Service Trust Portal. Your Statement of Applicability and risk treatment records should point to that exact evidence. When Microsoft issues a new certificate, your record shows which version your assessment relied on and when you need to re-check.
Find services outside scope that hold regulated data
List every Azure service that is outside the certificate, including preview features, marketplace offerings and third-party services you run in Azure. If any of them stores, processes or transmits regulated data, it still falls within your ISMS. Assign it an explicit risk treatment with your own controls, because the Microsoft certificate will not evidence it for you.
Getting Microsoft's audit documents from the Service Trust Portal
This sequence takes you from the Azure ISO/IEC 27001 certificate to a filed set of Microsoft audit documents that your assessor can review alongside your own controls. The output is an evidence folder that shows what Microsoft covers and what remains your responsibility. What the certification body accepts is its decision, so confirm the format and scope with them before you rely on the folder.
Confirm the in-scope Azure services
Start from Microsoft's Azure ISO/IEC 27001 certificate description and note which cloud offerings it covers, including Azure, Azure Government and Azure China. Azure DevOps has its own certificate, so list it separately if your delivery pipeline runs on it. Record the exact service names you use, because a service that is not named in the scope does not inherit Microsoft's certification. The output is a short scope register that your ISMS owner signs off.
Sign in to the Service Trust Portal
Open the Service Trust Portal with an account that your organization controls and that your identity team has approved for compliance material. Use multi-factor authentication and record who holds access, since the portal documents will become part of your audit evidence. The check that this step is done is a working session in the portal with the account owner named in your access register.
Locate the ISO/IEC 27001 audit documents
Find Microsoft's ISO/IEC 27001 material in the compliance section of the portal and identify the certificate, the statement of applicability for the cloud services and the audit report or summary that Microsoft makes available. Note the audit period and the version of each document, because an assessor will check that the material is current. The output is a list of document names, versions and dates for your evidence index.
Download and store the documents under version control
Download each document and store it in a controlled evidence repository with a fixed folder name, the date you retrieved it and the portal URL it came from. Do not edit Microsoft's files. Keep a copy of prior versions so that your evidence still matches the period an assessor samples. The check is that every file has a hash or checksum entry and an owner in your evidence register.
Map Microsoft's controls to your Annex A list
Compare the cloud services and control descriptions in the Microsoft material with your Statement of Applicability. For each Annex A control that Microsoft's documents address, record whether the responsibility is Microsoft's, shared or yours, using Azure Policy's responsibility labels as a starting point. Pay particular attention to A.5.23 on cloud service acquisition and exit, which stays with you. The output is a responsibility matrix that your certification body can read.
File the documents with your own control evidence
Place each Microsoft document next to the evidence it supports, such as Azure Policy compliance exports, configuration records, access reviews and change logs from your own tenant. Write a short note explaining why each Microsoft document is relevant to a specific control. The check is that a reviewer can follow a path from one Annex A control to a Microsoft document and then to your own evidence without asking for missing context.
Agree the evidence format with your certification body
Before the certification audit, share your responsibility matrix and evidence index with the certification body and ask which Microsoft documents it expects, how it wants them presented and whether it needs anything beyond the portal material. The certification body or assessor decides what they accept, and an implementation partner can prepare the package but cannot approve it. The step is complete when the decisions are recorded in writing in your audit plan.
What the Azure Policy ISO 27001 initiative shows and where it stops
Azure Policy includes a built-in regulatory compliance initiative for ISO/IEC 27001 that applies to Azure and Azure Government. The initiative maps each ISO/IEC 27001 control to one or more policy definitions in Azure, then evaluates your subscriptions and resources against those definitions. For each control, it labels the responsibility as customer, Microsoft or shared, so you can see which parts of a control Microsoft operates and which parts your team must configure or run.
- Control-to-policy mapping: Each mapped control lists the policy definitions that evaluate it, so you can trace a control to a measurable resource setting.
- Responsibility labels: Every control is tagged as customer, Microsoft or shared, which tells you where your own configuration and operating evidence are required.
- Compliance state per resource: The compliance view shows which resources pass or fail each mapped definition across the scope you select.
- Scope of evaluation: Results apply only to the subscriptions, management groups and resource types you assign the initiative to.
- Point-in-time view: Compliance states reflect the latest evaluation, so the dashboard is a snapshot rather than a continuous record of past states.
Confirm in the Azure portal which initiative version and control list your environment shows before you map them to your Statement of Applicability.
The initiative gives you technical evidence for controls whose requirements can be expressed as Azure resource settings, such as storage encryption, network restrictions or logging enabled. It does not show that your organization has a risk assessment, policies, trained staff or working management reviews. Those belong to your ISMS, and an auditor will test them separately. Treat the initiative as one input to the evidence set for technological controls, not as proof that the ISMS works.
- Configuration evidence: Passing definitions show that a setting existed at evaluation time, which supports controls about cryptography, logging and network configuration.
- Responsibility boundaries: Customer-labeled controls show where your evidence must come from, while Microsoft-labeled controls can be supported by the Service Trust Portal documents.
- Traceability: The control-to-definition mapping helps you link a Statement of Applicability entry to a specific, repeatable check.
- Drift detection: Failing resources flag configuration changes that may need a change record or a corrective action.
- Gaps the dashboard cannot show: Policies for people, suppliers, incident handling and continuity require records you produce yourself.
Ask your assessor how they will accept Azure Policy output alongside your own change, access and incident records before you rely on it.
You assign the initiative at a management group, subscription or resource group through the Azure Policy blade or with the Azure CLI and infrastructure as code. Assignment requires an identity with sufficient rights at that scope, and the initiative's parameters should be set deliberately rather than left at defaults. After assignment, evaluation runs on a schedule and on resource changes, so allow time before you read the first results. The compliance dashboard can then be exported for each control, and the exported data can be stored with your evidence set.
- Assign at a deliberate scope: Choose a management group that matches your ISMS scope so that excluded subscriptions are a documented decision.
- Set parameters explicitly: Record the parameter values used, since they affect what counts as compliant.
- Trigger an evaluation: Run an on-demand compliance scan before a review so the results reflect current state.
- Export per control: Export the compliance state for each control or initiative view and date-stamp each file.
- Keep the assignment as code: Storing the assignment definition in a repository gives you a change history for the evidence itself.
Check with your team which role owns assignment, who approves scope changes and where exports are stored under your retention rules.
Microsoft states that Azure Policy compliance is only a partial view of overall compliance. The initiative cannot see your identity governance decisions, your supplier due diligence, your staff screening, your risk treatment choices or whether people follow your procedures. It also cannot confirm that a passing definition is the right control for your risk, since the mapping reflects a general reading of the standard. Resources outside the assigned scope, such as on-premises systems, SaaS tools and endpoints, are invisible to the initiative unless you bring them into a separate process.
- Partial view by design: Microsoft's own statement means a green dashboard never equals certification.
- Scope blind spots: Anything outside the assigned subscriptions or resource types is not evaluated.
- Mapping is not a conclusion: A definition mapped to a control does not show that the control's purpose is met in your environment.
- Process controls are absent: Procedures, reviews and training are outside what a policy engine can evaluate.
- Certificate limits apply: Microsoft's certificate covers its own services, and your implementation still needs your own assessment.
Before your audit, ask your assessor to confirm in writing which controls they will accept with Azure Policy evidence and which need records from your own processes.
Which ISO 27001 controls stay with you on Azure
Microsoft's certificate covers the Azure platform, not the management system you run on top of it. The cards below cover the decisions, records and processes that remain your responsibility, even when every Azure service in your design is in scope.
Cloud service acquisition and exit
A.5.23 asks you to establish processes for acquiring, using, managing and exiting cloud services in line with your information security requirements. Microsoft's certificate does not write this process for you. Document how Azure subscriptions are requested, who approves them, how workloads are moved, and how data is removed when you leave. Check that the process names the Azure services you actually use, not the catalog as a whole.
Statement of Applicability decisions
Clause 6.1.3 d) requires a Statement of Applicability that lists the Annex A controls you apply, with justification for those you exclude. Azure's certificate does not tell an assessor which controls your Azure environment needs. You own every inclusion and exclusion decision, and an auditor will test whether the reasons still hold for your architecture.
Risk assessment and treatment
Your ISMS needs its own information security risk assessment and risk treatment, built on your assets, threats and business impact. Risks in a shared-responsibility cloud sit at the boundary between Microsoft's controls and yours. Record each risk, the treatment chosen, and who accepted any residual risk, and revisit the register when you add services or regions.
Access and identity decisions
Microsoft operates the identity platform, but your organization decides who receives roles in Microsoft Entra ID and Azure RBAC, which privileged access is granted, and how often entitlements are reviewed. Azure Policy can show whether MFA or role assignments are configured, yet it cannot approve a join, move or leave. Keep the approval records and periodic review evidence yourself.
Supplier and customer contracts
Your agreements with customers, subprocessors and suppliers set security obligations that the certificate cannot satisfy on your behalf. Confirm what your customer contracts require about hosting location, subprocessors and incident notice, and compare them with the Azure terms you accept. Assessors will check that these commitments map to controls in your Statement of Applicability.
Incident, continuity and staff training
Azure Monitor and Microsoft Defender can detect events, but your incident response plan, escalation roles, continuity tests and backup restore checks are your own processes. Training records for administrators and engineers who operate the environment are also your evidence. Confirm that staff can show they completed the training your plan requires, because the certificate cannot vouch for them.
Why Azure's certificate is against 27001, not 27002
An organization cannot be certified against ISO/IEC 27002:2022, because that standard gives guidance on the Annex A controls and is not a management system standard. The audit vehicle is ISO/IEC 27001:2022. Its clauses 4 to 10 set the requirements for the ISMS, and Annex A lists the 93 controls that your Statement of Applicability must address. ISO/IEC 27002 explains how to implement those controls, so an assessor reads it as supporting material. Microsoft's Azure certificate is issued to Microsoft under the same logic: it certifies Microsoft's management system and the in-scope Azure services, and it does not certify your use of them.
Your own certificate will therefore be issued against ISO/IEC 27001:2022, with your scope written around your Azure subscriptions, workloads, people and processes. Cloud-specific guidance sits in ISO/IEC 27017:2026, which extends the control guidance for cloud service providers and cloud service customers. Confirm with your certification body whether it will treat 27017 as reference material for your Azure controls, how it expects you to show the shared responsibility split for controls such as A.5.23, and whether it wants your cloud controls mapped to the provider's certificate. Ask for this in writing before the stage 1 audit, because the answer shapes the evidence you collect.
Two decisions follow. First, document which Azure services and regions your scope includes, and check them against the scope of Microsoft's certificate in the Service Trust Portal, since the certificate lists the cloud services it covers. Second, decide how you will evidence the controls Microsoft does not operate for you, such as access reviews, configuration baselines and cloud supplier monitoring. Whether an implementation partner helps with that documentation is a scoping question for the written quote, and the certification body still decides whether your evidence is sufficient.
How an Azure-based ISO 27001 project moves from scope to certificate
This sequence turns Azure's inherited certifications and Azure Policy results into an ISMS that a certification body can audit. Each phase ends with a named output, so the organization can see what is finished before the certification body arrives.
Define the ISMS scope and Azure boundary
The organization, with its management sponsor, decides which business units, products and processes fall inside the ISMS, then lists the Azure subscriptions, management groups, regions and Microsoft services that support them. Cloud services that are in scope but outside Azure, such as SaaS tools and identity providers, go on the same list. The output is a written scope statement and a boundary inventory that names each subscription and region. Confirm with the certification body how it expects scope to be described, because the certificate will carry the scope wording.
Map Microsoft documents and Azure Policy to controls
Engineers and the compliance lead take the Azure ISO/IEC 27001 certificate and its audit documents from the Service Trust Portal and match the Microsoft responsibility split to each Annex A control. They then enable the built-in ISO/IEC 27001 initiative in Azure Policy for the in-scope subscriptions and record which policy results cover which controls and which ones show customer responsibility. The output is a control responsibility matrix that marks each control as Microsoft, shared or customer, plus a note that Azure Policy compliance is only a partial view.
Close gaps and write the Statement of Applicability
Owners of each control implement what Azure Policy cannot show, such as access reviews, supplier and cloud acquisition processes under A.5.23, incident handling, awareness training and documented procedures. The risk assessment and risk treatment decisions feed the Statement of Applicability required by clause 6.1.3 d), which lists every Annex A control, states whether it applies, and links to the evidence. The output is an approved Statement of Applicability and a gap register that shows how each open item was closed or accepted.
Collect and retain evidence for each control
Each control owner stores dated evidence that the control operates, such as Azure Policy compliance exports, Azure Activity Log retention settings, access review records, change tickets and training completion. Evidence must come from systems that the organization controls, and it must cover a period long enough for the auditor to sample. The output is an evidence index that links each Statement of Applicability line to its artifacts, with a named owner and retention location for each.
Run an internal audit and management review
Someone independent of the operating teams audits the ISMS against clauses 4 to 10 and the in-scope Annex A controls, then records nonconformities and opportunities for improvement. Leadership holds a management review that considers audit results, risk changes, incidents and objectives, and records the decisions. The output is an internal audit report with a corrective action log and minutes of the management review. Nonconformities must be closed or formally planned before the certification body's stage audit.
Complete the certification body's stage audits
The organization selects an accredited certification body, which conducts the audit in stages. The certification body reviews the documented ISMS and then tests implementation on site or remotely, including Azure configuration evidence and the customer-side controls. Certification is issued only by the certification body after its review, and the certificate states the scope. The output is either a certificate or a list of nonconformities to resolve. Ask the certification body for its own timeline and fees, and confirm how it treats Microsoft's certificate in its assessment.
What must be in place before the certification audit
An assessor will test whether your Azure environment, your records and your own management activity agree with each other. The cards below are the artifacts that tie Microsoft's certificate and Azure Policy results to your scope, your controls and your internal checks.
Documented scope naming Azure services and regions
Your ISMS scope statement should list the Azure services, subscriptions, management groups and regions that hold or process in-scope information, and state which of them sit under Microsoft's certificate. Check that every service you name appears in Microsoft's ISO/IEC 27001 scope for Azure, and that the Azure Government or Azure China boundaries match where your data really lives. Any service outside that list needs its own control evidence.
Azure Policy compliance exports
Export the compliance state of the built-in ISO/IEC 27001 initiative for each in-scope subscription, dated close to the audit. Read each control's responsibility label (customer, Microsoft or shared) before you rely on a green result. Treat the export as a partial view of compliance: it shows configuration state, not whether your people follow procedures.
Microsoft audit documents and responsibility matrix
Download the current audit reports, bridge letters and shared responsibility documents from the Service Trust Portal and file them with the date and certificate scope they cover. Check the validity period and whether Azure DevOps or another service needs its separate certificate. Your own file should show which Microsoft controls you cite and which controls you still have to evidence yourself.
Infrastructure as code and change records
Keep the Bicep, Terraform or ARM templates, pipeline runs and approved pull requests that created or changed in-scope resources. Check that each production change traces to a reviewed commit and an approval, and that drift between code and live Azure resources is detected and recorded. These records give the assessor configuration and change evidence without manual screenshots.
Access review records
Export Microsoft Entra ID role assignments, privileged role activations and guest accounts for each in-scope tenant and subscription. Confirm that each review has a named reviewer, a date, a decision for every account and follow-up on removed access. Check that cloud administrators are reviewed separately from standard users.
Risk register and internal audit results
Your risk register should contain Azure-specific risks, such as misconfigured storage exposure or over-broad roles, with owners and treatment decisions that match the Statement of Applicability. Internal audit results must show that you tested these controls yourself, recorded nonconformities and closed corrective actions. An assessor will look for evidence that the review happened before the external audit, not just a filed report.
Who does what: your team, an implementation partner and the certification body
Your organization owns the information security management system, and no partner or cloud provider can take that ownership from you. Microsoft's certificate covers the Azure platform, but the risk decisions, the scope of your ISMS and the controls you choose to apply all sit with your leadership. Management commitment is a requirement in its own right, so the people who sign the policies and approve the risk treatment plan must be named and visibly involved.
- Scope and risk decisions: Define which Azure subscriptions, workloads, regions and business processes fall inside the ISMS, and accept or treat each risk in the risk assessment.
- Statement of Applicability: Decide which Annex A controls apply, justify each exclusion and record how each applicable control is implemented, as clause 6.1.3 d) requires.
- Management sign-off: Approve the information security policy, allocate resources and review the ISMS at planned intervals.
- Control ownership: Assign an owner to each control, including the customer responsibilities that Azure Policy marks as yours.
- Operation and records: Run access reviews, incident handling, supplier reviews and internal audits, and keep the records they produce.
Before you engage anyone, confirm that a named executive owns the ISMS and that the internal team has time allocated for the work.
An implementation partner such as DeployOpen works on the systems and evidence side of the project. Under a fixed scope agreed in writing, a partner can configure Azure controls, document how they operate, test them internally and assemble a readiness pack for your team and the certification body. The partner works inside your environment and on your instructions, and the decisions in the previous tab remain yours. A partner does not certify, attest or issue any report, and it should not be the same party that audits you.
- Azure configuration: Set up identity, logging, network and policy settings that support the controls you have chosen, and document the configuration as code where practical.
- Evidence preparation: Define what evidence each control produces, where it is stored and how long it is kept.
- Internal checks: Test whether controls work as documented before the certification body arrives, and record gaps as nonconformities to fix.
- Documentation: Draft procedures and runbooks for your review, which your organization must approve and adopt.
- Readiness pack: Hand over the configuration baseline, the evidence index, the test results and the open actions, so your team can answer auditor questions.
Ask the partner to state in the statement of work that it does not issue certificates or attestations, and to name who on your side accepts each deliverable.
The certification body is the only party that assesses your ISMS against ISO/IEC 27001 and issues a certificate. ISO does not certify organizations, and an accredited body must operate to ISO/IEC 17021-1 together with ISO/IEC 27006-1, which IAF MD 29:2024 required the bodies to apply to all clients by 31 March 2026. The body must be independent of the work it audits, which is why the consultant or partner who built the controls should not also be the auditor.
- Stage 1 and Stage 2 audits: The body reviews your documentation, then tests implementation and operating effectiveness on site or remotely.
- Nonconformities: The body records findings that you must correct within agreed timelines before a certificate is issued or maintained.
- Certificate and cycle: A certificate covers a defined scope, and surveillance audits follow in the three-year cycle.
- Accreditation: Confirm the body's accreditation scope covers ISO/IEC 27001 and check the certificate on the IAF CertSearch database, which ISO points to.
- Fees and terms: The body's quote, contract and audit plan are separate from any consultant fees.
Before signing, ask the body for its accreditation status and its policy on consultancy conflicts.
How to choose an auditor and an implementation partner for an Azure ISMS
An Azure ISMS needs two outside roles that must stay separate: a certification body that audits your management system, and an implementation partner that helps build and evidence it. The cards below cover the checks that keep both roles honest and the terms that keep the work in scope.
Confirm certification body accreditation
Only an accredited certification body can issue an ISO/IEC 27001 certificate. Ask for the accreditation body's name and the accreditation scope, then check the certificate in the IAF CertSearch database, which ISO still points to for accredited certificates. Since 1 January 2026, Global ACI has assumed the IAF and ILAC roles, so confirm the lookup route your accreditation body uses. Check that the body's accredited scope covers ISMS certification, not only a neighboring standard.
Keep the partner independent of the auditor
The firm that prepares your ISMS and evidence should not be the firm that audits it. Ask the partner to confirm in writing that it has no ownership, shared management or fee arrangement with the certification body you plan to use. A partner that also certifies you creates a conflict that can later invalidate the audit. Ask who on the partner side will sit in your readiness reviews and whether they will remain available after the audit.
Verify Azure and ISO 27001 experience
Ask for named engineers who have built Azure landing zones, configured Azure Policy and handled Microsoft's Service Trust Portal documents for an ISMS. Ask how they map Azure Policy initiative results to your own Annex A decisions, since policy compliance is only a partial view. Request an example of a control matrix or evidence index they produced, with client identifiers removed, and check that it names Azure services rather than generic cloud controls.
Require a written fixed scope
A fixed-scope statement of work should list the Azure subscriptions, regions, services and Annex A controls in scope, along with the deliverables such as the Statement of Applicability, risk treatment plan and evidence set. It should say which tasks remain with your staff, including risk decisions and management review. Ask how change requests are priced, and how the partner handles a scope change caused by a new Azure service.
Ask who owns the controls
Microsoft's certificate covers its own cloud operations, but you remain responsible for engaging an assessor to evaluate your implementation and your controls. Ask the partner to state in writing that your organization owns the risk decisions, the Statement of Applicability and the control operation. Be cautious of any proposal that promises certification by association with Azure's certificate.
Questions to ask before signing
Ask the certification body for its audit plan, its audit days for your scope and how it handles nonconformities. Ask the partner which deliverables you receive if the project stops early, who retains the evidence and where it is stored, and what support follows certification. Confirm the certification cycle with the body: under ISO/IEC 17021-1, a three-year cycle includes at least one audit each calendar year.
Questions about ISO 27001 on Azure
Is Microsoft's Azure ISO 27001 certificate enough to get certified myself?
No. Azure's certificate covers Microsoft's operation of the cloud services in scope, and it can be used as part of your assessment, but it does not certify your organization. Microsoft states that a customer seeking certification for an implementation on in-scope services remains responsible for engaging an assessor to evaluate its implementation and its own controls and processes. Your ISMS, risk assessment, Statement of Applicability and the controls you run in your own tenants, applications and people processes still have to be designed, operated and evidenced by you. Only an accredited certification body can issue your certificate after its audit.
How much of the ISO 27001 effort stays with my team on Azure?
Most of the effort stays with you, because the certificate only covers the provider side. Your team owns the clauses 4 to 10 management system work, the risk assessment and risk treatment, and the Statement of Applicability, which is required by clause 6.1.3 d). It also owns the Annex A controls that depend on your configuration, such as access reviews, logging, backup, secure development and supplier management. The cloud services control, A.5.23, asks for processes covering acquisition, use, management and exit from cloud services, and that process is yours to define. Ask any partner to show, control by control, which parts they prepare and which parts your staff must perform and evidence.
Can Azure Policy compliance serve as my ISO 27001 evidence?
Azure Policy can support evidence but should not be the whole of it. Azure has built-in ISO/IEC 27001 regulatory compliance initiatives for Azure and Azure Government that map each control to policy definitions and label responsibility as customer, Microsoft or shared. Microsoft says Azure Policy compliance is only a partial view of overall compliance. A passing policy state does not show that a risk was assessed, that a control was chosen for a reason, or that people followed the process. Use the policy results as technical evidence, keep the exported compliance state with a date, and pair it with records such as access review sign-offs, change approvals and incident tickets.
Can my team handle an Azure ISO 27001 implementation without outside help?
Some teams can, especially where they already run mature cloud governance and have someone who owns the ISMS. The questions to answer honestly are whether you have a named owner for the management system, staff who can explain each control's design and evidence, and time for internal audits and management review. Independent consultants and implementation partners can prepare systems, controls and evidence, but they cannot issue reports or certificates, and they should not be the same people who audit you. If you bring in help, agree the scope, deliverables and handover in writing before work starts, and check the auditor's accreditation separately.
How long is the ISO 27001 certification cycle on Azure?
Under ISO/IEC 17021-1, a management system certification cycle lasts three years, with at least one audit, either surveillance or recertification, in every calendar year. The Azure platform does not change that cycle. Your certification body will plan an initial audit, then surveillance audits and a recertification audit at the end of the cycle. Because the certificate's scope must match the services and sites you actually run, changes to your Azure footprint can trigger scope reviews between audits. Confirm the exact audit calendar and any scope change rules with your chosen certification body before you commit to a project plan.
What should a partner hand over for an Azure ISO 27001 project?
A well-run engagement should hand over documents and working systems you can keep operating after the project ends. Ask for the scope statement, the risk assessment and treatment records, the Statement of Applicability with the reasons for each control, the Azure Policy initiative setup and exported compliance state, and a mapping from each Azure-hosted control to the evidence source, such as logs, tickets or infrastructure as code. Also ask for the Service Trust Portal audit documents you rely on, a list of customer responsibilities, and a runbook for recurring evidence collection. Confirm in the written scope whether the partner also supports the internal audit and the certification body visit.
How DeployOpen prepares Azure systems and evidence for your ISO 27001 assessment
DeployOpen plans, builds and documents the self-hosted open-source platforms and supporting controls that sit inside your Azure subscriptions, so your team can show an assessor how each control operates. We prepare systems and evidence; the certification body and your own assessor decide what passes.
How we scope
- We agree the written scope with you before work starts, naming the Azure services, regions and subscriptions your ISMS covers.
- We map which Azure controls are customer, Microsoft or shared responsibility, so your ISMS does not assume inherited coverage.
- Scope, deliverables and timelines are fixed in writing, with a quote that follows from that scope.
How we build
- We implement and harden the open-source platforms and Azure configurations that your own controls depend on.
- We configure Azure Policy assignments and track findings that need your own process or a documented exception.
- We keep infrastructure as code under version control so configuration and change records can be reviewed by an assessor.
How we hand over
- We document system configurations, control owners and the evidence location for each in-scope control.
- We deliver evidence packs that show how each control operated over the period your assessor will sample.
- Your organization owns its controls, risk decisions and Statement of Applicability; we hand over the material to review and approve.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can prepare systems and evidence again for surveillance or recertification audits, based on the agreed scope.
- Certificates and audit reports are issued only by independent auditors and certification bodies, never by DeployOpen.
