Forum Discussion

lviskovic's avatar
lviskovic
Copper Contributor
Jan 16, 2026

Guidance: Sensitivity Labels during Mergers & Acquisitions (separate tenants, non-M365, etc.)

We’re building an internal playbook for how to handle Microsoft Purview sensitivity labels during mergers and acquisitions, and I’d really appreciate any lessons learned or best practices.

Specifically, I’m interested in how others have handled:

  • Acquired organizations on a separate Microsoft 365/O365 tenant for an extended period (pre- and post-close):
    • How did you handle “Internal Only” content when the two tenants couldn’t fully trust each other yet?
    • Any tips to reduce friction for collaboration between tenants during the transition?
  • Existing label structures, such as:
    • We use labels like “All Internal Only” and labels with user-defined permissions — has anyone found good patterns for mapping or reconciling these with another company’s labels?
    • What if the acquired company is already using sensitivity labels with a different taxonomy? How did you rationalize or migrate them?
  • Acquisitions where the target does not use Microsoft 365 (for example, Google Workspace, on-prem, or other platforms):
    • Any strategies for protecting imported content with labels during or after migration?
    • Gotchas around legacy permissions versus label-based protections?
  • General pitfalls or watch-outs between deal close and full migration:
    • Anything you wish you had known before your first M&A with Purview labels in play?
    • Policies or configurations you’d recommend setting (or avoiding) during the interim period?

Any examples, war stories, or template approaches you’re willing to share would be incredibly helpful as we shape our playbook.

Thanks in advance for any insights!

1 Reply

  • Hi lviskovic​

    When dealing with Microsoft Purview sensitivity labels during mergers and acquisitions, keep the focus on clarity and temporary controls rather than perfection.

    If the organizations stay on separate tenants, you can avoid a blanket “Internal” label because trust is not yet shared, so split it into simple, clear scopes like “Internal – Company A” and “Internal – Deal Team,” and use dedicated Teams or SharePoint sites for deal work with one enforced label per workspace. 

    Reduce friction by relying on container labels instead of file‑by‑file labeling, limiting guest access to named groups and avoiding heavy auto‑labeling early on. This lets people collaborate safely without opening up the entire tenant.

    For labels and content coming from the acquired organization, don’t rush to merge everything. If they already use labels, run both taxonomies for a while, choose a target model and gradually re‑label the most sensitive content first. If they are not on Microsoft 365, migrate content first with restricted access, then apply labels once it’s in place. Labels work best as the new control layer, not as a replica of old permissions. The biggest pitfalls are over encrypting too early, keeping too many custom permission labels and assuming legacy permissions equal sensitivity.

    Most importantly, Keep the labels simple during the transition, monitor sharing closely and plan a clean‑up once the organizations are ready to fully integrate. I would avid using generalized label for both companies at the early stage and try to cut down those common labels by narrowing it to specific department or functional labels. 

     

    If you find the answer useful, please do not forget to like and mark it as a solution 🙂