Acquisitions: When Two Data Inventories Become One Liability

If you’re a decision maker at your company, you need to be on the bleeding edge of, well, everything. But before you go signing up for seminars, conferences, lunch ‘n learns, and all that jazz, just know there’s a far better (and simpler) way: Subscribing to The Deep View.

This daily newsletter condenses everything you need to know about the latest and greatest AI developments into a 5-minute read. Squeeze it into your morning coffee break and before you know it, you’ll be an expert too.

Subscribe right here. It’s totally free, wildly informative, and trusted by 600,000+ readers at Google, Meta, Microsoft, and beyond.

Your executive team has been working nonstop for months on a new deal. Days, nights, weekends… every issue argued, every point negotiated, every redline polished into submission. I’ve been a deal lawyer, so I know how this goes. By the time closing day arrives, everyone is exhausted, slightly feral, and deeply committed to pretending this is all perfectly normal.

Then the closing call finally happens, the signature pages are released, and those hefty wires with lots of zeros at the end fly into the ether. Lawyers congratulate each other on a successful closing, sometimes sincerely and sometimes in the very special tone lawyers use when the only thing they sincerely mean is thank God we are done here. Inside the company, the acquisition team is celebrating because they just bought the thing that is going to strengthen the business, widen the moat, deepen the offering, or unlock a shiny new market narrative for the next board meeting.

And, to be fair, that part may all be true.

But before everyone gets too comfortable and starts popping open the champagne, let me offer a small reality check. You did not just acquire a company. You also acquired its systems, its vendors, its defaults, its internal workarounds, its retention habits, its old disclosures, its shadow processes, and whatever deeply cursed spreadsheet someone in operations has been nursing since 2018 because “that’s just how we do it.”

In other words, you just inherited their data attic.

And unless privacy was part of diligence all along (or unless the diligence that did happen was actually detailed enough to be useful), that attic may be full of surprises. Somewhere in there are systems nobody documented, subprocessors nobody fully reviewed, data flows no one can explain cleanly, retention practices based on vibes, and a privacy notice that has not been updated since the era when every company thought “we may collect information to improve our services” was a sufficiently complete disclosure strategy.

M&A is exciting like that.

The issue is not that acquisitions are inherently bad from a privacy perspective. The issue is that acquisitions compress change. They accelerate the pace at which systems merge, data moves, access expands, vendors proliferate, and internal assumptions stop matching external reality. Everyone has different goals. For, leadership it’s speed to prove that this spend was justified. Product wants integration so that they can start leveraging the new systems. Finance teams want the new capabilities live as soon as possible so that their balance sheets aren’t screaming anymore. Procurement wants vendor consolidation so that it doesn’t have to suddenly start managing double the contracts. Everyone wants the synergies immediately, and almost nobody wants to hear that the acquired company may have quietly imported a new set of privacy liabilities into the enterprise.

But that is exactly what happened. Because when you buy a company, you do not just buy its products and people. You buy its data posture. You buy its legacy decisions. You buy its risk.

That is why privacy becomes a first-90-days problem.

M&A increases privacy risk because controls tend to lag behind reality. The deal closes in a moment. Integration happens messily, in pieces, through a series of decisions that are often operationally rational and privacy-wise incomplete.

A support team gets new access because they need to service acquired customers. A new vendor relationship stays in place “temporarily” because nobody wants to disrupt operations during transition. Data starts flowing into a shared analytics environment before anyone updates the inventory. Sales wants a combined CRM view. Marketing wants to start cross-selling. Product wants to unify identifiers. Security wants visibility. Legal wants consistency. Privacy, if it is lucky, wants enough facts to figure out what is even happening. Even if you keep everything separate to start, that brings its own pressure to with it. Your company didn’t acquire the target just to not do anything with it, after all!

The question is not whether there will be gaps. There will be gaps.

The question is whether you find and close the highest-risk gaps before someone else finds them for you, like a customer doing diligence, a regulator asking questions, an attacker exploiting a weak point, or an internal stakeholder discovering that the acquired company had a very different idea of “appropriate data retention” than you did.

That is why the first 90 days matter so much. They are not about perfect integration. They are about establishing control.

Because you can’t clone yourself and the rest of the privacy team (or this newsletter would be very different), you have to take a strategic approach to post-merger integration.

The first 90 days should focus on the workstreams that create the greatest risk reduction per unit of effort. In practice, that means prioritizing the places where the acquired company’s reality can most quickly create drift, exposure, or confusion inside your own operating environment.

That usually includes six core workstreams: (1) inventory, (2) vendors, (3) access, (4) disclosures, (5) retention, and (6) incident readiness. And hovering over all of it is one additional theme that privacy teams ignore at their peril… evidence. I know this sounds like every privacy domain, but I guess that’s probably sort of the point.

Let’s take these one at time.

A common post-merger mistake is to assume the acquired company’s practices are “basically similar” to your own. Maybe they are mature. But mature is not the same thing as aligned.

Their systems are different. Their vendors are different. Their subprocessor lists are different. Their collection points are different. Their defaults are different. Their internal names for systems are probably different. Even if both organizations are reasonably sophisticated, they almost certainly made different decisions over time, which means that discovery has to come before assumptions.

You need a merged view (at least for critical systems) of what personal data is collected, where it lives, what it is used for, who can access it, where it flows, and which vendors touch it. You do not need a mural-sized masterpiece by day 10, but you want enough inventory clarity to answer the following practical questions: what is in scope for integration, what will change upon integration, and where do the highest-risk unknowns live.

Think of inventory as your map. Without it, everything else is guesswork.

An acquisition often brings duplicate tools, overlapping vendors, and subcontracted data relationships that nobody on your team negotiated. In theory, vendor rationalization sounds like a later-stage efficiency project. In reality, it is also a privacy control exercise.

Who touches data now in which regions and under what terms? What incident notice obligations apply and what do deletion rights look like? Which vendors handle AI and what AI training language applies, if any? Which vendors are now business-critical, and which ones were inherited but should be retired? Which ones are still active simply because no one has gotten around to shutting them down? If these questions are giving you a stomach ache, I’m sorry. But they do highlight why the vendor ecosystem should be very high on your list.

This is the point where organizations discover that the acquired company had a “critical” vendor that nobody internally would have approved under current standards or that multiple vendors are processing the same categories of data under different contractual protections.

You do not need to renegotiate every agreement in the first 90 days. But you do need a list of critical vendors, a sense of which contracts are acceptable, which are concerning, and which need escalation. If your team cannot say who is handling the most sensitive personal data and under what terms, that is a first-90-days problem.

Post-merger integration often expands data and system access before governance catches up. New teams get access to systems. Shared admin roles are granted. Internal users begin looking across environments they did not previously control. Support, product, analytics, and leadership may all need broader visibility to make integration work.

Some of that is unavoidable. But from a privacy perspective, access expansion is not just an IT housekeeping issue. It changes the actual risk posture of the data environment. More users, more systems, and more inherited permissions mean more opportunities for inappropriate access, misunderstanding, or accidental overexposure.

One of the smartest first-90-days questions is also one of the simplest… who now has access to what, and why? If you cannot answer that clearly with today’s information, then access control belongs near the top of your privacy integration list.

Privacy notices tend to drift even in quiet times. Add an acquisition, new data flows, new products, new vendors, and possibly new categories of users, and drift becomes almost inevitable.

This is where many organizations get caught flat-footed. Even if the combined business doesn’t start operating as though the acquisition has already been fully integrated, people get excited, information gets shared, and things start to change. Even if you have a freeze in place, the outward-facing disclosures still describe the pre-deal world, and it may or may not reflect reality. Internal notices may also become inaccurate for employees, applicants, or internal stakeholders if systems and uses have changed quickly.

The problem is not just compliance in the abstract. It is trust. If your public disclosures reflect a world that no longer exists, your notice stops being an asset and starts becoming evidence against you.

That does not mean you need to rewrite every notice in week one. It does mean you need a deliberate review of what is now true, what is newly in scope, and what statements are most likely to drift if left untouched. If you are playing it safe and keeping systems and data separate, it you will need this review to be able to understand what a post-integration notice is going to look like (or whether it’s even safe to integrate data at all… it may not be).

Retention issues get worse after acquisitions because inherited systems tend to come with inherited habits. Data that was retained “just in case” before the deal often remains retained “just in case” after the deal, except now it sits inside a larger enterprise environment with new access paths and new security and discovery implications.

This is how indefinite retention drift begins. And indefinite retention drift is one of the fastest ways to turn an acquisition into a long-term liability. It’s actually one reason that when I was helping clients with deals, I would advise them (regardless of whether I was on the buy or sell side) to get rid of as much ROT (redundant, outdated, trivial data) as possible before the deal closed.

The first 90 days should not be about perfect retention harmonization. That is usually unrealistic. But they should be about identifying the worst mismatches, documenting the highest-risk datasets, and deciding where retention and deletion practices need near-term attention. If the acquired company kept data forever because nobody owned deletion, that is not a charming legacy quirk. That is an integration priority.

M&A changes your incident surface area immediately. Vendor contacts change or expand. Internal escalation paths change depending on where in the organization you sit. Systems and logs may now sit in environments your existing incident playbooks never contemplated. Your breach notification and investigation workflows may now depend on people or vendors your original plan does not mention.

That means incident readiness is not a later governance clean-up task. It is a first-90-days integration workstream.

At a minimum, update critical contacts, identify which new systems and vendors belong in the incident process, confirm how notice obligations work for inherited vendors, and make sure your team is not relying on obsolete assumptions about who needs to be informed when something goes wrong.

None of this matters if you cannot show what you did. I mean it does matter, but how do you even really remember what you did in the haze of sprinting towards integration on 16 cups of espresso and a burning desire to just be done already?

Integration decisions will be questioned later. It might be by internal audit, customer diligence teams, insurers, executives, or the next group of stakeholders trying to understand why something was handled a certain way. If you do not capture evidence during the integration process, you will eventually spend your time reconstructing it and all that espresso will probably make it really hard to remember what you did.

Evidence does not require a sprawling compliance archive but does require discipline. Keep records of inventory updates, vendor reviews, decision logs, notice review points, key approvals, and the owners assigned to remaining gaps. Evidence is what turns “we handled that during integration” into something other people can trust. If you’ve been using the Privacy Change Engine to map this transition, you’ll have this well in hand already.

You will almost never have perfect integration in 90 days, which is my nice way of saying you will never have perfect integration in 90 days. Luckily, that’s not the goal. Knowledge and control is the 90-day goal.

Knowledge and control looks like this:

In other words, after 90 days you should not necessarily be “finished.” In fact, you won’t be finished. I say this pretty definitively. But you should no longer be surprised by the existence of your own data attic.

No merger is flawless. There is no mythical state where every system is harmonized and every document sings in perfect unison by the end of quarter one. There is only just enough clarity, ownership, and evidence that the combined company is no longer operating in ignorance.

Because acquisitions do not just create value. They create inherited complexity, and if this inherited complexity is left unmanaged, it becomes inherited liability.

The good news is that privacy integration does not have to start with perfection. It just has to start with map, a set of priorities, and the discipline to treat the acquired company’s data posture as a real integration problem rather than a post-closing afterthought.

Finally, reminder that the opinions expressed in this article are the opinion of The Privacy Design Lab. They are not legal advice, and no attorney-client relationship is formed by reading this article or downloading the M&A Privacy Integration Map. If you need to consult legal counsel, you can book a consult with ARLA Strategies or other legal counsel you trust!

If you’re tired of privacy advice that only works in theory, you’re in the right place.

The Privacy Design Lab exists for people who want to practice privacy, not just talk about it. It focuses on practical, repeatable ways teams actually learn. We offer hands-on workshops, downloadable systems, and the Design Studio community where teams and practitioners can go deeper. Paid Fieldnotes subscribers get access to our full archive, plus supporting materials you can actually use.

If that sounds like your kind of work, we’d love to have you.