Designing a security and compliance plan. If you build a house without locks and a fire escape, you are asking for trouble. In Azure, this topic is about creating the digital rules, locks, and alarm systems that protect your company's data, plus proving to auditors and lawyers that you follow the law — without that plan, you risk data breaches, fines, and losing customer trust.
Jump to a section
A simple way to picture Designing a Security and Compliance Plan
You have just hired a contractor to renovate your kitchen. But what guarantees they won't copy your house key, or run the wiring so badly it starts a fire? What happens if the council inspector turns up and demands to see the permits?
Designing a security and compliance plan is like, before any work begins, you and the contractor sit down and decide exactly who gets a key to your house, which parts of the house they are allowed to enter, what safety standards the electrical work must meet (that is the security policy) and how you will prove to the council that all the permits were filed correctly (that is the compliance evidence). You also agree that if the contractor hires a plumber, that plumber only gets a temporary key that stops working the day the job finishes — just like expiring access credentials in Azure.
Without this plan, your contractor might use cheap, dangerous wires to save money. Without compliance documentation, the council could shut the whole project down. The plan is not the work itself — it is the rule book and the evidence file that makes the work safe and legally valid. In Azure, a security and compliance plan defines who can access what, how data is encrypted, and how you prove to auditors you are following regulations such as GDPR or HIPAA.
Security and compliance planning is the process of deciding, in advance, how you will protect your cloud resources and how you will prove you meet legal or industry requirements. It is not the same as implementing security tools — the plan comes first.
Let us break down the two halves. Security is about prevention, detection and response. You want to stop bad things from happening (like a hacker stealing customer credit card numbers), notice when they do happen (like detecting unusual login attempts), and have a playbook to fix the problem quickly. Compliance is about proving you follow rules. Those rules might come from your government (like the GDPR in Europe), from your industry (like PCI DSS for credit card data), or from your own company policies (like 'we never share customer data with third parties').
A security and compliance plan typically covers these core areas:
Identity and Access Management (IAM): who can sign in (authentication) and what they are allowed to do (authorisation). This uses tools such as Microsoft Entra ID (the new name for Microsoft Entra ID) and RBAC (Role-Based Access Control).
Data Protection: how data is encrypted at rest (when stored on a disk) and in transit (when travelling over the network). This uses Azure Key Vault or Azure Disk Encryption.
Network Security: how you isolate your resources from the public internet and from each other using firewalls, network security groups, and virtual networks.
Threat Detection: how Azure monitors for suspicious activity using services like Microsoft Defender for Cloud.
Compliance Controls: which standards you must meet (e.g., ISO 27001, SOC 2) and how you collect evidence that you meet them — often with Azure Policy and Microsoft Purview compliance portal.
Why does the plan matter? Imagine you work for a hospital. You store patient medical records in Azure. If you do not have a plan, you might accidentally leave a database open to the public internet. That is a security breach. Worse, you might not have the logs to show that you were encrypting the data properly. That is a compliance failure, and hospitals face massive fines for that.
The plan replaces guesswork. Before Azure, organisations would often install security software ad hoc, reacting to each new threat. That approach is expensive and leaves gaps. A plan is proactive: it maps out who can do what, how data flows, and how to respond when something goes wrong. It also makes audits much smoother. When an auditor asks 'show me how you control access to your financial data', you simply point to your plan and the evidence that you follow it, rather than scrambling to find logs.
In terms of AZ-400, Microsoft expects you to know how to design this plan for DevOps teams. That means considering how developers, testers, and operations people all need different levels of access, how code changes can introduce security risks, and how to automate compliance checks so that every new deployment is automatically scanned against your rules (this is called 'shift-left security' and 'policy-as-code' with Azure Policy).
A common beginner mistake is to think security is just the IT department's problem. In cloud environments, everyone who uses Azure shares responsibility. Microsoft secures the physical data centres. You secure what you put inside them — your applications, your data, and your user accounts. This is called the Shared Responsibility Model. Your plan must acknowledge both sides of that split.
Finally, the plan is a living document. You revisit it as your applications grow, as new threats emerge (like ransomware), and as regulations change (like new data privacy laws). It is not a one-time checkbox — it is a continuous cycle of assessment, improvement, and auditing.
Classify Your Data and Identify Regulations
List the types of data you store (e.g., customer names, credit cards, health records). Determine which regulations apply to each type (e.g., GDPR for European customers, PCI DSS for payment data). This step guides all later decisions about encryption and access controls.
Design Identity and Access Controls
Use Microsoft Entra ID to create user groups (developers, operators, auditors). Assign RBAC roles that grant only the minimum permissions each group needs (principle of least privilege). Set up Conditional Access to block sign-ins from untrusted locations and Privileged Identity Management for temporary admin access.
Write Azure Policies for Configuration Rules
Define policies that enforce required configurations, such as 'all storage accounts must have encryption enabled' or 'all VMs must use managed disks'. Assign these policies to subscriptions or management groups so any new resource is automatically checked (and blocked if non-compliant).
Enable Threat Detection and Monitoring
Turn on Microsoft Defender for Cloud to get a secure score and detect threats like suspicious logins or malware. Configure alerts to notify your security team. Set up Azure Monitor to collect and retain audit logs for compliance evidence.
Document an Incident Response Plan
Write down exactly what steps the team should take if a security incident occurs, including isolating affected resources, notifying stakeholders, collecting evidence, and reporting to regulators within required timeframes (e.g., 72 hours under GDPR). Practise the plan with tabletop exercises.
Review and Update the Plan Regularly
Schedule quarterly reviews to assess new Azure features, changes in regulations, and lessons learned from incidents. Update Azure Policies, adjust RBAC roles, and refine the incident response plan. This keeps your plan effective over time.
Here is a concrete scenario. Sarah is a cloud security engineer at a medium-sized e-commerce company called 'ShopNow'. The company processes credit card payments and stores customer names, addresses, and purchase history. They operate in Europe, so they must comply with GDPR. They also handle credit cards, so they must follow PCI DSS. Sarah's boss asks her to design a security and compliance plan for their new Azure environment.
Step one: Sarah inventories all the data. She identifies customer PII (Personally Identifiable Information) such as names and emails, and PCI data such as full credit card numbers (though ideally, those are handled by a third-party payment processor). She classifies this data as 'highly confidential' and decides it must be encrypted at rest and in transit.
Step two: Sarah designs identity controls. She uses Microsoft Entra ID to manage employee accounts. She creates three groups: Developers (need read/write access to code repos and dev databases), Operators (need admin access to production VMs but not code), and Auditors (read-only access to logs). She assigns Azure RBAC roles to each group. She also sets up Privileged Identity Management (PIM) so that operators must request temporary admin access for emergencies — they cannot just stay logged in as admins all day.
Step three: She writes Azure Policies. For example, a policy that says 'every storage account must have encryption enabled' and 'every virtual machine must use managed disks'. She also writes a policy that tags all resources with a 'compliance_standard' tag ('GDPR' or 'PCI'). If a developer tries to create a new database without encryption, Azure Policy automatically blocks the request or flags it as non-compliant.
Step four: Sarah sets up continuous compliance monitoring. She uses Microsoft Defender for Cloud to get a 'secure score' — a percentage that tells her how well her environment meets security best practices. She configures it to alert her if the score drops below a threshold. She also uses Microsoft Purview Compliance Manager to run automated checks against GDPR and PCI DSS controls.
Step five: Sarah documents everything in an incident response plan. If a data breach happens (e.g., an unauthorised login is detected), the plan says: (1) isolate the affected resource using network security groups, (2) notify the security team via a Teams channel, (3) collect logs from Azure Monitor, (4) determine the root cause, and (5) notify the relevant data protection authority within 72 hours (as required by GDPR).
What does Sarah actually do day-to-day? She does not just set it and forget it. She reviews quarterly reports from Azure Policy. She runs tabletop exercises with the team (walking through a simulated breach to see if the plan works). She updates policies when new Azure services are introduced. She also communicates with the legal team to ensure the plan aligns with new regulations.
The key tools she uses:
Microsoft Entra ID for identity management
Azure Policy for automated rule enforcement
Microsoft Defender for Cloud for threat monitoring and secure score
Microsoft Purview Compliance Manager for compliance posture
Azure Key Vault for storing secrets and encryption keys
Azure Monitor and Log Analytics for collecting audit logs
Without this plan, ShopNow would be flying blind. A single misconfigured storage account could leak millions of customer records, and without the compliance evidence, they could face GDPR fines of up to 4% of annual global turnover.
The AZ-400 exam tests 'Designing a Security and Compliance Plan' primarily through scenario-based questions. You will not be asked to recite a list of services. Instead, you will be given a business case — for example, 'A company is migrating to Azure and needs to comply with GDPR. They have a DevOps team. What should they implement?' The correct answer will involve a combination of Azure Policy, Microsoft Entra ID (not 'Microsoft Entra ID'), and Microsoft Defender for Cloud.
Specific concepts the exam loves to test:
The Shared Responsibility Model: you must know which security tasks are Microsoft's responsibility (physical security of data centres) and which are yours (managing user access, configuring network security, encrypting data). Traps often ask who is responsible for patching a virtual machine — the answer is you, the customer.
Role-Based Access Control (RBAC) vs. Azure Policy: RBAC controls who can do what (permissions for users). Azure Policy controls what resources are allowed to exist (rules about configurations). Beginners mix these up. Expect a question that says 'You need to ensure all VMs are tagged with a department. Which tool?' Answer: Azure Policy.
Microsoft Entra ID features: know the difference between Conditional Access (grant or block access based on conditions like location or device state) and Privileged Identity Management (just-in-time admin access). Both are part of identity security.
Compliance standards: you must know the names of major frameworks (GDPR, HIPAA, SOC 2, PCI DSS, ISO 27001) and which Azure services help satisfy them (Microsoft Purview Compliance Manager, Azure Policy built-in initiatives).
Data encryption: know the difference between 'encryption at rest' (Azure Storage Service Encryption) and 'encryption in transit' (TLS). Also know that Azure Key Vault is used to manage the keys.
Defender for Cloud secure score: exam questions ask how to improve the secure score. The answer is usually 'implement recommended security controls' or 'enable Defender for Cloud plans for all subscription resources'.
Traps to watch for:
'Who is responsible for enforcing compliance?' The exam will offer an answer about Microsoft being responsible. That is a trap — Microsoft provides the tools, but you are responsible for configuring them.
'Azure service that provides encryption key management.' The answer is Azure Key Vault, not Azure Information Protection (that is for classifying documents).
'How to ensure a developer cannot accidentally create a storage account without encryption.' The trap answer might be 'train the developer'. The real answer is 'create an Azure Policy that denies the creation of unencrypted storage accounts'.
Mixing up Azure Policy with RBAC: remember, RBAC is about user permissions, Policy is about resource rules.
Question types: multiple choice, multiple select (pick two or three correct answers), and drag-and-drop (order steps of an incident response plan, match compliance frameworks to their descriptions).
Key definitions to memorise:
Azure Policy: a service to create, assign, and manage policies that enforce rules for your resources.
RBAC: fine-grained access management for Azure resources.
Microsoft Entra ID: Microsoft's cloud-based identity and access management service.
Privileged Identity Management (PIM): just-in-time privileged access to Azure resources.
Shared Responsibility Model: the division of security tasks between Microsoft and the customer.
Microsoft Defender for Cloud: a unified infrastructure security management system that strengthens the security posture and provides threat detection.
Azure Key Vault: a cloud service for securely storing and accessing secrets.
Microsoft Purview Compliance Manager: a solution for managing compliance requirements and assessing compliance posture.
A security and compliance plan defines who can access what, how data is protected, and how you prove you follow regulations.
The Shared Responsibility Model means Microsoft secures the physical data centres, but you must secure your own data, identities, and configurations.
Azure Policy enforces rules about resource configurations, while Azure RBAC controls user permissions.
Microsoft Entra ID is the foundation for identity security, including features like Conditional Access and Privileged Identity Management.
Compliance is not optional — failing to meet standards like GDPR or PCI DSS can result in massive fines and loss of customer trust.
Your security plan must be a living document, reviewed and updated continuously as threats and regulations evolve.
Automated tools like Azure Policy and Microsoft Defender for Cloud help to enforce rules and detect threats in real time, reducing human error.
Encryption protects data at rest and in transit, but compliance requires additional controls such as audit logging and breach response plans.
These come up on the exam all the time. Here's how to tell them apart.
Azure Policy
Enforces rules about resource configurations (e.g., 'all VMs must use managed disks').
Acts on the resource itself during creation or modification.
Is inherited by resource hierarchy (management group, subscription, resource group).
RBAC (Role-Based Access Control)
Controls user permissions (e.g., 'user A can delete VMs in this resource group').
Acts on the user or service principal accessing the resource.
Scope can be management group, subscription, resource group, or individual resource.
Microsoft Entra ID (Identity)
Manages user identities, authentication (sign-in), and authorisation (permissions).
Handles features like Conditional Access and Multi-Factor Authentication.
Stores and authenticates user accounts and service principals.
Azure Key Vault (Secrets Management)
Manages secrets like passwords, connection strings, and encryption keys.
Provides hardware security module (HSM) backed encryption key storage.
Does not authenticate users; applications retrieve secrets from it.
Encryption at Rest
Protects data when it is stored on disk or in a database (e.g., Azure Storage Service Encryption).
Ensures data is unreadable if physical disks are stolen or accessed offline.
Is often enabled by default in Azure storage services.
Encryption in Transit
Protects data when it moves over a network (e.g., HTTPS/TLS between client and server).
Prevents eavesdropping and man-in-the-middle attacks during data transfer.
Must be explicitly configured on endpoints (e.g., 'enforce TLS' on a web app).
Microsoft Defender for Cloud (Secure Score)
Focused on security posture: checks for misconfigurations, missing patches, open ports.
Provides a 'secure score' percentage based on implemented security controls.
Recommends actions to improve security, such as enabling MFA or installing endpoint protection.
Microsoft Purview Compliance Manager (Compliance Score)
Focused on compliance against specific regulations (GDPR, SOC 2, etc.).
Provides a 'compliance score' based on how many controls of a regulation are satisfied.
Includes built-in assessments and tasks to meet regulatory requirements (e.g., 'document data retention policy').
Conditional Access
Controls whether a user can sign in based on conditions (location, device state, risk level).
Can block or grant access to any cloud application using Microsoft Entra ID.
Works for all users (not just admins).
Privileged Identity Management (PIM)
Controls temporary admin access to Azure resources (just-in-time).
Requires users to activate a role for a limited time (e.g., 1 hour) to perform admin tasks.
Applies only to privileged roles, not regular users.
Mistake
Security and compliance are the same thing, so if I secure my data, I am automatically compliant.
Correct
Security is about protecting data; compliance is about proving you follow specific regulations. You can have strong security but still fail a compliance audit if you lack the documentation or specific controls a regulation demands (e.g., requiring encryption in a specific way).
Many beginners use the terms 'security' and 'compliance' interchangeably because both involve rules and controls. They do not realise compliance often requires specific evidence (e.g., audit logs) that pure security measures might not generate.
Mistake
Once I set up Azure Policies and RBAC, my security and compliance plan is done and does not need updating.
Correct
A security and compliance plan is a living document. Threats, regulations, and your own applications evolve. You must regularly review policies, update them when new Azure services appear, and reassess risks. It is a continuous cycle.
Newcomers often think of compliance as a one-off certification (like passing an exam) rather than an ongoing obligation. They overlook that regulations like GDPR require continuous monitoring and periodic reviews.
Mistake
Microsoft is responsible for all security in the cloud, so I do not need to worry about access controls.
Correct
Under the shared responsibility model, Microsoft secures the physical infrastructure, but you secure your accounts, data, and configurations. If you leave a storage account open to the public, that is your fault, not Microsoft's.
This misconception comes from a misunderstanding of the cloud. Because Microsoft 'runs' Azure, beginners assume they handle everything. They do not grasp that the customer must still configure identity, network, and data security settings.
Mistake
Azure Policy and RBAC are the same thing — both control access to resources.
Correct
RBAC controls who can do what (permissions for users and groups). Azure Policy controls what resources are allowed to exist or how they must be configured (rules about resource properties). They serve different purposes and are often used together.
Both services have the word 'policy' or 'role' which confuses beginners. They see that both can deny actions, but fail to understand that RBAC denies user actions on resources, while Azure Policy denies the creation or modification of non-compliant resources.
Mistake
Encryption alone makes my organisation compliant with regulations like GDPR.
Correct
Encryption is a strong security measure and often required by regulations, but compliance is broader. It also covers data retention policies, data subject access rights, breach notification procedures, and more. Encryption is just one control among many.
Beginners tend to focus on the most technical and visible control (encryption) and assume it ticks the compliance box. They do not yet appreciate the full scope of regulatory requirements, such as documenting data processing activities or obtaining consent.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Azure Policy enforces rules about how resources are configured (e.g., 'every VM must use managed disks'), while RBAC controls who can do what with those resources (e.g., 'only the admin group can delete VMs'). Both are used together in a security plan.
Not necessarily. You can design a single security plan that meets multiple regulations by identifying common controls (like encryption and access control) and then layering specific requirements (like GDPR breach notification) on top. Tools like Microsoft Purview Compliance Manager help map controls to multiple regulations.
Yes, Microsoft Entra ID is the new name for Azure Active Directory. They are the same service. The new name was introduced in 2023 to reflect the broader identity capabilities beyond Azure.
You are responsible. Microsoft patches the hypervisor (the underlying host), but the operating system inside your VM is your responsibility. You can use Azure Update Manager or automation to schedule patching.
Privileged Identity Management (PIM) provides just-in-time admin access. Instead of giving someone permanent admin rights, PIM allows them to request access for a limited time (e.g., 1 hour). This reduces the risk of a compromised admin account.
Azure provides compliance offerings like ISO 27001 certifications for its data centres. For your own environment, you use Azure Policy to enforce rules, Azure Monitor to collect logs, and Microsoft Purview Compliance Manager to generate compliance reports you can share with auditors.
Microsoft is responsible for the security of the cloud (physical data centres, network infrastructure). You are responsible for security in the cloud (your data, user accounts, configurations, and applications). If you misconfigure a database and leak data, it is your fault.
You've finished Designing a Security and Compliance Plan. Continue through the AZ-400 study guide to build a complete picture of the exam.
Done with this chapter?