Introduction

A policy is either Active or Inactive, and each control in it has its own on/off switch for that policy. Those are two levers at two levels, and choosing the right one keeps a change as narrow as you meant it.

Two switches, two blast radii

Switch	Turning it off stops	Affects
The policy	Every control in that policy, on every asset it covers	One policy
A control, on the policy's `Controls` tab	That control in this policy only	One policy — the control keeps running in every other policy that includes it

Note: The control switch is per policy. Turning a control off on a policy's Controls tab applies to that policy only. The same control keeps running in every other policy that includes it. To change what the control does everywhere, edit the control itself.

What stops, and what does not

Disabling a policy stops evaluation. From that moment nothing is checked and no incidents are raised. What it does not touch:

Existing incidents. They persist, stay triageable, and remain evidence.
Asset coverage. The Applies to configuration is untouched, so re-enabling resumes exactly where it left off — you do not rebuild the scope.
The controls themselves. They remain available to other policies.

So disabling is genuinely reversible and cheap, and it leaves a clean gap rather than a mess. That gap is the point: the period a policy was inactive is a period with no detection, and it will show as a hole in any coverage evidence later.

When disabling is the right move

A control is misfiring badly enough to be harmful — A block-action control with a bad pattern is stopping legitimate work. Switch it off in the policy, fix it, switch it back on. Faster and safer than editing under pressure on live traffic.
A policy is being reworked — Rather than leaving it half-edited and live, disable it while you change controls and scope.
A framework pack does not fit yet — Adopting a pack whose controls need substantial tuning is more manageable disabled — tune, test, then enable.

When disabling is the wrong move

Situation	Do this instead
Too many incidents from one control	Tune the control — narrow the pattern, raise the threshold. See Tuning Policy Noise
The policy is right but the agents are wrong	Change `Applies to`, not the switch
A control blocks things it should only flag	Change the action to `Flag`
One agent needs an exception	Remove that agent from the policy's coverage

The pattern behind all four: disabling is the blunt instrument. Scope, action and thresholds are the precise ones, and reaching for the switch usually means the policy is scoped too broadly.

"Disabling a policy to silence one agent is turning off the smoke alarm because you burnt the toast."

Two habits worth keeping

Say why, in the description. Nothing records the reason a policy is inactive. An Inactive policy with no explanation is indistinguishable from one someone forgot, and it will eventually be either deleted or re-enabled by someone who does not know what it broke.
Give temporary disables an end date. "Off while we tune" becomes permanent quietly. Review inactive policies on the same cadence you review incidents.

Enabling & Disabling Policies