Integrating data policies after an add-on acquisition

Which data policies need integrating after an add-on?#

The data policies to integrate are the ones that decide what the combined company may do with records: privacy notices, the AI use policy, the retention schedule, vendor terms, employee notices and customer contract templates. Security policies matter as well, but they usually follow the platform's IT integration and have their own owner.

Collect all of them in the first weeks, including the versions that applied in earlier years. A privacy notice updated recently says nothing about what customers were promised when older records were collected, and the add-on's staff may not know where earlier versions live. Old contract attachments, signed order forms and archived copies of the website often fill the gap.

• 1Website and customer privacy notices, including the past versions in force when older records were collected.
• 2Employee handbook sections on monitoring, email, chat and call recording.
• 3The AI use policy, or the absence of one, and the AI tools staff already use.
• 4The retention schedule and any legal holds in place at closing.
• 5Vendor agreements for every system holding records, including AI feature terms.
• 6Customer contract templates and the negotiated data clauses of large accounts.

Why old policies still govern old records#

Old policies still govern old records because the promises a company made when it collected information travel with that information. Publishing the platform's privacy notice on the add-on's website changes what applies to records collected from then on; it generally does not rewrite what earlier customers or employees were told.

Regulators have flagged the risk. In February 2024, FTC staff warned that a company that adopts more permissive data practices, such as using consumers' data for AI training, and tells consumers only through a surreptitious, retroactive change to its terms of service or privacy policy may be engaging in unfair or deceptive practices. Treat any plan to use the add-on's historical records in a new way, internally or through licensing, as a question for counsel, assessed against the terms in force at collection.

The practical control is tagging. Every record set that moves into a platform system should carry its source entity and the policy version it was collected under, so later decisions can filter on both.

The first-100-days policy checklist#

The first-100-days policy checklist groups the work into three windows. The order matters more than the exact dates: collect and freeze first, then decide, then publish.

Harmonize now or keep separate for a while?#

Not every policy should merge on the same timeline. The record type and the promises already made decide whether the add-on adopts the platform policy at once or runs in parallel for a period.

Vendor terms and AI features at the add-on#

Vendor terms deserve early attention because AI features in help desks, CRMs, call platforms and field service software can process records under defaults nobody at the add-on chose. Some vendors' terms allow use of customer data to improve their models unless an admin opts out; others rule it out. The answer sits in each contract and each admin console, so check both rather than assuming.

Record what you find: the setting, the date and the person who changed it. That record matters later for privacy compliance and for any licensing conversation, because a buyer of records will ask whether the same records were already made available to another AI developer.

Rights inherited from acquired contracts#

A buy-and-build platform assembles a deeper combined history with each add-on, which can make its records more interesting to AI developers. Rights, however, arrive slice by slice. Each add-on's records carry its own customer contracts, privacy notices and vendor terms, and the acquisition agreement may add restrictions or transition obligations of its own.

Plan for scoped licensing from the start. Keep a rights note per source entity and expect that a combined package may leave some add-ons out entirely. Scoping by entity lets the clear slices move forward without waiting for the most restricted one.

Illustrative: an engineering platform absorbs a surveying firm#

Illustrative: a fictional civil engineering platform acquires a land surveying firm as its third add-on. The surveying firm runs projects in BQE Core, keeps field data and plats on a file server, and uses an AI notetaker on client calls.

In the first month the platform pauses the file server's automated cleanup, archives the surveying firm's past privacy notices, and finds the notetaker storing transcripts under the vendor's default settings. The add-on's general manager pauses the notetaker until the platform's AI use policy applies. Counsel flags two municipal clients whose contracts restrict any reuse of project records.

By day 100 the surveying firm's records sit in the platform archive tagged by source entity. When the platform later screens its combined project history for licensing, the two municipal clients' records drop out automatically and every remaining slice carries its own rights note.

How SourceX works with integrated platforms#

SourceX treats each source entity inside a platform as a separate slice in the Rights step of the SourceX five-step transaction. The entity and policy-version tags this checklist creates let the rights review run from metadata and the governing documents, with no records shared during the initial assessment.

When a combined package proceeds, the SourceX Evidence Packet records which entities' records are included, the licensing rights for each, and release authorization from the correct signer.