To apply a pre-configured response template to your policy, complete the following steps:

1. Navigate to the Policies page.
2. Select the Automated Response policy you want to configure, or create a new Automated Response policy.
3. Click one of the three template buttons: Minimal, Moderate, or Aggressive.
4. Review the default severity-level settings the template has applied.
5. Optionally, adjust individual severity toggles for the desired response actions (Kill, Quarantine, Isolate) on (Yes) or off (No).
   Note: Some options may be greyed out at lower severity levels due to safety constraints.
6. Click Save to apply the policy.

The selected template's response actions are applied across all severity levels. Existing rule-specific overrides are preserved.

To configure a custom response for a specific detection rule, complete the following steps:

1. Navigate to the Policies page.
2. Select the Automated Response policy you want to configure, or create a new Automated Response policy.
3. In the Rule Specific Override section, click Add Rules.
4. In the Manage Custom Responses modal, select the detection rule(s) you want to override.
   Note: Rules already added to the override list are removed from the selection list to prevent duplicates.
   
   
5. Click Save.
6. Configure the desired response actions (Kill, Quarantine, Isolate) for each selected rule.
   
7. In the top right of the Edit Policy, click Create/Save to apply the overrides.

The selected rules now use the override settings instead of inheriting from the severity-level defaults. The override count updates to reflect the new configuration.

NOTE  To remove all rule-specific overrides and revert rules to the severity defaults, click Clear All.

Although it is natural to think automated responses should be applied when you are onboarding new customers, it is recommended you take some time to monitor existing behaviors first.

A good rule of thumb is implementing automated response policies 30 days after customer onboarding. During this ramp-up time, a typical customer will have triggered the baseline of alerts you'd expect to see in their environment. You will have the time to review these detections and the possible responses before applying policies.

During the monitoring period, you should review the rules triggered along with the recommendations created by the Datto EDR Content Engineers to determine if the recommendation would disrupt the behavior in a way you are comfortable with.

There may be cases where the recommended response actions could disrupt legitimate business operations. In these situations, you can override the recommendations in the policy for a specific client.

For example, backup software running on a domain controller may create a dump of the Active Directory database (NTDS.dit) as part of normal backup activity. Although authorized, this behavior may trigger the NTDS Dump detection rule, which can recommend actions such as Kill Process or Isolate Host. To avoid interrupting approved business processes, administrators can customize the policy and override the recommended response actions, allowing the backup software to run without triggering automated remediation.

Suppressed alerts supersede automated responses.

When an alert matches a suppression rule, no automated response actions occur. Suppressing specific, false positive alerts is better than overriding or customizing actions in the automated response policy as those changes apply to a rule and not the exact matched criteria from a suppression.

A default policy can be beneficial when supporting endpoints in a known network or from a single business vertical such as retail or manufacturing.

This concept is based on the idea you are already aware of all the standard business applications and have created the suppression rules needed to address any applications that may trigger behavioral events. The opposite may apply to MSPs that support customers from multiple business sectors. In this case, it might be better to deploy new organizations without automated response policies so you can monitor the possible outcomes and adjust them before applying changes.

The severity-level settings change to match the new template, but your rule-specific overrides are preserved.

For example, if you switch from Aggressive to Minimal, the severity toggles update to the Minimal configuration, but any custom overrides you previously configured remain intact.

Existing policies are automatically analyzed and mapped to the closest matching template with no loss of configuration.

During migration, the system selects the template that most closely matches your current settings. Any unique configurations that do not fit the selected template are preserved as rule-specific overrides. Override counts are displayed next to each severity level so you can review what was migrated.

Safety constraints prevent enabling high-impact actions at lower severity levels.

To reduce the risk of accidental negative impact, Quarantine File is disabled for Low and Medium severity levels, and Isolate Host is disabled for Low severity. These constraints apply only to severity-based toggles—rule-specific overrides are not subject to these restrictions.

Rule-Specific Overrides take highest precedence followed by Severity Settings.

When a detection is triggered, the system first checks for a rule-specific override. If no override exists, it applies the response configured for the alert's severity level. If Use Rule Default is enabled and the detection rule has a predefined response, that response is used. If Yes is selected, the configured response action is performed for alerts of the selected severity. If No is selected, no automated response action is performed for alerts of the selected severity.

The rule reverts to inheriting the severity-based response settings.

Once an override is removed, the detection rule falls back to whatever response actions are configured at its severity level. No additional action is required.