# Policy: Global Allow File Access - Require Approval
This example shows a **File Access Policy** used as a **Global Approval Requirement for running applications**. When enabled, it applies to any application a user tries to launch, creating a single, top‑level control point across all endpoints. After this **Baseline File Access Policy** is in place, additional policies can be added to allow specific applications, teams, or scenarios to run without approval.
***
### What this Policy Does
When a user on any **in-scope endpoint** tries to run an application:
1. The request is evaluated by the **File Access** policy engine.
2. Because the policy is broadly scoped (all users, all applications), it matches most execution attempts on those endpoints.
3. The policy requires **Approval** within the **Admin Console** before allowing the action to proceed.
### Why it Behaves this Way
This policy is intentionally written as a “broad match” policy, then applies a control:
* **Enforced**: The policy is active and will apply controls (not just log).
* **Approval control on success**: When the policy matches, it triggers an approval workflow.
* **All users**: A wildcard user filter makes it apply to any user account on in-scope machines.
* **All applications**: A wildcard application filter makes it apply to any application being evaluated by this File Access policy.
* **Built-in checks**: Standard checks (user, machine, file, date/time/day, certificate) are present. If those constraints aren’t narrowed (for example, no date/time/day/cert restrictions are provided), the policy behaves like a broad catch-all for execution on the targeted endpoints.
### What the User Experiences
* Most application launches on the targeted endpoints will generate an **approval request**.
* The policy includes a user-facing notification message. If the message references a specific date or one-off event, replace it with something generic (or remove it) to avoid confusion in production.
***
### Important Notes and Common Adjustments
* **High prompt volume**: Because this applies to *all* applications, it can create a lot of approvals—especially when expanded to many endpoints.
* **Narrow the scope** if needed:
* Restrict the application filter to a specific set of executables or paths
* Restrict the user filter to specific users/groups
* Add certificate/publisher constraints to treat trusted vs. untrusted software differently
* Add time/day/date restrictions for staged rollouts or business-hours-only enforcement
***
## How Build a Baseline File Access Policy
{% stepper %}
{% step %}
#### Create Policy
From the **Policies** tab of the Admin Console's Endpoint Privilege Manager page, click the **Create Policy** button.
This will open the **Create Policy Form** in a modal window.
{% endstep %}
{% step %}
#### Policy Name
Enter a descriptive name for your new Baseline File Access Policy.
{% endstep %}
{% step %}
#### Policy Type
Select **File Access** from the **Policy Type** select list.
{% endstep %}
{% step %}
#### Status
Select the status that you would like your new **Baseline File Access Policy** to be in upon submission of the completed **Create Policy** form.
{% endstep %}
{% step %}
#### Controls
Select **Require approval** from the **Add Control** sub-form.
{% endstep %}
{% step %}
#### User Groups
Click the **Add Group** link in the Create Policy form. This will open the **Add Group** sub-form.
Check the **Select all users** checkbox in the **Add Group** sub-form then click off of the sub-form to close it. **All Users and Groups** will now appear under **User Groups** as applied to your **Baseline File Access Policy.**
{% endstep %}
{% step %}
#### Machine Collections
Click the **Add Collection** link in the Create Policy form. This will open the **Add Collection** sub-form.
Check the **Select all machines** checkbox in the **Add Collection** sub-form then click off of the sub-form to close it. **All Machines** will now appear under **machine Collections** as applied to your **Baseline File Access Policy.**
{% endstep %}
{% step %}
#### Applications
Click the **Add Applications** link in the Create Policy form. This will open the **Add Applications** sub-form.
Check the **Select all applications** checkbox in the **Add Applications** sub-form then click off of the sub-form to close it. **All Applications** will now appear under **Applications** as applied to your **Baseline File Access Policy.**
{% endstep %}
{% step %}
#### Date & Time
For a **Baseline File Access Policy,** it is recommended that the **Date and Time Ranges** be set to **Always**, ensuring the block is continuously enforced with no time-based gaps.
{% endstep %}
{% step %}
#### Save Your New Baseline File Access Policy
Once the form has been sufficiently filled in per the previous steps, the **Save** button will be changed from an inactive to an active state. Click on the **Save** button. The **Create Policy** modal form will be closed and your **Baseline File Access Policy** will be saved.
Why this Baseline File Access Policy Should be your First Policy
This pattern — a **Baseline File Access** which **Requires Approval** that catches everything by default — serves a very specific and important strategic purpose in endpoint privilege management. Here's a full breakdown of the use-cases and the reasoning behind it:
### The Core Concept: "Default-Deny via Default-Require-Approval"
Rather than trying to enumerate every dangerous application upfront (which is nearly impossible), this approach **inverts the model**: everything requires approval by default, and you then carve out exceptions for trusted, known-good applications. It's conceptually similar to a default-deny firewall rule at the bottom of a ruleset.
### Primary Use-Cases
#### 1. Regulated or High-Security Environments
Organizations subject to compliance frameworks like HIPAA, PCI-DSS, SOC 2, or government/defense mandates often need to demonstrate that **no unauthorized software can execute** on managed endpoints without a documented approval chain. A global file access with required approval as a baseline policy creates a single, auditable control point for every application launch.
#### 2. Application AllowListing Rollouts
This policy is the ideal **foundation layer** when an organization is building out an application allowlist. Rather than blocking everything immediately (which would be disruptive), you:
* Start with a global approval requirement within a baseline policy (less disruptive — users can still run things, but must request approval)
* Observe what gets requested
* Add targeted **Allow policies** above it for IT-approved software (approved apps pass through without triggering the approval gate)
* Over time, transition toward a true deny policy at the baseline once the allowlist matures
This policy structure is intentionally written as a "broad match" policy that applies a control — because the user and application filters both use wildcards, it functions as a broad catch-all for execution on targeted endpoints.
#### 3. Pilot or Phased Deployment
This type of policy is useful for demonstrating how to introduce an approval workflow for application execution across a group of endpoints — for example, a pilot group or a department. Security teams can validate the approval workflow, tune approver capacity, and build the exception list before rolling out to the full fleet.
#### 4. Zero-Trust Endpoint Posture
In a zero-trust model, **implicit trust is eliminated** — even for standard user applications. A global file access with required approval as a baseline policy enforces that posture at the execution layer. No application is implicitly trusted simply because it's present on the machine.
#### 5. Incident Response / Breach Containment
If an organization has experienced (or suspects) a compromise, this policy can be rapidly deployed to **lock down a segment of endpoints** — requiring every application launch to be human-approved — while the investigation proceeds, without immediately blocking everything and causing a full outage.
#### 6. High-Risk User Groups or Machines
For specific populations like contractors, third-party vendors, or endpoints in sensitive network segments (e.g., OT adjacent, finance systems), a global approval policy provides maximum oversight without requiring granular per-app policy authoring upfront.
***
### Why File Access Policy (Not Privilege Elevation) for the use-cases?
This is a nuanced but important distinction. A **File Access policy** intercepts the *execution* of a file (the moment an application is launched), while a Privilege Elevation policy only intercepts attempts to run something with elevated privileges. By using File Access here, the approval requirement applies to **any application launch** — regardless of whether the user needs admin rights — giving broader coverage.
#### The Layered Policy Strategy That Follows
Implement sophisticated policy combinations using layered policies — applying multiple policies to the same resources for defense-in-depth. Once this baseline file access policy is in place, the operational model looks like this:
| Priority | Policy | Scope |
| --------------- | ----------------------------------------------------- | ------------------------ |
| High | **Allow** — IT-approved apps (browsers, Office, etc.) | Specific apps, all users |
| High | **Allow** — Developer tools | Specific users/groups |
| Low (catch-all) | **Require Approval** — Everything else | All users, all apps |
Applications matched by a higher-priority Allow policy pass silently. Anything not explicitly allowed falls through to the baseline file access policy with required approval.
***
### Key Operational Consideration
Because this policy applies to all applications, it can create a high volume of approval requests — especially when expanded to many endpoints. This is why the documentation recommends starting with a **pilot group** and building out the exception (Allow) policies *before* broad deployment. Deploying in batches while monitoring system performance and user feedback, and adjusting policies based on operational requirements, is the recommended approach.
