Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
A compliance review of Microsoft Discovery has two parts: the controls that Discovery implements as a product, and the controls that Discovery inherits from Azure. This article covers the first part and points you to Microsoft's authoritative sources for the second.
Microsoft already publishes framework crosswalks, audit reports, and certification scopes centrally, and those sources are updated as certifications change. This article doesn't restate them.
Important
This article is provided for informational purposes only. It doesn't constitute a certification, attestation, audit, or guarantee of compliance, and it doesn't imply that Microsoft Discovery is certified or independently audited against any framework referenced here. For the current, authoritative list of Microsoft certifications, audit reports, and control implementation details, use the Microsoft Trust Center and the Service Trust Portal.
Where to find authoritative mappings
Don't rebuild framework crosswalks from Discovery documentation. Use the source that owns each question.
| What you need | Authoritative source |
|---|---|
| Certifications and audit reports (ISO/IEC 27001, SOC 1/2/3, FedRAMP, PCI DSS, and others) and their scope | Service Trust Portal |
| How Azure services map to a specific standard or regulation | Microsoft compliance offerings, Azure compliance documentation |
| Prescriptive Azure security controls, and their mappings to CIS Controls, NIST SP 800-53, and PCI DSS | Microsoft Cloud Security Benchmark, MCSB control domains, MCSB mapping to CIS Controls |
| Continuous measurement of your own deployed Azure resources against a framework | Regulatory compliance in Microsoft Defender for Cloud, Microsoft Purview Compliance Manager |
| Division of security duties between Microsoft and you | Azure shared responsibility model |
| Secure architecture and governance design guidance | Well-Architected Framework security pillar, Cloud Adoption Framework |
| Privacy commitments, subprocessors, and data-protection terms | Microsoft Trust Center privacy |
What you assess in Discovery versus what you inherit
Microsoft Discovery deploys resources into your Azure subscription and Microsoft Entra tenant. That deployment model determines which side of the review each control falls on.
| Control area | Where to assess it |
|---|---|
| Datacenter physical and environmental security, platform hardening and patching, Microsoft personnel screening, platform incident response, subprocessors | Inherited from Azure. Use the Service Trust Portal. |
| Encryption algorithms and platform key management, Azure identity platform, Azure networking primitives | Inherited from Azure. Use Azure security fundamentals and MCSB. |
| Discovery role model, project isolation, managed identity design, network hardening defaults, log categories, AI safety controls | Assess in Discovery. See Discovery-specific control evidence. |
| Subscription and tenant configuration, role assignments, key lifecycle, network topology, log retention, data classification, replication | Your responsibility. See Security and compliance overview. |
| Agents, tools, container images, and prompts that you author | Your responsibility. See Data handling with tools and agents. |
Discovery-specific control evidence
These are the control decisions that are specific to Microsoft Discovery and that a reviewer can't answer from Azure platform documentation. Capture them as evidence in whichever framework or questionnaire your organization uses.
| Control area | Discovery-specific evidence to capture | Reference |
|---|---|---|
| Deployment and trust boundary | Resources deploy to your subscription and tenant; a managed resource group holds backend resources; the control plane runs in East US, Sweden Central, and UK South, with cross-region data-plane deployment available. | Security and compliance overview, Service architecture |
| Identity and access | Discovery built-in platform roles, project-level roles that isolate investigations, and the identity slots that require user-assigned managed identities rather than secrets. | Role assignments, Project-level access control, Managed identities |
| Encryption at rest | Microsoft-managed keys by default; customer-managed keys available for workspace, supercomputer, and bookshelf resources, and selectable only at resource creation time. | Data encryption at rest |
| Network security | Network hardening on by default from API version 2026-02-01-preview; private endpoints for workspace and bookshelf data-plane APIs; virtual network injection through delegated subnets; the scope of the NSP Perimeter Joiner custom role. |
Network security, Virtual networks |
| Logging and audit | Application logs collected automatically in the managed resource group; activity logs for control-plane operations; audit logs that you enable through diagnostic settings and route to storage you own; correlation IDs for end-to-end tracing. | Observability, Enable audit logging |
| AI safety | Foundry Guardrails applied by default to models created in Discovery, grounding with citations, the prohibited-use policy, human-oversight checkpoints, and pre-release safety and groundedness evaluations. | Responsible AI, Platform card, Code of conduct |
| Custom agents and tools | Which container images you publish, what data your tools read and write, and what permissions their identities hold. | Data handling with tools and agents, Tools and model integration |
| Operational resilience | Discovery's multiregion service architecture, and the fact that customer state isn't replicated between regional deployments automatically. | Business continuity and disaster recovery |
For question-level answers organized by the Shared Assessments Standardized Information Gathering (SIG) risk domains, see the SIG-based security and compliance FAQ.
AI governance frameworks
Reviews of agentic AI platforms increasingly reference AI management frameworks such as ISO/IEC 42001 and the NIST AI Risk Management Framework alongside general security controls. For those reviews, the Discovery-specific evidence is the platform's AI safety design: guardrails enabled by default, the prohibited-use policy, grounding and citation behavior, documented model limitations, and pre-release evaluations. See Responsible AI in Microsoft Discovery and the Platform card.
For the underlying Microsoft platform guidance and program-level commitments, see Responsible use of AI overview for Microsoft Foundry and the Microsoft Trust Center.
Regulated data considerations
- Cardholder data. Discovery isn't a payment-processing system, so PCI DSS is typically out of scope for a Discovery deployment. If your scenario introduces cardholder data, treat it under your own PCI DSS program and use the Azure attestations in the Service Trust Portal.
- Personal data. Microsoft's commitments as a processor are defined in the Microsoft Products and Services Data Protection Addendum. The Discovery-specific factor is placement: you choose the regions for your resources, and data stays in your subscription and tenant. See Microsoft Trust Center privacy and the SIG-based security and compliance FAQ.