Skip to main content
All CollectionsPolicy ManagementHow TosAdvanced Policy [Early Access]
Inheritance Rules in the Advanced Policy [Early Access]
Inheritance Rules in the Advanced Policy [Early Access]
Updated this week

This document explains how adding or overriding a policy affects the policy set hierarchy in the new advanced policy framework. Let’s consider this simple policy setup as an example to explain the inheritance rules.

A is a root policy set

B,C,D are child policy sets of A

B further has another child policy set, E

Let’s look at how these policies interact and propagate across these levels based on hierarchy.

Alerts And Scheduled Actions

Adding a new policy

Adding at root:

If a new policy is added at A, it will be added to the entire tree - B, C, D, E. Any changes made to the policy at A will apply the same change to the rest of the tree as well.

Adding at child:

If a new policy is added and enabled at B, this policy will be inherited by B’s child, E. Additionally, the new policy will also be inherited backwards into A, but in the disabled state. From A (since A is the root), the new policy will be inherited by C and D, in the disabled state. The new policy will hence be enabled at B and E, while it will be disabled at A, C, D.

Modifying an existing policy

Modifying at root:

Modifying a policy at root will simply update the policy and propagate it to all its children.

Modifying at child:

If a new policy that was introduced (added) at B is now being modified, the modified policy will be inherited by E. The rest of the tree will remain unaffected (A, C, D).

At B, if you override a policy that has been inherited from its root A, it will have an “OVERRIDDEN” tag at B. The overridden policy from B will be inherited into its child, E. Since the override happened at the child (B), the policy at the parent (A) remains unchanged. An override is effective only in the downward direction. Hence, the policy will remain unchanged at A, C, D, while it will be modified at B, E because of the override.

Other Policy types

The below logic is applied to the following policy types:

  • Patch Management

  • Antivirus

  • Backup

  • Intelligent Alerting

  • Software management

  • Remote Desktop

  • Agent Settings

For these policy types, it is only possible to have one individual policy active at a time. For example, in a policy set you can only have one antivirus (say, ESET) enabled. You cannot have a policy for ESET and another policy for SentinelOne within the same policy set. You can always disable ESET and enable SentinelOne, however, it is not possible to have both antivirus products enabled in the same policy set. Same applies to all the policy types listed above.

Adding a new policy

Adding at root:

Adding a new policy at A, will add the policy to the entire tree (i.e, A,B,C,D,E). If any one of its child policy sets, say D, already has an existing policy of the same type, then, the existing policy will take precedence. The new policy added at A will not apply to D, and its children, if any.

Adding at child:

If B has a policy inherited from its parent A, it is not possible to add a new policy of the same type at B. For example, if A has an antivirus policy already, which has been inherited by B, you cannot create a new antivirus policy at B. You can only modify (override) it. In other words, for the policy types listed above, you cannot have multiple policies active at the same time in one policy set.

If a new policy is added and enabled at B, this policy will be inherited by B’s child, E. Additionally, the new policy will also be inherited backwards into A, but in the disabled state. From A (since A is the root), the new policy will be inherited by C and D, in the disabled state. The new policy will hence be enabled at B and E, while it will be disabled at A, C, D.

Modifying an existing policy

Modifying at root:
Modifying a policy at root will simply update the policy and propagate it to all its children.

Modifying at child:
If a new policy that was added at B is now being modified, the modified policy will be inherited by E. The rest of the tree will remain unaffected (A, C, D).

At B, if you override a policy that has been inherited from its root A, it will have an “OVERRIDDEN” tag at B. The overridden policy from B will be inherited into its child, E. Since the override happened at the child (B), the policy at the parent (A) remains unchanged. An override is effective only in the downward direction. Hence, the policy will remain unchanged at A, C, D, while it will be modified at B, E because of the override.

Did this answer your question?