Nested Policy Groups

Nested Policy Groups let you organize Policy Groups into a three-level parent-child tree, where each nested Policy Group inherits the matching criteria and selected attributes of the Policy Group above it and policies cascade down the hierarchy. Instead of rebuilding the same match criteria and the same policy intent across many flat Policy Groups, you model your environment once at the top level and then refine it with nested Policy Groups that describe smaller portions of that same population.

A nested Policy Group is evaluated using its effective matching criteria: the matching criteria inherited from its parent plus the criteria defined on the nested group itself. This means a nested Policy Group always describes a subset of its parent. Policies follow the same model. A policy written between two top-level Policy Groups applies to everything nested beneath them, and a policy written on a lower level of the hierarchy takes precedence over the policy it inherits. The Policy Matrix reflects the hierarchy on both Side A and Side B, so you can expand a parent Policy Group to work at a granular level or collapse it to keep the matrix readable.

This article covers enabling Nested Policy Groups, building and managing the hierarchy, attribute inheritance, and how the hierarchy behaves in the Policy Matrix. For the fundamentals of Policy Groups themselves — Dynamic and Static types, match criteria, order of precedence, and Local Policy Groups — see the Policy Groups article.

Prerequisites

• Administrative access to Cloud Control Center with permission to modify Policy Settings and Policy Groups.
• At least one existing Policy Group to serve as a top-level parent.
• Familiarity with Policy Group match criteria and order of precedence, described in the Policy Groups article.

Enabling Nested Policy Groups

Nested Policy Groups are controlled by a tenant-wide setting. Until the setting is enabled, Policy Groups remain a flat list.

Step 1. Navigate to Policy > Policy Settings in Cloud Control Center and select the Advanced tab.

Step 2. In the Nested Policy Groups panel, turn on Enable Nested Policy Groups.

Step 3. Return to Policy > Policy Groups. Policy Groups can now be organized into parent-child hierarchies from the Actions menu of any existing Policy Group.

Understanding the Policy Group Hierarchy

The hierarchy is visible in both panes of the Policy Groups page. The tree on the left expands to show the nested Policy Groups beneath each parent, and the table on the right shows each Policy Group's position in the hierarchy in the Order column. Nesting is available for Device Policy Groups and for Workload Policy Groups, and both behave the same way throughout this article.

Element	Description
Order	Dotted notation that shows both the order of precedence and the depth of each Policy Group. A top-level Policy Group is numbered 3, its nested Policy Group is 3.1, and the next level down is 3.1.1. The hierarchy supports three levels.
Expand / collapse control	The chevron next to a Policy Group in the table or the tree shows or hides the Policy Groups nested beneath it.
Tree pane	Lists Local Policy Groups and Global Policy Groups. Nested Policy Groups are indented beneath their parent, and each parent displays the number of Policy Groups nested directly beneath it.
Name	Each level of the hierarchy is indented one step further in the table, so depth is visible without expanding the tree.
Genre, Security Level, Group Tag Value, Type	Standard Policy Group attributes. Nested Policy Groups display the attributes they inherit from their parent alongside the values that are unique to them, such as their own Group Tag Value.

Assets are classified using effective matching criteria. A nested Policy Group matches only the assets that already satisfy its parent's criteria and that also satisfy its own criteria, which makes each level of the hierarchy progressively more specific. Editing the matching criteria of a parent therefore changes the population of every Policy Group nested beneath it.

Creating and Managing Nested Policy Groups

Nested Policy Groups are created from an existing Policy Group rather than from the Create Policy Group button, so that the new Policy Group is placed directly beneath its parent in the hierarchy.

Step 1. On the Policy Groups page, locate the Policy Group that acts as the parent and click the three-dot Actions menu at the end of its row.

Step 2. Select Create Nested Policy Group.

Step 3. Complete the Policy Group configuration wizard. The nested Policy Group inherits its parent's matching criteria, so define only the additional criteria that narrow it further.

The Actions menu also contains the operations used to maintain an existing hierarchy.

Action	Description
Create Nested Policy Group	Creates a Policy Group one level beneath the selected Policy Group, inheriting its position in the order of precedence.
Move Policy Group	Moves the selected Policy Group to a different scope. Moving a parent moves the Policy Groups nested beneath it as well.
Duplicate Policy Group	Creates a copy of the selected Policy Group at the same level of the hierarchy, including the Policy Groups nested beneath it.
Delete Policy Group	Removes the selected Policy Group. Deleting a parent also removes the Policy Groups nested beneath it, and the confirmation dialog lists the nested Policy Groups that will be removed.
View / Edit Policy Group	Opens the Policy Group in read-only or edit mode. Editing a parent's matching criteria or inherited attributes propagates the change to every Policy Group beneath it.

Order of precedence is maintained within each level of the hierarchy. In Reordering Mode, a Policy Group can be moved among its siblings — the Policy Groups that share the same parent — but not to a different level.

Inheriting Attributes from a Parent Policy Group

In addition to matching criteria, a nested Policy Group can inherit a set of attributes from its parent. The choice is made in the Advanced Settings section of the Policy Group configuration wizard, using the Assignment Method options.

Setting	Description
Inherit from Policy Group	The nested Policy Group takes its Genre, Default Security Profile, Default Final Action, and Description from its parent. The four fields display the parent’s values where the parent defines them, and are locked for editing on the nested Policy Group. Changing any of them on the parent updates the nested Policy Groups automatically.
Assign Manually	The four fields become editable on the nested Policy Group, allowing it to carry a Genre, Default Security Profile, Default Final Action, and Description of its own.
Policy Group Label	Always inherited from the parent and cannot be set on a nested Policy Group. The labels applied to the parent determine the Policy Sets in which the entire hierarchy appears.

Working with the Hierarchical Policy Matrix

The Policy Matrix presents the same hierarchy on both axes. A parent Policy Group that contains nested Policy Groups displays an expand control next to its name, and expanding it adds the nested Policy Groups as rows on Side A and as columns on Side B. Policies written between two Policy Groups apply to everything nested beneath them, so you can define broad intent at the top of the hierarchy and refine it further down. For general matrix mechanics, see the Policy Matrix article.

Expanding and Collapsing the Hierarchy

Click the chevron next to a parent Policy Group to show its nested Policy Groups as additional rows and columns, and click it again to fold them away. Expanding a parent exposes the individual cells where a policy can be written against a specific level of the hierarchy.

When a parent Policy Group is collapsed, the policies defined deeper in its hierarchy remain in effect but their cells are hidden. To keep that policy visible, the empty root cell for the collapsed group displays the number of policies contained within it, and hovering over the cell displays a + control. The count appears only while the group is folded and disappears when the group is expanded and the individual cells are shown.

Cascaded and Overwritten Policies

A policy defined at one level of the hierarchy cascades to every level beneath it. Where a more specific policy is defined on a nested Policy Group, that policy takes precedence over the one it inherits, and the cell is marked as an overwritten policy. The matrix legend lists every cell state, including an overwritten variant for each policy type.

Legend entry	Description
Active Deny All / Allow All / Custom Policy	An active policy defined on the cell itself.
Active Deny All / Allow All / Custom Overwritten Policy	An active policy on the cell that takes precedence over a policy cascaded from a higher level of the hierarchy.
Simulated policy states	The same set of states for policies saved as simulations, including the overwritten variants.
Independent Control and Overwritten Independent Control	Traffic managed outside of Cloud Control Center, and the same state where a policy at a lower level of the hierarchy takes precedence.
No Policy and Disabled	A cell with no policy, which follows the default policy of the Policy Set, and a cell where policy cannot be applied.

Setting the Entity Type for Each Axis

The Side A and Side B selectors above the matrix set the entity type for each axis independently, so one axis can display Device Policy Groups while the other displays Workload Policy Groups. Each axis lists only the Policy Groups that exist for the entity type selected on it, and the hierarchy is drawn on whichever axis contains nested Policy Groups.

A tenant that has not yet created any Workload Policy Groups shows a single Unassigned Workloads group on an axis set to Workloads. That axis fills in as Workload Policy Groups are created, and gains its own expand controls once those Policy Groups are nested.

Design Considerations

• Build the hierarchy from the broadest population downward. Because a nested Policy Group can only narrow its parent, matching criteria that a nested group needs but its parent excludes will never match an asset.
• Reserve the top level for the intent that applies to every asset in the branch. Policies written there cascade to the entire hierarchy, which keeps the number of policies you maintain low.
• Use nested levels for the exceptions. A single overwritten policy on a nested Policy Group is easier to audit than a parallel set of flat Policy Groups that duplicate the same criteria.
• Plan Policy Group Labels at the parent. Because labels are inherited, the label applied to a parent determines the Policy Sets in which the whole hierarchy is available. See Policy Sets and Site Labels.
• Keep hierarchies shallow where possible. Three levels are supported, but each additional level adds another set of cells to review in the matrix.

Verifying the Hierarchy

After building a hierarchy, confirm that it behaves as intended:

1. On the Policy Groups page, check the Order column. Each nested Policy Group should show the dotted notation of its parent — for example, 3.1 beneath 3 — and appear indented beneath it in the tree.
2. Open a nested Policy Group and confirm the Assignment Method is set as intended. When Inherit from Policy Group is selected, the Genre, Default Security Profile, Default Final Action, and Description fields are locked and show the parent's values where the parent defines them, and the Policy Group Label field shows the parent's labels.
3. Review the Assets column. Assets are assigned to the most specific Policy Group whose effective matching criteria they satisfy, so a nested Policy Group draws its assets from the population of its parent.
4. In the Policy Matrix, expand the parent Policy Groups and confirm that the cascaded policies appear on the nested cells, and that any cell you overrode is marked as an overwritten policy.
5. Collapse the parent Policy Groups and confirm that the policy count shown on the empty root cell matches the number of policies you defined within that branch of the hierarchy.

To create, edit, and simulate the policies themselves, see Managing Policies Using the Policy Matrix.