4.9 Regulatory Compliance and Security Standards

Regulatory Compliance and Security Standards

Introduction

CSPM tells you whether your resources are configured securely. Regulatory compliance tells you whether your configuration meets specific regulatory and industry standards. The distinction matters: a resource can be secure (no known vulnerabilities, proper access controls) but non-compliant (does not meet a specific regulatory requirement for encryption at rest, logging retention, or access audit trails). Compliance and security overlap significantly, but they are not identical.

Defender for Cloud’s regulatory compliance dashboard maps your security posture against industry standards and regulatory frameworks. This gives you two things: first, a compliance status report that shows which controls are satisfied and which are not (useful for audit preparation). Second, a prioritised remediation list that tells you which security improvements also satisfy compliance requirements (useful for justifying security investment to management — “this configuration change satisfies both CIS 4.3.1 and GDPR Article 32”).

Built-in compliance standards

Defender for Cloud includes several compliance standards out of the box. Each standard is a collection of controls mapped to specific Defender for Cloud security recommendations.

The compliance dashboard

Navigate to Defender for Cloud → Regulatory compliance. The dashboard shows each enabled standard with a compliance percentage (how many of the standard’s controls are satisfied) and a breakdown by control domain.

Each control maps to one or more Defender for Cloud security recommendations. When a recommendation is implemented (the resource is compliant), the corresponding compliance control is marked as passed. When a recommendation is not implemented, the control is marked as failed. The mapping is many-to-many: one recommendation may satisfy controls in multiple standards, and one control may require multiple recommendations to be fully satisfied.

Reading the dashboard for audit preparation: An auditor reviewing your CIS compliance will look at specific controls: “4.3.1 — Ensure that ‘Auditing’ is set to ‘On’ for SQL servers.” The compliance dashboard shows whether this control is passed or failed, which SQL servers are non-compliant (if failed), and the specific remediation steps. You can export the compliance status as a report (CSV or PDF) for the auditor — providing evidence of compliance without giving the auditor direct access to your Azure environment.

Adding and customising compliance standards

To add a standard: Defender for Cloud → Regulatory compliance → Manage compliance policies → select your subscription → Security policy → Add standard. The available standards include all built-in options plus custom standards.

Custom standards let you define your own compliance framework. If your organisation has internal security policies that go beyond industry standards (e.g., “all VMs must have disk encryption AND network isolation AND endpoint protection”), you can create a custom standard that maps these requirements to Defender for Cloud recommendations. Non-compliant resources appear in the compliance dashboard alongside the built-in standards.

Custom policies extend the built-in recommendations. If Defender for Cloud does not have a recommendation for one of your compliance requirements (e.g., “all storage accounts must use customer-managed encryption keys”), you can create a custom Azure Policy definition, assign it to your subscription, and it appears in the compliance dashboard as a custom control.

Compliance in the SOC workflow

As a SOC analyst, you interact with compliance in three contexts:

During incident investigation: When a security alert fires, check whether the compromised resource had compliance gaps. A VM compromised through brute-force SSH that did not have JIT enabled was non-compliant with CIS controls for access management. Document this in the incident report: the compliance gap enabled the attack. This evidence supports remediation investment.

During posture reviews: Monthly or quarterly, review the compliance dashboard trends. Are compliance percentages improving? Which standards have declining compliance (new resources deployed without controls)? Which control domains consistently fail (systemic gaps that need engineering attention)?

During audit preparation: Before an audit, export the compliance report for the relevant standard. Review any failed controls and either remediate them before the audit or prepare documented exemptions with business justifications.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Compliance posture trending in Sentinel
SecurityRecommendation
| where TimeGenerated > ago(30d)
| extend ComplianceStandard = tostring(Properties.assessedComplianceStandards)
| extend IsHealthy = tobool(Properties.isHealthy)
| summarize PassedCount = countif(IsHealthy == true),
    FailedCount = countif(IsHealthy == false)
    by bin(TimeGenerated, 1d)
| extend CompliancePct = round(100.0 * PassedCount / (PassedCount + FailedCount), 1)
| project TimeGenerated, CompliancePct, PassedCount, FailedCount
| order by TimeGenerated asc

Compliance reporting for management

The compliance dashboard provides metrics that translate directly into executive reports:

“Our Azure environment is 78% compliant with CIS Microsoft Azure Foundations Benchmark. The top 5 failing controls are: [list]. Remediation of these 5 controls would improve compliance to 91%. Estimated effort: 3 weeks. The primary gap is VM endpoint protection — 23 VMs do not have MDE installed.”

This format — current state, specific gaps, improvement target, effort estimate — is what management needs to make investment decisions. The Defender for Cloud compliance dashboard provides all the data. Your job is to translate it into the business language.

Multi-standard overlap: fixing once, satisfying many

Many compliance controls overlap across standards. A single security improvement (encrypting data at rest) may satisfy controls in CIS (2.9), NIST 800-53 (SC-28), PCI DSS (3.4), ISO 27001 (A.10.1.1), and the Azure Security Benchmark (DP-4). The compliance dashboard shows this overlap — when you remediate a Defender for Cloud recommendation, every standard that includes a corresponding control is updated simultaneously.

This overlap is powerful for prioritisation: recommendations that satisfy controls in multiple standards provide the most compliance value per remediation effort. Sort recommendations by the number of standards they satisfy, and address the high-overlap recommendations first. A single fix that resolves controls in 4 standards is more valuable than 4 fixes that each resolve controls in 1 standard.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// Identify recommendations that satisfy multiple compliance standards
SecurityRecommendation
| where TimeGenerated > ago(1d)
| where tobool(Properties.isHealthy) == false
| extend Standards = tostring(Properties.assessedComplianceStandards)
| extend StandardCount = array_length(split(Standards, ","))
| extend Description = tostring(Properties.displayName)
| extend Severity = tostring(Properties.severity)
| where StandardCount > 2
| project Description, Severity, StandardCount, Standards
| order by StandardCount desc, Severity asc
| take 10

Compliance exemptions: documenting acceptable risk

Not every compliance control is applicable to every resource. A test VM that intentionally lacks endpoint protection to simulate an unprotected endpoint for training purposes should not count against your compliance score. Exemptions formally document these exceptions.

When to exempt: The resource has a legitimate business reason for non-compliance, the risk is accepted by an authorised risk owner, and the exemption is documented with the justification, the risk acceptance, and the review date.

How to exempt: In the recommendation detail page, select the affected resource and click “Exempt.” Choose an exemption category: “Waiver” (the risk is accepted, the recommendation does not apply to this resource) or “Mitigated” (the risk is addressed by a compensating control not tracked by Defender for Cloud). Provide the justification text. The exemption is logged and the resource is excluded from the compliance calculation.

Exemption governance: Exemptions should be reviewed quarterly. A resource exempted 12 months ago may no longer need the exemption (the business reason may have changed) or the exemption may no longer be appropriate (new regulations may have stricter requirements). Governance rules can include exemption review reminders.

Continuous compliance monitoring with Sentinel

The Defender for Cloud compliance dashboard provides point-in-time compliance status. For continuous monitoring and alerting on compliance changes, use Sentinel analytics rules that query the SecurityRecommendation table.

1
2
3
4
5
6
7
8
9

// Alert when a previously compliant critical control becomes non-compliant
SecurityRecommendation
| where TimeGenerated > ago(1h)
| where tobool(Properties.isHealthy) == false
| where tostring(Properties.severity) == "High"
| extend ControlId = tostring(Properties.assessedComplianceStandards)
| where ControlId has "CIS" or ControlId has "NIST"
| extend ResourceName = tostring(Properties.resourceDetails.ResourceName)
| project TimeGenerated, ResourceName, Properties.displayName, ControlId

Schedule this query as a Sentinel analytics rule (every 1 hour). When a high-severity compliance control fails (a resource becomes non-compliant), the rule generates a Sentinel incident. This provides real-time compliance regression detection — you learn about compliance drift within an hour, not at the next quarterly review.

Cross-cloud compliance: comparing posture across Azure, AWS, and GCP

When you have multi-cloud connectors configured (subsection 4.3), the compliance dashboard shows compliance status per cloud environment. This enables direct comparison: is your AWS environment more or less compliant than your Azure environment?

Cross-cloud comparison reveals governance gaps. If Azure compliance is 85% and AWS compliance is 62%, the AWS environment was likely provisioned without the same security governance. The gap is not a technology problem — it is a process problem. The same security standards should apply regardless of which cloud hosts the workload.

Generate a cross-cloud compliance comparison report: for each enabled standard, show the compliance percentage per cloud environment, the top failing controls per cloud, and the total number of non-compliant resources per cloud. Present this to management as evidence that multi-cloud governance needs attention: “Our Azure environment meets 85% of CIS controls. Our AWS environment meets 62%. The gap represents 31 high-severity misconfigurations in AWS that do not exist in Azure.”

Compliance drift: detecting and responding to regression

Compliance is not a destination — it is a continuous state that degrades unless actively maintained. Compliance drift occurs when previously compliant resources become non-compliant due to configuration changes, new resource deployments without controls, or newly added compliance controls that existing resources do not meet.

Sources of compliance drift:

Manual configuration changes: an administrator disables encryption on a storage account to troubleshoot a performance issue and forgets to re-enable it. The storage account drops from compliant to non-compliant on encryption controls.

Infrastructure-as-code updates: a Terraform module is updated to deploy VMs without endpoint protection (the MDE extension was removed from the template). Every VM deployed from the updated template is non-compliant.

New compliance requirements: your organisation adds PCI DSS to the compliance dashboard. Resources that were compliant with CIS may not meet all PCI requirements — new controls are evaluated and new failures appear.

Preventing drift: Implement Azure Policy in “Deny” mode for critical controls (deny deployment of VMs without endpoint protection, deny storage accounts without encryption). Use governance rules to auto-assign new non-compliant findings. Monitor the Secure Score trend weekly and investigate any decline. Run the Sentinel compliance monitoring query from earlier in this subsection as a scheduled analytics rule.

Responding to drift: When a compliance regression is detected, treat it like a security incident: identify the root cause (who changed what and when), remediate the non-compliant resource, and implement preventive controls (Azure Policy in Deny mode, pipeline validation) to prevent the same drift from recurring.

The compliance-to-incident connection works both ways. Compliance gaps can cause incidents (an unencrypted storage account is easier to exploit than an encrypted one). And incidents can reveal compliance gaps (the incident report identifies pre-existing recommendations that were not implemented). This bidirectional relationship is why SOC teams and compliance teams must collaborate — the SOC provides the incident evidence that demonstrates the real-world impact of compliance gaps, and the compliance team provides the governance framework that prevents those gaps from recurring.

Knowledge check