Who is accountable for privacy compliance when data is transferred in an acquisition?

Why This Matters for Security Teams

In an acquisition, privacy compliance does not pause while legal entities are being combined. The acquiring side typically becomes the party that must demonstrate lawful processing, data minimisation, retention discipline, and jurisdiction-aware transfer handling across the merged estate. That means privacy is not just a legal diligence item; it is an operational control problem that touches records of processing, vendor commitments, consent scope, and security governance. The baseline expectations in NIST Cybersecurity Framework 2.0 and privacy-aware control sets such as NIST SP 800-53 Rev 5 Security and Privacy Controls are useful because they tie governance to evidence, not assurances.

Security teams often assume that the seller’s privacy posture can be inherited as-is, but acquisition conditions usually invalidate that assumption. Data may have been collected under a different notice, a narrower purpose, or a different transfer mechanism, and those differences become material once systems, identities, and logs are merged. This is especially important where personal data is intermixed with employee records, customer records, or regulated data subject to cross-border transfer restrictions.

In practice, many security teams encounter privacy noncompliance only after migration decisions have already been made, rather than through intentional pre-close governance.

How It Works in Practice

The practical question is not just who is “responsible” in theory, but who can prove that each dataset still has a lawful basis after the transaction closes. The acquiring organisation usually has to carry that burden because it controls the post-close processing environment, the security stack, and the evidence trail. If the target company had valid notices and consent language, those records still need to be mapped to the new operating model before data is moved, repurposed, or retained beyond the original scope. For many organisations, this mapping should sit alongside integration planning, not after it.

A defensible acquisition workflow usually includes:

• Inventorying personal data by system, entity, geography, and business purpose.
• Checking whether notices, consents, and contractual terms survive the transfer.
• Confirming cross-border transfer mechanisms and any localisation obligations.
• Reassessing retention, deletion, and access rights after identity consolidation.
• Updating incident response, breach notification, and DSAR ownership for the merged estate.

Where regulated sectors are involved, the security side and privacy side should be aligned through formal control mapping. That is consistent with the management system approach in ISO/IEC 27001:2022 Information Security Management and supporting guidance in ISO/IEC 27002:2022 Information Security Controls, because privacy obligations usually fail when ownership, access, and retention controls are split across teams. Acquisition due diligence should also verify whether identity stores, service accounts, and privileged access paths are being merged in ways that expand access beyond the original lawful purpose, because privacy governance and access governance become inseparable once data is consolidated. These controls tend to break down when integration teams copy data into shared analytics platforms before transfer assessments are complete because the original purpose, access limits, and deletion obligations are no longer technically enforceable.

Common Variations and Edge Cases

Tighter privacy controls often increase transaction friction and integration cost, requiring organisations to balance deal speed against compliance assurance. Best practice is evolving, and there is no universal standard for exactly how much diligence is enough before a transfer, especially when multiple jurisdictions and legacy data sources are involved. In some deals, the target remains a separate controller for a transition period; in others, the acquirer immediately becomes the main decision-maker. That distinction matters because accountability can be shared contractually while still landing operationally on the party that actually processes the data.

There are also edge cases where personal data cannot simply be rolled into the combined environment. Data collected for employment screening, health-related administration, or financial crime obligations may have distinct retention and access rules that survive the deal. In those cases, the stronger rule usually governs until counsel and privacy leadership confirm otherwise. Where the transaction touches AML, KYC, or customer due diligence records, a separate review is prudent because those records often carry purpose limitations that differ from ordinary customer data. For additional privacy-specific context, the principles in the EU General Data Protection Regulation (GDPR) remain a useful benchmark even when the acquisition spans multiple regimes.

Identity teams should also watch for a hidden control gap: post-merger access recertification often focuses on employment status and system access, while privacy teams assume dataset governance has been preserved. That mismatch can leave inherited data exposed to users whose access is technically valid but no longer purpose-bound.

Related resources from NHI Mgmt Group

• Who is accountable when privacy obligations span identity, data, and compliance teams?
• Who is accountable when sensitive personal data is transferred to a country of concern?
• Who is accountable when identity data collection conflicts with privacy rules?
• Who is accountable when identity data quality causes a compliance failure?