Data loss prevention (DLP) projects rarely fail because the product lacks a channel; they fail because detection is too noisy to enforce, so policies stay in monitor mode for years while data still leaves. This template is a ready-to-issue request for proposal for a DLP platform covering endpoints, email, web and cloud applications, including generative AI tools. Its requirements are numbered and scorable, and the proof of concept measures detection accuracy on your own test data rather than vendor demonstrations. It is distinct from the DSPM RFP Template, which buys discovery and posture of data at rest; DLP controls data in motion and in use. It is vendor-neutral and written for data security leads, security architects, privacy officers and procurement. For how the market is shaped, read the DLP Buyer's Guide; this page is the procurement document.
How to use this template
- Replace text in square brackets, such as [Organisation], [number of endpoints] and [identity provider], with your own details. Delete requirements for channels you are not buying rather than leaving them unscored.
- Each requirement has an ID (for example DLP-DT-03) and a type: M mandatory (pass or fail; a fail eliminates the bid), S scored (0 to 5, weighted) or I informational.
- Weights, volumes and thresholds in brackets are illustrative. Set them before issue and do not change them once responses arrive.
- Issue sections 1 to 8 to bidders. The Implementation guidance section is for your evaluation panel only.
- Involve your data protection officer before issue: DLP inspects staff communications, so section 4.6 requirements and the proof of concept data handling need privacy sign-off.
1. Purpose and scope
[Organisation] invites proposals for a data loss prevention platform. The platform must identify sensitive data accurately, apply consistent policies across the channels where data leaves, coach or block users in proportion to risk, and give investigators the evidence they need while respecting staff privacy.
- In scope: endpoint DLP for [Windows, macOS, Linux]; email; web and cloud application traffic including generative AI tools; sanctioned SaaS through API; [on-premises file shares]; incident management and reporting.
- Out of scope: [data discovery and posture across cloud data stores, covered by DSPM]; [classification labelling rollout, already in progress]; [insider risk management scoring], unless offered as an option.
- Contract term: [three] years with an option to extend by [two] years.
- Drivers: [personal data and payment card data leaving by email and personal cloud storage]; [staff pasting confidential data into generative AI tools]; [regulatory obligations under UK GDPR, PCI DSS or sector rules]; [replacing an end-of-life DLP product]; [insider data theft investigations].
2. Organisation background and current state
| Item | [Organisation] value |
|---|---|
| Users and devices | [number users], [Windows endpoints], [macOS endpoints], [VDI], [mobile] |
| Email and collaboration | [email platform], [collaboration suite], [file sharing services] |
| Web and network | [secure web gateway or SSE], [TLS inspection status], [proxy for unmanaged devices] |
| Sanctioned SaaS | [CRM], [file storage], [ticketing], [code repositories], [approved AI tools] |
| Sensitive data types | [personal data], [payment card data], [health data], [source code], [customer contracts], [named project codes] |
| Classification | [labelling scheme and coverage] |
| Current tooling | [existing DLP and channels], [number of policies], [monthly alert volume], [percentage of policies in block mode] |
| Jurisdictions | [countries where staff are monitored], [works council or union consultation requirements] |
3. Instructions to bidders
- Timeline: RFP issued [date]; clarification questions by [date]; answers shared with all bidders by [date]; responses due [date, time, time zone]; shortlist and proof of concept [dates]; decision [date].
- Single point of contact: [name, email]. Contact with other [Organisation] staff about this RFP may lead to disqualification.
- Response scale: for each requirement state available now; available with configuration; available with custom development; third-party product required (name it); roadmap (with a committed date); not supported. Roadmap answers score zero unless the date is contractually committed.
- Channel matrix: as Appendix A, give one table listing each channel (USB, print, clipboard, browser upload, sync clients, email, named SaaS, AI tools) against each operating system, and for each cell state monitor, coach, block or not supported.
- Edition: state which edition or module each answer depends on and confirm it is in the Appendix B price.
4. Functional requirements
4.1 Detection and classification
| ID | Requirement | Type |
|---|---|---|
| DLP-DT-01 | Provides built-in detectors for [UK and EU personal data, payment card numbers with checksum validation, national identifiers, health data], with proximity keywords and confidence levels. | M |
| DLP-DT-02 | Supports exact data matching against hashed extracts of [customer database], so only real records trigger, and states the maximum rows and refresh frequency. | M |
| DLP-DT-03 | Supports document fingerprinting or indexed matching for [contract templates, design documents] including partial matches. | S |
| DLP-DT-04 | Reads and applies [Organisation]'s existing sensitivity labels and file metadata as policy conditions. | M |
| DLP-DT-05 | Inspects content inside archives, images (optical character recognition) and common file formats, and states nesting depth and size limits. | S |
| DLP-DT-06 | Describe any machine learning classifiers (for example for source code or financial documents): training data, whether customer data is used for training, and how accuracy is measured. | I |
See the Data Classification Guide.
4.2 Endpoint channels
| ID | Requirement | Type |
|---|---|---|
| DLP-EP-01 | Monitors and controls copy to removable media, print, clipboard, browser upload, personal sync clients and network shares, per Appendix A. | M |
| DLP-EP-02 | Applies policy offline and reports events when the device reconnects. | M |
| DLP-EP-03 | Uses a single agent, or states every agent required, with CPU and memory impact under [limits] and tamper protection that alerts on stop or uninstall. | S |
| DLP-EP-04 | Allows device control by vendor, product and serial number for approved encrypted USB devices. | S |
See the Endpoint DLP Guide.
4.3 Email, web, cloud and AI channels
| ID | Requirement | Type |
|---|---|---|
| DLP-NW-01 | Inspects outbound email and attachments and supports actions: notify, require justification, encrypt, quarantine, block. | M |
| DLP-NW-02 | Inspects web uploads and form posts through [secure web gateway or SSE] or the endpoint, distinguishing corporate and personal instances of the same service (for example a personal and a corporate file storage account). | M |
| DLP-NW-03 | Inspects prompts, pasted text and file uploads to generative AI tools in [list], with allow, coach, redact or block actions per tool. | M |
| DLP-NW-04 | Scans data at rest and sharing settings in [sanctioned SaaS] through API, and remediates public or external links. | S |
| DLP-NW-05 | Applies the same policy definitions and detectors across all channels from one console, without redefining rules per channel. | M |
See the CASB Guide and Insider Risk from AI Tools Guide.
4.4 Policy, response and user coaching
| ID | Requirement | Type |
|---|---|---|
| DLP-PL-01 | Runs any policy in simulation or monitor mode and reports what would have been blocked, before enforcement. | M |
| DLP-PL-02 | Supports graduated actions: audit, notify with policy tip, block with justified override, block. Overrides and justifications are logged and reportable. | M |
| DLP-PL-03 | Scopes policies by user group, department, device and location, with exceptions that carry an owner and expiry. | S |
| DLP-PL-04 | Adjusts actions by user risk where integrated with [insider risk or identity threat tools] (for example stricter policy for leavers in their notice period). | S |
4.5 Incident management and investigation
| ID | Requirement | Type |
|---|---|---|
| DLP-IN-01 | Aggregates matches into incidents by user, policy and time window, with severity, matched content excerpt, channel, destination and file. | M |
| DLP-IN-02 | Provides a case workflow (assign, triage, escalate, close with reason) and records false positive feedback for tuning. | S |
| DLP-IN-03 | Streams incidents and events to [SIEM] and [SOAR] in a documented format, and exposes an API. | M |
| DLP-IN-04 | Reports false positive rate per policy, override rate, incidents per channel and time to triage. | S |
4.6 Privacy and data minimisation
| ID | Requirement | Type |
|---|---|---|
| DLP-PV-01 | Masks user identity in incident views by default, with de-anonymisation only for named roles and logged. | S |
| DLP-PV-02 | Stores only the matched excerpt by default; full file evidence capture is optional per policy, encrypted, and subject to retention of [days]. | M |
| DLP-PV-03 | Keeps incident and evidence data in [regions], and states where content inspection happens (on device, in region, elsewhere). | M |
| DLP-PV-04 | Supports excluding categories of traffic from inspection, such as [banking and health sites] and named personal communications. | S |
5. Platform security and non-functional requirements
| ID | Requirement | Type |
|---|---|---|
| DLP-SEC-01 | Administrator access through [Organisation] SSO with phishing-resistant MFA and roles separating policy authoring, incident review, evidence access and agent management. | M |
| DLP-SEC-02 | Logs all administrative actions, policy changes and evidence views with actor and time, retained for [period]. | M |
| DLP-SEC-03 | Credentials used for SaaS API connectors and exact data match uploads are least privilege, documented per connector and rotatable; exact data match sources are hashed before leaving [Organisation]. | M |
| DLP-SEC-04 | Provide a current ISO/IEC 27001 certificate with in-scope service or SOC 2 Type II report, sub-processor list and a completed [SIG or CAIQ] questionnaire. | M |
| DLP-NF-01 | Scales to [number] endpoints and [messages per day], with inspection latency under [milliseconds] for web and email. | S |
| DLP-NF-02 | Exports policies, incidents and evidence in a documented format at exit. | M |
A DLP console holds copies of your most sensitive content and the activity of every employee: its own administrators and evidence store need privileged access controls. See the Insider Threat and Identity Guide.
6. Implementation, services and support
- Approach: phases, deliverables and acceptance criteria for [discovery and monitor mode, tuning, coaching, enforcement by channel] within [months].
- Policy migration: how existing policies and exceptions are mapped and tested if replacing a current product.
- Tuning services: days included for false positive reduction and who owns tuning after go-live.
- Support: tiers, hours, response targets by severity, and agent update cadence with rollback.
- References: [two or three] customers of similar size or sector with policies enforced in block mode on at least two channels.
7. Commercials
| Cost element | What to state |
|---|---|
| Licence metric | Per user, per device or per mailbox; treatment of shared and service mailboxes |
| Channels and modules | Which channels and section 4 requirements need add-ons (exact data match, OCR, AI tool inspection, SaaS API) |
| Dependencies | Any required gateway, SSE or suite licence not in this bid |
| Storage | Evidence storage included and overage pricing |
| Implementation and tuning | Fixed price or day rates with estimated days by phase |
| Growth, renewal and exit | Price for [growth %]; renewal cap; export charges |
8. Evaluation method and proof of concept
[Organisation] will check mandatory requirements first, then score the rest with these illustrative weights:
| Criterion | Weight | Evidence |
|---|---|---|
| Detection accuracy (4.1) | [25%] | Proof of concept test corpus results |
| Channel coverage and enforcement (4.2, 4.3) | [20%] | Appendix A, proof of concept tests |
| Policy, coaching and incident handling (4.4, 4.5) | [15%] | Analyst walkthrough |
| Privacy controls (4.6) | [10%] | DPO review |
| Platform security and operations (5, 6) | [10%] | Assurance reports, agent impact test |
| Life-cycle cost (7) | [20%] | Appendix B |
Scores use 0 to 5: 0 not met; 1 roadmap only; 3 met with configuration; 5 met fully and demonstrated. Shortlisted bidders run a proof of concept of [three to four] weeks with [50] pilot users and a synthetic test corpus prepared by [Organisation]:
- The panel builds a corpus of [300] files and messages: true positives (synthetic personal data, valid test card numbers, fingerprinted documents, exact match records) and near misses (invalid card numbers, public documents, similar but unregistered records). No real personal data is used.
- Bidders configure equivalent policies; the panel measures detection rate and false positive rate on the corpus for each channel.
- Exfiltration tests by channel: copy to USB, print, upload to a personal cloud storage account and a corporate one, paste into an AI tool, send by email, and repeat while offline.
- Show simulation mode for one policy, then enforce with justified override, and report the overrides.
- Review incidents as an analyst with identity masked, de-anonymise one case as an authorised role, and show the audit trail.
- Measure agent CPU and memory on [pilot device models] and attempt to stop the agent as a standard user.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Score accuracy, not detector counts: a library of hundreds of detectors is worth little if precision on your own corpus is poor. Weight false positive rate as heavily as detection rate, because noise is what keeps policies in monitor mode.
- Use synthetic data only: build the test corpus from generated records and test card numbers so the proof of concept itself does not move real personal data to bidder platforms.
- Test the personal versus corporate split: the most common real leak path is a personal instance of a sanctioned service. DLP-NW-02 should be tested, not answered.
- Check the dependency stack: some web and AI channel controls depend on a gateway, browser or suite licence. Include those in Appendix B comparisons.
- Agree privacy controls before rollout: monitoring staff communications engages UK GDPR obligations, including a data protection impact assessment for high-risk processing. Read the ICO guidance on monitoring workers and record your decisions on section 4.6.
- Plan enforcement by channel: moving one channel at a time from monitor to coach to block, with an override, gives measurable progress and a clean rollback.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | MITRE ATT&CK v20 technique addressed |
|---|---|---|---|
| Detection and classification (4.1) | AC-4 | ID.AM-07 | All exfiltration techniques below |
| Endpoint channels (4.2) | MP-7, AC-4 | PR.DS-01, PR.DS-10 | T1052.001 Exfiltration over USB |
| Web, cloud and AI channels (4.3) | SC-7(10), SI-4(4) | PR.DS-02 | T1567.002 Exfiltration to Cloud Storage; T1048 Exfiltration Over Alternative Protocol |
| Incidents and monitoring (4.5) | SI-4, AU-6 | DE.CM-03 | Not applicable |
| Privacy (4.6) | PT-2 | GV.OC-03 | Not applicable |
| Supplier assurance (5) | SA-9, SR-6 | GV.SC-06 | Not applicable |
After award, carry requirement IDs into the statement of work and rerun the corpus test at each enforcement phase. For the exfiltration techniques DLP must catch, see the Data Exfiltration Guide and T1567 Exfiltration Over Web Service.
Standards and references
- NIST NCCoE: SP 1800-28 Data Confidentiality: Identifying and Protecting Assets Against Data Breaches
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: Exfiltration (TA0010)
- ICO: Employment practices and data protection, monitoring workers
Related NHI Mgmt Group resources: DLP Buyer's Guide · Data Loss Prevention (DLP) Guide · DSPM RFP Template · Security Vendor Evaluation and RFP Guide · Insider Data Theft Guide