Maynor in the Cloud / Beyond the Tenant
Why discovery, evidence, exposure, ownership, and history are not the same thing.
Microsoft Purview can tell you a lot.
It can help you identify sensitive information, understand classification, review activity, investigate events, track posture, export evidence, and act on security findings.
But there is a point where a Purview report stops being a complete answer.
That point usually appears when somebody asks a question like:
That sounds like one reporting question. Architecturally, it is several. And they do not all come from the same evidence.
The Reporting Problem Is Larger Than Discovery
A common starting point is: What can I export from Purview?
I would start somewhere else:
A classification result can tell me sensitive information was detected. It does not necessarily tell me who can access it today.
An activity record can tell me something happened. It does not necessarily tell me the current state of the content.
A technical owner can tell me who administers a workspace. It does not necessarily tell me who is accountable for the data.
A current posture view can tell me what the service understands now. It does not automatically create every historical record the organization may need.
Start With What the Evidence Needs to Prove
I separate the reporting question into evidence classes:
| Evidence class | Question it answers |
|---|---|
| Classification | What type of information is this? |
| Inventory | Does it exist, and where? |
| Exposure | Who can reach it? |
| Activity | What happened? |
| Ownership | Who is accountable? |
| Historical state | What changed over time? |
| Risk | What does all of this mean to the organization? |
These are related. They are not interchangeable.
A reporting architecture can correlate those things. It should not pretend they prove the same thing.
Native Purview Is Often Enough
I do not think the right conclusion is that Purview reporting is inadequate. That is too broad.
Native Purview already provides useful evidence across classification and discovery, Audit, Activity Explorer, DLP, eDiscovery, DSPM, and supported exports or interfaces.
For example, Activity Explorer provides a bounded historical view of activity involving labeled content. Audit provides a broader searchable activity record with retention that depends on licensing and policy. DSPM provides posture insights, trends, reports, and recommendations.
If one of those capabilities answers the business question, I would stop there.
Do not build an engineering platform because the portal does not look like the dashboard you imagined.
Classification Is Not Exposure
Suppose Purview tells me a SharePoint site contains sensitive information.
That tells me something useful. The content exists, and the classification or detection logic found it.
But now somebody asks: Who can actually access it?
That is a different question.
To answer it properly, I may need to understand SharePoint permissions, groups, external identities, sharing links, inherited permissions, direct access, and directory context.
Some of that evidence may come from SharePoint or Microsoft Graph rather than the classification result itself.
The Purview finding was not wrong. It simply answered a different question.
Activity Is Not Current State
An audit event can tell me a file was shared. Useful.
But that does not necessarily tell me the file is externally accessible right now.
The sharing link might have expired. Permissions might have changed. The file might have moved. The site might have been archived.
Activity is evidence that an event occurred. Current exposure is evidence about present state.
Those are two different architectural questions, and they may require two different sources.
Ownership Is More Complicated Than an Owner Field
A Microsoft 365 object may have an owner. That does not automatically make that person the accountable owner of the information.
A SharePoint administrator can keep a site operational. A Teams owner can manage membership. Neither necessarily has authority to decide how long the data should be retained, whether a risk should be accepted, or whether access is still appropriate.
If the business needs accountable ownership, additional context may be required from Entra ID, organizational data, HR, CMDB, owner attestation, or workflow.
Purview can tell us what it knows. It cannot manufacture an ownership model the organization never defined.
History Changes the Architecture
Suppose the question is: What sensitive data exists today?
A current native view may answer it.
Now change the question:
That introduces a historical requirement.
Some native experiences already provide history. But that does not mean every custom business metric, inventory snapshot, ownership state, or cross-workload correlation will exist historically at the level the organization needs.
If it does not, history has to be designed. That might require scheduled collection, exports, APIs, dated raw evidence, SQL, or a data lake.
The reporting requirement — not Purview itself — changes the architecture.
The Moment Reporting Becomes Data Engineering
Once teams find a reporting gap, the instinct is often to collect everything: Graph, SharePoint, Exchange, Entra, Audit, Purview, PowerShell, APIs — put it all into a database and build Power BI on top.
Technically, you can.
Architecturally, I would ask why.
If the requirement is simply to show current sensitive-data classifications, stay native if native gives you the answer.
If the requirement becomes sensitive data correlated with current external exposure and accountable business ownership, enrichment may be justified.
If the requirement becomes showing the same condition every quarter and proving whether remediation improved it, historical storage may be justified.
Technology should enter because the evidence requirement demands it, not because we decided we wanted a data platform.
The Purview Evidence / Reporting Architecture
Purview Evidence / Reporting Architecture — extend only when the evidence requirement proves something is missing.
The most important decision happens early:
If yes, stop. Use it.
If no, identify the gap precisely, then add only the capability needed to close that gap.
A Reporting Layer Cannot Create Missing Facts
Once data is centralized, it begins to look authoritative. There are charts, KPIs, trend lines, and executive dashboards.
But presentation quality does not improve source quality.
If the source does not prove effective access, Power BI cannot make that fact appear.
If accountable ownership was never established, a directory join does not magically create business accountability.
If historical observations were never collected, a warehouse cannot reconstruct the past with certainty.
A custom reporting layer can collect, normalize, correlate, preserve, and present evidence. It cannot create evidence that never existed.
What I Ask Before Extending Purview Reporting
- What question are we trying to answer?
- What evidence would actually prove it?
- Which Purview capability already provides that evidence?
- What specifically is missing?
- Where does the missing evidence exist?
- Do we need current state, historical state, or both?
- How fresh does the evidence need to be?
- Who is going to consume it?
- Who owns the definition of the metric?
- Who validates that the correlation is accurate?
- What happens after the report finds something?
- What remains unknown even after we build it?
If we cannot answer those questions, I am not ready to recommend the reporting platform yet.
The Architectural Judgment
The limit of native Purview reporting is not simply that Purview cannot report enough.
The limitation appears when the business question crosses evidence boundaries.
A classification result does not automatically prove exposure. An activity event does not prove current state. A technical owner does not prove business accountability. A current dashboard does not necessarily prove every historical condition. And a custom report does not become truth simply because multiple Microsoft APIs have been joined together.
That keeps Purview authoritative for what it knows. It keeps custom engineering focused on an actual evidence gap. And it keeps the architecture from becoming a technology project before the organization has even defined the question.
