Data Loss Prevention Policy Template with Examples

A data loss prevention (DLP) policy template is a structured starting document that tells your organization which data to protect, how each class of data may move and what happens when someone breaks the rules. This one pairs every clause with the rule that backs it, so the policy you approve matches what your DLP tool does.

Most teams treat the policy and the rules as two separate projects. The policy says "protect customer data." The tool blocks whatever someone happened to configure. That distance is where a policy stops matching reality.

Copy the template below, replace every [bracketed value] with your own and give each section an owner. If you are new to the discipline, start with our guide to data loss prevention.

A DLP Policy Lives in Two Places

The word "policy" covers two different things, and a template has to serve both. The first is the document: the approved text that sets intent, owners, data classes and exceptions. The second is the rule: a detector, a channel and an action configured in Forcepoint DLP or any other tool.

The two layers of a DLP policy

A document without rules is a wish. Rules without a document are hard to defend, because nobody can explain why one rule blocks a team that another rule only warns. Write the document first, then translate each clause into a rule. If you need a scale for ranking incidents, our post on DLP policies covers severity levels.

What the Policy Must Settle Before Any Rule Fires

Ten decisions sit underneath every working DLP policy. Settle them in this order, because each one feeds the next. The table shows what each section decides and the kind of rule it becomes.

Template sections and the rules they become

Auditors ask how your policy maps to the frameworks you follow. Three references cover most DLP conversations: ISO/IEC 27001:2022, the General Data Protection Regulation (GDPR) and the National Institute of Standards and Technology (NIST) SP 800-53 catalog.

Framework references for a DLP policy

These pointers start the conversation. Confirm the current text of each framework with your auditor before you cite it in the policy.

Sort Data Into Four Classes Before You Write Anything Else

A policy without classes forces every rule to guess. Four classes cover most organizations:

• Restricted: data whose exposure triggers legal duties or serious harm, such as payment card data, protected health information (PHI), national ID numbers, credentials and core source code
• Confidential: personal data, contracts, customer lists and financial results
• Internal: everyday business material that is not meant for outsiders
• Public: material approved for release, such as press releases and published web content

Every data set gets one owner and one class. A file that mixes classes takes the highest one. A class only matters if it changes behavior, so turn each class into a handling matrix.

Starter handling matrix

Add rows for USB drives and personal devices if your environment needs them. Before owners assign classes, scan your repositories. Forcepoint DSPM discovers and classifies sensitive data across cloud and on-premises stores, so classes rest on evidence instead of memory.

Copy the Template, Then Fill In Every Bracket

Each section below is ready to paste. Brackets mark the values you decide, with a sensible default inside. A good clause names the data, the channel, the action and a number, so an auditor can test it and a DLP tool can enforce it.

Purpose and scope

This policy protects [Company Name] data from unauthorized disclosure, loss and misuse. It applies to all employees, contractors and vendors who handle company data, and to every system, device, cloud service and AI tool that stores, processes or transmits it. Where this policy and a DLP tool setting differ, this policy governs.

If your scope also covers retention, access and acceptable use, pair this document with a broader data security policy.

Roles and ownership

The [Chief Information Security Officer] owns this policy. The [DLP lead] owns DLP rules, tuning and reporting. Data owners assign each data set one class and approve exceptions for it. The [privacy lead] decides whether an incident is a personal data breach. Managers make sure their teams complete data handling training within [two weeks] of hire.

Data classes and handling

Every data set has one owner and one class: Restricted, Confidential, Internal or Public. A file that mixes classes takes the highest class. Restricted data goes outside the company by email only when it is encrypted and the recipient is on the data owner's approved list. External share links name each recipient and expire on a set date. Only Public data may use an open link.

Approved channels

Company files move only through [approved file service], [approved email platform] and [approved transfer tool]. Personal email, personal cloud storage and removable media are not approved for Confidential or Restricted data. Endpoint agents block writes to USB storage, except to [company-encrypted drives] registered to users with written approval.

Monitoring and rule modes

Every new DLP rule starts in Monitor mode for at least [four] weeks. The DLP lead reviews matches each week and records false positives for each rule. The DLP lead promotes a rule out of Monitor mode only when its false-positive rate holds under [5%] across [two] consecutive reviews. Only [named roles] can read alert content. [Company Name] tells staff that DLP inspects company email, files and devices, and Legal reviews monitoring practices against local law before launch.

Incidents and breach notification

Anyone who suspects a leak reports it to [security contact] within [two hours]. The security team contains the incident, records the data class, the number of people affected and whether the data was encrypted, and assigns a severity of [Low, Medium or High]. If personal data is involved, the privacy lead decides within [24 hours] whether it is a personal data breach. Where the GDPR applies, [Company Name] notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach, unless the breach is unlikely to result in a risk to people.

For a fuller response process, see our walkthrough of DLP incident response.

Exceptions

The data owner and the [CISO] approve exceptions in writing. Every exception names the data, the user or team, the compensating control and an end date no more than [90] days out. The DLP lead keeps an exception register and reviews it every [month].

Review and consequences

The policy owner reviews this policy at least every [12] months, and sooner after a significant regulatory change, a new cloud or AI service, a merger or a [High] severity incident. Violations are handled under [HR policy]. Reporting a mistake promptly counts as a mitigating factor.

Write Down What Employees and AI Agents May Do With Company Data

Email and USB drives were the old leak paths. Prompts, copilots and agents are the new ones, and a policy that stays silent on them leaves a channel ungoverned that employees already use. Add three short clause sets. The rule side of this work, including how prompts and responses get inspected, is covered in our post on DLP for AI.

Prompts: Employees do not enter Restricted data into any AI tool. Confidential data goes only into [approved company AI tools]. DLP inspects prompts and responses in approved tools and blocks Restricted data before it leaves.

Copilots: A copilot may retrieve only data the requesting user is permitted to read. Data owners review sharing permissions on Restricted repositories every [90] days, and before a copilot is enabled for them.

Agents: Each AI agent has a named owner, a documented purpose and the minimum access it needs. An agent gets an inventory entry before it gets access. Agents do not send Restricted data outside [approved systems]. The security team reviews agent access every [90] days.

Agents act on their own access, so each one needs an owner and an access review. Our page on agentic AI security shows how to detect and control them.

Translate Each Clause Into a Rule Your Tool Can Run

A DLP rule pairs a detector with a channel, an action and a mode. A detector can be a pattern, a keyword list, a sensitivity label or a document fingerprint. The table gives six starter rules, one for each data type most policies protect first. Treat every threshold as a default to tune.

Six starter rules

Forcepoint DLP ships pre-defined classifiers for regulated data such as payment cards, national IDs, health data and credentials, and it supports fingerprinting for structured data, documents and other files. You set thresholds and actions instead of writing detection logic. Each rule inherits its owner, class and channel list from the policy. Rules for cloud apps run through Forcepoint Cloud App Security, and outbound email runs through Forcepoint DLP for Email. Risk-Adaptive Protection can tighten a rule automatically for users whose behavior raises risk.

Three Data Loss Prevention Policy Examples From Clause to Rule

The clearest way to see how a policy and a rule connect is to follow one clause all the way down. These three examples use hypothetical scenarios.

Payment card data

Clause: "Payment card numbers do not leave the company by email, web upload or removable media, except through [approved payment system]."

Rule: Detect card-length numbers that pass a Luhn check across email, web and endpoint channels. Start in Monitor mode and move to Block after [four] weeks of tuning.

Result: A support agent who pastes a customer's card number into a personal webmail message sees the message stop, and the DLP lead sees the event in the queue.

Health data

Clause: "Protected health information stays in [approved clinical or HR systems] and leaves only by encrypted email to approved recipients."

Rule: Detect medical record numbers or diagnosis and drug terms beside a patient name or ID in email and cloud apps. Block unencrypted sends and uploads to unapproved cloud apps.

Result: An analyst who uploads a spreadsheet of patient records to a personal drive is blocked and pointed to the approved share.

Source code

Clause: "Source code stays in [company repositories]. Developers do not paste it into unapproved AI tools or personal storage."

Rule: Fingerprint the main repositories and detect code file types in cloud apps, endpoints and web uploads. Start in Monitor mode and move to Warn once false positives hold under [5%].

Result: A developer who pastes a proprietary module into an unapproved AI chatbot sees a warning that explains the policy and points to the approved tool.

Start From Policy Templates Instead of a Blank Rule Set

Writing detection logic from scratch is the slowest part of any DLP project. Forcepoint DLP includes 2,000+ classifiers and policy templates for personally identifiable information (PII) and other sensitive data. When you create a policy, you choose an industry or country, pick a template such as GDPR or the Health Insurance Portability and Accountability Act (HIPAA) and see the rules populate, then adjust them to your data.

A template knows what a card number looks like. It does not know your unreleased pricing sheet or a proprietary formula. Add fingerprints or custom classifiers for the data only your company holds. Forcepoint DLP also includes ARIA, an embedded AI assistant that recommends protection and deploys policies from a chat interface. These capabilities sit inside Forcepoint Data Security Cloud.

Roll Out Each Rule in Monitor Mode Before It Blocks Anything

Turning every rule on in Block mode on day one stops real work and teaches people to route around the tool. Move each rule through four steps instead:

1. Monitor: log every match without alerting the user for [four] weeks
2. Review: check new matches each week and record false positives for each rule
3. Tune: add nearby keywords, raise match counts and exclude test data
4. Warn, then Block: move a rule up only when its false-positive rate holds under [5%] across [two] consecutive reviews

Use Warn mode for Confidential data and for rules that still catch harmless content. Reserve Block for tuned rules on Restricted data. A short Warn message that explains why an action stopped and what to do instead turns a policy collision into a lesson.

Keep the Policy Current After Launch

A policy ages the day you approve it. Review the document on the schedule in your policy, and review it early when a trigger hits: a new regulation, a new cloud or AI service, a merger or a serious incident. Review the rules more often than the document, because false-positive rates and coverage gaps shift faster than policy language.

Track three numbers each month:

• False-positive rate for each rule
• Exceptions still open past their end date
• Sensitive data sets that have no rule

Those numbers also double as audit evidence. For more on that side of the program, see our post on DLP compliance.

Data Loss Prevention Policy Template FAQs

What should a data loss prevention policy template include?

A complete template covers purpose and scope, roles, data classes with handling rules, approved channels, AI use, monitoring modes, incident handling, exceptions and review. It also links each clause to a rule, so the policy and the tool stay in step.

What is the difference between a DLP policy and a DLP rule?

A DLP policy is the approved document that sets intent, owners and limits. A DLP rule is one setting in a tool that pairs a detector with a channel, an action and a mode. One policy usually produces many rules.

Do you need a DLP tool to have a DLP policy?

You can write and publish the policy without a tool, and you can apply parts of it through training and sharing settings. Rules that inspect content, such as blocking an email that contains card numbers, need DLP software.

Does ISO 27001 require data loss prevention?

ISO/IEC 27001:2022 added Annex A control 8.12, data leakage prevention. Annex A works as a reference list, so you decide through your risk assessment whether the control applies and record that decision. A DLP policy is a common way to show how you apply it.

How do you cover AI tools in a DLP policy?

Add clauses for three things: what employees may enter into prompts, what copilots may retrieve and what each AI agent may access. Name an owner for every approved tool and agent, and pair each clause with a rule that inspects prompts, responses or agent activity.

Is there a PDF or Word version of this template?

There is a PDF checklist that follows the same sections, free to download with no form. The template itself sits on this page, so you can copy it straight into a Word document or your policy system.

How often should you review a DLP policy?

Review it at least every [12] months, and sooner after a new regulation, a new cloud or AI service, a merger or a serious incident. Review the rules more often than the document.

Put the Template to Work

A policy only protects data once a tool applies it. Pair this template with the Practical Executive's Guide to DLP for a 10-step deployment framework, or talk to an expert about building these rules in Forcepoint DLP.