They are independent proofs that a service follows recognised security, privacy and operational standards.

Compliance means following rules. The rules may be laws, such as privacy laws that protect personal data. They may be industry standards, such as the rules for handling payment cards. They may be promises that a company makes to its own customers. A compliance certification, or more broadly a compliance offering, is evidence that an independent expert has examined a service and found that it meets a particular set of rules.

Microsoft builds Azure to meet a very large number of standards, covering many industries and countries. Specialist auditors who are not part of Microsoft examine the data centres, the processes, the people and the technology. When they are satisfied, they issue a report or a certificate. Customers can then use these documents as part of their own evidence when they ask regulators and auditors to approve the use of Azure.

This does not mean that anything you build on Azure is automatically compliant. The certificates describe how Microsoft runs the platform. How you configure and use the platform is a separate question, and it remains your responsibility. We will return to this point many times, because it is the most important idea in this guide.

Words you will meet again and again

Because regulated businesses must prove that they chose safe suppliers, and cannot simply say “trust us”.

A bank cannot move customer records to a new service because the service looks modern. Its regulator will ask how the bank checked that the provider protects data, how it handles incidents, where the data lives and who can access it. A hospital faces similar questions about patient records, and a retailer about payment cards. Every one of them needs documents that an independent party has verified.

Without certifications, each customer would need to inspect Microsoft’s data centres personally, which is impossible for thousands of customers. With certifications, the audit is done once by a qualified auditor, and the results are shared with all customers. This saves enormous time and gives everyone a common language.

The words sound alike, but they describe different kinds of proof, and mixing them up causes confusion.

People often say “Azure is certified for everything”. In reality, the proofs come in several forms. Knowing the differences helps you ask for the right document and understand what it can and cannot tell you.

Azure’s compliance portfolio is large, so it helps to group it by purpose.

Microsoft lists its compliance offerings in the Azure compliance documentation and keeps the list updated as audits are completed. The names below are examples, not a complete or permanent list. Always check the current list before relying on a specific standard.

flowchart TD
  A["Azure Compliance Portfolio"] --> G["Global: ISO, SOC, CSA STAR"]
  A --> F["Financial: PCI DSS and regulator guidance"]
  A --> H["Healthcare: HIPAA support, HITRUST"]
  A --> P["Public Sector: FedRAMP, national schemes"]
  A --> R["Regional: country programmes"]
  A --> L["Privacy: contractual commitments"]
        

A handful of names appear in almost every conversation about cloud compliance.

Some customers need extra separation and special rules, which Azure meets with distinct environments.

Most customers use the public Azure cloud, spread over many regions around the world. A region is a geographic area with one or more data centres. A group of regions that share rules about where data stays is called a geography. Some organisations, however, are not permitted to use the public cloud because of national security or strict legal rules. For them, Microsoft offers separate clouds with additional controls.

Behind every certificate is a long cycle of preparation, testing, evidence and review.

Audits are not one-time events. Microsoft runs a continuous compliance programme. Teams design controls, operate them every day, collect evidence automatically and test themselves before the real auditor arrives. External auditors then examine the controls by interviewing staff, reading documents, inspecting systems and checking samples of records.

sequenceDiagram
  participant M as Microsoft Teams
  participant A as Independent Auditor
  participant P as Service Trust Portal
  participant C as Customer
  M->>M: Operate controls and collect evidence
  M->>A: Provide scope, documents and access
  A->>M: Test controls and raise findings
  M->>A: Fix findings and supply further evidence
  A-->>M: Issue report or certificate
  M->>P: Publish for customers
  C->>P: Download reports for own audit
        

A certificate only covers what was inside the audit boundary, and the boundary is not always the whole of Azure.

Every audit has a scope. The scope names the services, the regions and sometimes the clouds that were examined. A service that launched recently may not yet appear in a particular report. A preview feature is usually outside the scope of audits. A region opened last month may not have been included in the last audit cycle.

Microsoft publishes its compliance material in a few well-known places.

What you can usually find

This chapter holds the most important lesson of the whole guide.

Azure follows a shared responsibility model. Microsoft is responsible for the security of the cloud: the physical data centres, hardware, network and the platform services that it operates. The customer is responsible for security in the cloud: data, identities, devices, configuration and application code. Certificates describe the first half. Your own audit will examine the second half.

flowchart LR
  MS["Microsoft evidence: data centres, platform, hosts"] --> J["Your audit file"]
  CU["Your evidence: configuration, access, data, processes"] --> J
  J --> AU["Auditor or regulator decision"]
        

Reading standards is hard, so Microsoft provides a tool that turns them into a to-do list.

Microsoft Purview Compliance Manager is a tool that helps you assess and manage your compliance with many standards across Microsoft cloud services. You choose a regulation or standard, and the tool creates an assessment. The assessment breaks the standard into controls and, for each control, shows what Microsoft does, what you must do and the status of each action.

Paper promises need technical teeth, and Azure offers tools that check and enforce your settings.

Azure Policy lets you write rules about how resources must be configured, such as requiring encryption or blocking public access, and checks all resources against them. It includes built-in regulatory compliance initiatives, which are bundles of policy rules mapped to the controls of standards such as ISO, NIST, PCI DSS and others.

Microsoft Defender for Cloud shows a regulatory compliance dashboard built on these initiatives. It groups the technical checks by control domain and shows which resources pass and which fail, so that you can see progress per standard.

flowchart TD
  S["Standard such as ISO or PCI DSS"] --> I["Built-in Regulatory Initiative in Azure Policy"]
  I --> E["Evaluates your resources"]
  E --> D["Defender for Cloud Compliance Dashboard"]
  D --> R["Remediate or prevent issues"]
  R --> EV["Export reports as evidence"]
        

Many standards ask the same questions, and Azure offers features that answer them.

A clear path turns a scary audit into a series of manageable steps.

Auditors believe what they can see, so records are the heart of compliance.

An auditor will rarely accept “we do this” without proof. For each control, they ask for evidence, for example a list of who has administrator rights, logs showing that access reviews happened, screenshots of encryption settings or reports of patching status. Evidence must be complete, dated and tamper-resistant.

Compliance is not only technical. Contracts carry promises that certificates cannot.

AI services bring familiar compliance questions, and some new ones.

When organisations use AI services such as language models hosted in Azure, regulators and customers ask where prompts and data go, whether they are used to train models, how outputs are controlled and how people are protected from harm. Microsoft publishes documentation about the data handling of its AI services and states that customer data in Azure OpenAI Service is not used to train the underlying models for other customers. Details vary by service, so read the current terms.

Teams that pass audits easily tend to use the same handful of approaches.

flowchart TD
  LZ["Compliant Landing Zone: policy, identity, network, logging"] --> EN["Regulated Enclave: card or health data"]
  LZ --> GEN["General Workloads"]
  EN --> EV["Evidence Store: logs and reports with retention"]
  GEN --> EV
  EV --> AU["Audit Readiness and Reporting"]
        

Different industries use the same building blocks in different ways.

These beliefs and habits regularly lead to failed audits and unpleasant surprises.

Walk through these steps whenever you plan a regulated workload on Azure.

No. Certificates cover the platform that Microsoft operates. Your configuration, access control, data handling, application code and processes are your responsibility, and you must provide your own evidence for them.

Through the Service Trust Portal, which hosts reports, certificates and compliance guides. Some documents require sign-in or acceptance of a confidentiality agreement. The Microsoft Trust Center and Azure compliance documentation explain what each document means.

SOC 1 focuses on controls relevant to financial reporting. SOC 2 covers security, availability, confidentiality, processing integrity and privacy. SOC 3 is a public summary of the SOC 2 opinion, without the sensitive detail.

These are laws, so there is no single certificate. Microsoft provides contractual commitments, documentation, tools and independent reports that help customers meet their own duties under such laws.

Preview services are generally not included in compliance commitments or audit scope unless stated otherwise. Avoid using them for regulated data without checking the specific terms.

Use the services-in-scope pages for the relevant standard in Microsoft’s compliance documentation, and check that the region and the cloud environment you use are listed. Record the date of your check and repeat it regularly.

Compliance Manager is a tool that turns standards into assessments, improvement actions and a score, and shows which duties belong to Microsoft and which to you. It guides your work and organises evidence, but it does not certify you.

Reports and certificates are renewed on cycles, commonly yearly, with some standards using longer cycles and interim reviews. Scopes also change as services launch. Always use the latest documents and note their dates.

Yes, you choose regions for most services, and many keep data at rest in the chosen geography. Check the data location terms for each service, because some processing, support and telemetry may follow different rules.

Write down your obligations and your data types, then check that the Azure services and regions you plan to use are in scope for the relevant standards. After that, build a responsibility matrix and a governed landing zone, and involve legal and audit specialists early.

Compliance certifications in Azure are independent proofs, such as ISO certificates, SOC reports, PCI DSS attestations and government authorisations, that Microsoft runs its platform according to recognised standards. They are found in the Trust Center and the Service Trust Portal, and they are valid only within their stated scope and dates. They prove Microsoft’s half of the shared responsibility model, and your own audit still depends on your configuration, access control, data handling, contracts and processes. With tools such as Azure Policy, Defender for Cloud and Compliance Manager, a governed landing zone, a small regulated enclave and automated evidence, you can turn the provider’s proof and your own controls into a smooth and convincing audit.