Policy Sets and Site Labels

 

Overview

Policy Sets are a logical grouping of policies that can be applied to specific sites or groups of policy enforcement points within an organization. By organizing policies into sets, administrators can easily define and enforce different sets of policies tailored to the unique needs and requirements of individual sites or business units, especially as your segmentation efforts expand. This flexibility allows for more granular policy enforcement and ensures that policies are aligned with the specific characteristics and operational environments of each site. This article provides a comprehensive technical overview of Policy Sets, highlighting their benefits and practical usage, and how they contribute to a more streamlined and customizable policy management process.

Requirements

This article covers advanced policy management concepts. Before proceeding, ensure you're familiar with the following foundational topics:

Elisity Architecture: Understand how policy is enforced, managed, and distributed across your network.

Introduction to Elisity

Virtual Edge Design Guide

Policy Constructs: Policy Sets are built on top of core constructs like Policy Groups and the Policy Matrix. Review the following to ensure a working understanding:

Policy Groups

Policy Matrix

Managing Policies Using the Policy Matrix

Understanding these topics is essential for successfully implementing and managing Policy Sets.

Policy Set Structure

Policy Sets are comprised of unique selections of policy groups and policies between these groups that can be custom tailored to the needs of different sites or Business Units.

Default Policy Set

The Default Policy Set is the default, unmodifiable policy set that contains every Policy Group defined within your organization. As a reminder, Policy Groups are collections of assets defined by common match criteria to be used as policy endpoints. This Default Policy Set is distributed to all Virtual Edges (and associated Virtual Edge Nodes) that have not been configured to use a different Policy Set. In this article you will learn how to use custom-defined policy sets to distribute selective policies throughout your network.

Policy Groups and Policy Sets

User-defined Policy Sets are smaller, customized versions of the Default Policy Set. While the Default Policy Set includes all Policy Groups, a custom Policy Set includes only the groups that you choose. You can create as many Policy Sets as you need to match the specific needs of different sites or business units.

Policy Group Labels

Policy Group Labels are used to link Policy Groups to Policy Sets. These labels act like tags that help organize which groups belong to which sets. This setup makes it easier to manage and adjust policies as needed—whether for specific sites, business units, or changes over time. You can use Policy Group Labels to connect one or more Policy Groups to one or more Policy Sets. There’s no limit to how many groups or sets a label can link. Also, a Policy Group can have multiple labels, allowing it to be part of different Policy Sets.

Site Labels and Policy Set Distribution

Site Labels help control where Policy Sets are applied. In this context, a "site" means a group of Virtual Edge Nodes—not necessarily a physical location. Site Labels let you organize these nodes and assign the right Policy Set to each group. Policy Sets can be linked to multiple Site Labels, so you can apply the same policies across different groups. You can leverage Policy Sets regardless of your deployment model (Switch-Hosted Virtual Edge or Virtual Edge VM).

Each Site Label can only have one Policy Set at a time, which keeps policy enforcement clear and consistent.

By default, all Virtual Edges and Virtual Edge Nodes are part of a site label called Default.

Practical Implementation

Implementing Policy Sets involves the following steps.

  1. Administrators define Policy Groups based on discovered match criteria for assets, such as device type, device vendor, device model or user AD group, user department etc.
  2. Policy Group Labels are created, and assigned to these Policy Groups.
  3. Policy Sets are created, and Policy Group Labels are selected to import the associated Policy Groups into the Policy Set.
  4. Site Labels are created (if not yet created) to define the sites or groups of policy enforcement points (Virtual Edge Nodes) within the organization. Policy Sets are then associated with the appropriate Site Labels, effectively distributing the set of policies across the designated sites.

Note: This is one way to implement Policy Sets, however these steps do not have to go in this particular order. The order you implement Policy Sets is quite flexible. Below is a walk-through of how to implement the various components of Policy Sets described above.

Create Policy Groups

Your Policy Groups should already be created, but if not, follow our in-depth guide on how to implement Policy Groups

Create and Assign Policy Group Labels

Policy Group Labels are used to assign both Global and Local Policy Groups to Policy Sets. This determines which Policy Groups appear in the Policy Matrix for a given set, enabling policy creation between matched asset groups.

Labeling Mechanism

  • Policy Group Labels are administrative tags used to bundle Policy Groups.

  • A Policy Set imports one or more labels to make those PGs visible in its matrix.

  • Labels can include any combination of Global and Local PGs.

Devices are automatically matched to Policy Groups, but whether you see those groups when creating policies depends on the labels they have.

Policy Group Evaluation Logic

When a device connects to a Virtual Edge Node:

  1. The system checks whether the device is attached to a non-default Site Label.

  2. If so, it evaluates the device against any Local Policy Groups that belong to Policy Sets assigned to that Site Label.

  3. If no Local PG matches, the device is evaluated against all Global Policy Groups, regardless of label assignments.

This local-first evaluation ensures that site-specific classification rules take precedence, while global classification logic acts as a fallback.

Best Practices for PG Labeling

  1. Use Local PGs for Site-Specific Segmentation
    Create Local PGs in Policy Sets where devices or users have site-unique traits, naming schemes, or organizational roles. This prevents unnecessary global exposure and avoids complexity from conditional logic.

  2. Label Global PGs Based on Function or Scope
    Group Global PGs into logical labels—e.g., Clinical Devices, Contractors, or Noncompliant Hosts—that reflect usage patterns. This allows you to quickly reuse consistent segmentation logic across multiple Policy Sets.

  3. Import Only What You Need
    Avoid assigning all PG labels to every Policy Set. Limit imports to those actually required for the site's segmentation scope. This keeps matrices clean and manageable.

  4. Review the Devices View by Site Label
    To validate coverage, use the Devices dashboard filtered by Site Label. Check for devices that are matched to PGs not visible in the matrix—this is a signal to revisit label assignments or consider converting a Global PG to Local for tighter control.

Creating Policy Group Labels 

To create a new Policy Group Label:

  1. Select Policies> Policy Group Labels>+Create Policy Group Label.

    You will notice the two system-created default Policy Group Labels. These are non-modifiable and serve an important purpose, detailed below.

    • The Default Policy Group Label is automatically assigned to every user-defined Policy Group by default, associating EVERY Policy Group with the Default Policy Set. 
    • The System Policy Group Label is reserved for the default InternetPG and Unassigned Policy Groups. This dedicated label allows administrators to clearly include the InternetPG and Unassigned Groups in any Policy Set.

      Common use cases for Policy Group labels include assigning PG's to Incident Response Policy Sets and Simulation Mode or staging Policy Sets. More information on each of these use cases can be found near the end of this article. 
      Note: This dashboard is also where you can modify and delete Policy Group Labels by clicking Actions in a user-created Policy Group Label.
  2. Enter a Label Name for your Policy Group Label that aligns with the Policy Sets you are going to assign Policy Groups to using the label. Select all relevant Policy Groups from the drop-down list.

    You can create as many Policy Group Labels as needed by continuing to click + Add New Label.
  3. Click Create.
    You can modify Policy Group Labels in Policy Groups by selecting Policies>Policy Groups, clicking your desired Policy Group, and modifying the Policy Group Label field to include the appropriate labels as seen in the example below.

Create and Assign Policy Sets

Now that our Policy Group Labels are created and assigned, we need to create Policy Sets and select Policy Group Labels that we want to include in each Policy Set. 

  1. Select Policies>Policy Sets>Create Policy Set.
  2. Give your Policy Set a name, select the appropriate Policy Group Labels, and if you have created Site Labels already, select those as well. Note that Site Labels are used to assign Policy Enforcement Points, called Virtual Edges and Virtual Edge Nodes, to a Policy Set.

    Note: The System and Default Policy Group Labels are always included for a new policy set. You can remove the Default Policy Group Label, but you cannot remove the System Policy Group Label.

    The example created is as follows:

    Policy Set - Clinic Policy Set

    Policy Group Labels assigned: System, Default, Hospital A, and Hospital B

    Policy Groups:

    • Hospital A Servers (associated with Hospital A Policy Group Label)
    • Hospital B Devices (associated with Hospital B Policy Group Label)
  3. After making your selections, click Create.

You can now see the Clinic Policy Set details by going back to the policy matrix, clicking the Policy Set icon in the top left of the matrix, and selecting the newly created Clinic Policy Set. All the Policy Groups associated with the Policy Group Labels for the Policy Set will be visible on the matrix. 

IMPORTANT: Show Traffic Flow is linked to your current Policy Set, meaning the Traffic Flow View ONLY reflects traffic observed at sites or Virtual Edges (and associated Virtual Edge Nodes) where your currently selected Policy Set is distributed.

You can begin deploying or simulating policies at any time in your newly created Policy Set. When you choose to assign site labels to both this Policy Set and to your Virtual Edges, the policies will be dynamically distributed to all relevant policy enforcement nodes (Virtual Edge Nodes). 

Managing Policy Sets

On the Policy Set page, there are several columns that indicate important information about each Policy Set. 

  • Policy Set Name indicates the name of the policy set.
  • Enforcement Score quantifies and visualizes how well policies are enforced within each Policy Set.
  • Policies indicates the number of policies associated with a policy set.
  • Policy Group Labels indicate the policy group labels associated with a policy set.
  • Site Labels indicate the site labels associated with a policy set.
  • VE Nodes indicates the number of Virtual Edge Nodes that are assigned to this Policy Set through the use of Site Labels.
  • Status is a quick way to indicate whether this policy set has been deployed to any Virtual Edge in your enterprise. If this Policy Set is deployed somewhere in your network by means of the associated Site Labels being assigned to any Virtual Edge, the status will indicate In Use. If this Policy Set has not yet been distributed, the status will indicate Not in Use.
  • Parent Policy Set indicates the name of the parent policy set if you have created a Replica Policy Set.

You can find several more options for managing Policy Sets by clicking the three dots under the Actions column. Below is a brief description of each of these options. 

Edit Policy Set

Here you can change the name of your Policy Sets. More importantly, you can add and remove Policy Group Labels and Site Labels.

Create Replica Policy Set

Clicking Create Replica Policy set opens up a window to create a new Policy Set, with all the Policy Group labels of the source Policy Set pre-selected and in simulation mode.

Duplicate Policy Set

Clicking Duplicate Policy Set opens up a window to create a new Policy Set, with all the Policy Group labels of the source Policy Set pre-selected. You can then assign the Policy Set to any available Site Labels upon creation. 

Delete Policy Set

Deleting a Policy Set requires that you first unassign all Site Labels and Policy Group Labels from the Policy Set using the Edit Policy Set option.

Once this has been completed, the Delete Policy Set option will be made available and you can delete the Policy Set.

Replica Policy Sets

Replica Policy Sets are read-only, simulation-mode copies of an existing (parent) Policy Set that continuously mirror all policies and Policy Group Labels (PGLs) from the parent. PGLs are replicated to ensure that the same Policy Groups are available and consistently defined in both the parent and its replicas. This guarantees that all policies reference the correct groups across environments, preventing configuration drift and ensuring policy logic behaves identically during simulation.

This functionality allows security teams to safely test policy impact across different sites or business units while maintaining a single source of truth.

Replica Policy Sets are ideal for organizations that require controlled, mirrored environments to evaluate changes without affecting production environments.

Use Cases

  • Mirrored Policy Evaluation for Enterprise Environments
    Maintain one or more synchronized, simulation-only replicas of a production Policy Set. Evaluate changes and monitor traffic impact without any risk of enforcement.
  • Onboarding New Sites
    Assign a Replica Policy Set to new sites during the evaluation phase. Once validated, simply reassign the Site Label to the Parent Policy Set to move the site into enforcement without configuration changes.
  • Incremental Deployment with Traffic Visibility
    Create multiple Replicas from a single parent to monitor policy simulation per site. This supports phased rollouts while maintaining centralized policy management.

Creating a Replica Policy Set

Replica Policy Sets are created from the Policy Sets view in Cloud Control Center. Each Replica is linked to a Parent Policy Set and inherits all policies and PGLs from the parent.

  1. Navigate to Policies > Policy Sets.
  2. Click + Create Policy Set and select Replica Policy Set.

In the dialog window, name your replica, select a Parent Policy Set, and assign one or more Site Labels.

Note: Policy Group Labels are inherited from the Parent Policy Set and cannot be modified in the Replica Policy Set. 

After creation, the Replica Policy Set will appear nested under its Parent in the Policy Sets list. It is visually marked with a chain link icon to indicate the linkage.

Replica Policy Set Behavior

  • Replica policies are always in simulation mode.
  • All policies and PGLs are continuously synced from the Parent.
  • Replicas are read-only. Policies cannot be edited, created, or deleted directly within the Replica.
  • A Parent Policy Set can have up to five Replica Policy Sets.

A Parent Policy Set cannot be deleted if it has Replica Policy Sets associated with it. Attempting to do so will result in a validation error in the UI.
Site Labels assigned to a Replica can be changed after creation, but Policy Group Labels are always inherited from the Parent and remain locked.

Creating and Leveraging Site Labels

The final step of implementing Policy Sets is assigning them to Virtual Edges or Virtual Edge Nodes using Site Labels.

Creating Site Labels can be done in several ways:

Creating Site Labels in any of these workflows requires the same input from the user.

Create Site Labels from Virtual Edges Settings

To create Site Labels from the Virtual Edge settings page (recommended):

  1. Select Virtual Edge > Settings.
  2. In the Site Labels tab, click + Create Site Label.
  3. Fill out the following information about the site:
Site Label Name Give the Site Label a name that aligns with the naming conventions used by your organization. This might be a site code along with city name, business unit, etc.
Tags Select previously created Site Tags or type a new tag to assign to the Site Label for Filtering, Visibility, and Analytics purposes. Tags can be used similarly to Site Labels as a top level filter in the Overview, Virtual Edges, and Devices pages in Cloud Control Center. Tags can also be used in Analytics filtering.
Description Give an optional description to include additional information that may be useful for identifying how/where the Site Label is used.
+ Create Another Site Label Add additional Site Labels in the same action before clicking Create

Distributing Policy Sets Using Site Labels 

First, if you have not created Site Labels and assigned them to Virtual Edges and Virtual Edge Nodes, its time to consider what approach you would like to take.

Method 1: Assign Site Labels to VEs/VENs during onboarding, then associating the Site Label with a Policy Set when ready (Recommended)

This option stages your VEs/VENs so that when you assign the Site Label to a Policy Set, policy is distributed immediately, requiring no further action in the VE/VEN dashboard. Assigning Site Labels to VEs and VENs takes a little more time and consideration, so doing this step first makes distributing policies a much quicker process. This method also means that as you onboard VEs and VENs, you can assign a site label to them during deployment, resulting in a more efficient workflow for assigning VEs/VENs to Policy Sets.

To learn how to assign site labels to VEs and VENs, read our article on Managing Virtual Edges and Virtual Edge Nodes. After Site Labels have been assigned to your VEs/VENs, you are ready to proceed with assigning site labels to your Policy Sets. 

Assign Site Labels to Policy Sets

  1. Select Policies>Policy Sets.
  2. Select a previously created policy set, click the three dots and click Edit Policy Set.
  3. On the Site Labels tab, click Add Site Label.
    Here we can modify the Policy Group Labels and Site Labels that were associated earlier with the Policy Set.
  4. Select the site labels you would like to associate with this Policy Set by selecting them and clicking Add Label.

You can see the number of Virtual Edge Nodes that you have associated with each Site Label before clicking Save Changes.

Once you click Save Changes your policies will be distributed to all the associated Virtual Edges and Virtual Edge Nodes that have been assigned these Site Labels.

Method 2: Create and assign Site Labels to Policy Sets, then assign the Site Labels to VEs/VENs

This method stages your Policy Set with site labels FIRST, so that when you assign site labels to VEs/VENs, they are moved from Default to their assigned Policy Set.

Removing a Site Label from a Policy Set

To remove a site label from a Policy Set, or to reassign a site label, perform the following steps.

  1. Select Policies>Policy Sets.
  2. Select a previously created policy set, click the three dots and click Edit Policy Set for a deployed/in-use Policy Set with Site Labels.
  3. On the Edit Policy Set screen, click the Site Labels tab. 
  4. Select a Site label and click the Delete icon, and click Save Changes once applicable changes have been made. You can also multi-select labels and click Remove Site Labels rather than removing each label individually.

If you remove all Site Labels from a Policy Set, it will no longer be associated with any Site Label—not even the Default Site Label.

 

Using Site Labels and Tags as a Top Level Filter

Elisity Cloud Control Center now supports tag-based filtering for Site Labels across the Overview, Devices, and Virtual Edges pages. This feature enhances usability for customers managing a large number of sites by enabling logical grouping and selective filtering via top-level UI filters.

How It Works

Site Labels can now be associated with Tags, which are available as a top-level filter option in the UI. When a Tag is selected:

  • The list of Site Labels in the filter dropdown is dynamically narrowed to only those associated with the selected tag.

  • You can then select one or more of these filtered Site Labels to scope the view of devices, edges, or metrics in the active dashboard.

This workflow simplifies operations in environments with dozens or hundreds of Site Labels, allowing users to quickly focus on relevant subsets based on location, business unit, or logical grouping.

 

Using Labels in Analytics Filtering

In addition to dashboard views, Site Labels and Site Tags can be used as filters in the Analytics section of Cloud Control Center. This allows for precise data scoping based on operational groupings or infrastructure type.

You can filter analytics views by:

  • Selecting a Site Tag to limit data to matching Site Labels.

  • Selecting Device Labels to narrow the data set to specific device categories.

This enables teams to correlate behavioral, flow, or security metrics by logical groupings that align with how sites and devices are organized operationally.

Scalability

One of the key advantages of Policy Sets is their scalability. Organizations can effortlessly add or modify policies within a set without affecting the entire organization, simplifying the management of policies across different entities. Centralized administration further streamlines policy enforcement, as administrators can easily configure and manage Policy Sets through a centralized interface.

Policy Sets not only offer customization and control but also play a pivotal role in improving scalability within organizations. By leveraging Policy Sets, organizations can streamline policy distribution, ensuring that only relevant policies are deployed to policy enforcement points at each site.

Customized Policy Distribution

One of the fundamental benefits of Policy Sets is the ability to distribute policies selectively to policy enforcement points based on site-specific requirements. Rather than deploy a one-size-fits-all policy configuration to every site, each site or business unit can have customized policies. This customization enables the deployment of policies that are directly relevant to the context of each site, eliminating the need to distribute unnecessary or redundant policies.

Simplified Policy Management

Policy Sets also contribute to enhanced scalability by simplifying policy management. With traditional approaches, managing a large number of policies across numerous sites can quickly become complex and challenging. However, Policy Sets enable administrators to define and modify policies at a higher level of abstraction through Policy Groups and policy labels. This abstraction not only makes policy management more intuitive but also allows for efficient updates and modifications across multiple sites, ensuring consistency while reducing administrative overhead.

Flexibility for Growth

As organizations expand and new sites are added to their network infrastructure, scalability becomes a critical consideration. Policy Sets offer the flexibility needed to accommodate growth by easily incorporating new sites into the existing policy framework. With the ability to assign multiple Site Labels to a Policy Set, organizations can seamlessly distribute the relevant policies to new sites, ensuring consistent policy enforcement while maintaining scalability as the network expands.

 

Using Policy Sets as an Incident Response Tool

Policy Sets can also be used creatively to provide solutions for problems that have traditionally been very hard to solve for, far beyond everyday network security management. In the realm of incident response, policy sets can prove to be an invaluable tool for swiftly and decisively handling cybersecurity emergencies while minimizing operational disruptions.

Consider a scenario where an organization faces a critical security breach or cyberattack targeting specific manufacturing units or production sites. The priority becomes mitigating the threat and containing the potential damage. In such cases, traditional methods of reconfiguring policies across the entire network could be time-consuming and disruptive to the core business functions.

This is where Policy Sets come into play. By strategically deploying a more restrictive "incident response" Policy Set to the affected sites, organizations can rapidly and aggressively shut down all unnecessary traffic while ensuring the continuity of essential operations. This incident-specific policy set should be designed to contain most, if not all, of the policy groups present in the organization's standard "Default" Policy Set, but with additional policy restrictions in place.

The incident response policy set acts as a powerful tool to swiftly contain the threat. It enforces stringent network access controls, tightly restricting traffic to only essential communication channels. This effectively isolates the compromised segments while allowing critical business functions to continue running without interruption.

In practical terms, the process involves associating the incident response policy set with the affected sites using site labels. This action triggers the deployment of the more restrictive policies exclusively to the sites experiencing the security incident. Once the threat is neutralized and the situation is under control, reverting to the standard Default Policy Set is a straightforward process.

 

Was this article helpful?
1 out of 1 found this helpful