01
Chapter one
The adjacency cost argument
Every document-management platform has a license fee you see and a set of adjacency costs you don't. The second category usually dwarfs the first. The compliance-platform decision is really about which set of adjacency costs you're willing to absorb.
Ask a mid-market CFO to approve a new software platform and they’ll look at the license cost. Ask a compliance officer what it actually costs to add that platform and they’ll mention a dozen things that aren’t in the vendor’s pricing sheet. The license is the smallest number in the picture.
Separate user lifecycle
A new platform = a new identity system to provision, deprovision, maintain MFA on, run conditional access against. IT overhead that recurs annually, not a one-time cost.
New vendor in every assessment
GDPR Article 28 sub-processor review. ISO 27001 internal audit. SOC-2 third-party scope. Each assessment now has another vendor to include. 1-3 days per year, per assessment type.
Data leaves your perimeter
Documents now live in a vendor's cloud. Different location, different legal jurisdiction, different set of sub-processors downstream of them. Compliance implications scale with data sensitivity.
Connectors to everything
HRIS, ERP, identity, ticketing, messaging. Each integration is built and maintained. Breakage over time is a recurring IT cost.
New UX to learn
Workforce members learn a new authoring interface. Compliance officers learn a new admin console. The learning curve has labor cost plus productivity cost during adaptation.
Lock-in through format
Proprietary metadata formats. Audit-log schemas that don't transfer. If you ever want to leave the platform, you pay to extract. Not in the license bill, but real.
The adjacency-cost math is why most "best-of-breed" platform strategies quietly fail in mid-market compliance programs. The platform itself is fine; the sum of adjacency costs isn't.
Running document management inside M365 eliminates these costs. Not because M365 is perfect, but because every adjacency is already resolved: the identity is there, the audit scope is already defined, the data already sits in the perimeter, the integration already exists, users already know the tools, the exit path is SharePoint itself.
02
Chapter two
Microsoft's compliance portfolio
M365 ships with more compliance attestations than any individual customer could reasonably require. The portfolio is public, audited, and renewed annually. Your compliance program inherits it.
Microsoft maintains one of the largest compliance-attestation portfolios in the enterprise software industry. The Microsoft Service Trust Portal lists current certifications, audit reports, and compliance documentation across every major framework. A sample of what M365 tenants inherit:
ISMS certification
Microsoft's information-security management system is ISO 27001 certified across M365 services. Your ISO 27001 audit scope can reference Microsoft's certification rather than auditing the provider directly.
Trust-services criteria
SOC 2 Type II report covers M365's security, availability, processing integrity, confidentiality, and privacy. Provides evidence for enterprise customers' own SOC-2 programs.
Business Associate Agreement
Microsoft signs BAAs with HIPAA-covered entities for M365 tenants. Provides the contractual basis healthcare customers need to store PHI in SharePoint.
Article 28 DPA
Microsoft's Online Services Data Protection Addendum provides the controller-processor agreement GDPR Article 28 requires. Covers SCCs and data-transfer scenarios.
US Federal authorization
FedRAMP High authorization for M365 Government clouds. Relevant for US federal customers and contractors handling federal data.
Sector and regional
PCI DSS, FFIEC, sector-specific (medical devices, financial services), regional (EU Cloud Code of Conduct, C5 Germany, ENS Spain, IRAP Australia). Full list maintained at the Trust Portal.
What this means operationally. When a customer’s own audit asks about the document-management platform’s compliance posture, the answer is Microsoft’s current attestation plus our layer’s specific behaviors (audit log, sequential approval, etc.). Two layers of evidence; the underlying one is provided by Microsoft.
What this doesn’t mean. Microsoft’s attestations don’t make your compliance program automatic. They provide the substrate; your program must still use it correctly. Customers sometimes misread this — they assume M365’s SOC 2 means their own program is SOC 2 compliant. It doesn’t. The attestations are the platform’s, not yours.
03
Chapter three
Your tenant as your perimeter
The M365 tenant is a compliance and security perimeter you've already invested in. Adding another platform doesn't extend it — it creates a second perimeter to maintain.
Enterprises spend significant resources defining their security perimeter: what data is allowed where, who can access what, how access is monitored, how incidents are responded to. For most mid-to-large organizations, the M365 tenant is the primary perimeter for workforce-accessible data. Email, documents, chat, meetings, SharePoint collaboration — all inside the tenant, all under one set of controls.
Adding a second platform fragments that perimeter. Now there are two places documents live, two identity systems to synchronize, two audit-scope boundaries to monitor, two incident-response playbooks. The cost isn’t technical — it’s operational and cognitive. Security teams can maintain one perimeter well; two perimeters is markedly worse.
One perimeter
Document management inside M365
The tenant boundary already defined. Documents live inside. Identity, DLP, conditional access, eDiscovery, retention — one coherent system of controls. When an incident happens, one response playbook covers the relevant data.
Two perimeters
Separate DMS platform
Tenant for most data + DMS vendor cloud for governed documents. Two identity systems (federated but separate). Two DLP configurations. Two audit scopes. Incident response needs to coordinate across vendors. Reconciliation work is continuous.
04
Chapter four
Data residency as structural
For GDPR, for certain healthcare rules, for national-security-adjacent regulations, data residency is a real constraint. Running inside M365 makes it structural rather than a configurable option that can fail.
Data residency — where exactly your data is stored geographically — is a compliance constraint in several regulatory contexts. GDPR expects EU data to stay in the EU (or to have SCCs plus supplementary measures). HIPAA doesn’t prescribe residency but healthcare customers often have state-level or payer-contract requirements. French, German, and Italian public-sector rules have specific residency expectations.
M365 has regional data residency for its core services — tenants can be deployed in specific geographic boundaries, and the data stays there. When document management runs inside the tenant, it inherits the residency policy. There’s no separate question of “where does the DMS store data?” because the answer is “wherever your M365 tenant stores SharePoint data.”
EU Data Boundary
EU-based tenants store SharePoint content in EU data centers. Documents governed by our active-lifecycle product inherit this. GDPR data-residency obligations are satisfied structurally.
No "also stored in the vendor's cloud"
Our product doesn't ingest documents into a separate SaaS storage. Everything stays in your SharePoint. No shadow copies, no "we temporarily cache it" caveat.
Signing ceremony only
When DocuSign is used for PAdES signatures, the document transits DocuSign briefly for the signing ceremony, then returns. DocuSign has its own data-residency options; customers with strict residency can choose DocuSign EU region or decline DocuSign entirely.
Residency as evidence
Microsoft publishes data-center locations per service. Auditors can verify the residency claim by checking the tenant's configured region. Not a promise — a verifiable fact.
05
Chapter five
Identity, MFA, conditional access
Every audit-log event in the active-lifecycle product traces back to a Microsoft Entra identity. That identity is already covered by your tenant's MFA, conditional access, and offboarding policies. You don't configure any of that for the DMS — it's inherited.
The identity model is the single largest adjacency-cost driver that M365-native document management eliminates. Every user who signs a document, approves a flow, or accesses the library authenticates through Entra. Entra is where your tenant-level security policies live. A few consequences:
Already enforced
If your tenant requires MFA for SharePoint access, every approval event in the audit log comes from an MFA-authenticated session. FDA Part 11 §11.200(a) two-factor authentication is satisfied at the tenant level, not at the DMS level.
Policy-based access control
Location-based access, device-trust requirements, risk-based sign-in — all of your Entra Conditional Access policies apply automatically to DMS access. No separate configuration.
Deprovisioning is one action
When an employee leaves, deprovisioning them in Entra deprovisions them everywhere — email, Teams, SharePoint, and every DMS action that depends on their identity. No separate "remove from DMS" step.
Entra audit + our audit = full trail
Entra logs authentication events; we log document events. Together they reconstruct the full path from login to approval. Useful during investigations where the question is "who was logged in when this approval happened?"
06
Chapter six
What Microsoft governs, what we add
The separation of responsibility between the M365 substrate and our active-lifecycle layer is specific. Understanding it is what lets your compliance team own the right questions.
| Concern |
M365 substrate |
Active-lifecycle layer |
| Storage |
SharePoint document libraries, redundancy, backup |
Organization (folders, metadata, archive) on top |
| Identity |
Entra, MFA, Conditional Access, provisioning |
Role-mapping for approval flows |
| Versioning |
Native version engine (minor + major) |
Approval-flow integration for major versions |
| Authoring |
Word Online, co-authoring, sync |
Template enforcement and metadata binding |
| Search |
SharePoint full-text + metadata search |
Protocol-code and document-type indexing |
| Retention |
Purview retention policies |
Active review cadence (orthogonal to retention) |
| Audit log |
Platform-level audit (Microsoft 365 Audit Log) |
Document-lifecycle events attached to each document |
| DLP |
Content-inspection policies, exfiltration prevention |
N/A — inherited from tenant policies |
| Workflow |
Power Automate, if configured |
Sequential approval engine with audit-grade output |
The substrate/layer separation is what keeps our product focused and what keeps Microsoft doing the heavy lifting they're best at. We don't reimplement what Microsoft already does; we add what Microsoft doesn't.
07
Chapter seven
Purview, eDiscovery, DLP
The three Microsoft capabilities most customers ask about when evaluating the M365-native model. Each operates at the tenant level; active-lifecycle document management runs underneath them without conflict.
Records retention
Purview retention policies apply at the SharePoint library level. They govern how long versions and archived documents are preserved. Our expiration reminders are orthogonal — they drive review cadence; Purview governs eventual deletion.
Legal hold and discovery
Microsoft Purview eDiscovery applies legal hold across the tenant. Our active-lifecycle documents, being SharePoint documents, are included natively. A hold preserves all minor and major versions; discovery queries return full document history.
Content-inspection policies
Microsoft Purview DLP policies prevent exfiltration of sensitive content from SharePoint. Governed documents inherit these policies automatically. No separate DLP configuration for our layer.
The “no conflict” property. In customer conversations, a common question is whether the active-lifecycle product interferes with Purview, eDiscovery, or DLP. It doesn’t. We operate at the document-governance layer; Microsoft’s capabilities operate at the tenant records-management layer. They see the same documents but focus on different properties.
08
Chapter eight
Compliance regimes where this model wins
Not every regime maps equally well to M365-native. Here's where the model genuinely shines and where it requires specific considerations.
| Regime |
M365 fit |
Notes |
| ISO 9001 |
Strong fit |
Substrate + layer produce the clause 8.5 evidence. Customers use the active-lifecycle as the document-control spine of certified QMS programs. |
| ISO 27001 |
Strong fit |
M365's own ISO 27001 certification covers the substrate. Our layer adds the documented-information control for the ISMS itself. |
| GDPR |
Strong fit |
EU Data Boundary, Microsoft's DPA, and no additional sub-processor in our layer. Adjacency cost for GDPR compliance is meaningfully lower. |
| HIPAA |
Strong fit |
Microsoft's BAA covers M365. Our layer provides audit controls §164.312(b) requires. Customer's HIPAA program certifies the whole. |
| FDA Part 11 |
Good fit, validation scope |
Customers use the layer's capabilities in their Part 11 compliance program. Validation posture (IQ/OQ/PQ) remains with QA team. Not a "Part 11 validated" product. |
| SOX |
Good fit |
Audit log + versioning produce the §404 evidence external auditors need for internal-controls testing on documented processes. |
| Validated pharma (GxP) |
Not a fit |
Where the DMS itself must be a Part 11 qualified system with vendor-provided validation docs, MasterControl (or equivalent) is the right answer. |
09
Chapter nine
When to consider leaving M365
The honest cases where the M365-native model doesn't fit. Small in number, but real.
You're not on M365
Obvious but worth saying: the M365-native model only makes sense if your organization runs M365 as its primary collaboration platform. Orgs on Google Workspace, Lotus Notes, or custom stacks need different architectures.
Validated pharma / medical devices
Where the DMS platform itself must be a validated Part 11 qualified system, MasterControl or equivalent is the right choice. M365 + our layer don't compete for this scope.
Qualified e-signatures
eIDAS qualified electronic signatures, Italian AGID signing — our DocuSign integration doesn't cover these. Customers with those obligations run specialized tools alongside.
Data sovereignty beyond M365 regions
Specific national-security-adjacent regulations require data residency in jurisdictions M365 doesn't host locally. Sovereign cloud instances may be required instead.
10
Chapter ten
The honest posture summary
The claim isn't "M365 is perfect." It's that for most mid-to-large enterprises, running document management inside the tenant produces the strongest compliance posture they can realistically achieve.
1 perimeter
Instead of two. The tenant you've already defined is the tenant governed documents live in.
50+
Microsoft compliance attestations your tenant inherits. Your program references; Microsoft renews annually.
0 new
Sub-processors in your DPA. Our layer doesn't add new data processors beyond Microsoft.
The best compliance platform is the one you already have defenses for. For most mid-to-large enterprises that runs on Microsoft 365, and extending governance inward is a faster, cheaper, and safer path than adding a parallel platform outward.
If your organization runs Microsoft 365 and is weighing document-management options, the adjacency-cost math almost always favors staying inside the tenant. A 30-minute conversation with our team maps your specific profile against the trade-offs, and points you to the right answer — which will sometimes be us, sometimes MasterControl, sometimes something else — based on facts rather than vendor framing.
