Azure Security, Identity and Compliance for Regulated Businesses

Security and compliance get spoken about as one thing. They are two. Security is keeping attackers out and your systems sound. Compliance is proving, to a regulator or an auditor, that you operate to a defined standard, repeatedly, with evidence. You can be secure and non-compliant: you do the right things but cannot prove it. You can be compliant and insecure: you have the paperwork and a gap nobody tested. In a regulated market you need both, and the compliance half is usually the harder one, because it never finishes.

This guide covers both halves. The first is the security engineering: identity, least privilege, network control, audit trails, the fundamentals that breaches exploit when they are done badly. The second, expanded because it is where most regulated businesses struggle, is compliance: the regulatory landscape you actually operate in, how the obligation is shared with Microsoft, and how to produce evidence continuously instead of scrambling once a year. We run Azure for businesses in financial services, insurance, healthcare and the public sector, so the bias throughout is towards what survives an audit, not just what looks secure on a diagram.

Part one: get the security fundamentals right

Azure security failures are rarely exotic. They are the boring basics done badly: over-permissioned access, no audit trail, a storage account left open, a secret hard-coded in an app setting. Close these and you have shut the most common doors.

The shared responsibility model

Microsoft secures the cloud. You secure what you put in it. Microsoft owns the physical infrastructure, the hypervisor, and the managed service internals. You own your data, your identities, your access controls, your network configuration, and your application security. The line moves by service (more is yours with a VM, less with a fully managed PaaS service), but the principle is fixed: a misconfiguration on your side is your incident, and Microsoft will not configure your access model for you. Knowing exactly where the line falls for each service you run is the starting point for everything else, including compliance, because regulators hold you to your side of that line.

Identity is where breaches start

Most cloud incidents come down to identity. In Azure, identity is Microsoft Entra ID (formerly Azure Active Directory), and it is the control plane for everything. Get it right and most of your security posture follows. Get it wrong and nothing else matters.

The fundamentals: enforce multi-factor authentication for every user, with no exceptions for administrators. Use Conditional Access policies to require compliant devices, block legacy authentication protocols, and challenge risky sign-ins. For hybrid estates that still run on-premise Active Directory, Azure AD SSO for hybrid environments connects the two so people authenticate once against a single identity, and keeping Azure AD Connect performance healthy keeps that synchronisation reliable.

Privileged access is the highest-value target. Use Privileged Identity Management (PIM) to make admin roles just-in-time: nobody holds Global Administrator standing, they activate it for a bounded window with approval and justification, and it expires automatically. This single control eliminates the largest category of standing risk in an Azure tenant.

Least privilege through RBAC, then prove it

Azure role-based access control (RBAC) is how you scope permissions. Least privilege means every identity (human, service principal, managed identity) has exactly the permissions it needs and nothing more. Assign roles at the narrowest scope that works (resource, then resource group, then subscription, in that order of preference) and prefer built-in roles over broad ones like Owner or Contributor at subscription level.

The discipline is not assigning roles, it is reviewing them. Role assignments accumulate. People change teams, projects end, service principals outlive the workload they were created for. Auditing Azure RBAC role assignments on a schedule is what keeps least privilege true over time rather than just true on day one, and when access does not behave as expected, RBAC troubleshooting is how you find out why. Use Access Reviews in Entra ID to make recertification a recurring, evidenced process rather than a manual scramble before an audit.

Control the network

Identity controls who, the network controls where. Network Security Groups are the first layer: default deny, open only what is needed, document why each rule exists, and capture NSG flow logs so you can see what is actually traversing the network rather than what you assume. Azure Firewall adds centralised, stateful protection at the network edge, and the Basic vs Standard decision comes down to whether you need threat intelligence and TLS inspection or just core filtering.

For anything handling sensitive data, Azure Private Endpoints take a PaaS service like Storage or SQL off the public internet entirely and put it on your private network. For regulated workloads this is often not optional: it removes a whole class of public exposure that auditors will ask about.

Audit trail and encryption

When something goes wrong, or an auditor asks, you answer one question: who did what, when. Azure Activity Log records control-plane operations across the tenant. Microsoft Entra ID sign-in and audit logs record authentication and directory changes. Route all of it to a Log Analytics workspace with a defined retention period, and protect it from tampering. Without a centralised, retained, immutable log, you have no audit trail and no incident evidence.

Encryption belongs alongside it: data encrypted at rest and in transit by default, keys managed through Azure Key Vault, with encryption best practices for backups extending the same discipline to your recovery data. Sensitive services like Azure Cache for Redis need the same treatment: TLS enforced, access restricted, secrets in Key Vault rather than in config. For posture, Microsoft Defender for Cloud aggregates findings and scores your environment against established benchmarks, and a real vulnerability management process turns drift and new weaknesses into routine remediation rather than a future incident.

That is the security baseline. None of it is exotic. All of it is the difference between secure and exposed, and all of it becomes evidence when you turn to compliance.

Part two: compliance for regulated markets

Here is where regulated businesses live or die. The controls above have to exist, and you have to prove they exist, to a defined external standard, on demand. That is a different discipline.

Compliance, security, and governance are three things

Security is the controls. Governance is the policy that says which controls must exist and applies them consistently. Compliance is the evidence that proves, externally, that the policy is enforced. In Azure, governance is largely Azure Policy and management groups: you define rules (encryption must be on, public network access must be off, only approved regions may be used) and Azure enforces or audits them across every subscription automatically. That enforcement is also your evidence engine, because a policy that denies non-compliant resources produces a continuous, queryable record of compliance.

The regulatory landscape you actually operate in

For UK and Irish businesses running regulated workloads on Azure, the frameworks that come up most often:

DORA (Digital Operational Resilience Act). Applies to EU financial entities and, critically, their ICT providers. If you operate in EU financial services, DORA brings requirements around incident reporting, operational resilience testing, and third-party risk management. Microsoft is a regulated third party in scope, and so is any managed provider you use.

FCA, PRA and Bank of England operational resilience. UK financial services firms must identify important business services, set impact tolerances, and prove they can stay within them through severe but plausible disruption. Your Azure architecture and your evidence both have to support that.

NIS2. Expands the scope of EU cyber-resilience obligations across more sectors, with stricter incident reporting and management accountability.

PCI DSS. If you handle card data, the control requirements are specific and audited annually. Azure provides a compliant foundation, but the configuration and evidence are yours.

UK GDPR and the Data Protection Act 2018. Data residency, encryption, access control, and the ability to evidence all three. Azure's UK and EU regions plus a compliant data processing addendum support this, but the configuration decisions are yours.

ISO 27001 and SOC 2. The general-purpose assurance standards. Azure carries its own certifications for the infrastructure layer, which you inherit, but your workloads and processes on top need their own evidence.

Sector-specific frameworks. Healthcare workloads touch HIPAA and NHS requirements. Energy touches NERC CIP. Each adds its own controls and its own audit cadence.

Inherited vs shared vs your controls

Azure's compliance certifications cover the infrastructure. You inherit those. But most framework controls are shared or entirely yours: Microsoft certifies the datacentre, you still have to prove your access model, your encryption configuration, your audit logging, and your incident process. The Service Trust Portal gives you Microsoft's audit reports to inherit; Microsoft Purview Compliance Manager maps your own controls against frameworks and tracks the evidence. The mistake regulated businesses make is assuming Azure's certifications cover them. They cover the floor you build on, not the building.

Produce evidence continuously, not annually

The teams that struggle with audits are the ones that treat compliance as an event. The teams that pass treat it as a continuous output of how they operate. Azure Policy enforcing your control baseline produces a live compliance record. Defender for Cloud's regulatory compliance dashboard maps your posture against frameworks like PCI DSS and ISO 27001 in real time. Activity logs and sign-in logs retained in Log Analytics give you the who-did-what-when on demand. Built correctly, an audit becomes an export rather than a project.

In regulated markets, security is operational resilience

The throughline across DORA, FCA rules and NIS2 is the same: it is no longer enough to be secure, you must be demonstrably resilient and able to prove it under scrutiny. That means your security controls, your monitoring, and your evidence have to be one connected system, not three separate efforts. A control you cannot evidence is a finding. An incident you cannot reconstruct from logs is a reportable failure. The bar has moved from "are you secure" to "can you prove it, continuously, to a regulator."

Where Critical Cloud comes in

Running Azure security to this standard, then producing the evidence that regulated markets demand, while operating the platform reliably day to day, is most of a full-time function. We do it for businesses in financial services, insurance, healthcare and the public sector. As the world's first Powered by Datadog accredited partner, we run unified observability across the security and compliance layer, so the audit trail, the monitoring, and the evidence are one connected system rather than three. We are ISO 27001 certified and Cyber Essentials Plus accredited, so the standard we hold your environment to is the standard we hold our own. If proving compliance is pulling your team away from building, see how Critical Support works.