Business Acquisitions and PIPEDA: The Data Diligence That Deals Miss

By Laith Sarhan

Business Transactions Data Protection & Cybersecurity

When a private equity firm acquires an e-commerce business, the value often lies in the customer database. Repeat purchasers, email subscribers, purchase history, marketing preferences — these assets drive the multiple.

Yet in most Canadian M&A transactions, privacy diligence remains superficial. The deal team confirms a privacy policy exists, checks for obvious litigation, and moves on. The assumption is that customer data transfers seamlessly with the business.

That assumption can be expensive.

The Statutory Framework: What s. 7.2 Actually Says

PIPEDA's business-transaction exception — s. 7.2, added by the Digital Privacy Act in 2015 — permits use and disclosure of personal information without the knowledge or consent of the individual in connection with business transactions (defined broadly: asset sales, mergers, corporate financing, securitization, leases and licences of assets). But it is a conditional exception, and the conditions differ between the prospective and completed phases.

Prospective transaction (s. 7.2(1)) — due diligence and negotiation phase. Parties may use and disclose personal information without consent only if:

• (a) the organizations have entered into an agreement requiring the receiving organization:
  • (i) to use and disclose the information solely for purposes related to the transaction,
  • (ii) to protect it by security safeguards appropriate to the sensitivity of the information, and
  • (iii) if the transaction does not proceed, to return or destroy it within a reasonable time; and
• (b) the information is necessary both to determine whether to proceed and, if proceeding, to complete the transaction.

Completed transaction (s. 7.2(2)) — post-closing. The exception continues only if:

• (a) the parties' agreement requires the receiving organization:
  • (i) to use and disclose the information only for the purposes for which it was collected (the purpose-limitation condition),
  • (ii) to protect it with appropriate safeguards, and
  • (iii) to give effect to any withdrawal of consent made under clause 4.3.8 of Schedule 1;
• (b) the information is necessary for carrying on the business or activity that was the object of the transaction; and
• (c) one of the parties notifies the individual, within a reasonable time after completion, that the transaction completed and their information was disclosed.

Two further provisions with teeth: s. 7.2(3) makes those agreements binding — an organization must comply with the terms of any agreement it enters under the exception (a breach is a PIPEDA contravention, not just a contract claim). And s. 7.2(4) carves out transactions whose primary purpose or result is the purchase, sale, or lease of personal information itself — a straight data-broker deal gets no exception at all.

The provincial equivalents matter in cross-border deals: Alberta's PIPA (s. 22) and BC's PIPA (s. 20) have parallel business-transaction provisions with similar structure, and Quebec's Private Sector Act (as modernized by Law 25) has its own commercial-transaction exception at s. 18.4 — likewise conditioned on an agreement, use limited to concluding the transaction, and destruction if the deal dies. Quebec's definition of "commercial transaction" is broad, extending to financing and security creation.

Where Acquirers Get It Wrong

1. The Purpose Limitation Trap

The completed-transaction condition in s. 7.2(2)(a)(i) is where deals quietly break. The acquirer may use transferred personal information for the purposes for which it was originally collected — nothing more.

Consider an e-commerce acquisition where the target collected customer data for order fulfillment, customer service, and marketing communications (with consent). The acquirer wants to cross-sell products from other portfolio companies, integrate the database with its existing CRM, and apply proprietary analytics to identify high-value segments.

Each of those is plausibly a new purpose — beyond what a reasonable person would have understood at collection. PIPEDA then requires either that the new use fall within reasonable expectations or that fresh consent be obtained. "We own the database now" is not a legal basis.

2. Consent Quality Issues

During diligence, ask: what exactly did customers consent to? Common findings:

• Vague privacy policies that don't specify marketing uses, leaving consent scope ambiguous
• Pre-checked boxes or bundled consents that don't meet the "meaningful consent" standard (s. 6.1 and the OPC's guidelines — consent is only valid if a reasonable person would understand the nature, purpose, and consequences)
• No records of consent for legacy customers acquired before the target implemented proper consent management
• Consent to the target, not to unnamed future acquirers — raising questions about whether consent "travels" with the transaction at all

The OPC has been increasingly focused on consent validity — the Federal Court of Appeal's 2024 Facebook decision confirmed that "meaningful" consent is read seriously. An acquirer inheriting a database built on questionable consent inherits that liability.

3. Marketing Database Contamination (and CASL)

E-commerce businesses often maintain multiple data categories: transactional customers, marketing-only contacts, and scraped or purchased third-party lists. The regulatory status of each differs — and CASL (Canada's anti-spam legislation) intersects significantly: commercial electronic messages run on express consent or implied consent through existing business relationships, with time-limited windows. Whether the target's implied-consent relationships and express consents support the acquirer's email program post-closing is a diligence question in its own right — don't assume consent and relationship transfer automatically with the asset sale. Acquirers who treat the entire database as a unified asset often discover, post-closing, that significant portions can't be marketed to lawfully.

Diligence That Actually Protects Value

Data mapping. Before assigning value to a customer database, understand what it contains: record counts and data elements, collection source per category, what consents exist and how they were obtained, opt-out/unsubscribe history, and records from jurisdictions with different rules (Quebec, EU).

Privacy policy archaeology. The current privacy policy isn't sufficient — you need the policies in effect when data was collected: historical versions, changes in consent mechanisms over time, and any modifications made in response to complaints or regulatory guidance.

Consent audit. For marketing databases: sample consent records to verify what customers agreed to; review language for specificity about marketing, third-party sharing, and transfer; identify reliance on implied consent that may not withstand scrutiny; assess Quebec-specific issues (Law 25's consent standard is stricter, and its commercial-transaction exception at s. 18.4 has its own conditions).

Regulatory history. Any OPC or provincial commissioner complaints, prior inquiries or investigations, CASL compliance history, breach records (PIPEDA requires 24-month breach record-keeping — ask to see the register).

Post-Acquisition Integration

Notification isn't consent. Section 7.2(2)(c) requires notifying individuals within a reasonable time after closing — but notification alone doesn't authorize new uses. Practical approaches:

• Segmented communication: inform customers of the acquisition and simultaneously request consent for new uses — but make the request distinct and genuinely optional
• Sunset legacy data: for records with unclear provenance, run a re-engagement campaign that effectively refreshes consent
• Ring-fence the database: if cross-selling isn't covered by existing consents, treat the acquired data as separated until proper consent exists
• Honour withdrawals: s. 7.2(2)(a)(iii) requires giving effect to consent withdrawals under Schedule 1, clause 4.3.8 — your suppression lists need to survive integration

CRM integration risk. Merging customer databases across portfolio companies creates purpose-creep risk. Owning multiple customer relationships doesn't mean they can be combined without attention to the consent basis for each.

What This Means for Deal Teams

For buyers: build privacy diligence into the standard playbook — not as a compliance checkbox but as a value assessment. A customer database is only worth what you can lawfully do with it. If post-acquisition plans require consent you don't have, the database is worth less than the model assumes, and the reps/indemnities should price that.

For sellers: clean up data practices before going to market. Consent gaps, retention failures, and sloppy data management become diligence findings that erode valuation or become purchase-price adjustments.

For M&A counsel: privacy has moved from "check the box" to material deal issue. Reps and warranties should be specific about consent quality, regulatory history, and data provenance. Indemnities should cover privacy claims arising from pre-closing practices. Post-closing covenants should address integration constraints. And where the target's value includes AI models or training data, the diligence extends further — see the companion piece on acquiring an AI company.

The acquirer that inherits a privacy mess owns that mess.

The Larger Point

Customer data has become central to how businesses are valued. But data value depends on data usability, and usability depends on the legal foundations for how that data was collected and can be used. PIPEDA's s. 7.2 isn't an obstacle to transactions — it's a framework with specific, citable conditions: agreements in place (7.2(1)(a), 7.2(2)(a)), necessity tests (7.2(1)(b), 7.2(2)(b)), notification (7.2(2)(c)), binding effect (7.2(3)), and a carve-out for data-as-asset deals (7.2(4)). The deals that struggle are the ones that ignored those conditions until closing, then discovered the constraints too late to address them cleanly.

FAQ

Does PIPEDA allow customer data to be shared with a prospective acquirer during due diligence?

Yes, under s. 7.2(1), without individual consent — but only if the parties have a written agreement requiring the recipient to use the information solely for purposes related to the transaction, protect it with safeguards appropriate to its sensitivity, and return or destroy it if the deal doesn't proceed; and only information necessary to decide whether to proceed and to complete the transaction may be shared.

Can an acquirer use an acquired customer database for new purposes after closing?

Not under the s. 7.2 exception alone. Section 7.2(2)(a)(i) limits post-closing use to the purposes for which the information was originally collected. New uses — cross-selling to other portfolio customers, novel analytics, AI training — require either that the use fall within what a reasonable person would have expected at collection, or fresh consent. The post-closing notification under s. 7.2(2)(c) is a notice obligation, not a consent substitute.

Does the business-transaction exception apply when the deal is primarily about buying data?

No. Section 7.2(4) excludes transactions whose primary purpose or result is the purchase, sale, other acquisition or disposition, or lease of personal information itself. A transaction that is fundamentally a data sale gets no consent exception.

Do Quebec, Alberta, and BC have their own versions of the exception?

Yes. Alberta's PIPA (s. 22) and BC's PIPA (s. 20) contain parallel business-transaction provisions, and Quebec's Private Sector Act (as modernized by Law 25) has a commercial-transaction exception at s. 18.4 — similarly conditioned on an agreement, use limited to concluding the transaction, and destruction if it doesn't proceed. Cross-border deals should map all applicable regimes, not just PIPEDA.