Approval Policies: Choose Which Recommendations Need Sign-Off
A recommendation that runs without review is a recommendation nobody can defend after the fact. When an engineer clicks Remediate and a resource changes in seconds, the team discovers the gap from an incident, not from a process.
Approval policies put a gate between the recommendation and the action. In Policies, then Recommendation Approvals, admins create a policy and choose its scope. A policy can cover all recommendations, a single category, or specific rules. Each gate is scoped, staffed, and time-boxed before it takes effect. A scoped gate is one where the policy targets only the recommendations that need review, rather than blocking every action across the board.
Three Levels of Scope and the Most Specific One Wins
The scope picker offers three levels. An all-recommendations policy covers everything. A category-level policy covers one recommendation category. A rule-level policy covers individual rules inside a category.
When scopes overlap, the most specific one wins. A rule-level policy beats a category-level one, which beats an all-recommendations policy. The platform refuses to save a new policy if it overlaps with an existing enabled policy at the same scope level. This prevents conflicting approval requirements from stacking on the same recommendation.
| Setting | What it controls |
|---|---|
| Scope | All recommendations, one category, or specific rules |
| Approvers | Named users who can approve or reject |
| Minimum approvals | How many approvals before the action proceeds |
| Deadline | Days before the request expires without a decision |
Overlap detection runs before save, not after. Two admins creating policies at the same time cannot both succeed if their scopes collide at the same level.
Approvers, Minimum Count, and a Deadline Close the Policy
Each policy names its approvers, sets a minimum approval count, and picks a deadline. The approver list is a set of named users. The minimum count determines how many of those users must approve before the recommendation proceeds. The deadline sets how many days the request stays open before it expires.
A policy with one approver and a minimum of one is the narrowest gate. A policy with five approvers and a minimum of three requires consensus. The deadline prevents requests from sitting open indefinitely, which is the state that turns a review gate into a bottleneck.
New approvers can be invited inline during the approval flow. When an engineer sends a recommendation for auto-remediation approval for the first time on a rule, the platform prompts with a seven-day per-rule snooze. This prevents repeated prompts on rules the team has already decided on.
This Stops Working When the Policy Covers the Wrong Scope
An all-recommendations policy on a team that generates hundreds of findings a week creates a queue that nobody reviews. The gate exists, but the review is rubber-stamped because the volume is too high to evaluate each finding.
A policy also cannot help when recommendations are acted on outside the platform. A change applied directly in the cloud console bypasses the approval policy entirely. The recommendation may close when the next verification pass finds the resource updated, but the approval history will show no review.
For teams building custom recommendation rules, approval policies add the layer that keeps a one-click action from running before the right people have signed off.
