Privacy due diligence questions for data assets in an acquisition

Why do data assets need their own diligence track?#

Data assets need their own diligence track because the usual privacy review asks whether the target complied with the law, while an acquirer planning AI features or data licensing also needs to know what the records may be used for next. A target can be compliant today and still hold records that cannot be reused beyond the purpose they were collected for.

For a software holding company the split is sharp. A vertical SaaS target holds two kinds of records: content its customers stored in the product, which the target usually processes on their behalf, and records about its own work, such as support tickets, Jira issues, code reviews and release notes. The first group is often off-limits for licensing; the second is often where the opportunity sits.

Run the data-asset questions alongside the privacy and security workstreams, not after them. Answers that arrive after signing cannot shape price, representations or covenants.

Provenance and collection questions#

Provenance questions establish where each record family came from and under what terms it was collected. A handy frame for the request list comes from the Data & Trust Alliance, whose Data Provenance Standards sort dataset metadata under three headings: Source, Provenance and Use. The Use heading names items such as where consent documentation is kept, the license to use and the intended use, all of which an acquirer should ask about.

Notices, consents and customer contracts#

Notices and contracts decide what an acquirer may do with records later, so ask for their history, not just current versions. A privacy notice updated last year does not govern records collected under the version before it.

A missing notice archive is common and often fixable. Old site builds, marketing email records and public web archives can usually reconstruct what a notice said at a given time.

• 1Every version of the privacy notice, with the dates each version applied.
• 2Employee and contractor privacy notices, plus any monitoring or recording notices.
• 3Customer contract templates by era, including data processing addenda, use restrictions and any clause on aggregated, de-identified or AI training use.
• 4Negotiated exceptions for large customers that override the template.
• 5Consent records for marketing, call recording and any sensitive data.
• 6Terms of the SaaS tools that hold the records, including export rights and the vendor's own use of customer data.

Prior licenses, exclusivity and existing data sharing#

Prior licenses and data-sharing deals can restrict what an acquirer may license later, and they rarely surface in a standard privacy questionnaire. Ask for every agreement under which the target's data left the company or was used to build something.

Look for exclusive licenses, most-favored-customer terms, sharing with analytics or marketing partners, reseller arrangements, research collaborations and any earlier AI training use, whether by the target or by its vendors under their own terms. Check change-of-control and assignment clauses in each, since some end or require consent on a sale.

Ask the product team a direct question as well: has the product used customer content to train or improve any model? A straight answer from the people who built it can matter as much as any document in the data room.

Deletion, retention and data subject requests#

Deletion records show whether the target can prove which data it no longer holds. An acquirer that later licenses a record a person asked to delete inherits that problem, along with the gap in the paperwork.

Security and incident history#

Cybersecurity due diligence overlaps with data-asset diligence wherever an incident or a weak control affects records you might reuse. A breached archive may carry notification history and regulatory attention, and weak access logging makes provenance harder to prove.

• 1Incident log and any breach notifications, with the record families affected.
• 2The latest SOC 2 report or equivalent assessment, with exceptions noted.
• 3Access controls for production data and for bulk exports.
• 4Vendor inventory with data processing terms for each vendor.
• 5Encryption, key management and logging for the systems that hold the richest history.

Illustrative: a software holding company checks a target's data before closing#

Illustrative: a fictional software holding company is buying a construction project management vendor. The group COO adds data-asset questions to the privacy workstream because the group has begun reviewing licensing options across its businesses.

The answers split the target's data in two. Customer project files, drawings and daily logs sit under contracts where the target acts for its customers, and the newer contract template prohibits AI training on customer content. The target's own records, years of support tickets linked to Jira issues and code reviews, are company-created and covered by employee notices that mention internal use of work systems.

The deal team adds a covenant requiring the target to preserve its old help desk archive through a planned migration, plus representations about notice history and prior data sharing. After closing, the internal engineering and support records go forward to a rights review, and customer content stays out of scope.

How SourceX uses diligence answers#

SourceX maps diligence answers onto the Rights step of the SourceX five-step transaction. Provenance, notices, contracts and deletion records are the same evidence a rights review needs, so well-organized diligence files carry straight into post-closing work.

Where a package goes ahead, its SourceX Evidence Packet sets out provenance, licensing rights, permitted use, the privacy record and release authorization, much of it drawn from the diligence file. The acquirer's counsel decides what the findings permit, and SourceX records the result.