By Yair Knijn · January 22, 2026

The acquisition closed before anyone audited how the target moved files

Data diligence on a deal tends to mirror the data room: organized by named system. The GRC lead asks for the target's MFT platform, its SFTP server inventory, its DLP coverage, and a list of partner connections. The answers come back tidy, the compliance workstream goes green, and everyone moves on. The flaw is in the framing. You audited the systems someone wrote down. Regulated data moves through the systems nobody wrote down, and at close you own both.

I have walked into two post-close integrations where the documented transfer estate was accurate and beside the point. The actual movement of cardholder data and partner files ran through channels that never surfaced in a single diligence answer.

What M&A security due diligence usually skips: how data moves

Standard tech diligence inventories assets: servers, applications, vendors, certificates, open findings. It rarely traces flows. There is a real gap between "the target runs a managed file transfer appliance" and "here is every path a regulated record takes from creation to the partner that consumes it." The first is a list. The second is a map, and the liability lives on the map, because a flow that bypasses the appliance is invisible to anyone reading the asset list.

If your checklist never asks the engineer who actually moves the nightly settlement file how they move it, you have measured the front door and ignored every window.

Inherited shadow flows: scripts, personal cloud, partner backdoors

The flows you inherit and never audited tend to look like this:

• A cron job firing a curl or lftp script at an ftps:// endpoint, written by someone who left two years ago, with the partner password sitting in plaintext in the script.
• A "temporary" personal Dropbox or consumer file-share link, adopted because the real channel broke during a quarter-close and nobody switched it back.
• A partner handed direct SFTP credentials years ago: never rotated, never logged centrally, still pulling files on a schedule no one tracks.
• An email-attachment habit for the records that were "too urgent" to wait for the batch.

None of these answer the question "what is your MFT platform." Each one is a regulated flow with no audit trail, no key rotation, and no owner. They were workarounds for the seller. For you, they are unmonitored exfiltration paths.

Why the acquirer owns the target's transfer liability immediately

This is not a soft governance point. U.S. enforcement has already treated an acquirer as responsible for a target's cybersecurity noncompliance that predated the deal, including settlements brought under the False Claims Act where the buyer was named a successor in liability for conduct that happened years before it owned the business. Several of those matters turned on failures to meet baseline controls like NIST SP 800-171 and on certifications that proved false. Successor liability means the conduct does not reset at close. You inherit the obligation and the exposure on day one, whether or not the flow ever reached the data room.

An undocumented FTPS script moving regulated data with no logging is exactly the kind of "we were not actually compliant" fact that surfaces after close, attaches to you, and is hard to defend as something reasonable diligence would have caught.

A file-transfer due-diligence checklist for integration teams

Treat transfer flows as a first-class diligence item, not a sub-bullet under "infrastructure." Ask the people, not just the platform. Request a flow inventory, then verify it by reading the actual cron tables, scheduled tasks, and partner connection logs on the target's hosts. Pull a sample of regulated records and trace each one end to end, including who holds the credentials and when they were last rotated. Diff the documented partner list against the endpoints real traffic actually hits. Assume at least one critical flow is a script no one mentions until you find it.

The integration goal matches the one diligence should have set: every regulated transfer running through one auditable channel instead of a pile of inherited scripts. With xEvolve you consolidate the acquired flows into a single governed Environment where every SFTP, FTPS, and AS2 transfer is logged, keys are managed, and the audit trail exists before a regulator asks for it. Map the flows you are inheriting before you sign, and see how that consolidation works across the protocols we support.