Fix Microsoft Compliance Regulatory Errors & Misconfigs
Why This Is Happening
You've just been handed a compliance audit deadline. Maybe your security team flagged a gap in your Azure environment against the CIS Microsoft Azure Foundations Benchmark. Maybe your organization is trying to meet HIPAA, SOC 2, or GDPR requirements and the Azure Policy dashboard is showing a wall of red "non-compliant" resources. Or , and I've seen this more times than I can count , someone ran a CIS Benchmark assessment tool and got back 200+ failing checks with zero guidance on what actually matters.
I know exactly how this feels. The error messages Microsoft surfaces in the compliance center are technical, terse, and often point you to documentation that assumes you already understand what went wrong. That's a rough place to start when your organization's certification or a regulator's audit is on the line.
Here's the core problem: Microsoft's compliance regulatory framework covers an enormous surface area. We're talking about global standards like ISO 27001, SOC 1, SOC 2, and SOC 3. US government frameworks like FedRAMP, FIPS 140-2, NIST 800-171, and DoD IL2/IL5. Industry-specific mandates like HIPAA/HITECH, PCI-DSS, HITRUST, FERPA, and GLBA. And regional regulations spanning GDPR in the EU, IRAP in Australia, ISMAP in Japan, MeitY in India, and dozens more. When a policy scan returns non-compliant results, the system doesn't tell you which regulatory framework you're actually violating or how severe the gap is in practice.
The other reason this gets so messy: configuration drift. Your Azure environment might have been fully compliant when it was first deployed using an Azure Blueprint or ARM template, but resources get added, settings get changed, and suddenly you're out of alignment with the CIS Level 1 or Level 2 baseline you were targeting, and nobody noticed until the audit.
There's also genuine confusion about the difference between Microsoft's compliance attestations (things Microsoft has certified itself) versus what you as a customer need to configure and maintain. Microsoft holds SOC 2, ISO 27001, and FedRAMP authorizations for its cloud platforms, but your workloads running on those platforms still need to meet the relevant controls on your end. That shared responsibility model is where most organizations fall through the cracks.
The good news: most of the common Microsoft compliance regulatory misconfigurations follow predictable patterns, and the fixes are repeatable once you know where to look. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If you're staring at a non-compliant status in Microsoft Defender for Cloud (formerly Azure Security Center) and need to understand what's actually failing before doing anything else, start here. This single step clears up about 60% of the confusion I see with Microsoft compliance regulatory setup problems.
Open the Azure portal and navigate to Microsoft Defender for Cloud → Regulatory Compliance. You'll see your active compliance standards listed, typically the Microsoft cloud security benchmark is enabled by default, but your org may also have added CIS Microsoft Azure Foundations Benchmark, SOC 2, or others.
Click on the failing standard. You'll see controls broken into domains. Look at the "Failed resources" column first, sort by it descending. The controls at the top with the most failed resources are your highest-priority items. Don't try to fix everything at once. That's how you end up breaking production.
For each failing control, click into it. Microsoft shows you the exact resource name, the subscription it lives in, and, this is the key part most people miss, a "Remediation steps" link in the right panel. That link gives you the specific setting or policy you need to change.
For quick wins that apply to nearly every environment: enable Microsoft Defender for Servers if it's off (this resolves a large cluster of HIPAA, SOC 2, and CIS controls simultaneously), turn on Azure Policy Guest Configuration for your VMs, and make sure Diagnostic Settings are enabled on your Key Vaults, Storage Accounts, and Network Security Groups. These three categories alone account for a disproportionate share of compliance failures across the frameworks Microsoft supports.
Run this PowerShell to quickly pull a list of all non-compliant resources across your subscriptions so you have a full picture before touching anything:
Get-AzPolicyState `
-Filter "ComplianceState eq 'NonCompliant'" `
| Select-Object ResourceId, PolicyDefinitionName, ComplianceState `
| Sort-Object PolicyDefinitionName `
| Export-Csv -Path "C:\compliance-gaps.csv" -NoTypeInformationOpen that CSV and sort by PolicyDefinitionName. You'll quickly see which policies are flagging the most resources, those are your batched fixes.
This sounds obvious but it's the most common miss: before anything shows up as non-compliant in Defender for Cloud, you have to explicitly assign the compliance standard you're targeting. Microsoft doesn't automatically enroll you in HIPAA or PCI-DSS assessments just because you're running healthcare or payment workloads.
Go to Microsoft Defender for Cloud → Environment settings → [your subscription] → Security policies. You'll see a list of available standards. The ones with a toggle on the right can be enabled directly. For standards like CIS Microsoft Azure Foundations Benchmark, FedRAMP High, NIST SP 800-53, HIPAA/HITECH, PCI-DSS, ISO 27001, and SOC 2, flip the toggle to On.
If the standard you need isn't listed, you may need to add it as a custom initiative. Go to Policy → Definitions → Initiatives and search for the standard by name. Assign it to your subscription or management group scope depending on how many subscriptions need to be in scope for your audit.
After enabling, give it 30–60 minutes for the initial assessment to run across your resources. Don't panic if you see a compliance percentage of 20–40% when you first enable a new standard, that's completely normal for an environment that hasn't been explicitly hardened. What you're looking for is a baseline, not perfection.
# Assign CIS Azure Foundations Benchmark via PowerShell
$definition = Get-AzPolicySetDefinition `
-Name "1a5bb27d-173f-493e-9568-eb56638dde4d"
New-AzPolicyAssignment `
-Name "CIS-Azure-Foundations" `
-DisplayName "CIS Microsoft Azure Foundations Benchmark" `
-Scope "/subscriptions/" `
-PolicySetDefinition $definition When it's working correctly, the Regulatory Compliance dashboard will refresh and start populating control pass/fail counts within about an hour.
The Center for Internet Security benchmark is where most organizations should start their Microsoft compliance regulatory hardening work. CIS benchmarks exist specifically for Microsoft Azure Foundations, Microsoft 365 Foundations, Windows 11, and Windows Server 2022, and Microsoft was an active partner in developing all of them through the consensus review process.
CIS benchmarks define two levels. Level 1 is your essential baseline, security settings that should be applied to any system with minimal risk of breaking functionality. Level 2 is for higher-security environments and may restrict some features. For most organizations starting their compliance journey, Level 1 is the target.
The most commonly failing CIS Level 1 controls in Azure environments fall into these categories:
Identity and Access Management: Multi-factor authentication (MFA) must be enabled for all users with subscription owner or contributor roles. Navigate to Azure Active Directory → Security → Multi-Factor Authentication → Additional cloud-based MFA settings. Make sure MFA is enforced, not just enabled.
Storage Security: Secure transfer must be required on all storage accounts. In the portal: Storage accounts → [account] → Configuration → Secure transfer required: Enabled. You can fix this at scale with:
Get-AzStorageAccount | Where-Object {
$_.EnableHttpsTrafficOnly -eq $false
} | ForEach-Object {
Set-AzStorageAccount `
-ResourceGroupName $_.ResourceGroupName `
-Name $_.StorageAccountName `
-EnableHttpsTrafficOnly $true
}Key Vault: Expiration dates must be set on all secrets, keys, and certificates. This is a blanket CIS requirement. Go to Key Vaults → [vault] → Secrets/Keys/Certificates and verify every object has a defined expiration. There's no bulk fix for this, it must be done per object or scripted through the Key Vault SDK.
When CIS Level 1 controls pass in your compliance dashboard, you'll see the associated control IDs turn green in the Regulatory Compliance view. Each passing control reduces your overall compliance gap score.
Across nearly every compliance framework Microsoft supports, SOC 2, HIPAA, ISO 27001, NIST CSF, FedRAMP, there is a common thread: you must prove that audit logging was active and that the logs were retained for a sufficient period. This is one of the most frequently cited gaps in audits I've seen, and it's almost always a configuration problem rather than a licensing problem.
First, confirm that Azure Monitor Diagnostic Settings are enabled for the critical resource types. The minimum set for most standards is: Azure Active Directory sign-in logs, Azure Activity Logs (subscription level), Key Vault audit logs, Network Security Group flow logs, and SQL Database audit logs.
Go to Monitor → Diagnostic settings. For each resource that lacks a diagnostic setting, click the resource name and then Add diagnostic setting. Route logs to a Log Analytics workspace (preferred for querying) and optionally to a Storage Account for long-term retention.
# Enable diagnostic settings on a Key Vault via PowerShell
$kv = Get-AzKeyVault -VaultName "MyVault" -ResourceGroupName "MyRG"
Set-AzDiagnosticSetting `
-ResourceId $kv.ResourceId `
-WorkspaceId "/subscriptions//resourceGroups//providers/Microsoft.OperationalInsights/workspaces/" `
-Enabled $true `
-Category "AuditEvent" For retention: HIPAA and HITECH require audit logs to be retained for a minimum of 6 years. SOC 2 and ISO 27001 typically require at least 1 year. FedRAMP requires 3 years for some log categories. Set your Log Analytics workspace retention under Log Analytics workspaces → [workspace] → Usage and estimated costs → Data retention. The default is 30 days, almost certainly not enough for any regulated environment.
When this step is complete, your SOC 2 CC7 and ISO 27001 A.12.4 controls should start showing as compliant in the Regulatory Compliance dashboard within the next assessment cycle.
Once you've identified your non-compliant resources, the question is how to fix them efficiently. For environments with dozens or hundreds of resources, manual portal-clicking is not a real option. Azure Policy has a built-in remediation task system that can apply fixes automatically for policies that support the DeployIfNotExists or Modify effect.
Go to Policy → Compliance. Filter by Non-compliant. For each non-compliant policy definition, check whether a Remediation task button is available in the top toolbar. If it is, the policy supports automated remediation. Click it, review the scope (make sure you're not remediating resources outside your intended scope), and create the task.
Remediation tasks run asynchronously. You can monitor them under Policy → Remediation → Remediation tasks. Watch for tasks that fail, they'll show a Failed resources count. Click into failed tasks to get the specific error. Common reasons: missing RBAC permissions on the managed identity that Policy uses, resources in a locked resource group, or resources in a region the policy doesn't support.
If you need to trigger remediations programmatically:
Start-AzPolicyRemediation `
-Name "remediation-enable-mfa" `
-PolicyAssignmentId "/subscriptions//providers/Microsoft.Authorization/policyAssignments/SecurityCenterBuiltIn" `
-ResourceDiscoveryMode ReEvaluateCompliance For policies that don't support automated remediation (most Audit effect policies), you'll need to remediate the resource directly. In those cases, the Remediation steps section inside each policy definition in the portal tells you the exact setting to change. Follow it precisely, these steps are derived from the official CIS and regulatory control requirements.
After remediation tasks complete, trigger a fresh compliance evaluation: Policy → Compliance → [your initiative] → Re-evaluate. Results update within 30 minutes typically.
If you're setting up a new environment or want to ensure future deployments start from a compliant baseline, Azure Blueprints is the right tool. Microsoft publishes an official Azure Blueprint specifically for the CIS Microsoft Azure Foundations Benchmark that deploys a pre-configured set of Azure Policy assignments, role-based access controls, and resource configurations aligned to CIS controls.
Go to Blueprints → Blueprint definitions → + Create blueprint. On the "Choose a blueprint sample" screen, search for CIS Microsoft Azure Foundations Benchmark. Select it and click Use this sample. Give it a name, select a definition location (your management group or subscription), and click Next: Artifacts.
Review the artifacts, you'll see policy assignments, role assignments, and resource group configurations that will be deployed. You can customize which artifacts to include if some don't apply to your environment. Click Save draft, then Publish blueprint (assign a version like 1.0).
To assign the blueprint to a subscription:
# Assign blueprint via PowerShell
$blueprint = Get-AzBlueprint `
-ManagementGroupId "" `
-Name "CIS-AzureFoundations" `
-Version "1.0"
New-AzBlueprintAssignment `
-Name "CIS-Assignment-Prod" `
-Blueprint $blueprint `
-SubscriptionId "" `
-Location "eastus" `
-Parameter @{} Once assigned, resources provisioned through this Blueprint are automatically evaluated against the CIS controls. The blueprint enforces policy through Azure Policy, meaning non-compliant resource deployments are blocked before they ever go live, not discovered after the fact. This is fundamentally different from reactive compliance scanning, and it's the model mature compliance programs operate on.
You should see the blueprint assignment status as Succeeded in Blueprints → Assigned blueprints within 10–20 minutes of assignment.
Advanced Troubleshooting
When the standard remediation steps don't resolve your Microsoft compliance regulatory gaps, you're usually dealing with one of three deeper scenarios: Group Policy conflicts on domain-joined machines, custom or legacy resources that Azure Policy can't reach, or framework-specific requirements that the portal UI doesn't surface clearly.
Group Policy Conflicts (Windows Endpoints): If you're trying to align Windows 11 or Windows Server 2022 machines to the CIS benchmark and your Azure Policy Guest Configuration is reporting failures even after remediation, the issue is often that local or domain Group Policy settings are overriding the desired configuration. Open the Group Policy Management Console (gpmc.msc) and run gpresult /h C:\gpresult.html on the affected machine. Open the HTML report and look at the Applied GPOs section. Any policy applied from a domain GPO takes precedence over Azure Policy Guest Configuration for on-premises settings. You'll need to align your domain GPOs with the CIS benchmark settings, specifically the Windows Security Settings under Computer Configuration.
Event Viewer for Policy Failures: On Windows machines, compliance configuration failures often log to Event Viewer under Applications and Services Logs → Microsoft → Windows → DSC → Operational. Look for Event IDs 4103 (module execution failed) and 4104 (script block logging). These give you the exact DSC configuration that failed to apply and why. This is far more informative than the Azure portal's generic "non-compliant" status.
FIPS 140-2 Compliance Conflicts: Organizations targeting US government frameworks like FedRAMP or DoD IL2/IL5 need FIPS 140-2 compliant cryptography across their environment. Enabling FIPS mode on Windows (HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy\Enabled = 1) can break applications that use non-FIPS cryptographic algorithms. Before enabling this registry key, audit your application stack for MD5, RC4, DES, or 3DES usage. Applications using these algorithms will fail after FIPS mode is enabled. This is a known and intentional breaking change, compliance with FIPS 140-2 requires accepting those breaks.
Regulatory Scope Mapping: One of the most time-consuming parts of compliance work is mapping controls to frameworks. If your organization needs to satisfy multiple regulations simultaneously, say, HIPAA and PCI-DSS and SOC 2, many controls overlap. Microsoft's compliance documentation and the CIS controls mapping explicitly calls out that CIS controls map to NIST CSF, NIST SP 800-53, ISO 27001, PCI DSS, HIPAA, and others. In the Azure portal under Microsoft Defender for Cloud → Regulatory Compliance, you can view multiple standards side by side and identify which single remediation action satisfies controls across multiple frameworks simultaneously. This is how you avoid duplicating work.
Enterprise CA and Certificate Errors: FedRAMP, ITAR, and DoD IL5 environments often require that PKI certificates come from a government-approved CA. If Azure resources are rejecting certificates or TLS handshakes are failing in a high-compliance environment, verify that your certificate chain roots to an approved CA. Check the certificate chain with:
certutil -verify -urlfetch "C:\path\to\certificate.cer"Prevention & Best Practices
The organizations I've seen maintain clean compliance postures over time don't rely on quarterly audit sprints. They build compliance into their standard operating procedures so that new deployments start from a compliant baseline and configuration drift is caught continuously rather than during a crisis.
The single most impactful change you can make is switching from reactive compliance scanning to preventive policy enforcement. Use Azure Policy in Deny mode for your highest-risk controls, things like "storage accounts must require secure transfer" or "VMs must not have public IP addresses in the production subscription." If a developer tries to deploy a non-compliant resource, the deployment fails immediately rather than showing up in a scan weeks later. Yes, this means some developers will hit walls. That friction is the point, it forces compliance to be part of the deployment design, not an afterthought.
Establish a change management process for your CIS benchmark configuration. When someone needs to change a hardened setting, maybe a legacy application requires a non-standard authentication protocol, document it as a formal exception with an expiry date and compensating controls. Don't just quietly change the setting and hope the auditor doesn't notice. Every exception needs to be time-boxed and reviewed.
Set up automated compliance score alerts. In Microsoft Defender for Cloud → Workflow automation, you can create Logic App-based alerts that fire when your compliance score drops below a threshold. I'd set alerts at drops of more than 5% from your baseline score, that's usually enough to catch a significant configuration drift event without generating noise from normal day-to-day fluctuations.
Review the CIS benchmark version you're targeting at least annually. CIS updates its benchmarks, the Windows Server 2022 benchmark and the Azure Foundations Benchmark both go through revisions, and controls that were Level 2 sometimes move to Level 1 in updated versions. Subscribe to CIS update notifications at the CIS website so you know when a new benchmark version drops that may affect your compliance posture.
- Enable Azure Policy
Denyeffect on your top 10 highest-risk non-compliance patterns to block future drift at the source - Set Log Analytics workspace retention to match your longest regulatory requirement (6 years for HIPAA, 3 years for FedRAMP), do this once and forget it
- Use Azure Blueprints for every new subscription deployment so the environment starts compliant rather than being remediated after the fact
- Schedule a monthly compliance score review in your team calendar, 30 minutes to catch drift early is infinitely better than an emergency scramble before an audit
Frequently Asked Questions
Does Microsoft's SOC 2 or ISO 27001 certification mean my Azure workloads are automatically compliant?
No, and this is the most important distinction to get right. Microsoft holds SOC 2 Type II, ISO 27001, and many other certifications for its cloud platform infrastructure. What that means is that Microsoft's data centers, hardware, physical security, and core platform services meet those standards. But your workloads, the VMs you deploy, the databases you configure, the access controls you set up, are your responsibility under the shared responsibility model. You need to independently configure and demonstrate compliance for the controls that fall in the customer scope. The Microsoft compliance documentation explicitly separates "Microsoft-managed controls" from "customer-managed controls" for each framework.
What's the difference between CIS Level 1 and Level 2, and which one should my organization target?
CIS Level 1 covers essential security baselines, settings that any organization should be able to apply without meaningfully breaking their applications or workflows. Level 2 goes further, applying stricter restrictions that are appropriate for sensitive or high-security environments but may disable some features your users or applications rely on. For most commercial organizations starting their compliance journey, Level 1 is the right target. If you're operating in a regulated industry like defense, government, or financial services with strict data handling requirements, Level 2 is worth pursuing, but do it incrementally and test each additional control in a non-production environment first. Breaking a production workload in the name of compliance does not make anyone more secure.
How long does it take for Azure Policy compliance status to update after I fix a non-compliant resource?
The standard Azure Policy evaluation cycle runs every 24 hours automatically. However, you don't need to wait that long, you can trigger an on-demand evaluation from the portal under Policy → Compliance → Re-evaluate, or run Start-AzPolicyComplianceScan -ResourceGroupName "MyRG" in PowerShell to trigger an immediate scan for a specific resource group. Even with an on-demand trigger, allow 30–60 minutes for the results to propagate through the Defender for Cloud Regulatory Compliance dashboard. If a resource still shows non-compliant after a full 24-hour cycle following your fix, verify the remediation actually applied by checking the resource's settings directly in the portal rather than relying solely on the compliance dashboard.
We need to meet both HIPAA and PCI-DSS. Do I have to configure everything twice?
You don't, and you shouldn't approach it that way. Many HIPAA and PCI-DSS controls overlap significantly, particularly around encryption at rest and in transit, access control, audit logging, and vulnerability management. The CIS controls framework explicitly maps to both HIPAA and PCI DSS, among other standards. In the Azure Regulatory Compliance dashboard, you can add both standards simultaneously and use the control-level view to identify which remediations satisfy requirements in both frameworks at once. The practical advice: start with your CIS Level 1 baseline first. You'll find that it satisfies a large percentage of both HIPAA Security Rule and PCI-DSS requirements, and then you only need to address the framework-specific gaps individually.
What is the Microsoft Azure Foundations Benchmark and is it the same as a general CIS Benchmark?
The CIS Microsoft Azure Foundations Benchmark is a specific benchmark document published by the Center for Internet Security, developed with Microsoft's active participation, specifically for Azure cloud environments. It is not the same as the general CIS controls framework, which is a broader set of cybersecurity best practices applicable to any technology. The Azure Foundations Benchmark gives you prescriptive, Azure-specific configuration guidance, things like specific Azure Security Center settings, storage account configurations, and Azure Active Directory policies. Microsoft was directly involved in developing it, testing the recommendations against actual Azure services, and it's updated as Azure itself evolves. Think of the general CIS controls as the "what" and the Azure Foundations Benchmark as the "exactly how to do it in Azure."
My compliance score dropped suddenly after deploying new resources. What should I check first?
A sudden compliance score drop almost always means new resources were deployed without the required configurations, especially common when teams use infrastructure-as-code templates that were built before your compliance requirements were defined. Go to Defender for Cloud → Regulatory Compliance → [your standard] and sort failing controls by "Recently failed." This surfaces controls that changed state recently rather than long-standing gaps. Compare the list of newly failing resource IDs against your recent deployment history in Activity Log filtered to the past 24–48 hours. You'll almost always find the deployment event that introduced the gap within the first few minutes of investigation. The fix is to update your IaC templates so future deployments of the same type start compliant, then remediate the current instance.