The best way to run Microsoft Defender for Cloud is to settle who owns it before you switch it on, enable it across every subscription you have, work recommendations from the highest risk down, and fix issues at scale with policy and governance rather than one resource at a time. Defender for Cloud is a cloud-native application protection platform (CNAPP) that combines posture management, DevSecOps integration and workload protection. The tool is only as good as the habits around it. This guide covers those habits in the order you need them.
TL;DR
- Define security roles, ownership and success metrics before onboarding, so every recommendation has a named person responsible.
- Enable Defender for Cloud on all subscriptions, ideally through automation, and extend it to AWS and GCP through connectors.
- Sort recommendations by risk level and deal with Critical items first.
- Remediate at scale with Fix, Azure Policy remediation tasks, governance rules and documented exemptions.
- Review drift, alerts and threat intelligence on a fixed schedule, not when someone has time.
Table of Contents
- Decide who owns what before you enable anything
- Enable Defender for Cloud across every subscription
- Bring AWS and GCP into the same view
- Work through recommendations by risk, not by volume
- Remediate at scale and check the fix held
- Build a monitoring and governance routine
- Shift security earlier in development
- Use custom standards for regulated work
- Let Nexus run the routine with you
- FAQ
- Sources
Decide who owns what before you enable anything
Most failed rollouts do not fail on technology. They fail because a dashboard full of findings has no owner. Microsoft's guidance is to determine ownership and define success metrics before adoption, including who responds to alerts and who acts on recommendations.
Write this down in one page:
- Who monitors and remediates recommendations. Often this is split: the security team triages, the resource owners fix.
- Who responds to alerts, and what happens out of hours.
- Who can change policy. Microsoft's planning guide covers defining security roles, policies, data collection and onboarding strategy, and it points to Azure RBAC roles such as Security Reader and Security Admin for managing permissions.
- How you will know it is working. Pick two or three measures, such as the number of Critical recommendations open, how long they stay open, and how quickly alerts are triaged.
Keep permissions narrow. Most people who need to see findings only need a reader role. Reserve admin rights for the few who change policy or plans.
For multicloud environments, Microsoft also recommends planning a lifecycle strategy for onboarding resources and defining how teams collaborate. In practice that means deciding what happens when a new account or project appears: who connects it, how fast, and who is told.
Enable Defender for Cloud across every subscription
Coverage gaps are the most common weakness. A subscription that nobody connected is a subscription nobody sees. You can enable Defender for Cloud on Azure subscriptions from the Azure portal, and that is also where you turn on paid plans for additional protections.
A sensible sequence:
- Inventory your subscriptions. Include the forgotten ones: test, sandbox, acquired-company and contractor subscriptions.
- Enable at the broadest sensible scope. Use management groups where your structure allows, so new subscriptions inherit the same baseline.
- Start with posture, then add protection plans. Look at what the free posture assessment shows first, then choose paid plans for the workload types you actually run, such as servers, storage or databases.
- Automate. If you manage more than a handful of subscriptions, script it. Microsoft documents PowerShell onboarding across subscriptions, including setting the CISO as a security contact and assigning the default policy initiatives.
- Set security contacts. Alerts that go to a shared mailbox nobody reads are the same as no alerts.
Once a subscription is onboarded, Defender for Cloud creates a default security policy for it. You can edit that policy or extend it with Azure Policy across management groups. Treat the default as a starting point. A healthcare provider and a software startup should not carry the same rules.
Turn on paid plans deliberately
It is tempting to enable everything. A better habit is to match each plan to an asset you can name. If you run virtual machines, plan a servers deployment with the same care you give any production change. If you have no containers, you do not need container protection yet. Review the plan list each quarter as your estate changes, and check Microsoft's current pricing page before budgeting.
Bring AWS and GCP into the same view
If you run more than one cloud, one console beats three. Defender for Cloud offers CSPM for AWS and GCP through connectors, and some workload protection features rely on the Azure Arc agent. Check those dependencies before you promise coverage to leadership, because they affect who needs to install what, and where.
Two practical points:
- Give the person who owns the AWS account or GCP project a role in the connection process. Security cannot do this alone.
- Decide in advance which findings are handled in Defender for Cloud and which in the native tools of each cloud, so nothing is handled twice or not at all. Our overview of cloud-native security tools can help you draw that line, and our write-up on turning GCP findings into SIEM playbooks shows what the Google side looks like in operation.
If Azure is where you are heading rather than where you are, plan the move first. We explain how to avoid months of delay in an Azure migration.
Work through recommendations by risk, not by volume
The first scan of a mature environment can produce hundreds of recommendations. Do not try to clear the list. Prioritize it.
Defender for Cloud assigns risk levels of Critical, High, Medium, Low and Not evaluated. These reflect environmental context, how likely a weakness is to be exploited and the business impact, and Microsoft's guidance is to address Critical recommendations immediately.
A workable triage routine:
| Risk level | What to do | Suggested rhythm |
|---|---|---|
| Critical | Assign an owner the same day and fix or mitigate immediately | Daily check |
| High | Schedule into the current sprint or maintenance window | Weekly review |
| Medium | Batch by resource type and fix through policy where possible | Monthly review |
| Low | Fix opportunistically or document an exemption | Quarterly review |
| Not evaluated | Find out why the assessment did not run, then re-check | Monthly review |
The rhythm column is our suggestion, not a Microsoft requirement. Adjust it to your team size.
Two habits make triage faster. First, group by cause. Fifty findings often trace back to one missing setting in a deployment template, and fixing the template removes all fifty. Second, read the description and manual remediation steps on each recommendation before you assign it, so the owner receives something they can act on rather than a link to a dashboard. The same logic applies beyond the cloud console. Our post on CISA-aligned vulnerability remediation covers how to decide what gets fixed first.
Remediate at scale and check the fix held
Fixing resources one by one does not scale and it does not last. Microsoft's training material lists the main tools for remediating recommendations at scale: the Fix action, Azure Policy remediation tasks, governance rules and structured exemptions.
- Fix suits a single resource or a small group where a quick, supervised change is acceptable.
- Azure Policy remediation tasks correct existing resources that do not comply, and policy prevents new ones from drifting. Test in a non-production scope first, because an automated change that breaks an application creates a new incident.
- Governance rules assign recommendations to owners with deadlines, so the work is tracked. Governance supports improvement by assigning tasks to resource owners and tracking progress against security policies.
- Exemptions are for risks you accept or compensate for in another way. Record the reason, the approver and a review date. An exemption with no expiry is a hidden problem.
Confirm the result
A fix is not finished when somebody ticks a box. It is finished when the recommendation shows as healthy on the next assessment and stays that way. Include these checks in your routine:
- Re-check the recommendation after the next assessment cycle.
- Watch the count and age of open Critical and High items over time.
- Look for recurrence. If the same issue returns, the cause is upstream, in a template, a pipeline or a habit.
As a rule of thumb, if a recommendation keeps coming back, stop fixing the resource and fix whatever creates it.
Build a monitoring and governance routine
Posture decays. People add resources, change settings and install things. Microsoft advises organizations to check regularly for configuration changes, drift from recommended baselines and security alerts, and to visit threat intelligence daily. Incident response then follows a pattern of detecting, assessing and diagnosing a threat and applying remediation steps.
Turn that into a calendar:
- Daily: review new alerts, Critical recommendations and threat intelligence.
- Weekly: review High recommendations, governance rule progress and new resources.
- Monthly: review exemptions due for renewal, plan coverage and policy changes.
- Quarterly: revisit roles, security contacts, plans enabled and the success metrics you set at the start.
Defender for Cloud analyzes log data from resources, networks and connected partner solutions to detect threats such as brute force attacks and compromised virtual machines. Detection only helps if someone acts at three in the morning as readily as at three in the afternoon. Smaller teams often cannot staff that, which is why many organizations pair the tool with outside coverage. We explain how managed detection works and what to measure in 24/7 MDR coverage. If you feed several tools into one place, our threat detection integration guide shows how to avoid duplicate alerts.
Governance deserves its own review. Our piece on cloud security governance types compares the models organizations use, from central control to federated ownership.
Shift security earlier in development
Defender for Cloud covers the lifecycle from code to runtime. Microsoft's view is that embedding security early in development helps DevOps teams find misconfigurations, apply policies and fix risks early. It is cheaper to fix an insecure template than a live resource.
What that looks like day to day:
- Scan infrastructure-as-code and pipelines so findings reach developers in the tools they already use.
- Use the same policies in development and production, so a build that passes review does not later trip a Critical recommendation.
- Treat repeated production findings as feedback for the pipeline.
If your team is also adding automation or AI to its workflows, NIST guardrails for automation are a useful frame for deciding which checks must run before anything ships.
Use custom standards for regulated work
Healthcare providers and other regulated organizations rarely fit a generic baseline. Defender for Cloud lets you create custom recommendations with KQL and assign them to custom security standards. That is useful when your own policy asks for something the built-in checks do not cover, such as a specific tagging rule for systems that hold patient data or a naming convention for encrypted storage.
Keep two things in mind. Custom standards support your compliance work but do not replace it: someone still has to map controls to HIPAA, SOC 2, PCI-DSS or ISO 27001, gather evidence and be ready for an assessor. And a custom recommendation needs an owner like any other. Agree up front who maintains the query when your environment changes.
What we see in the field
We meet the same pattern again and again. A company turns on Defender for Cloud, sees a long list of findings, and then a few months later the list is longer and nobody is sure who is supposed to act. The tool is not the problem. Fragmentation is: one team owns the cloud, another owns the endpoints, a third handles compliance, and a vendor handles monitoring. Each sees a slice.
That is why we built Nexus around consolidation. When cybersecurity, cloud management and compliance sit under one provider with one SLA, a Critical recommendation has a single point of accountability, and an alert reaches someone who can both diagnose and fix it. Our approach is designed to bring real-time detection, cloud infrastructure management and compliance work into one routine, which in our experience shortens the path from finding to fix.
Our advice: do not judge your Defender for Cloud rollout by how many recommendations it shows. Judge it by how few Critical items stay open, and for how long.
Nick - Sr. Executive
Let Nexus run the routine with you
If the practices above describe work your team does not have the hours or the people to do, that is the gap we fill. Nexus provides managed IT and cybersecurity services, including 24/7 threat detection, cloud management across AWS, Azure and Google Cloud, and compliance assessments for SOC 2, HIPAA, PCI-DSS and ISO 27001, under one contract and one SLA, at a flat monthly fee.
See everything we offer on our services page, or start at our home page and tell us about your environment. If you want to harden your Azure baseline first, our guide to seven domains for an Azure security baseline is a good place to begin, and our note on which extensions to enable and why covers the next layer.
FAQ
What should I do first after enabling Defender for Cloud?
Agree who owns monitoring and remediation, then look at your Critical recommendations. Microsoft's guidance is to address Critical items immediately. Set security contacts at the same time so alerts reach a person.
How do I decide which Defender for Cloud recommendations to fix first?
Start with risk level. Defender for Cloud rates recommendations as Critical, High, Medium, Low or Not evaluated, based on environmental context, likelihood of exploitation and business impact. Work from Critical down, and group findings that share a root cause so one fix clears many.
Can Defender for Cloud cover AWS and GCP as well as Azure?
Yes. It provides CSPM for AWS and GCP through connectors. Some workload protection features use the Azure Arc agent, so check those dependencies before you plan coverage.
How do I fix recommendations across many subscriptions?
Use the tools built for scale: Fix for quick supervised changes, Azure Policy remediation tasks for existing non-compliant resources, governance rules to assign owners and track progress, and exemptions for accepted risk. Test automated remediation in a non-production scope first.
How often should we review our posture?
Microsoft advises watching regularly for configuration changes, drift and alerts, and checking threat intelligence daily. A practical split is daily for alerts and Critical items, weekly for High items, and monthly or quarterly for exemptions, plans and roles.
Sources
- Microsoft Defender for Cloud overview
- Defender for Cloud common questions: general
- Defender for Cloud planning and operations guide
- Connect your Azure subscriptions
- Onboard with PowerShell
- Determine multicloud CSPM and CWPP dependencies
- Define a multicloud adoption strategy
- Security recommendations in Defender for Cloud
- Configure security controls and remediate recommendations
- Create custom standards and recommendations