Why Microsoft 365 Is Not the Answer for eDiscovery
Author: Amit Dungarani – Casepoint
...It’s no wonder four in five Fortune 500 companies now use the subscription-based productivity suite...
...When you factor in the data management, compliance, and eDiscovery capabilities through Microsoft Purview, many organizations have even turned to M365 as their preferred eDiscovery technology solution to conquer the data avalanche...
… using M365 to manage your whole eDiscovery process is likely to cause headaches. You’d be better served choosing a platform that allows you to process, review, produce, and analyze data from any source...
In my bad old analyst days, I was frequently asked to draft ‘competitive analysis’ content like this for marketing teams worried about losing customers. It is relatively easy to highlight any product’s documented limitations, the trick is to recast them in an unsuitable usage scenario. Casepoint asserts that customers are using M365 Purview for the ‘whole eDiscovery process’. The Microsoft product team has clearly positioned Purview and the Graph API to support complex eDiscovery scenarios with the expectation that customers and partners will export relevance rich search results to partner platforms for review, redaction and production.
Microsoft’s Purview (Basic and Premium) walks the line between broad preservation in place and selective ECA/collection requirements. While I have clients who use Purview Premium for small investigations or hold scoping, larger matter discovery searches are generally exported via Purview for review.
Casepoint calls out many of the same M365’s platform architectural limitations that I documented in my recent free research paper, “Microsoft 365: Information Governance in Place”. Knowing your technology’s limitations is essential to creating a defensible workflow to meet discovery requirements. I focus on M365 capabilities because EVERY ONE of my global corporate clients has their primary custodial ESI stored there. Every M365 customer’s defensible eDiscovery workflow stack leverages Microsoft Purview and/or the API infrastructure beneath it, even if they still think that admin console mailbox exports are ‘best practice’.
Indeed, Casepoint’s connector uses the same Microsoft platform/API in their solution. I would argue that their old-school ‘migrate all the held data’ scenario is impractical and inefficient. I could not find any published documentation of the Casepoint platform limitations, performance or exceptions. This is unfortunately typical of eDiscovery technology providers.
The Casepoint blog points out many real limitations that may indeed impact M365 customers with unrealistic expectations that Purview is some kind of eDiscovery Easy Button. Regretfully, the blog does not use that opportunity to provide practical advice on how customers can leverage Purview in their aggregate eDiscovery lifecycle including the Casepoint platform. Maybe that is why I could not find Casepoint in the Microsoft partner directory? I know that I have also been guilty of finding fault without tempering the issues with work arounds in my zeal to share knowledge. In the future I hope to focus on success strategies over FUD.