# Policy: Phased Rollout Planning ## Phased Rollout Approach A phased rollout allows administrators to observe real-world policy behavior — what would be blocked, allowed, or flagged — before any controls are enforced, eliminating the risk of accidentally locking users out of legitimate workflows. Starting in Monitor mode also builds a behavioral baseline that makes it far easier to write precise, well-targeted policies rather than guessing at filters and rules upfront. By the time enforcement is enabled, both administrators and end users are informed, prepared, and confident in the outcome. Before enforcing any policy, use the policy status lifecycle to safely validate behavior without impacting users: * **Monitor** — The policy is evaluated and logged, but no controls are applied. Users are unaffected. Use this to establish a behavioral baseline and confirm your filters are matching the right users, machines, and applications. * **Monitor & Notify** — Same as Monitor, but users receive an informational notification that the action is being observed. Use this to build awareness and prepare users for upcoming enforcement without disrupting workflows. * **Enforce** — Controls are actively applied (Allow, Deny, MFA, Justification, Approval). Only switch to Enforce after you've confirmed policy behavior in the prior stages. ## Example Phased Rollout Plans ### File Access Policy Phased Rollout Plan File Access policies control which applications can read, write, or execute files and folders. Because these policies can affect a wide range of applications and workflows, a gradual rollout is essential. **Phase 1 — Monitor** Create a File Access policy targeting **all users, all machines, all applications** and set it to **Monitor** mode. Review the audit logs to understand what file access activity is occurring across your environment. Identify any sensitive paths that require protection, and confirm your folder targeting (including variables like `{userprofile}`) is resolving correctly. Once you have identified which executable files you would like to control access to (such as PowerShell, Command Prompt, DMG, pkg, or applications in Downloads and home folders): * Use wildcards for any executable not in a protected path. * Create collections for sensitive areas where additional controls are required. * Create policies that restrict unmanaged areas such as Downloads and home folders and require Approval. Set these policies to **Monitor & Notify** without acknowledgement (ACK). **Phase 2 — Monitor & Notify** Switch to **Monitor & Notify** with ACK. Users will begin receiving informational notices that their file activity is being observed and that additional controls will be required in the future to execute. This builds awareness and surfaces any unexpected friction before enforcement begins. **Phase 3+ — Enforce** Switch to **Enforce** and apply appropriate controls: * **Deny** for prohibited paths. * **Justification** for sensitive directories. * **Approval** for high-risk operations. Tune filters based on what you observed during the monitoring phases. Consider starting with Justification or Approval controls before moving to hard Deny rules. > **Note:** While wildcards are the recommended starting point for policy coverage, some executables may warrant an explicit Allow or hard Deny based on your organization's needs. These can be defined in more granular policies as appropriate. #### **Recommendations:** * Use variables such as `{userprofile}`, `{systemroot}`, and `{programfiles}` to write cross-platform, portable policies. * Target sensitive directories explicitly (e.g., credential stores, configuration folders) rather than broad-blocking everything. * Use collections to scope enforcement to groups most likely to access sensitive paths before rolling out org-wide. * Non-executables should be specifically targeted where they contain sensitive information — for example, configuration files that include keys, passwords, or account names (e.g., `hosts.inf`, `/etc/hosts`). *** ### Privilege Elevation Policy Phased Rollout Plan Privilege Elevation policies govern when and how users or processes can run with elevated (administrator) rights. These policies directly affect users' ability to install software, modify system settings, and run admin tools, so validation before enforcement is critical. **Phase 1 — Monitor** Create a Privilege Elevation policy targeting **all users, all machines, all applications** and set it to **Monitor** mode. Review audit logs to identify: * Which elevation requests occur most frequently. * Which applications are being run as elevated. * Which users or machines are generating the most activity. **Phase 2 — Monitor & Notify** Switch to **Monitor & Notify**. Users performing elevation requests will receive a notification that the action is being tracked. This is an opportunity to communicate upcoming changes to your user base and gauge the volume of requests that will require controls when enforced. **Phase 3+ — Enforce** Switch to **Enforce** and apply controls appropriate to the risk level of each action. Common starting configurations include: * **Allow** for known-safe, business-critical applications. * **Justification** for elevation requests that are infrequent or require an audit trail. * **Approval** for high-risk or unusual elevation scenarios. * **MFA** or **Approval + MFA** for highly sensitive administrative tools. #### **Recommendations:** * Use collections to target high-risk user populations (e.g., developers, IT staff) before rolling out broader enforcement. * Establish specific Allow policies for well-known, sanctioned applications before enforcing a broad Deny. This minimizes disruption to legitimate workflows. * Pair Privilege Elevation policies with Least Privilege policies for a complete admin control strategy. *** ### Command Line Policy Phased Rollout Plan Command Line policies control which commands, scripts, and shell operations users can execute. Because command line access is a common attack vector — and also essential for many legitimate workflows — these policies require careful baselining before enforcement. **Phase 1 — Monitor** Create a Command Line policy targeting **all users, all machines, all shell applications** (e.g., `cmd.exe`, `powershell.exe`, `pwsh.exe`, `bash`) and set it to **Monitor** mode. Review audit logs to identify: * Which commands are being run, by whom, and from which machines. * Commands with high-risk potential such as `format`, `rm -rf`, `net user`, `reg`, or script execution patterns. **Phase 2 — Enforce** Switch to **Enforce** and apply controls. Common configurations include: * **Deny** for known-dangerous commands (e.g., destructive file operations, user account manipulation, registry edits outside approved workflows). * **Justification** for commands that are occasionally legitimate but require an audit trail. * **Approval** for commands that require explicit authorization from a supervisor or security team. **Understanding Policy Scope** Before writing Command Line policies, it's important to understand how policy scope is determined: * A policy with no `Extensions` section is a **wildcard elevated-only policy** — it acts as a wildcard sudo policy and applies to all elevated commands. * To apply a policy to **non-elevated commands**, the `Extensions` section must explicitly include `"IsElevated": false`. * A policy with no `AllowCommands` section in `Extensions` is a **wildcard command line policy**, meaning it applies to all commands. Once commands are listed in `AllowCommands`, the policy applies only to those specific commands. * Specific policies take precedence over wildcard policies, consistent with standard policy evaluation rules: * If a command is listed in `AllowCommands` with an **Allow** control, it will be allowed even if a wildcard policy requires a control such as MFA. * Conversely, if a specific policy requires **Justification**, that control applies even if a second specific policy for the same command is set to Allow. **Recommendations:** * Start with the predefined policies as a baseline, then iterate. * Start with a targeted Deny list of the highest-risk commands rather than attempting to whitelist everything at once. * Scope initial Command Line policies to elevated contexts (e.g., `sudo`, `runas`, elevated shells) before applying broader controls. * Use `AllowCommands` and `DenyCommands` together to define precise combinations within a single shell application. * Keep policies specific: avoid overly broad wildcards on command patterns, which can produce unexpected matches. Review the Wildcards reference before writing command patterns. *** ### Least Privilege Policy Phased Rollout Plan Least Privilege policies remove standing administrator rights from users, reducing the attack surface for lateral movement and privilege abuse. Because this policy type directly changes what users can do on their machines, it carries the highest potential for disruption and requires the most careful planning before rollout. **Phase 1 — Enforce** Before enabling enforcement, finalize the following: * Your exclusion list (e.g., IT staff, break-glass accounts, service accounts that require standing admin). * Privilege Elevation policies are already in place and tested for actions users may need to perform post-demotion (e.g., installing approved software, running admin tools). * A helpdesk escalation path exists for users who experience unexpected friction. Once the above are confirmed, switch to **Enforce**. The policy will begin removing local administrator rights from matched users. #### **Recommendations:** * Always configure Privilege Elevation policies **before** enforcing Least Privilege. Removing admin rights without an elevation path in place creates immediate friction. * Use exclusions to protect service accounts, local IT admins, and any users with documented business justification for standing admin rights. * Pilot enforcement with a small, non-critical deployment group before rolling out org-wide. Confirm the elevation workflow is smooth before expanding scope. * Consider rolling out by department or machine group — start with users least likely to have complex admin dependencies. * Treat this as a change management exercise, not just a technical one. User communication and manager alignment are as important as policy configuration. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.keeper.io/en/keeperpam/endpoint-privilege-manager/policies/policy-phased-rollout-planning.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.