Technical Evidence: Referencing M365, Purview, and Cloud Security Configurations
How to effectively map Microsoft 365 screenshots, Purview outputs, and Security Configurations to your IT governance framework.
Beyond Policy: The Proof is in the Configuration
Governance often starts with policies, but it must survive at the configuration level. For organisations leveraging Microsoft 365, the evidence requirements shifted from “Trust me, we have an MFA policy” to “Show me the Entra ID conditional access policy.”
Vivid Risk allows for granular referencing of technical evidence using three primary modalities:
1. M365 & Admin Center Screenshots
Screenshots are effective “Point-in-Time” proofs. When uploading M365 screenshots (e.g., of a mailbox security setting or an account lockout policy):
- Best Practice: Ensure the system clock and the user context (the email in the top right) are visible.
- Vivid Mapping: Use the “Screenshot” type.
- AI Insight: Our scanning engine looks for specific keywords like “Enabled,” “Enforced,” or “Global Administrator” to match the screenshot to the relevant control.
2. Microsoft Purview & Compliance Manager Outputs
Purview is the gold standard for Microsoft-centric organisations. Its exports—whether they are Data Loss Prevention (DLP) reports or eDiscovery logs—are high-fidelity audit signals.
- Best Practice: Export Purview results as PDF or CSV. A CSV export from the Compliance Manager can satisfy multiple “Data Privacy” controls simultaneously.
- Vivid Mapping: Use the “Export” or “Log” type.
- Verification: Link these to “M8.1 (Logging)” or “M2.3 (Data Protection)” sections.
3. Security Configurations (JSON, XML, or CLI)
For “Security Configurations,” the platform supports the upload of actual configuration files or their rendered exports from tools like Microsoft Defender for Cloud or CIS Benchmarks.
- Best Practice: Upload the JSON configuration of a specific tenant or an export of the M365 Secure Score checklist.
- Vivid Mapping: Use the “Config” type.
- AI Scan: Vivid Risk parses configuration metadata to detect “Audit Confidence.” For example, if a configuration file mentions “Require-MFA: True,” the confidence score of the associated control is automatically raised to “Audit-Grade.”
Structured Referencing
By categorising your evidence correctly—Screenshots for UI-based proof, Exports for system-generated data, and Configs for infrastructure-level intent—you build a multi-layered defence for your audit.
Instead of a single document, you are presenting a Triangulated Proof Layer:
- Policy: What we said we would do.
- Config: What we told the machine to do.
- Screenshot/Log: What the machine actually did.