Lesson 13 — Recommendation Remediation

Learning objectives

After completing this lesson, you should be able to select a remediation method, apply changes safely and validate that the recommendation has been resolved.

Read the remediation guidance

Defender for Cloud recommendations usually include explanation, affected resources, suggested actions and relevant documentation.

Confirm assessment freshness

Old or stale assessment data can lead teams to remediate an issue that has already changed.

Review affected resources

Check each resource because ownership, environment, exposure and dependencies may differ.

Manual remediation

Manual remediation is suitable for small scopes, investigation work and changes requiring careful operator judgement.

The Fix action

Some recommendations provide a Fix option that can apply a supported correction directly from Defender for Cloud.

Bulk Fix

Bulk Fix can accelerate remediation, but the selected resource scope should be reviewed carefully.

Azure Policy remediation

DeployIfNotExists and Modify policy effects can support remediation tasks for non-compliant resources.

Managed identity

Azure Policy remediation may require a managed identity with permissions to modify affected resources.

PowerShell

PowerShell can provide controlled and repeatable remediation across multiple Azure resources.

Azure CLI

Azure CLI can support scripted remediation in local, pipeline and automation environments.

REST APIs

APIs can integrate recommendation remediation into broader security engineering workflows.

Infrastructure as Code

Bicep, ARM templates, Terraform and other deployment sources should be updated so secure configuration persists.

Golden images

Virtual machine images and base templates should be corrected when the same weakness appears repeatedly.

CI/CD pipelines

Pipeline checks can prevent insecure settings from being deployed again.

Testing

Test remediation in a safe environment or limited scope before applying broad changes.

Canary deployment

Apply the change to a small representative group before expanding to the full environment.

Change control

Production remediation may require approvals, maintenance windows and stakeholder communication.

Rollback planning

Define how to reverse the change if availability, compatibility or performance is affected.

Dependency review

Understand application, identity, network, storage and monitoring dependencies before remediation.

Service availability

Security improvement should not create uncontrolled service outages.

Customer impact

Customer-facing resources may require additional testing and communication.

Permissions

The remediation operator or automation identity needs only the permissions required for the task.

Least privilege

Avoid granting broad permanent rights merely to complete one remediation action.

Separation of duties

Approval and implementation responsibilities may need to be separated in regulated environments.

Automation accounts

Automation accounts can run repeatable remediation tasks, but identities, secrets and permissions must be protected.

Logic Apps

Logic Apps can create tickets, notify owners and coordinate remediation workflows.

Tickets

Each remediation action should record the resource, owner, priority, due date, change and validation evidence.

Owner assignment

An accountable owner is required to move a recommendation from open to verified closure.

Due dates

Remediation deadlines should reflect priority, exposure and operational complexity.

Compensating controls

Network restrictions, access limitations or enhanced monitoring can reduce risk before permanent remediation.

Exceptions

A formal exception may be required when remediation is not technically or operationally possible.

Exemption review

Exceptions should include justification, owner, expiry date, compensating controls and review schedule.

False positives

Confirm evidence carefully before dismissing a recommendation as a false positive.

Configuration drift

Secure settings can be lost when resources are changed outside approved deployment processes.

Prevent recurrence

Policy, templates, pipelines and governance should be updated so the weakness does not return.

Reassessment delay

Defender for Cloud may require time to reassess the resource after remediation.

Healthy status

A healthy status indicates the assessment no longer detects the issue, but operational validation is still important.

Secure Score update

Secure Score may update after the recommendation and affected resources are reassessed.

Attack path validation

Check whether related attack paths have disappeared or changed after remediation.

Service health validation

Confirm the resource still performs its intended function after the security change.

Evidence

Capture screenshots, command output, configuration values, policy results or ticket records as evidence.

Metrics

• Open critical and high-priority recommendations
• Overdue remediation actions
• Mean time to remediate
• Percentage successfully validated
• Recurring recommendations
• Resources remediated through automation
• Temporary controls approaching expiry
• Recommendations reopened after closure

Mean time to remediate

Mean time to remediate helps measure how efficiently the organisation reduces identified risk.

Recurring recommendations

Repeated findings often indicate weak templates, unmanaged drift or incomplete root-cause remediation.

Root cause

Fix the process, template or governance weakness that allowed the insecure configuration to exist.

What Agent Foskett checked

Agent Foskett checked the portal setting, deployment history, infrastructure template and reassessment result.

Best practices

• Confirm the recommendation is current.
• Review the affected resource scope.
• Test before broad deployment.
• Use least-privileged identities.
• Document approvals and rollback steps.
• Update Infrastructure as Code.
• Automate repeated remediation safely.
• Validate service health after the change.
• Wait for reassessment before closure.
• Fix the root cause to prevent recurrence.