Compliance & Identity Governance
Azure Policy for compliance at scale, plus Privileged Identity Management, access reviews, and entitlement management — the governance layer that keeps your Azure environment audit-ready.
Why compliance and identity governance matter
Compliance is the rulebook. Identity governance is the referee.
Azure Policy enforces rules across your resources: “All storage must be encrypted,” “VMs must be in approved regions,” “Public endpoints are not allowed.” These rules run continuously — not just at deployment time.
Identity governance controls WHO has access and for HOW LONG: “Admins only get privileges when they need them (PIM),” “Guest access is reviewed every 90 days,” “New employees automatically get the right access packages.”
Azure Policy: compliance at scale
Policy effects
| Effect | What Happens | When to Use |
|---|---|---|
| Deny | Blocks the resource operation | Hard guardrails — “MUST NOT happen” |
| Audit | Allows operation but creates compliance entry | Visibility — “should not happen, but don’t block yet” |
| Modify | Changes resource properties at create/update | Auto-remediate — “fix it for them” |
| DeployIfNotExists | Deploys a companion resource if missing | Auto-configure — “if VM exists, deploy agent” |
| Append | Adds properties to a resource | Add fields — “force HTTPS on storage accounts” |
| Disabled | Policy exists but isn’t enforced | Testing, temporary exclusion |
Exam tip: Deny vs Audit for new vs existing resources
New deployments: Start with Audit to understand what would break, then switch to Deny once teams are ready.
Existing resources: Policies with Deny effect only block new operations. Existing non-compliant resources are flagged but not changed. Use Modify or DeployIfNotExists with a remediation task to fix existing resources.
The exam often tests this: “You apply a Deny policy for encryption. Will existing unencrypted storage accounts be blocked?” Answer: No — they’ll be flagged as non-compliant but continue working. New storage accounts will be blocked.
Policy initiatives for regulatory compliance
Instead of managing individual policies, use initiatives (policy sets) that map to compliance frameworks:
| Initiative | Framework | What It Covers |
|---|---|---|
| CIS Microsoft Azure Foundations | CIS Benchmark | 200+ controls: identity, networking, logging, storage, databases |
| NIST SP 800-53 Rev. 5 | US Government | Comprehensive security and privacy controls |
| ISO 27001:2013 | International | Information security management |
| PCI DSS v4.0 | Payment Card Industry | Cardholder data protection |
| Azure Security Benchmark | Microsoft | Best practices across all Azure services |
🏦 Elena’s compliance stack: FinSecure Bank assigns three initiatives at the management group level:
- PCI DSS v4.0 — mandatory for any subscription handling payment data
- CIS Azure Foundations — baseline for all subscriptions
- Custom initiative — bank-specific requirements (data residency, approved regions, encryption standards)
All three are assigned in Audit mode during rollout, then promoted to Deny after a 30-day compliance assessment.
Compliance dashboards
| Tool | What It Shows | Best For |
|---|---|---|
| Azure Policy compliance | Policy-level compliance percentage per scope | Day-to-day governance operations |
| Microsoft Defender for Cloud | Secure score, regulatory compliance dashboard | Executive reporting, security posture |
| Azure Resource Graph | Query all resources and their compliance state | Custom reports, automation, cross-subscription queries |
Identity governance with Entra ID P2
Identity governance answers three questions: WHO has access? SHOULD they still have it? HOW do they get new access?
Privileged Identity Management (PIM)
| Factor | Permanent Role Assignment | PIM Just-In-Time (JIT) |
|---|---|---|
| Access duration | Always active — 24/7 | Time-bound — 1-24 hours (configurable) |
| Activation | None — always has permissions | User must activate and justify the request |
| Approval | None required | Optional — require manager/security team approval |
| MFA | Depends on CA policy | Required at activation |
| Audit trail | Assignment logged, usage hard to track | Full trail: who activated, when, why, what they did |
| Blast radius | Large — compromised account always has privileges | Minimal — privileges expire, attacker window is narrow |
| Best for | Break-glass accounts only | All admin roles in production |
🏛️ David’s PIM design for government: CloudPath Advisory’s standard:
- Global Administrator: PIM-eligible only, 2-person approval, 4-hour max activation, MFA required
- Subscription Contributor: PIM-eligible, self-approval with justification, 8-hour max
- Reader roles: Permanent (low risk, read-only)
- Break-glass accounts (2): Permanent Global Admin, excluded from all Conditional Access, stored in physical safe
Design decision: PIM for Azure resources too
PIM isn’t just for Entra ID roles — it also works for Azure resource roles (RBAC). You can make someone “eligible” for Owner on a subscription and require activation with justification.
Design pattern: Developers are permanent Readers but eligible Contributors. They activate Contributor when they need to deploy, and it expires after 4 hours.
Access reviews
| Setting | Description | Recommended |
|---|---|---|
| Frequency | How often reviews occur | Quarterly for most roles, monthly for privileged |
| Scope | Which assignments to review | All members of a group, all guests, specific role assignments |
| Reviewer | Who decides to approve/deny | Resource owner, manager, or self-review |
| Auto-apply | What happens if reviewer doesn’t respond | Remove access (default safe) or keep access |
| Duration | How long reviewers have to complete | 14-30 days |
🏗️ Priya’s access review strategy:
- Guest access: Quarterly review — sponsoring employee must confirm each guest still needs access
- Privileged roles: Monthly review — security team validates all PIM-eligible assignments
- Application access: Quarterly — application owners review who has access to their apps
- Auto-apply: Non-responses default to “remove access” (fail-safe)
Entitlement management
Entitlement management creates access packages — bundles of groups, apps, and sites that users can request through self-service.
| Component | Description |
|---|---|
| Access package | Bundle: “Marketing team access” = SharePoint site + Teams team + Power BI workspace |
| Catalog | Container for access packages — organised by department or project |
| Policy | Who can request, who approves, how long it lasts, auto-renewal rules |
| Connected organisations | External orgs whose users can request access packages |
🚀 Marcus’s use case: When NovaSaaS hires a new developer:
- Developer requests the “Engineering Access Package” from the self-service portal
- Package includes: GitHub org membership, Azure DevOps project, shared Key Vault, dev subscription Contributor role
- Manager approves automatically (pre-approved for Engineering department)
- Access expires after 365 days, auto-renewal with manager re-approval
Knowledge check
🏦 Elena needs to ensure all Azure Storage accounts across FinSecure Bank's 20 subscriptions use encryption with customer-managed keys. Existing storage accounts that don't comply should be flagged but not disrupted. New storage accounts must comply or be blocked. Which policy approach should she recommend?
🏛️ David's government client has 15 users with Global Administrator privileges — all permanently assigned. The security audit requires: only 2 break-glass accounts should have permanent admin access, all others must activate when needed with approval. Which solution should David recommend?
🎬 Video coming soon
Domain 1 complete! You’ve designed monitoring, authentication, identity management, authorization, secrets management, governance, and compliance for your Azure architecture.
Next up: Now let’s design where your data lives — Relational Data: Choosing Your SQL Platform.