Agent Foskett Academy • Microsoft Defender for Cloud • Module 4 • Lesson 33

Lesson 34 — Investigating Cloud Alerts

The Regulatory Compliance Dashboard becomes useful when you understand the relationship between standards, controls, assessments, policies and affected resources.

Microsoft Defender for Cloud uses security standards that are implemented through Azure Policy initiatives or native Defender assessments. Each standard contains controls, each control contains one or more assessments, and each assessment evaluates the resources in scope.

This lesson explains that hierarchy, the purpose of common Azure Policy effects, how responsibilities are assigned, how technical findings map into governance reporting, and why failed assessments must be prioritised by business risk rather than percentage alone.

Thirty controls had failed—but only a small number represented immediate risk to critical workloads.
Agent Foskett Defender for Cloud Security Alerts lesson
What you will learn

This lesson explains how Microsoft Defender for Cloud security alerts are generated, prioritised, investigated and connected to incidents.

Standards and initiatives
Controls and assessments
Policy effects
Risk-based prioritisation

Security alert investigation flow

Compliance standard or benchmark

Azure Policy initiative or Defender-native standard

Control domain

Technical assessment

Policy definition or native evaluation

Affected resource

Recommendation and remediation guidance

Reassessment

Updated governance evidence

Azure Policy effects

EffectPurposeTypical use
AuditRecords noncompliance without blocking.Measure impact before enforcement.
AuditIfNotExistsChecks for a related required resource or setting.Detect missing diagnostic configuration.
DenyBlocks a noncompliant create or update request.Prevent public storage or disallowed regions.
DeployIfNotExistsDeploys a missing related configuration.Enable required diagnostics or agents.
ModifyChanges supported properties or tags.Add required tags or secure configuration.
DisabledStops evaluation for the assignment.Temporarily turn off a policy without deleting it.

Learning objectives

  • Explain standards, controls and assessments.
  • Understand Azure Policy initiatives.
  • Describe policy definitions, assignments and parameters.
  • Compare common Azure Policy effects.
  • Interpret assessment status.
  • Prioritise failed controls by business impact.
  • Use technical results in governance reporting.

What is a compliance standard?

A compliance standard is a benchmark or framework used to organise security requirements and measure technical alignment across a defined scope.

What is a control?

A control groups one or more requirements that address a particular compliance objective, such as identity, logging, encryption or network protection.

What is an assessment?

An assessment evaluates a specific technical condition and reports whether affected resources satisfy the requirement.

What is a recommendation?

A recommendation provides practical remediation guidance for the security issue identified by an assessment.

What is a policy definition?

A policy definition describes the resource condition Azure Policy evaluates and the effect applied when that condition matches.

What is an initiative?

An initiative groups multiple policy definitions so they can be assigned, managed and reported together.

What is an assignment?

An assignment applies a policy or initiative to a management group, subscription, resource group or supported external-cloud scope.

What are parameters?

Parameters allow one policy or initiative to be reused with different values, such as allowed regions, required SKUs or enforcement modes.

Policy scope

Scope determines which resources are evaluated. Incorrect scope can leave workloads unassessed or apply controls where they are not intended.

Exclusions

Exclusions remove selected child scopes from an assignment. Every exclusion should have an owner and documented reason.

Audit effect

The Audit effect records noncompliance without blocking the resource request. It is useful for understanding impact before enforcement.

AuditIfNotExists effect

AuditIfNotExists checks whether a related or required resource exists and records noncompliance when it does not.

Deny effect

The Deny effect blocks a create or update request that does not meet the policy requirement.

DeployIfNotExists effect

DeployIfNotExists can deploy a required related resource or configuration when the expected condition is missing.

Modify effect

Modify can add, update or remove supported resource properties or tags during creation or update and can support remediation of existing resources.

Disabled effect

The Disabled effect turns off evaluation for that assignment or definition while preserving the configuration.

Enforcement mode

Enforcement mode can allow policy evaluation without enforcing certain effects, which is useful for staged rollout and testing.

Policy evaluation

Azure Policy evaluates resources during creation and update and also performs periodic compliance scans.

Compliance state

Assessment results commonly include compliant, noncompliant, exempt, not applicable, unknown or unavailable states.

Compliant

The assessed resource currently satisfies the technical condition defined by the policy or native assessment.

Noncompliant

The assessed resource does not satisfy the requirement and requires remediation, exemption or scope review.

Exempt

An exemption documents an approved reason for excluding a resource from the normal compliance result.

Not applicable

A result is not applicable when the resource does not meet the conditions required for the policy to evaluate it.

Unknown

An unknown result can indicate delayed evaluation, missing data, unsupported resource state or assessment failure.

Customer responsibility

Customer-responsible controls require the organisation to implement and maintain the relevant technical or operational control.

Microsoft responsibility

Microsoft-responsible controls relate to cloud-service obligations implemented by Microsoft and may include attestation or implementation details.

Shared responsibility

Shared controls require both Microsoft and the customer to complete different parts of the requirement.

Control mappings

One technical assessment can map to multiple standards and controls when the same security measure supports several frameworks.

Cross-framework reuse

Fixing a single high-value configuration issue can improve results across several assigned standards at once.

Microsoft Cloud Security Benchmark

The Microsoft Cloud Security Benchmark provides cloud-neutral security guidance and serves as the default benchmark in Defender for Cloud.

Industry standards

Supported standards can include frameworks such as CIS, ISO, PCI DSS and NIST, depending on availability and cloud scope.

Custom initiatives

Custom Azure Policy initiatives can represent internal baselines, contractual requirements or organisation-specific control sets.

Manual controls

Some controls require documentation, process evidence or human review and cannot be assessed automatically by Defender for Cloud.

Technical controls

Technical controls can often be evaluated automatically through Azure Policy or Defender-native assessments.

Control status

A control can contain several assessments. One failed assessment may affect the overall control status even when others pass.

Assessment weighting

Do not assume every control or assessment has equal security impact. Technical risk, business value and exploitability still matter.

Business context

Prioritise failed assessments affecting internet-facing, privileged, sensitive or production workloads.

Resource count

A control affecting hundreds of low-risk resources may require a different response from a control exposing one critical Key Vault.

Attack-path context

Use attack paths and exposure context to understand whether a failed assessment contributes to a realistic compromise route.

Secure Score relationship

Some recommendations influence Cloud Secure Score while also supporting compliance controls. The two reporting models remain distinct.

Dashboard drill-down

Open the standard, select the control, review the assessment, identify affected resources and follow the linked remediation guidance.

Remediation tasks

DeployIfNotExists and Modify policies can require remediation tasks and managed identities to correct existing resources.

Testing policies

Start new policies in Audit or AuditIfNotExists where practical to understand impact before using enforcement effects.

Deny rollout

Move to Deny only after validating scope, exemptions, deployment pipelines and operational consequences.

Policy as code

Store custom definitions, initiatives and assignments in source control so changes are reviewed, repeatable and auditable.

Versioning

Track initiative and policy versions because changes can alter compliance results across large environments.

Change management

Policy updates should include testing, communication, exception handling and rollback planning.

Evidence quality

Compliance evidence must include scope, timestamp, standard, assignment and assessment state.

Governance reporting

Reports should explain the failed control, affected service, business impact, owner, due date and current remediation status.

Common mistake: control confusion

A control is not the same as a single recommendation. Controls can contain several assessments and responsibilities.

Common mistake: policy confusion

A policy definition is the technical evaluation logic; a standard is the broader compliance framework.

Common mistake: equal priority

Do not treat every failed assessment as equally urgent merely because it appears in the same dashboard.

Common mistake: hidden exemptions

Review exemptions regularly so accepted risk does not disappear from governance attention.

Common mistake: unsupported evidence

A passing policy result does not prove that every manual or operational requirement has been satisfied.

Agent Foskett investigation: “Thirty controls had failed…”

The compliance score dropped suddenly

Thirty failed assessments appeared

Management treated every failure as an emergency

Agent Foskett grouped findings by standard and control

Twenty-eight failures involved low-risk development resources

One control involved a production Key Vault with public access

One control involved a storage account exposing customer exports

Attack-path context connected both resources to privileged identities

The Key Vault and storage controls were remediated first

Network access was restricted

Excessive permissions were removed

The remaining findings were assigned owners and due dates

Reassessment confirmed the critical controls had passed

Thirty controls had failed

But only a small number represented immediate business risk
Security alert investigation flow helps organise work. Risk context decides what should be fixed first.

Standards and controls investigation checklist

AreaQuestionEvidence
StandardWhich framework or benchmark is assigned?Standard and initiative assignment.
ScopeWhich management groups, subscriptions or cloud accounts are included?Assignment scope and exclusions.
ControlWhich compliance objective is affected?Control mapping and responsibility.
AssessmentWhat technical condition failed?Policy or native assessment details.
EffectIs the policy auditing, denying or remediating?Policy effect and enforcement mode.
ResourceWhich workload is affected and how critical is it?Resource details and business owner.
RiskDoes the failure create exposure or an attack path?Secure Score, exposure and attack-path context.
RemediationWho owns the correction and when will it be validated?Ticket, due date and reassessment.

Key takeaways

  • A compliance standard organises security requirements into a framework.
  • Controls group related requirements within the standard.
  • Assessments evaluate specific technical conditions against resources.
  • Azure Policy initiatives group multiple policy definitions for assignment and reporting.
  • Assignments determine scope, parameters, exclusions and enforcement behaviour.
  • Audit observes, Deny blocks, DeployIfNotExists deploys missing configuration and Modify changes supported properties.
  • Customer, Microsoft and shared responsibility influence how controls are interpreted.
  • One technical assessment can support several standards.
  • Compliance status and Cloud Secure Score are related but separate.
  • Failed assessments should be prioritised using business impact, exposure and attack-path context.

What Agent Foskett checked

  • Assigned standard
  • Azure Policy initiative
  • Assignment scope
  • Exclusions
  • Control mapping
  • Assessment status
  • Policy effect
  • Affected resource
  • Business criticality
  • Attack-path context
  • Remediation owner
  • Reassessment result

Best practices

  • Assign standards at the right scope.
  • Start enforcement with Audit.
  • Test Deny policies carefully.
  • Use initiatives for consistency.
  • Version policy as code.
  • Document exclusions.
  • Review exemptions.
  • Prioritise by business risk.
  • Validate remediation.
  • Preserve dated evidence.

Related Agent Foskett resources

Continue developing practical Microsoft Defender for Cloud compliance, governance and investigation skills.

Continue learning

Continue Module 4 by learning how to investigate cloud security alerts.

What are compliance standards and controls in Microsoft Defender for Cloud?

Compliance standards organise technical and operational requirements into controls, while assessments use Azure Policy or Defender-native evaluations to determine whether resources satisfy those requirements.

Compliance Standards and Controls Lesson

This Agent Foskett lesson explains standards, controls, assessments, Azure Policy initiatives, assignments, parameters, policy effects, responsibility models, remediation and risk-based prioritisation.