Understanding Policy Order in ThreatLocker

Policy Order

ThreatLocker evaluates policies in a specific order to determine whether an action should be permitted or denied. When an action is taken on an endpoint, the ThreatLocker Agent will review the applicable policies from the top of the list down until it finds one that matches the activity. Once a match is found, that policy is enforced, and no further policies are evaluated.

This means that policy order directly affects what is permitted or denied in your environment. If a broad policy is positioned above a more specific one, the specific policy will never be applied. Understanding how policy order works is essential when troubleshooting a policy’s behavior or creating exceptions.

Note: The order in which the agent processes policies may not be exactly the same as the order displayed in the ThreatLocker Portal. The factors that can cause this difference are outlined below.

How Policy Order is Determined

The position of a policy, and when it is evaluated, is determined by three factors:

1. Order Number – The number assigned to the policy.
2. Policy i – Whether your organization uses a Policy Hierarchy or a Flat Policy Structure.
3. Built-In Application Prioritization – Whether built-in applications are prioritized over custom applications (in Allowlisting policies only).

Order Numbers

Every policy is assigned an Order number, which determines its evaluation relative to other policies in the same list. Policies with a lower Order number are evaluated before those with a higher Order Number; for example, a policy with an Order Number of 10 is checked before one with an Order number of 500. If two policies share the same Order number, the most recently created policy will appear higher in the list and be evaluated first.

Policy Structures

Each ThreatLocker product maintains its own separate policy list, and each list uses one of two structures: Policy Hierarchy and Flat Policy Structure. Allowlisting and Storage Control can use either structure, depending on your organization's configuration.

Policy Hierarchy

In a Policy Hierarchy, policies are grouped into Policy Levels based on its scope set by its Applies To field. These Policy Levels will be evaluated in the following order and illustrated below:

1. Global: Policies apply to all assets in the currently managed Organization and all child Organizations.
2. Global Groups: Policies apply to all assets belonging to the designated Global Group in the currently managed Organization and all child Organizations.
3. Entire Organization: Policies apply to all assets in the currently managed Organization.
4. Individual Assets: Policies apply only to the asset (computer or mobile phone) specified.
5. Device Groups: Policies apply to all assets in the designated Device Group in the currently managed Organization.

In a Policy Hierarchy, Order number only apply within a Policy Level. For example, a policy applied at the Computer Level will always be evaluated after a policy that is applied to the Entire Organization, even if the Computer Level policy has a lower Order number.

Note: Policies hierarchies are only available for Allowlisting and Storage Control for Microsoft Windows agents below version 10.5.3 in organizations created before Portal version 3.3.1. These products in newly-created organizations are not offered in a policy hierarchy.

Flat Policy Structure

In a Flat Policy Structure, all policies are kept in a single list, and the Order number alone determines where a policy is positioned. This structure gives you more direct control over which policies take precedence and makes it easier to create exceptions. For example, a Computer Level policy can be evaluated before an Entire Organization policy by assigning it a lower Order number.

Note: Newly-created organizations will come with the flat-policy structure already enabled.

Transferring to a Flat Structure

Organizations may choose to transfer (or “flatten”) eligible policy lists from a policy hierarchy to a flat policy structure to gain more direct control over policy precedence, reduce policy duplication, and standardize policy processing across ThreatLocker objects.

See this Knowledge Base article to learn how to transfer policies in a policy hierarchy to a flat structure.

Built-In Application Prioritization

Built-in Application Prioritization, enabled through the Configure Application Prioritization advanced setting, instructs applicable ThreatLocker agents to evaluate Allowlisting policies targeting built-in application definitions before policies targeting custom application definitions, according to their respective assigned Order numbers. It is enabled by default.

Built-in prioritization affects how a ThreatLocker agent will process the order of an Allowlisting policy list but does not affect how the policies in the list are ordered or displayed. The order in which Allowlisting policies are evaluated by agents where this setting is enabled may differ from the order displayed in the Allowlisting policy list in the Portal.

Note: This Advanced Setting is ONLY available for Allowlisting.

See this Knowledge Base article for more information on configuring the Configure Application Prioritization advanced setting.

Working with Order Numbers

Policy Order numbers are automatically assigned when a policy is created and can be edited afterward. Creating, deleting, repositioning, or modifying the Applied To field of a policy entry may result in different behavior depending on the specific ThreatLocker product and the arrangement of other policies in the policy list.

After completing any of the actions described below, an applicable Deploy Policies button must be clicked to ensure the changes are downloaded by their respective ThreatLocker agents.

Repositioning a Policy

A policy can be repositioned by changing its Order number through two methods:

A lower Order number moves the policy closer to the top of the list, and a higher Order number moves it closer to the bottom.

Please keep the following in mind when repositioning policies in your organization:

• Deleting a policy does not renumber the remaining policies.
• Changing a policy’s scope preserves its existing Order number.
• ThreatLocker recommends avoiding duplicate Order number whenever possible to keep policy evaluation predictable.

Order Numbers When Creating a Policy

When creating a new policy, the Order number and corresponding position within the policy list, or within a specific Policy Level, are determined by the Policy Order setting:

All new policies will be added to the top or bottom of the policy list, or Policy Level in policy hierarchies, with the following exceptions:

• In some products, if the top or bottom most policy is already assigned the lowest or highest available Order number, the new policy will assigned the next lowest or highest number value available and arranged accordingly.
• In Allowlisting policy hierarchies, a new policy will be assigned an Order number value of 100 if no other policiy exists in the same Policy Level.
• In Storage Control policy hierarchies, a new policy will be assigned an Order number value of -1 if no other policiy exists in the same Policy Level.
• Secure Network policies are always created at the top of the policy list.

Move Policy to Top and Move Policy to Bottom Features

Both Allowlisting and Storage Control provide ‘Move Policy to Top’ and ‘Move Policy to Bottom’ buttons when you are editing a policy. These button options mean different things depending on the policy structure within your environment:

• Flat structure– ‘Move Policy to Top’ assigns the policy the same Order number as the current top-most policy. ‘Move Policy to Bottom’ assigns the next available Order number after the current bottom-most policy.
• Policy Hierarchy – ‘Move Policy to Top’ assigns the policy the same Order number as the current top-most policy in the same Policy Level. ‘Move Policy to Bottom’ assigns the next available Order number after the current bottom-most policy in the same Policy Level.

Order Numbers of Policies Created Through Approval Requests

Policies created automatically through the Approval Center requests will be assigned Order numbers as described below:

Note: Automatically created policies can result in duplicate Order numbers. After approving requests, ThreatLocker recommends reviewing these policies for conflicts with existing policies.

Order Numbers of Policies Created Through Application Control Learning Mode

Policies created automatically through Application Control Learning Mode will be assigned Order numbers as described below:

Note: Automatically created policies can result in duplicate Order numbers. After approving requests, ThreatLocker recommends reviewing these policies for conflicts with existing policies.

Default Policy Order Numbers

When a new organization is created, it will include a set of default policies that occupy reserved Order number ranges:

Note: In flat policy structures, the Order numbers of the default Allowlisting policies are read-only.

Duplicate Order Numbers

If two policies in the same list (or the same Policy Level in a Policy Hierarchy) share an Order number, the policy that was created most recently will be positioned higher in the list. Duplicate Order number most commonly occur when policies are created automatically, such as through Learning Mode or request approvals. ThreatLocker recommends reviewing and adjusting these values as needed to prevent conflicting policies in your organization.

Order Numbers After Transferring a Policy Hierarchy to a Flat Policy Structure

When an Allowlisting Policy Hierarchy is converted to a flat structure, all policies are automatically renumbered. The top-most policy will be assigned Order number 101, and the remaining policies will be reassigned based on Policy Type. The following is taken into consideration by ThreatLocker when this occurs:

Custom application policies are further grouped within their range according to their former Policy Level, in the same order as the original Policy Hierarchy.

Special Cases That Affect Policy Order

Elevation Control on Allowlisting Policies

When Elevation Control is applied to an Allowlisting policy, how it is processed depends on the agent version:

• ThreatLocker Windows Agents Version 9.7 and later – No specific Order number is required. When elevation is requested, the agent evaluates all matching policies with Elevation Control applied, regardless of their position in the list.
• ThreatLocker Windows Agent Version 9.7 and below – The policy with Elevation Control applied must have a lower Order number than other policies targeting the same application and objects, ensuring that the elevated policy matches first.

Built-In and Custom Definitions in the Same Policy

When Built-In Application Prioritization is enabled, a single policy that targets both a Built-In application definition and a custom application definition may not successfully match the custom definition. In these cases, ThreatLocker recommends creating separate policies for each definition.

Policy Order Best Practices

To keep your policies evaluating as intended, ThreatLocker recommends the following:

• Regularly review your policy lists and their assigned Order numbers.
• Avoid duplicate Order numbers within the same policy list or level, and reassign duplicates when possible.
• When reviewing policies, select the Inactive/Expired checkbox to display hidden and inactive entries so that nothing is overlooked.
• After approving requests, verify the order of any automatically created policies to ensure no conflicts arise.

Troubleshooting Unexpected Policy Behavior

If a policy is not behaving as expected, review it in the context of its position among all other policies. In nearly all cases, unexpected results occur because another policy was matched first. The following steps will help you identify the cause:

1. Confirm the policy applies to the expected endpoint.
2. Verify whether the product uses a Policy Hierarchy or a flat structure.
3. Review the policy’s Order number and position in the list.
4. Check for duplicate Order number.
5. For Allowlisting, verify whether Built-In Application Prioritization is enabled.
6. Determine whether another matching policy exists higher in the evaluation order.
7. Consider the special cases described above that may affect when the policy is processed.

Since ThreatLocker enforces the first matching policy it encounters, reviewing policy order is often the fastest way to determine why a particular outcome occurred.