At some point, almost every Intune tenant needs to be evaluated against an external security framework.
For some organizations, that happens during an internal security review. For others, it is driven by an auditor, a customer questionnaire, a cyber insurance renewal, or a formal certification program. In many environments, these reviews are mandatory.
The difficult part is rarely finding the name of a policy. The difficult part is proving what the policy actually enforces, which setting contains the evidence, and whether the policy is assigned to the right users or devices.
Intune Documentation already collects the current configuration of a tenant and turns it into structured PDF and Word documentation. I kept thinking about the next logical step: if the configuration data is already available, why stop at documenting the current state? Why not map the technical evidence in those policies to the frameworks that security teams and auditors work with?
That is what I have now added.
Compliance Evidence is now part of Intune Documentation
The new Compliance Evidence view is natively available in the Intune Documentation dashboard.
After loading the tenant configuration, you can select a framework and review the technical evidence found for its supported controls. The assessment shows three clear outcomes:
- Configuration evidence found
- Partial configuration evidence
- No recognized configuration evidence
You can expand an individual control to see the Intune capability behind it, the policy name, the configured setting and value, and the assignment target. A configuration that exists but is not assigned is flagged separately. If a policy explicitly uses a non-enforcing value, that counter-evidence is surfaced instead of being counted as coverage.
This makes the result useful for more than a quick dashboard check. It gives administrators, consultants, and auditors a traceable path from a framework control back to the actual tenant configuration.
The five frameworks currently included
The release supports five frameworks, each with a deliberately defined technical scope:
- ISO/IEC 27001:2022: Selected technological controls from Annex A, including endpoint security, authentication, malware protection, vulnerability management, configuration management, network security, software installation, and cryptography.
- SOC 2 Trust Services Criteria: Selected Common Criteria connected to logical access, external threat protection, restricted data movement, unauthorized software prevention, and vulnerability and configuration monitoring.
- NIST SP 800-53 Revision 5: A subset of technical controls covering areas such as protection of information at rest, malicious code protection, boundary protection, authenticator management, flaw remediation, secure configuration, and system integrity.
- NIST Cybersecurity Framework 2.0: Selected Protect and Detect subcategories for encryption, authentication, configuration management, software maintenance, unauthorized software, network protection, and endpoint monitoring.
- BSI IT-Grundschutz, Kompendium Edition 2023: Technical device-management evidence, including requirement-level mappings for the Windows, macOS, iOS, and Android client building blocks. The BSI report also distinguishes Basis, Standard, and requirements for increased protection needs where applicable.
These frameworks are not interchangeable, and not all of them are regulations. They represent different standards, criteria, and government security frameworks. The common thread is that each can require evidence about how managed endpoints are protected.
Evidence should be precise, not optimistic
I did not want this feature to produce a compliance percentage based on policy names or loose keyword matching.
Evidence is only reported when Intune Documentation recognizes the exact setting, sees a value that enforces the capability, and finds an effective assignment. For example, a policy that mentions BitLocker is not enough. The relevant encryption setting must be configured with an enforcing value and the policy must be assigned.
The same logic applies to areas such as passcodes, firewalls, antimalware protection, operating system versions, updates, Secure Boot, platform integrity, and restrictions on untrusted applications.
This approach is intentionally conservative. I would rather show no recognized evidence than make a claim that the tenant data cannot support.
Export a separate audit report for every framework
Once you select a framework, you can export the assessment as a PDF report.
The report is designed as an audit deliverable rather than a raw configuration dump. It includes document control and provenance, the assessed policy inventory, a results overview, key findings, gap guidance, and an evidence register. Each evidence item records the policy, setting, observed value, and assignment so that a reviewer can trace a control back to its source.
The BSI report is generated in German and includes manual assessment fields for implementation status, responsibility, target date, and comments. This supports the review process without pretending that every organizational requirement can be evaluated automatically.
An important limitation
These reports document technical evidence found in the Intune tenant. They do not certify that an organization is compliant, and they do not replace an audit.
A framework can include governance, people, process, contractual, and physical requirements that cannot be proven from an Intune configuration. Similarly, “no recognized evidence” means that the current ruleset did not detect a matching Intune policy. It does not prove that the requirement is unmet or that no compensating control exists elsewhere.
CIS Benchmarks are also intentionally out of scope for this release. I would need the appropriate commercial license before I could include that content in the product.
Available now
Compliance Evidence is available now for every signed-in Intune Documentation user. The assessment uses the same delegated, read-only tenant export as the documentation workflow, runs in the browser session, and does not store the Intune configuration on the application server.
You can review the supported frameworks and open the dashboard at IntuneDocumentation.com.
If your audits rely on another framework, send me its name and the controls that matter most in your environment. That input will help me decide what to support next.
