Skip to main content
tclowater
BeyondTrust Employee
BeyondTrust Employee
September 21, 2026

EPM-WM - Policy Ownership for Changes

  • September 21, 2026
  • 0 replies
  • 9 views

A common question that I’ve been receiving in newer deployments is how to build a mature process for managing EPM-WM policies and risks of what’s allowed in an organization. While Technical Account Manager (TAM) calls go into more strategy discussions based on the unique environment, there are common foundational layers that lead to more successful reviews, and security gates that should be in place regardless that any customer can adopt.

 

Getting Started with Data and Broad Strokes

Tell People What You’re Doing

If you’re afraid of telling people that there’s a change and everyone will blame this change so you don’t tell them of the change you implement, then welcome to a worse outcome 😶 The curious few will find the new item in the task-bar, see a new pop-up, etc., and will lose trust before you even get started.

The best option is to have a written policy you can point to that acts as a pointer in an EPM policy messages, your change management communications, and details any procedures internally to your organization. This includes exception policies, and, preferably, the acceptable use of technology policy.

 

Get the Data

Working with Professional Services, we typically will start with ensuring there’s a pilot group to start collecting data to build a policy. The goal is to get a policy that’s functional, and can be rolled-out to provide real security benefits along with the data needed to properly assess the estate. Security benefits include removing standing local administrative rights, speedy global blocks if needed, and learning what you’re working with.

 

I do not recommend building out the application level ‘should this even be here’ at a granular level at this point. Exceptions to having the local administrative rights removed until more in-depth policy testing can be done - yes-ish.

 

Get Broad Strokes Local Admin Removal Exceptions In Place

 

You are likely going to see abuse to any exception policy put in place. The goal is to make it easier to review, with accountability tracked, to remediate when this temporary deferral window closes.

 

If required, build out the preliminary exception policy to having local admin rights temporarily deferred for removal. This allows business users to continue with their workload and the implementation to continue with the broad-strokes use cases.

 

Tips for success

  • Ensure everything is tracked through a standard request form; and any exceptions not captured in the request forms need to be investigated for policy violations.

  • Higher level management approvals, or more than one manager approvals required may stem individual teams attempting to bypass EPM deployment.

  • Reviewing exception requests for commonalities that can help with prioritizing policy adjustments.

 

First Pass Review of Data

With the pilot users, the first pass of the data will be reviewing the events in analytics to start identifying known applications, and moving them out of the (Default) Application Groups (e.g., (Default) Any Application) by following the best practices for application group definitions.

 

Exception Handling - Undecided Applications

We strongly recommend having the time to right-size the policy with sufficient data as the pressures for a second pass are typically lower for many organizations.

Occasionally, deployments have tight deadlines driven by external factors, and this may become a more broad approach in the first pass, and a strong pressure for a second pass to ensure alignment to security goals is paramount.

 

For undecided application handling, I recommend having an application group, or a few, specifically calling out applications that are undecided in an environment. The application groups would be targeted for handling just above the catch-all group it was found in. These should be recorded with the application group name, and the cause for being undecided.

 

Example

For definitions that land in (Default) Any Application that you know are in the environment, but need a decision if it should continue in the environment, then you may need to create an application group (UNDECIDED) Passive - Auditing Enabled. The auditing will help ensure that the data required for the decisions are later available for review, while also ensure that filters for the Defaults will show only unexamined applications.

 

Continuous Policy Refinement

After the first pass has gone through, the policy has been deployed to the estate, and data is flowing in (preferably to a SIEM!), you can now start go to more granular in the policy refinement. At this point, the operational process for managing the EPM policy takes over as policy refinement is a continuous journey.

 

Review Temporary Exceptions and Modify Exception Policy

After the broader strokes roll-out has been completed, focusing on the temporary exceptions of the local administrators being deferred removal is the best first focus for remediation. While spending focused time on the individual use cases, it’s also best to update the exception policy to be more stringent for new requests. This ensures that new use cases begin flowing through the operational process to be remediated rather than adding to a backlog of use cases to remediate with a less-secure stance of having local administrative rights provisioned.

 

Application Granularity and Policy Ownership

It’s at this stage that the ownership of policy approvals digs in deeper as it is fundamental to building the granular application definitions.

 

Tips for success:

  • Your policy is never, ever, put into a change ticket. Not even for proof of changes. Your policy is protected by anti-tamper on the endpoints for a security reason; adding the policy into the change control system is an easy way to reduce the effectiveness of this security control.

  • Representation of security and desktop engineering or support teams with input from business units taken into consideration. The security teams and desktop engineering or support teams have typically different experiences and, sometimes, goals when it comes to EPM policy. Having both able to provide input can highlight potential gotchas before implementing a change. The business units may provide valuable insights such as roadmaps for tool changes, etc., which can alter policy choices going forward.

  • Sometimes the best policy means changing a business process. There are occasions where implementing EPM will highlight a desired change in a business process to meet a security goal. This is a benefit, although it can cause friction when first encountered. The best mitigating strategy for this friction is a deployment that values business process inputs and builds trust.