Regulated industries — healthcare, financial services, insurance, energy — face a unique challenge with cloud adoption. The benefits of cloud are compelling (scalability, managed services, global reach), but the regulatory requirements are non-negotiable. Getting cloud security wrong means compliance failures, fines, and loss of customer trust.
This guide covers the security architecture that regulated industries need in the cloud, based on real implementations across multiple regulatory frameworks.
The Shared Responsibility Model
Every cloud security failure starts with a misunderstanding of who is responsible for what.
| Layer | IaaS (VMs) | PaaS (App Service, SQL) | SaaS (M365, Dynamics) |
|---|---|---|---|
| Physical security | Provider | Provider | Provider |
| Network infrastructure | Provider | Provider | Provider |
| Host OS / hypervisor | Provider | Provider | Provider |
| Network controls | Customer | Shared | Provider |
| Application | Customer | Customer | Provider |
| Identity & access | Customer | Customer | Customer |
| Data classification | Customer | Customer | Customer |
| Data encryption | Customer | Shared | Shared |
The critical insight: You are always responsible for your data, your identities, and your access controls — regardless of the cloud service model. Moving to the cloud doesn't transfer these responsibilities.
Security Layers
Layer 1: Identity and Access
Identity is the new perimeter. In cloud architecture, network boundaries are porous — identity controls are your primary defence.
Non-negotiable controls:
- Multi-factor authentication for all users, no exceptions
- Conditional Access policies (location, device compliance, risk level)
- Privileged Identity Management — just-in-time activation for admin roles
- Service accounts use managed identities (no stored secrets)
- Regular access reviews (quarterly for privileged access, annually for all)
For regulated industries specifically:
- Segregation of duties enforced through RBAC (no single person can approve and deploy)
- Break-glass procedures documented, tested, and monitored
- Admin actions logged to a tamper-proof audit log
- External identity access (partners, vendors) through B2B with strict conditional access
Layer 2: Network Security
Defence in depth:
Internet
│
┌───▼───────────────┐
│ DDoS Protection │ ← Volumetric attack mitigation
├───────────────────┤
│ WAF / Front Door │ ← Application-layer protection
├───────────────────┤
│ Azure Firewall │ ← Network-layer filtering, TLS inspection
├───────────────────┤
│ NSGs (per subnet) │ ← Microsegmentation
├───────────────────┤
│ Private Endpoints │ ← No public exposure for PaaS services
└───────────────────┘
Key principles:
- Private by default. PaaS services (databases, storage, key vaults) use Private Link. No public endpoints.
- Microsegmentation. NSGs on every subnet. Deny by default, allow by exception.
- East-west inspection. Traffic between subnets routes through Azure Firewall for inspection.
- Zero public IP. Virtual machines should never have public IP addresses. Access through Azure Bastion or VPN.
Layer 3: Data Protection
Encryption at rest:
- All storage encrypted by default (Azure Storage Service Encryption, Transparent Data Encryption for SQL)
- Customer-managed keys (CMK) in Azure Key Vault for sensitive workloads — required by some regulations
- Key rotation automated on a defined schedule (90 days for high-sensitivity keys)
Encryption in transit:
- TLS 1.2 minimum for all connections
- Certificate management through Azure Key Vault or App Service Certificates
- Internal service-to-service communication encrypted (mutual TLS for service mesh)
Encryption in use (Confidential Computing):
- For the most sensitive workloads, Azure Confidential Computing protects data while it's being processed
- Uses hardware-based Trusted Execution Environments (TEEs)
- Relevant for multi-party computation, sensitive data processing, and key management
Layer 4: Application Security
- Container images scanned for vulnerabilities before deployment
- Runtime protection (Microsoft Defender for Containers)
- API security (authentication, rate limiting, input validation)
- Dependency scanning in CI/CD pipeline (SCA tools)
- SAST/DAST integrated into deployment pipeline
Layer 5: Monitoring and Response
Security monitoring stack:
- Microsoft Sentinel: SIEM for security event collection, correlation, and alerting
- Microsoft Defender for Cloud: CSPM (Cloud Security Posture Management) and workload protection
- Log Analytics: Centralised log storage and query
- Azure Monitor: Performance and availability monitoring
Incident response:
- Detection: Automated alerting from Sentinel analytics rules
- Triage: Severity classification and assignment
- Investigation: Timeline reconstruction, impact assessment
- Containment: Isolation procedures for compromised resources
- Recovery: Restoration from known-good state
- Post-incident: Root cause analysis, control improvements
Compliance Mapping
| Requirement | SOC 2 | ISO 27001 | HIPAA | PCI DSS | NIS2 | DORA |
|---|---|---|---|---|---|---|
| Access controls | CC6.1-6.8 | A.9 | §164.312(a) | Req 7-8 | Art 21(2)(d) | Art 9 |
| Encryption | CC6.1, CC6.7 | A.10 | §164.312(a)(2)(iv) | Req 3-4 | Art 21(2)(e) | Art 9(2) |
| Logging/monitoring | CC7.1-7.4 | A.12 | §164.312(b) | Req 10 | Art 21(2)(f) | Art 10 |
| Incident response | CC7.3-7.5 | A.16 | §164.308(a)(6) | Req 12.10 | Art 23 | Art 17 |
| Risk assessment | CC3.1-3.4 | A.8, A.12.6 | §164.308(a)(1) | Req 6.1 | Art 21(1) | Art 6 |
| Business continuity | CC9.1 | A.17 | §164.308(a)(7) | Req 12.10 | Art 21(2)(c) | Art 11 |
The good news: these frameworks overlap significantly. A strong security baseline satisfies 70-80% of requirements across all frameworks. The remaining 20-30% is framework-specific documentation and process requirements.
Practical Implementation Priority
Month 1: Foundation
- Enable MFA and Conditional Access for all users
- Deploy Azure Firewall and configure default-deny rules
- Enable Private Link for all PaaS services
- Enable Microsoft Defender for Cloud (all plans)
- Configure diagnostic settings for all resources
Month 2: Hardening
- Implement Privileged Identity Management
- Deploy NSGs on all subnets
- Configure customer-managed encryption keys for sensitive data
- Enable Sentinel with core detection rules
- Implement automated vulnerability scanning
Month 3: Compliance
- Complete compliance assessment against target framework(s)
- Remediate identified gaps
- Implement automated compliance monitoring
- Document security controls and evidence
- Conduct initial penetration test
Cloud security architecture for regulated industries requires a systematic, layered approach. The investment is significant, but the alternative — a compliance failure or security breach in a regulated environment — is orders of magnitude more costly. If you need help designing cloud security for regulated workloads, let's talk.