Policies control how Defend behaves on enrolled devices — how sensitive the detection engine is, which automated response actions run when rules fire, and how those settings are applied across device groups. Configuring policies correctly reduces noise, decides which threats are surfaced most urgently, and lets you apply different settings to different client environments.
What Policies Configure
Policies cover several categories of settings accessible under Settings:
- Detection sensitivity — how aggressively rules fire on ambiguous signals
- Response behavior — which actions (isolate, kill process, run playbook) a matching rule is configured to take. ⚠️ These take effect automatically only where automated response has been enabled; otherwise the rule creates an alert and a technician acts
- Protection settings — tamper protection, local detection options
- Alert settings — thresholds and routing for alert notifications
- Response templates — predefined action sets that can be attached to rules
- Deployment settings — telemetry configuration and agent update behavior
Configuring Detection Sensitivity
Detection sensitivity controls how the engine scores ambiguous events. Higher sensitivity catches more threats but increases false positive rates. Lower sensitivity reduces noise but may miss low-confidence signals.
- Go to Settings → Policies.
- Select or create the policy you want to configure.
- Adjust the sensitivity slider or discrete level (the available levels depend on the rule category).
- Save the policy.
Changes apply to all devices in the device group assigned to that policy.
Configuring Automated Response
You can attach a SOAR playbook to a policy so that when a rule at a defined severity fires, the playbook runs without a technician clicking through the alert.
Automated response is off by default. Attaching a playbook to a policy configures what would run; it does not by itself make Defend act on its own. Automated response has to be enabled for your environment as a separate, deliberate step. Until that is done, a matching rule raises an alert and a technician takes the action.
- Go to Settings → Policies.
- Open the policy.
- Under Automated Response, pick a severity threshold (for example, auto-respond on Critical detections).
- Assign a playbook to run when the threshold is met.
- Save.
Be deliberate about automated isolation. Isolating a device interrupts the end user immediately and may disrupt business operations. Start with automated playbooks that only notify or collect forensics, then escalate to automated isolation once you have confidence in the detection quality for that client.
Applying Policies to Device Groups
Policies are applied through device groups. A device group is a named collection of enrolled devices that share the same policy.
- Go to Settings → Deployment → Device Groups.
- Create a group or open an existing one.
- Assign devices to the group by device name, OS, or organization.
- Set the policy for the group.
Devices that are not in any group receive the default policy. The default policy should be a conservative baseline — not the most aggressive sensitivity level.
Managing Detection Rules
Rules are the individual detection conditions that fire inside a policy's scope. Go to Rules to:
- View the curated rule library and which rules are enabled.
- Enable or disable individual rules.
- Create custom rules with your own match conditions and MITRE mapping.
- Edit existing rules to tune match conditions or change severity.
Custom rules apply across all policies unless you scope them to a specific device group.
FAQ
What is the default policy? The default policy is seeded when an organization is first set up through the onboarding wizard. It enables the curated rule library at a moderate sensitivity level with no automated response actions. You can edit it, but you cannot delete it.
Can different clients have different policies? Yes. Each client organization has its own device groups and can have its own policy. MSP-level global policies set a baseline that client policies layer on top of.
How do I know if my policy is working? Review the MITRE coverage map under MITRE Coverage. It shows which tactics and techniques your enabled rules map to — a read of the rule store, not a measurement of what the engine is doing. On the arm in force today the engine's own KQL rule runtime is retired on this arm, so it evaluates no rule and no rule fires to be counted. An attack simulation does not close that gap either: the console records the simulation and reports no fired rules.