> For the complete documentation index, see [llms.txt](https://docs.keeper.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.keeper.io/keeperpam/endpoint-privilege-manager/policies/policy-examples/anti-ransomware-policies/gate-4-data-protection.md). # Gate 4: Data Protection
**Audience:** Windows administrators deploying a layered Keeper EPM anti-ransomware baseline. *** For an overview of the layered anti-ransomware model and how this gate fits in, see [Anti-Ransomware Policies](/keeperpam/endpoint-privilege-manager/policies/policy-examples/anti-ransomware-policies.md). This policy is the **data protection gate** in a layered Keeper EPM anti-ransomware deployment on Windows. Where the other three gates stop ransomware from executing, escalating, or destroying recovery options, this gate protects the data itself. File Access policy modifies the NTFS ACL on protected directories to deny READ, WRITE, and DELETE access unless the policy control (Approval, MFA, or Justification) is satisfied. The protection is enforced by the operating system itself — even a ransomware encryption process running under the user's full token cannot overwrite or delete files in a protected directory, because Windows refuses the I/O at the file system layer. This is the last line of defense. If Gates 1, 2, and 3 have all failed and ransomware is actively encrypting, this gate is what preserves the data. ### Step-by-Step: Create the Policy {% stepper %} {% step %} ### Identify the Directories to Protect Not every directory needs protection — broad protection creates friction without proportional benefit. Focus on directories whose loss would constitute a material incident: * Finance and accounting share roots (general ledger, AR/AP working files, payroll exports) * Source code repositories on developer endpoints (`C:\repos`, `C:\src`, `C:\dev`) * Executive shares and board materials * HR data (employee records, benefits, performance documentation) * Legal hold and litigation directories * Backup staging directories (before backups are written to off-host destinations) * Engineering documentation, IP, and design files * Customer data exports and CRM working files {% hint style="info" %} **Do not protect entire drives or user profile roots.** Broad protection creates excessive approval traffic and trains users to click through without reading. Focused protection on the directories that actually matter creates a meaningful control with manageable operational overhead. {% endhint %} {% endstep %} {% step %} ### Create the Application Collection Application Collections for File Access policies on directories use a different pattern from executable collections: each entry is a directory path rather than a filename. Path variables (`{userprofile}`, `{public}`, etc.) help where appropriate, but most data-protection use cases use literal paths. 1. From the Keeper Admin Console, navigate to **Endpoint Privilege Manager → Collections → Applications**. 2. Click **New Collection**. 3. In the **New Collection** modal: * **Type**: `Applications` * **Name**: `Protected Data Directories (Windows)` * Click **Next**.
4. In the **Add Item to Collection** modal, check **Manually define resource**. 5. Add each protected directory as a custom resource. Example entries: * `C:\Finance` * `C:\Legal\LitigationHold` * `C:\repos` * `C:\Executive` * `C:\HR\Records`
**Adjust paths to match your environment.** For network shares mapped to drive letters on user endpoints, use the mapped path the user sees (e.g., `S:\Finance`). {% hint style="danger" %} When you save the collection, note the collection's UID. {% endhint %}
{% hint style="info" %} **About the ACL behavior:** File Access policy enforcement on non-executable paths uses the native NTFS ACL — Keeper adds an explicit DENY ACE for in-scope users on the protected path. When a user requests access and the policy control is satisfied, Keeper modifies the ACE to allow the user read/write for the duration of the grant. The protection is enforced by Windows itself, which is why it survives even when the ransomware process has the user's full token. {% endhint %} {% endstep %} {% step %} ### Create the Policy 1. Navigate to **Endpoint Privilege Manager → Policies** and click **Create Policy**. 2. Fill in the policy details: * **Policy Name**: `Protect Sensitive Data Directories (Windows)` * **Policy Type**: `File Access` * **Status**: `Monitor` for the initial pilot. Monitor mode logs which users would have been prompted without actually applying the ACL, giving you a preview of approval traffic before enforcement.
{% endstep %} {% step %} ### Add the Approval Control 1. Click **Add Control**. 2. Select **Admin Approval**.
{% hint style="info" %} **Control choice:** Approval is the default recommendation for data protection because it preserves legitimate access through an audited request workflow. Alternatives: * **Require Justification** for lower-friction directories where audit trail is sufficient and you don't need a human approver * **Require MFA** for directories where the user already has legitimate access but you want to add a credential-binding step * **Deny** for directories where no user should write under any circumstances (rare for data directories; more common for system locations) {% endhint %} {% endstep %} {% step %} ### Set Filters 1. **Accounts**: Select **All Accounts** (wildcard). Specific exemptions (service accounts running legitimate backup software, for instance) should be handled by a separate higher-priority Allow policy. 2. **Machine Collections**: Select your Windows endpoint collection. For directories that only exist on certain endpoints (e.g., `C:\repos` only on developer machines), scope this to a developer-specific machine collection. 3. **Applications**: Select the `Protected Data Directories (Windows)` collection from Step 2. 4. Leave **Date & Time Window** unset.
{% endstep %} {% step %} ### Set the Notification in Advanced Mode 1. **Notification Message**: `Keeper EPM protects this directory because it contains sensitive business data. Please submit your access request with a brief description of what you need to do. Your administrator will be notified to approve.`
{% endstep %} {% step %} ### Save and Pilot 1. Click **Save**. The policy is pushed to all in-scope endpoints within approximately 30 minutes. 2. **Run in Monitor mode for at least one week.** Review the audit log to understand normal access patterns: * Which users routinely access each protected directory? * What is the approval traffic going to look like in enforcement mode? * Are there legitimate automated processes (backup agents, indexing services) that need to be exempted via a separate Allow policy? 3. Build out exemption policies for legitimate automation. The most common case: enterprise backup software (Veeam, CommVault, Backup Exec) needs read access to the protected directories. Create an Allow policy scoped to the backup service account. 4. When Monitor data is understood and exemptions are in place, edit the policy and change **Status** to `Enforce`. The NTFS ACL changes apply within approximately 30 minutes; users attempting access without an approved request will be denied at the OS layer. {% endstep %} {% endstepper %} ### Reference: Policy JSON The following JSON is the exported form of the finished policy. The `` and `` placeholders are filled in by the Admin Console when the policy and collection are created. ```json { "PolicyName": "Protect Sensitive Data Directories (Windows)", "PolicyType": "FileAccess", "PolicyId": "", "Status": "enforce", "Actions": { "OnSuccess": { "Controls": [ "APPROVAL" ] }, "OnFailure": { "Command": "" } }, "NotificationMessage": "Keeper EPM protects this directory because it contains sensitive business data. Please submit your access request with a brief description of what you need to do. Your administrator will be notified to approve.", "NotificationRequiresAcknowledge": false, "RiskLevel": 85, "Operator": "And", "Rules": [ { "RuleName": "UserCheck", "ErrorMessage": "This user is not included in this policy", "RuleExpressionType": "BuiltInAction", "Expression": "CheckUser()" }, { "RuleName": "MachineCheck", "ErrorMessage": "This Machine is not included in this policy", "RuleExpressionType": "BuiltInAction", "Expression": "CheckMachine()" }, { "RuleName": "ApplicationCheck", "ErrorMessage": "This application is not included in this policy", "RuleExpressionType": "BuiltInAction", "Expression": "CheckFile(false)" }, { "RuleName": "DateCheck", "ErrorMessage": "Current date is not covered by this policy", "RuleExpressionType": "BuiltInAction", "Expression": "CheckDate()" }, { "RuleName": "TimeCheck", "ErrorMessage": "Current time is not covered by this policy", "RuleExpressionType": "BuiltInAction", "Expression": "CheckTime()" }, { "RuleName": "DayCheck", "ErrorMessage": "Today is not included in this policy", "RuleExpressionType": "BuiltInAction", "Expression": "CheckDay()" }, { "RuleName": "CertificateCheck", "ErrorMessage": "Certificate hash is not included in this policy", "RuleExpressionType": "BuiltInAction", "Expression": "CheckCertificate()" } ], "UserCheck": [ "*" ], "MachineCheck": [ "*" ], "ApplicationCheck": [ "" ], "DayCheck": [], "DateCheck": [], "TimeCheck": [], "CertificationCheck": [], "Extension": {} } ``` ### Why This Gate Matters The first three gates aim to stop ransomware before it does damage. This gate exists because no preventive control is perfect, and the consequence of failure is data loss. Even in the worst-case scenario where ransomware has evaded execution gating, has somehow obtained admin rights, and has successfully removed shadow copies and backups, the encryption process still has to write to the file system — and the operating system itself, configured by Keeper EPM's ACL modifications, refuses the write. That is the value of defense in depth: each gate makes the attacker's job harder, and the last gate makes the attack's payload impotent even when every other defense has failed. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.keeper.io/keeperpam/endpoint-privilege-manager/policies/policy-examples/anti-ransomware-policies/gate-4-data-protection.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.