Legal governance + technology governance
We read your written policies — or draft them — then design the Purview posture from that paper, not from a product template. The deliverable is a Policy-to-Purview design report.
A default DLP policy does not know what your board published. An acceptable-use policy that nobody mapped into labels will not survive the first incident. Ghani Governance is a Microsoft Purview practice. DPO and privacy-counsel judgement is how that Purview work is designed: the written policy is the input, and Purview is the control plane that has to carry it.
You get both sides in one engagement — legal governance (what you have promised, what UK GDPR and your regulators actually require) and technology governance (what Microsoft Purview can enforce, audit, retain or investigate). That is the groundwater. The tenant build comes after.
This is policy drafting and Purview design, informed by DPO and privacy-counsel experience. It is not a regulated legal service and it is not a substitute for advice on your facts from a solicitor.
The report is the popular artefact. For each obligation in your written set we say: which Purview control carries it, in which workload, in what mode (audit then enforce), who owns the exception, and what cannot be carried in the product so it has to stay a process. It is the brief the engineers and the DPO can share.
Policies, notices, ROPA, incident plans, cloud and AI rules — including the versions sitting unread in SharePoint.
If the set is a gap, we write the policies the Purview design needs. Not a 40-document pack for its own sake.
Each clause to a Purview capability — DLP, labels, retention, Insider Risk, catalog, Communication Compliance, eDiscovery, DSPM for AI — or an honest gap.
Implementation follows the report. Purview services are the build phase, not a separate brochure.
Names vary by organisation. We work with the substance, not the filename.
We will read or draft any other relevant policies the Purview posture actually needs — the named list is not closed. We do not invent a policy you do not need just to sell a document.
Partner pages usually sell a Purview menu. Privacy pages usually sell a document pack. Organisations still have to make a DLP rule that a finance team can live with, that matches the AUP, and that a DPO can explain. The offer is Purview implementation. The DPO and privacy-counsel background is what that work is meant to demonstrate — not a separate legal chapter. Evidenced Purview delivery includes Avanade, IBM, Zurich and JP Morgan. The site is the firm, not a personal brand page.
A written map from your organisation’s published policies (or the ones we draft) onto Microsoft Purview controls — DLP, labels, retention, Insider Risk, catalog, eDiscovery and the rest — plus honest gaps where the product cannot carry the obligation.
That is common. We draft the policies the Purview design actually needs: data handling, data classification, data protection / information security, acceptable use, privacy, employee privacy notice, ROPA, incident response, information governance, AI / Copilot / emerging technology, cloud usage, and IT / cloud architecture where they are in scope — and any other relevant policy the design actually needs. Then we design Purview against that set.
No. It is policy drafting and Purview design, informed by DPO and privacy-counsel experience. It does not replace advice on your facts from a solicitor, and it does not make a web page a substitute for a regulated legal service.
Both. The report is the groundwater. Implementation of DLP, labels, catalog, Insider Risk and the wider platform is the build. You can stop at the report; most organisations want the tenant to match it.
A scoping conversation about what you need to protect, what is already configured, and what must not break.