A data loss prevention migration is the one project where the security team deliberately switches off its own exfiltration controls, and most migrations lose coverage quietly because rules are translated by name rather than tested by outcome. Organisations change DLP platforms when they consolidate onto a security service edge, move email and collaboration to a new cloud suite, replace an on-premises network appliance, or take on another company's estate after an acquisition. This playbook is for security engineers, data protection leads and programme managers moving from one DLP platform to another. It covers what has to move besides policies, how to prove detection parity, how to run old and new side by side, how to cut over channel by channel, and how to decommission a system that holds copies of the most sensitive data in the organisation. It is vendor-neutral. The fundamentals of DLP itself are in the Data Loss Prevention (DLP) Guide, and choosing a platform is covered in the DLP Buyer's Guide.
Key takeaways
- Migrate outcomes, not rule names. Two platforms will interpret the same regular expression, proximity window or confidence level differently; parity is proven with a labelled test corpus, not with a mapping spreadsheet.
- Classification and fingerprints are the real asset. Labels, exact data match tables and document fingerprints took years to build and are rarely portable; plan their rebuild before you plan rule translation.
- Run in parallel, enforce one at a time. Put the new platform in monitor mode beside the old one, compare verdicts on the same traffic, and switch enforcement one channel at a time so there is always a blocking control.
- The incident archive is evidence. Old DLP incidents hold captured content and may support HR, legal or regulatory cases; decide retention and access before the old console goes dark.
- Decommissioning is a data disposal task. Forensic copies, quarantine stores and fingerprint databases must be exported, retained or sanitised, and the old platform's service accounts and API tokens revoked everywhere.
What has to move
A DLP platform is not just a policy set. It holds detection content, integrations, identities and a store of captured sensitive data. Inventory each object type before the vendor's migration tooling tells you what it can import.
| Object | Typical portability | Migration approach |
|---|---|---|
| Policies and rules (conditions, actions, exceptions) | Low: rule logic and actions differ by engine | Rewrite from a requirements register, then test against the corpus |
| Detectors: regular expressions, keyword lists, validators (for example checksum checks on card numbers) | Medium: patterns copy, but validation and proximity logic differ | Copy patterns, re-test precision on known samples |
| Exact data match (EDM) tables and indexed document fingerprints | Very low: hashed with platform-specific schemes | Re-index from the authoritative source data, never from the old platform's index |
| Classification labels and label-based rules | Medium where labels are stored in file metadata; low where only the old platform reads them | Confirm the new platform reads existing labels; map label names and IDs |
| Exceptions and allow lists (users, groups, domains, applications, devices) | High to copy, but often stale | Re-approve each one; expire those without an owner |
| Incidents, captured content and quarantine stores | Very low | Retain in place or export to an evidence store; do not import into the new platform |
| Integrations: mail flow connectors, proxy chaining, cloud API connectors, SIEM and ticketing | None: re-created per platform | Rebuild with new, scoped identities |
| Endpoint agents and their configuration | None | Deploy new agent in monitor mode, then remove old agent by ring |
Build a requirements register before touching rules: for each data type (payment card data, national identifiers, health records, source code, customer exports, board papers) record the business owner, the legal or contractual driver, the channels that must be covered and the required action (monitor, warn with justification, block, encrypt). NIST CSF 2.0 ID.AM-07 asks for inventories of data and its metadata for designated data types; that inventory is the input the migration needs and is often more valuable than the old rule set.
Proving detection parity
The question executives ask is "are we as protected on the new platform as on the old one?". Answer it with evidence.
- Build a labelled test corpus. Synthetic records for every data type in the register (generated card numbers that pass checksum validation, fake identifiers in the correct format), true negatives that look similar (invoice numbers, order IDs), each in the file formats in use: office documents, PDF, archives, images with text if optical character recognition is in scope, and encrypted or password-protected files.
- Replay through each channel. Send each sample by email, web upload, sanctioned cloud storage, removable media, print and clipboard where those channels are covered, through both platforms.
- Score both platforms. Record detection rate, false positive rate and action taken per data type per channel. The old platform's score is the baseline, not a perfect standard; record where the old platform missed too.
- Explain every difference. A gap is either a translation error to fix, an engine limitation to accept with a compensating control, or an improvement. Record the decision and approver.
NIST SP 800-53 SC-7(10) Prevent Exfiltration includes conducting exfiltration tests; the corpus becomes the recurring test for that control after go-live, so build it to be reused.
Choosing a migration pattern
| Pattern | How it works | Use when | Main risk |
|---|---|---|---|
| Parallel monitor, staged enforcement | New platform observes the same traffic in monitor mode; enforcement moves channel by channel | Default for most organisations | Double alert volume during overlap; agent conflicts on endpoints |
| Channel by channel replacement | One channel (for example email) is fully moved, then the next | Channels are served by different products already, or the new platform matures unevenly | Policy drift between channels during a long programme |
| Big-bang cutover | All channels switch on one date | Contract expiry forces it, or the old platform is failing | No parity evidence; high false positive storm on day one |
| Rebuild from requirements | Old rules are not translated at all; new policies are written from the register | Old rule set is large, stale or poorly understood | Longer tuning; stakeholders see it as starting again |
Small organisations: often move from email gateway or suite-native DLP to a new suite; a short parallel period on email and cloud storage with a corpus of a few dozen samples is proportionate. Large organisations: expect several thousand rules and exceptions; treat rule rationalisation as its own workstream and expect to retire a large share of rules that have not fired, or only produced false positives, in the past year.
The phased playbook
- Phase 0: decide and contain scope. Confirm drivers, channels in scope and the end date of the old contract. Record a risk acceptance for any channel that will have reduced coverage during the move.
- Phase 1: inventory and rationalise. Export rules, exceptions, detectors and integrations from the old platform. Pull twelve months of incident statistics per rule to identify rules that never fire and rules that only generate dismissed alerts.
- Phase 2: build foundations. Create identities for every integration (mail connector, cloud API connector, SIEM forwarder) with least privilege. Re-index EDM and fingerprints from source systems. Confirm the new platform reads existing classification labels.
- Phase 3: monitor-mode pilot. Deploy endpoint agents to a pilot ring of a few percent of devices across business units, including heavy data users (finance, legal, engineering). Turn on the network and cloud channels in monitor mode. Watch for agent conflicts, performance complaints and broken workflows.
- Phase 4: parity testing and tuning. Run the corpus, compare verdicts on live traffic, tune detectors, and agree the parity sign-off with data owners.
- Phase 5: staged enforcement. Switch enforcement channel by channel, lowest business impact first (often removable media or print), email and web upload later. Keep the old platform in monitor mode on that channel for a defined period so you can compare.
- Phase 6: endpoint agent swap by ring. Remove the old agent only after the new agent is enforcing on that ring. Track devices with both agents, with neither, and with the old one only.
- Phase 7: freeze and decommission. Freeze the old platform's policies, export or retain the incident archive, revoke its integrations and sanitise its data stores.
Testing and rollback
Every enforcement switch needs a rollback condition written before it happens, for example a business-critical workflow blocked for more than an agreed period, or a false positive rate on a channel above an agreed threshold. Rollback means putting the new platform back to monitor mode and re-enabling the old platform's enforcement on that channel, which only works if the old platform's configuration has been frozen rather than edited. Keep both mail flow connectors defined and test the switch in a maintenance window. As an NHI Mgmt Group recommendation, keep the old platform able to enforce for at least 30 days after each channel moves.
Integrations and the identities behind them
Modern DLP depends on non-human identities: API connectors with read access to entire cloud storage and mail tenants, proxy or gateway service accounts, label-reading permissions, and SIEM forwarding credentials. These are among the broadest read permissions in the enterprise, and a migration usually creates a new set while leaving the old set active.
- Scope new connectors to what the policy needs: read and label rather than full write, specific sites or mailboxes where the platform supports it.
- Record each connector as an NHI with an owner, purpose and expiry; see the Data loss prevention (DLP) integration security guide.
- Revoke the old platform's consent grants, API tokens and service accounts on the day its channel is decommissioned, not at contract end.
- Watch for drift in admin roles: DLP administrators can read captured content; translate roles deliberately rather than granting the new console's top role to the whole old team. The Securing the data loss prevention (DLP) itself guide covers the platform's own attack surface.
Incident archive and decommissioning
The old platform's incident store contains snippets or full copies of the sensitive data it caught. It may be needed for open HR cases, litigation holds, insider investigations or regulatory requests. Agree with legal and HR which incidents must be retained, for how long and in what format, before export. NIST SP 800-53 AU-11 Audit Record Retention applies to the platform's audit records; captured content is personal and sensitive data in its own right, so retention should be no longer than the case requires. For insider cases in progress, align with the Insider Threat Programme Guide.
- Export incident metadata and evidence for retained cases to a controlled evidence store with access logging.
- Remove agents, connectors, mail flow rules and proxy chaining; confirm no traffic still routes through the old appliance.
- Sanitise databases, quarantine stores, fingerprint indexes and appliance disks following NIST SP 800-88 Rev. 2 Guidelines for Media Sanitization (MP-6), including cloud tenancy deletion confirmation from the provider.
- Revoke the vendor's support access and any customer-side credentials it held; CSF 2.0 GV.SC-10 covers activities at the end of a supplier relationship.
Detection and measurement
During the migration, monitor the gap as well as the platform.
- Coverage gaps: devices with no DLP agent reporting, mailboxes or sites not covered by a connector, and egress paths that bypass the new proxy.
- Exfiltration techniques the policies target: MITRE ATT&CK T1567.002 Exfiltration to Cloud Storage, T1048 Exfiltration Over Alternative Protocol and T1052 Exfiltration Over Physical Medium. Confirm detections exist on both platforms during the overlap.
- Admin activity: policy changes, exception creation and incident exports on both consoles, forwarded to the SIEM (CSF DE.CM-09).
| Metric | What it shows |
|---|---|
| Corpus detection rate per data type and channel, old versus new | Detection parity; the sign-off measure |
| False positive rate (dismissed incidents as share of total) per channel | Whether tuning is complete before enforcement |
| Endpoint coverage: share of managed devices with the new agent healthy and enforcing | Progress and gaps during the agent swap |
| Exceptions migrated with a named owner and expiry | Whether stale allow lists were carried over |
| Old platform integrations still active | Decommissioning progress; should reach zero |
| Days any in-scope channel ran with no enforcing control | Real exposure during the programme; target zero |
Common failure patterns
- Translating rules one to one. Thousands of old rules are copied, including those that never fired, and the new platform inherits years of noise.
- Losing a channel nobody owned. The old platform quietly covered a path (print, a web category, a legacy mail relay) that is not in the new design. New channels need adding too: staff pasting code into public AI tools, as in the Samsung ChatGPT Source Code Leak 2023, is a channel many legacy rule sets never covered; see the Generative AI Data Loss Prevention Guide.
- Two endpoint agents fighting. Both agents hook file and clipboard operations; users see slowdowns, and the team removes the new agent from the complaining devices without tracking them.
- Rebuilding EDM from the old index. Fingerprints exported from the old platform are stale or unusable; indexes must come from current source data.
- Forgetting the evidence. The old console is switched off at contract end and open insider cases lose their evidence.
- Leaving the old connectors live. Read-all API grants for a decommissioned platform remain in cloud tenants for months.
Framework mapping
| Migration activity | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | Other |
|---|---|---|---|
| Data inventory and requirements register | ID.AM-07 | CM-8 | ISO/IEC 27001:2022 A.5.12 Classification of information |
| Policy rebuild and enforcement | PR.DS-01, PR.DS-02 | AC-4, SC-7(10) | ISO/IEC 27001:2022 A.8.12 Data leakage prevention; CIS Control 3 Data Protection |
| Parity and exfiltration testing | DE.CM-09 | SC-7(10), SI-4(18) | ATT&CK T1567.002, T1048, T1052 |
| Change control for cutover and rollback | PR.PS-01, PR.PS-02 | CM-3 | ISO/IEC 27001:2022 A.8.32 Change management |
| Integration identities | PR.AA-05 | AC-6 | See NHI guidance linked above |
| Incident archive and decommissioning | GV.SC-10 | AU-11, MP-6 | NIST SP 800-88 Rev. 2 |
Practitioner checklist
- Requirements register built per data type with owner, driver, channels and required action.
- Rules with no hits or only dismissed hits in twelve months identified for retirement.
- Labelled test corpus created for every data type and file format, with true negatives.
- EDM and fingerprints re-indexed from source systems, not exported indexes.
- New integration identities scoped, owned and recorded; old ones scheduled for revocation.
- Parallel monitor-mode run completed with documented verdict comparison and parity sign-off.
- Rollback condition and procedure written for every channel switch.
- Endpoint agent swap tracked by ring, with a report of devices on neither agent.
- Incident archive retention agreed with legal and HR, exported to a controlled evidence store.
- Old platform data stores sanitised, connectors and consent grants revoked, vendor access closed.
Standards and references
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- NIST: SP 1800-28 Data Confidentiality: Identifying and Protecting Assets Against Data Breaches
- NIST: SP 800-88 Rev. 2 Guidelines for Media Sanitization
- CIS: Control 3 Data Protection
- MITRE ATT&CK: Exfiltration to Cloud Storage
- MITRE ATT&CK: Exfiltration Over Alternative Protocol
Related NHI Mgmt Group resources: Data Loss Prevention (DLP) Guide, Endpoint DLP Guide, Data loss prevention (DLP) health check, Data Loss Prevention Policy Template, Insider Data Theft Guide.