Theory — Compliance and Governance in the Cloud
Theory — Compliance and Governance in the Cloud
This page covers the core concepts behind Day 5's labs: compliance, governance, and how they relate to the security controls you'll use throughout the day.
Compliance vs Governance
These terms are often used interchangeably, but they mean different things:
| Compliance | Governance | |
|---|---|---|
| Question | "Can we prove we meet the standard?" | "Do our processes enforce the standard?" |
| Focus | Evidence collection | Process enforcement |
| Example | A report showing all storage accounts are encrypted | A policy that prevents creating unencrypted storage accounts |
| Timing | After the fact (auditable) | Before the fact (preventive) |
Think of it this way: compliance is proving; governance is enforcing.
A compliance report shows you what happened. A governance process makes sure things happen the right way in the first place. You need both — but governance is usually more effective because it prevents problems rather than documenting them after the fact.
Three Types of Security Controls
When designing governance, it helps to think in terms of three categories. Each answers a different question and uses different tools.
Preventive Controls — Stop Bad Things Before They Happen
Preventive controls block non-compliant actions at the point of creation or modification.
| Control | Example |
|---|---|
| Deny policies | Block creating storage accounts with public blob access |
| Require secure transfer | Deny HTTP-only API endpoints |
| Tag enforcement | Deny resources without required tags |
When to use: When the risk is high and the rule is clear-cut. Preventive controls don't just report — they stop.
Trade-off: Can break deployments if scoped too broadly. Always test in audit mode first.
Detective Controls — Report What Went Wrong
Detective controls flag non-compliance but allow the action to complete. They create an audit trail.
| Control | Example |
|---|---|
| Audit missing diagnostic settings | Flag resources without logging enabled |
| Audit public exposure | Report storage accounts with public access |
| Audit resources without required tags | Flag resources missing cost-centre or environment tags |
When to use: When you need visibility before committing to enforcement, or when the action is low-risk but needs to be tracked.
Trade-off: Doesn't stop bad things — relies on people noticing and fixing them.
Corrective Controls — Fix What Went Wrong Automatically
Corrective controls take action to bring non-compliant resources into compliance.
| Control | Example |
|---|---|
| Add missing tags | Automatically add cost-centre, environment, and managed_by (value: terraform) tags |
| Disable public blob access | Turn off public access on storage accounts |
| Re-enable diagnostics | Deploy diagnostic settings to resources that are missing them |
| Enable infrastructure encryption | Turn on infrastructure encryption on storage accounts |
When to use: When the fix is deterministic, low-risk, and you want to reduce manual work.
Trade-off: Can break things if the remediation is too aggressive. Always scope narrowly and test first.
Infrastructure encryption on Azure Storage
Infrastructure encryption is a specific Azure Storage feature that encrypts data at rest using an additional layer of encryption managed by Microsoft. When enabled, data is encrypted twice — once with your key (if you have one) and once with Microsoft's key. This is a compliance requirement for many frameworks (including ISO 27001 and SOC 2) in production environments.
When to use: Production storage accounts that hold sensitive or regulated data. Not typically required for development environments where data is non-sensitive.
Trade-off: Adds a small performance overhead. Enable only where the compliance requirement justifies it.
Choosing the Right Control Type
Rule of thumb: Start with detective controls. Move to corrective if the fix is safe and repetitive. Use preventive only when the risk justifies blocking user actions.
Citizen Development and Why Compliance Matters
Citizen development — non-IT professionals building applications, automating workflows, and deploying resources — has transformed how organisations operate. Power Automate flows, Azure Logic Apps, low-code apps on Power Apps, and self-service IaC via Terraform modules are all citizen development in practice.
But citizen development creates a compliance paradox:
The more people can deploy resources, the more ways there are for those resources to be misconfigured.
When only IT staff could provision infrastructure, compliance was enforced through gatekeeping — IT reviewed every deployment. Today, citizen developers need to move fast without waiting for IT approval. The answer isn't to slow them down; it's to shift compliance left — bake the rules into the platform so citizen developers can deploy safely by default.
Why This Is Different from Traditional Compliance
| Traditional (IT-only) | Citizen Development Era |
|---|---|
| IT reviews every deployment | Hundreds of deployments per day from non-IT teams |
| Compliance checked after the fact | Compliance must be enforced at creation time |
| Slow, manual processes | Automated guardrails that work the same way for everyone |
| IT is the bottleneck | Citizen developers own their resources but follow shared rules |
What Citizen Developers Need
Citizen developers don't need to become security experts. They need guardrails that make the right thing easy:
- Preventive controls stop them from creating risky configurations without blocking their workflow
- Detective controls tell them when something they deployed needs attention
- Corrective controls fix common issues automatically so they can focus on building
The goal isn't to prevent citizen development — it's to enable it safely. Azure Policy, automated remediation, and anomaly detection are the tools that make this possible. Without them, every new deployment becomes a potential compliance risk.
The LLM and GenAI Acceleration
LLMs and GenAI have dramatically accelerated citizen development — and with it, the compliance challenge. Where citizen development was once limited to non-IT professionals who could use low-code platforms, GenAI has extended it to every professional in the organisation:
- Natural language to infrastructure — ChatGPT and similar tools can generate Terraform configurations, Bicep templates, and ARM templates from plain English descriptions. A marketing manager can now provision a storage account with a prompt instead of writing IaC code.
- AI-assisted code generation — GitHub Copilot and similar tools let developers write application code, API endpoints, and data pipelines by describing what they want in natural language. The barrier to building custom applications has dropped to near zero.
- Automated workflow creation — Agents that can build automation flows, set up integrations, and orchestrate multi-step processes from conversational prompts. Power Automate Copilot is a prime example.
- Self-service analytics and dashboards — Natural language query tools let anyone create data visualisations and reports without writing SQL or KQL.
The result: the volume of infrastructure being deployed has multiplied exponentially, and the people deploying it are even less likely to know compliance implications.
Why GenAI Makes Compliance Harder
| Before GenAI | After GenAI |
|---|---|
| Citizen developers needed some technical skill to deploy resources | Anyone can deploy infrastructure with a chatbot |
| Deployments were slow and deliberate | AI-generated deployments are fast and numerous |
| IT could track who deployed what | Every team member can be a "deployer" |
| Compliance checks had time to catch issues | AI can generate hundreds of resources before a human reviews them |
| One misconfigured resource was a problem | Hundreds of misconfigured resources generated simultaneously |
The key insight: GenAI hasn't just increased the number of citizen developers — it's changed the nature of how they deploy. AI-generated infrastructure often lacks the context-awareness that an experienced IT professional would bring. A Terraform module generated by an LLM might work perfectly in dev but fail in prod because it doesn't know your organisation's specific requirements.
What This Means for Governance
The governance strategy that worked before GenAI is no longer sufficient:
- Gatekeeping is impossible — You can't review every AI-generated deployment. The volume is too high.
- Training is insufficient — You can't train every employee on every compliance standard. The scope is too broad.
- Reactive detection is too late — By the time you detect the violation, hundreds of resources may already be non-compliant.
The answer is the same as before but more critical than ever: shift compliance left. Define policies that enforce guardrails at creation time, automate remediation for what slips through, and use anomaly detection to catch patterns that automated tools missed. Compliance must be baked into the platform so that even AI-generated deployments are compliant by default.
Key Takeaways
- Compliance means proving you meet a standard; governance means enforcing rules that keep you compliant.
- The shared responsibility model means Microsoft certifies its infrastructure, but you configure your resources — and that configuration is where compliance lives.
- Manual compliance checking doesn't scale beyond a handful of resources.
- Citizen development has multiplied the number of people who can deploy infrastructure, making gatekeeping impossible.
- LLMs and GenAI have accelerated citizen development exponentially — anyone can now generate Terraform, Bicep, and automation flows from natural language.
- Governance must shift left: bake compliance into the platform so AI-generated and citizen deployments are compliant by default.
- Azure Policy provides the governance layer that prevents misconfigurations before they happen.
Sources
- Gartner definition of citizen developer — Gartner IT Glossary
- Azure Policy deny effect — Microsoft Learn