Few decisions stall a SharePoint Embedded project faster than an unresolved security review. The engineering team is ready, the containers are provisioned, the demo works, and then the deployment hits the desk of a CISO, a data protection officer, or a compliance lead in a regulated industry, and the questions begin. Where does the data physically reside? Which encryption keys protect it, and who holds them? Can we apply our existing data loss prevention policies? Will an eDiscovery search find content stored in these containers? Who is accountable when something goes wrong — Microsoft, or us?
This article is written for exactly those reviewers. SharePoint Embedded security and compliance is not a bolt-on; it is inherited from the Microsoft 365 substrate that the platform is built on. But “inherited” does not mean “automatic”, and the precise boundaries of what you get for free, what you must configure, and what remains your responsibility as the application owner are frequently misunderstood. Getting SharePoint Embedded data residency, Purview coverage, encryption and audit right is the difference between a sign-off and a six-week delay. Below we walk the compliance surface so your security review can reach a confident, evidence-backed decision.
How SharePoint Embedded Inherits Microsoft 365 Compliance
SharePoint Embedded stores application content in containers — file-storage partitions that live within your Microsoft 365 tenant but are not surfaced through the standard SharePoint user interface. This architectural detail is the single most important fact for a compliance reviewer to internalise: container content is tenant data. It resides on the same storage substrate as SharePoint Online and OneDrive, it is governed by the same tenant boundary, and it is reachable by the same compliance engines.
That inheritance is what makes the platform attractive to regulated organisations. Rather than building data loss prevention, retention, encryption and discovery from scratch inside a bespoke document store, you adopt the controls Microsoft already operates at scale, and most of your compliance story is told through Microsoft Purview rather than through application code.
Two caveats matter from the outset. First, because containers are not visible in the normal SharePoint admin surfaces, governance is administered through container types and PowerShell/Graph rather than site-by-site clicking — your processes must adapt. Second, support for individual Purview features has matured at different rates, and a few capabilities carry conditions or remain in active development. A security review should confirm current feature status against Microsoft’s published documentation at the point of sign-off rather than assuming parity with classic SharePoint.
The Microsoft Purview Integration Surface
Microsoft Purview is the compliance control plane, and SharePoint Embedded participates in most of it. The integration surface a reviewer needs to assess covers five pillars.
Data Loss Prevention (DLP). SharePoint Embedded content can be brought within the scope of SharePoint/OneDrive DLP policies, allowing you to detect and block the egress of sensitive information types — payment card numbers, national insurance numbers, health identifiers and custom patterns — held in container files. DLP evaluation depends on content being indexed and on the policy location scope including the relevant content; validate enforcement behaviour (block, warn, audit-only) against your own test data rather than assuming a policy applies silently.
Sensitivity labels (Microsoft Information Protection / MIP). Labels classify content and can carry protection, including encryption and usage rights. We treat label propagation as its own topic below because it is the area most prone to misunderstanding.
Retention labels and policies. Retention governs how long content is kept and when it is disposed of — the backbone of records management for finance, legal and public-sector workloads. Retention applied at the policy or label level lets you enforce “keep for seven years, then review and delete” rules on container content, and supports preservation so that deletion by a user or by the application does not destroy a record before its retention period expires.
eDiscovery. Container content should be discoverable through Purview eDiscovery so that legal holds and content searches reach it. This is a question a litigation-conscious legal team will always ask: “If we are served, can we find and preserve everything?” Confirm that your container types and content are within eDiscovery scope and test a search against seeded content before you rely on it.
Communication Compliance. Where your scenario involves message-like or collaborative content, Communication Compliance can monitor for regulatory and conduct breaches. Its applicability depends on the nature of the content you store; assess it against your use case rather than enabling it reflexively.
A mature review does not tick these as binary “supported / not supported”. It asks, for each pillar: is the capability available for our container type today, is it enabled, is the policy scope correct, and have we demonstrated it working with representative test content?
Sensitivity Label Propagation and Label-Based Encryption
Sensitivity labels are where the most consequential security questions live, because a label can carry encryption that travels with the file wherever it goes.
When a sensitivity label with encryption is applied to a document, Microsoft Information Protection encrypts the file itself and embeds the usage policy — who can open it, and what they may do. That protection is persistent: it remains attached to the file if it is downloaded, emailed or copied out of the container, and only authorised identities can decrypt it. For a regulated organisation this is the strongest form of protection available, because it does not rely on the storage boundary holding.
Propagation behaviour is the detail to pin down. Labels may be applied by users in client applications, by automatic or recommended labelling policies, or programmatically by your application as it ingests content. A label set on a container or applied as a default can flow to the documents within it; conversely, the label already on a document is honoured when it is opened or edited. The key review question is which propagation paths your design depends on — default container labelling, auto-labelling on content inspection, or explicit labelling through the API — and whether each behaves as expected for your container type. Because label-based encryption interacts with indexing, co-authoring and DLP, test these together: an encrypted file may be deliberately excluded from certain processing, which can affect whether a DLP rule or a search behaves as you expect.
Document, in your evidence pack, the exact labelling model: who can apply and remove labels, whether downgrade is permitted and audited, and how label-based encryption keys are managed (see below).
SharePoint Embedded Data Residency: Multi-Geo and Advanced Data Residency
“Where does the data live?” is non-negotiable for organisations under GDPR, UK data protection law, financial-services regulation or public-sector data sovereignty requirements. Because SharePoint Embedded data residency is governed by the same mechanisms as the rest of SharePoint Online, the answer flows from your tenant’s geography configuration.
In a single-geography tenant, container content resides in the tenant’s home Microsoft datacentre region, and Microsoft’s regional commitments for SharePoint Online apply. For organisations operating across borders, Multi-Geo allows data to be provisioned and stored in specific satellite geographies, so that, for example, UK-resident content stays in the UK region while another business unit’s content stays in its own geography. Advanced Data Residency (ADR) provides additional contractual and technical assurances about where covered customer data is stored at rest for eligible workloads.
For a security review, the practical points are:
- Container data residency follows the tenant and, where configured, the Multi-Geo geography assignment. Confirm which geography your containers are provisioned into and whether that satisfies your regulatory obligations.
- Multi-Geo and ADR have licensing and eligibility prerequisites. Verify your tenant actually carries the entitlements before you promise a regulator a specific residency outcome.
- Data residency commitments cover data at rest. Service operations, telemetry and certain processing may involve other regions; distinguish “where my documents are stored” from “where every byte of metadata is processed”.
- Cross-geo behaviour for search, eDiscovery and compliance policies has nuances in Multi-Geo deployments — test that your controls reach content in every geography you use.
Do not assume residency; obtain it as a configured, documented fact and pair it with the licensing evidence that backs it.
Encryption and Customer-Managed Keys
SharePoint Embedded content is encrypted in transit and at rest by default, using Microsoft-managed keys as part of the SharePoint Online service — TLS for data in motion and service-side encryption for data at rest, including the per-file encryption Microsoft applies across SharePoint and OneDrive.
For organisations that require control over the encryption key hierarchy, Customer Key allows you to supply and manage the root keys used to encrypt your tenant’s data at rest, backed by keys you hold in Azure Key Vault. This addresses two distinct compliance demands: the ability to assert that you, not solely the provider, control the encryption root; and the ability to revoke access to your data by destroying or withholding keys. Customer Key operates at the tenant/workload level rather than per container, so it should be assessed as part of your overall Microsoft 365 encryption posture.
Distinguish this clearly from the label-based encryption discussed earlier. Customer Key protects data at rest within the service; sensitivity-label encryption (MIP) protects individual files persistently wherever they travel, using its own key management through the protection service. A thorough review documents both layers and the keys behind each. Where your regulator expects customer-managed keys, confirm Customer Key eligibility for your workloads and that your Key Vault, key rotation and recovery procedures meet your operational-resilience standards — losing control of those keys means losing access to your data.
Identity, Conditional Access and Least Privilege for Container Access
Encryption and data residency protect content at rest; identity controls govern who reaches it in the first place. SharePoint Embedded access is brokered through Microsoft Entra ID, and your application authenticates and is authorised against container types and containers using Microsoft Graph and the SharePoint Embedded permission model.
Three identity controls belong in every review.
Conditional Access. Because access flows through Entra ID, Conditional Access policies — requiring multi-factor authentication, compliant or hybrid-joined devices, trusted network locations, or sign-in risk thresholds — apply to the identities accessing the platform. Confirm which policies govern both interactive users and the application’s service identity, and that high-risk sign-ins are challenged or blocked.
Application permissions and least privilege. Your application is registered in Entra ID and granted Graph and SharePoint Embedded permissions. The review must verify that these are scoped to the minimum required: the application should only be able to act on the container types it owns, and broad, tenant-wide permissions should be challenged. Container type registration ties the application’s identity to the containers it is permitted to operate on — this owning-application model is a core least-privilege control and should be documented explicitly.
Credential hygiene. Application credentials (certificates or secrets) must be stored securely, rotated, and monitored. Prefer certificate-based credentials and managed identities where the architecture allows, and ensure secrets never live in source control or configuration files.
The reviewer’s mental model should be simple: a user’s access is gated by Conditional Access; the application’s access is gated by its registered, least-privilege permissions and its container-type ownership; and both are auditable in Entra ID logs.
The Audit Log Surface: What Is Captured, and What Is Not
Auditability is a recurring sign-off requirement, and it is an area where expectations must be set carefully. Activity against SharePoint Embedded content is recorded in the Microsoft Purview unified audit log alongside other SharePoint and OneDrive activity — file access, modification, deletion, sharing and administrative operations on containers can generate audit events that are searchable and exportable for investigation.
The honest position for a security review is that audit coverage is strong but not infinite, and you should validate rather than assume:
- What you can generally rely on: file-level activities (view, edit, download, delete), container administrative operations, and identity events (sign-ins, consent, permission grants) surfaced through the unified audit log and Entra ID logs.
- What to verify: the exact event types emitted for your container operations, the latency before an action appears in the log, and the retention period for audit records — which depends on your licensing tier.
- Known gaps to design around: audit logging captures actions through the platform’s own access paths; it cannot record what a user does with a file after they have legitimately exported it (which is precisely why label-based encryption matters), and it is not a substitute for application-level logging of business events.
Treat audit as a layered control: Microsoft’s logs for platform activity, Entra ID logs for identity, and your application’s logs for business context. Where your regulator expects a complete chain of custody, supplement the unified audit log with your own trail and reconcile the two — and document the retention period for each, because “can we investigate an incident from 18 months ago?” is a question that will be asked.
The Microsoft–ISV Shared-Responsibility Model
Cloud compliance is always shared, and SharePoint Embedded is no exception. The mistake to avoid is assuming that because the platform “inherits Microsoft 365 compliance”, Microsoft is accountable for your compliance outcome. It is not. Microsoft is responsible for the security of the platform; you, as the application owner or ISV, are responsible for security and compliance in your use of it. A workable split for your review documentation looks like this.
Microsoft’s responsibility: the physical and infrastructure security of the datacentres; the availability and integrity of the storage substrate; default encryption in transit and at rest; the operation of the Purview, Entra ID and audit services; and meeting the data-residency commitments for the regions and licences you hold.
Your responsibility (as the application owner / ISV): the design of container types and the least-privilege permissions your application requests; configuring and enabling the Purview controls (DLP, labels, retention, eDiscovery) so they actually cover your content; choosing and configuring data-residency options and holding the necessary licences; managing customer keys and label-based encryption if you adopt them; enforcing Conditional Access on the identities you onboard; protecting application credentials; classifying the content you ingest; honouring your own contractual and regulatory obligations to your end customers; and supplementing platform audit with application-level logging.
Shared / situational: end-user behaviour, third-party integrations, and any data you copy out of the platform into systems where Microsoft’s controls no longer apply.
If you are an ISV serving regulated customers, expect to articulate this split again downstream — your own customers will run their own security review against your application, and a clear, documented shared-responsibility position is one of the most reassuring artefacts you can present.
A Compliance Officer’s Checklist for SharePoint Embedded
Use the following as a pre-sign-off checklist. Each item should map to documented, demonstrable evidence rather than an assertion.
- Data residency: geography of container provisioning confirmed; Multi-Geo / Advanced Data Residency configured and licensed if cross-border or sovereignty requirements apply; at-rest commitments distinguished from processing locations.
- Encryption at rest and in transit: default service encryption confirmed; Customer Key adopted and Key Vault governance documented if customer-managed keys are required.
- Sensitivity labels: labelling model defined (who, how, default vs auto vs programmatic); label-based encryption tested; downgrade controls and auditing in place.
- DLP: policies scoped to container content; enforcement behaviour tested against representative sensitive data.
- Retention and records: retention labels/policies applied; disposition and preservation behaviour verified; deletion cannot destroy records prematurely.
- eDiscovery and legal hold: container content confirmed discoverable; a seeded search and hold tested end to end.
- Identity: Conditional Access policies applied to users and the application identity; MFA enforced; risky sign-ins challenged.
- Least privilege: application Entra ID permissions scoped to owned container types; broad permissions justified or removed; credentials rotated and securely stored.
- Audit: unified audit log coverage validated for your operations; retention period confirmed against licence; application-level audit trail in place to close gaps.
- Shared responsibility: Microsoft / ISV split documented and agreed; downstream customer obligations understood.
- Feature status: each relied-upon Purview capability re-checked against current Microsoft documentation at the point of sign-off.
The Questions Your Security Review Will Ask
If you want to anticipate the meeting rather than react to it, prepare evidence-backed answers to these:
- In which datacentre region does our container content physically reside, and what licence underpins that commitment?
- Who controls the encryption keys — Microsoft, or us — and what happens to access if we revoke them?
- If a file leaves the container, is it still protected?
- Can our existing DLP policies detect sensitive data in these containers, and have we proved it?
- If we receive a legal hold or a regulator’s request, can we find, preserve and export everything?
- What permissions does the application hold, and could it reach data it has no business reaching?
- What is logged, for how long, and where are the gaps?
- When something goes wrong, who is accountable for what?
An organisation that can answer these with documented evidence rarely fails a security review. An organisation that answers with “Microsoft handles that” usually does.
How McKenna Consultants Can Help
Signing off a SharePoint Embedded deployment in a regulated industry is as much a documentation and assurance exercise as an engineering one. As a Microsoft document integration consultancy with deep experience across SharePoint Embedded, WOPI and the wider Microsoft 365 compliance estate, we help organisations design container architectures that satisfy security architects, CISOs and compliance officers from the outset — least-privilege container types, Purview controls that genuinely cover your content, a defensible data-residency and encryption posture, and an audit and shared-responsibility story your reviewers can act on.
Whether you are an ISV preparing to face your customers’ security teams, or a regulated enterprise readying your own sign-off, we can run a SharePoint Embedded security and compliance review with you, map the evidence, and close the gaps before they become blockers. If a security review is standing between you and your deployment, get in touch for an initial conversation about your SharePoint Embedded data residency, Purview and audit requirements.
