Shared Services and Conglomerate Tenants

A parent company may want to operate one GCC High tenant as a shared compliance platform for multiple operating subsidiaries, each of which may undergo its own CMMC Level 2 assessment at different times. This chapter assesses whether that architecture is technically and contractually defensible, and where it breaks down under C3PAO scrutiny.

Throughout, ParentCo refers to the corporate parent that owns the shared-services tenant and IT organization, and OpCo refers to an operating subsidiary that consumes ParentCo's tenant as a service. Multiple OpCos (OpCo A, OpCo B, …) coexist in the same shared-services tenant.

The central question. Can one tenant hold multiple OpCos such that (1) ParentCo IT carries logging and compliance responsibility, (2) OpCos cannot see each other's users or content, and (3) a C3PAO will assess one OpCo without pulling siblings into scope?

Short answer. There are three defensible architectures — presented in the Decision framework below as Option A (Unified Tenant), Option B (Individual Tenants, Shared AVD Infrastructure), and Option C (Individual Tenants, Individual AVD Infrastructure). Option A matches ParentCo's stated preference and can be made defensible, but it is a scope-sharing outcome, not a scope-reduction outcome — ParentCo's shared services land inside every OpCo assessment as Security Protection Assets. Options B and C are prepared fallbacks for different degrees of C3PAO pushback on sharing.

Glossary

• AU — Administrative Unit. An Entra ID container that scopes administrative permissions (e.g., password reset) to a subset of users, groups, or devices. A Restricted Management AU additionally prevents tenant-level admins from modifying in-scope objects. AUs do not prevent standard users from reading directory data outside the AU.
• IB — Information Barriers. A Microsoft Purview feature that blocks discovery and collaboration between defined segments of users across Teams, SharePoint, and OneDrive. Multi-segment mode allows designated users (e.g., ParentCo oversight) to be compatible with multiple segments simultaneously.
• ABP — Address Book Policy. An Exchange Online policy that presents each user with a filtered view of the Global Address List. A virtual separation of directory visibility only; does not block mail delivery or prevent Graph-level enumeration.
• PIM — Privileged Identity Management. The Entra feature that makes privileged roles eligible rather than permanently assigned, requiring just-in-time activation with approval, MFA, and time limits.
• DLP — Data Loss Prevention. Microsoft Purview policies that inspect content for sensitive data and enforce actions (block, warn, encrypt, audit) across Exchange, SharePoint, OneDrive, Teams, and endpoints.
• EEEU and Everyone — "Everyone Except External Users" is a built-in SharePoint claim that includes every internal user in the tenant; "Everyone" additionally includes authenticated guests. Using either claim for sharing inside a shared-services tenant flattens OpCo boundaries and must be prohibited and monitored. Data Access Governance reports surface both.
• RAC — Restricted Access Control (SharePoint). A per-site setting that requires a user to be in a designated Entra security group in addition to holding normal site permissions. Acts as a second gate that overrides inherited or inherited-link access.
• SPA — Security Protection Asset. A CMMC scoping category for assets that provide security functions to the assessed environment, whether or not they process CUI. Under CMMC, SPAs are in assessment scope alongside CUI Assets.
• SPD — Sensitive Program Data. The program-identifying context (codenames, platform designators, customer names, contract numbers) whose presence in metadata like group names, site URLs, or channel titles reveals CUI-related program information even when the underlying content is protected. Req-9 addresses SPD leakage in metadata.

Decision framework

Three architectures meet the business requirement with different degrees of sharing between ParentCo and the OpCos. They are listed in order of how much is shared — from most unified (Option A) to most separated (Option C). The right answer depends on what the C3PAO will accept for any given OpCo's assessment.

Option	Architecture	OpCo isolation	Independent assessment	Assessor acceptance
Option A	Unified Tenant — multiple M365 assets, ParentCo-only control plane, per-OpCo segmentation via IB V2, RAC, ABPs, dynamic groups, and label encryption	Strong segmentation, policy-enforced only — platform boundary is the tenant, not the OpCo	No — ParentCo services are SPAs in every OpCo assessment	Moderate; depends on C3PAO experience with shared-services tenants and on the rigor of the Shared Responsibility Matrix and evidence pipeline
Option B	Individual Tenants per OpCo, shared AVD infrastructure hosted by ParentCo (per-OpCo host pools in a ParentCo subscription, accessed from each OpCo tenant)	Platform boundary for identity, mail, and content — OpCos cannot see each other's users or data. AVD session hosts are ParentCo-operated but scoped per OpCo via host-pool entitlement	Each OpCo assesses its own tenant independently. ParentCo's shared AVD is narrated as an External Service Provider-style shared service; each OpCo inherits controls from a shared FedRAMP-aligned AVD package	High for the tenant boundary; Moderate-to-High for the shared AVD layer depending on how ParentCo documents the ESP relationship and the host-pool isolation
Option C	Individual Tenants per OpCo, individual AVD infrastructure per OpCo, no sharing	Complete — every layer is per-OpCo	Yes — each OpCo's assessment is fully independent of siblings	High; cleanest story for the C3PAO. Highest cost, slowest to deploy, and loses every shared-services efficiency

How to use this framework. ParentCo's stated preference is Option A (one tenant, shared security platform, OpCos as tenants of the tenant). Options B and C are prepared fallbacks in case a C3PAO balks:

• If the C3PAO accepts a shared-services tenant with a signed Shared Responsibility Matrix (Req-10) and evidence that the Req-1 through Req-9 controls are continuously enforced, Option A holds.
• If the C3PAO rejects sharing the M365 identity/content control plane across OpCos (insisting on tenant-level platform boundaries), fall back to Option B. Each OpCo gets its own Entra tenant; ParentCo retains shared-services value through a single AVD fleet serving all OpCos via per-OpCo host pools. The shared AVD is then the SPA narrative, and its scope is narrower and more defensible than a shared M365 tenant.
• If the C3PAO further rejects sharing anything — treating even the AVD layer as unacceptable cross-OpCo risk — fall back to Option C. Each OpCo operates a fully sovereign environment; ParentCo's shared-services value is limited to governance, policy templates, and playbooks rather than operational infrastructure.

The chapter body that follows details Option A because that is ParentCo's preferred starting point. The mapping table, three-layer model, requirement sections, and Shared Responsibility Matrix are the minimum engineering content required to defend Option A at assessment. Options B and C inherit most of the same requirements but apply them within each OpCo's tenant instead of across the shared tenant.

Three-layer model

A defensible single-tenant design must implement all three layers. No single layer is sufficient alone.

Layer	Question it answers	Primary controls
Identity	Who exists, who can sign in, what admin scope applies per OpCo	AD → Entra sync, CompanyCode attribute, dynamic groups, AUs for delegated helpdesk, PIM, restricted portal/Graph access
Data	What each OpCo can see, send, store, and label	Information Barriers (multi-segment), SharePoint Restricted Access Control, Exchange mail flow rules, ABPs, sensitivity labels, DLP
Resource	Which resources and sessions each OpCo user can reach	Conditional Access (per-OpCo dynamic groups), AVD host pools per OpCo, Intune scope tags and device filters, SPO/Teams permissions

Requirement to platform mapping

Requirement	Layer	Primary controls	800-171	See
OpCo users cannot enumerate sibling OpCo users	Identity	IB V2 (Teams + SPO/ODB people picker), AllowedToReadOtherUsers=false, per-OpCo ABPs covering all Exchange address-list types, SPO people-picker hardening (SearchResolveExactEmailOrUPN, claim removal), CA block of Graph/Azure Mgmt for non-admins, Delve/Viva people-graph disabled	3.1.1, 3.1.2	Req-1
OpCo users cannot access sibling SPO/ODB/Teams content	Data	IB, SPO Restricted Access Control, ban EEEU, private Groups, disallow sharing outside RAC	3.1.3, 3.1.22	Req-2
OpCos cannot email each other except via sanctioned bridge	Data	Exchange transport rules, ABPs per OpCo	3.1.3, 3.13.1	Req-3
OpCo sessions reach only OpCo-approved resources	Resource	CA per OpCo, AVD host pools per OpCo, Intune scope tags	3.1.1, 3.1.12, 3.1.16	Req-4
ParentCo IT delivers logging and audit evidence	Identity+Data	Sentinel workspace (ParentCo-owned), Purview Audit, per-OpCo workbooks, scoped RBAC	3.3.1–3.3.9	Req-5
OpCo delegated admin without tenant-wide authority	Identity	Restricted Management AUs, PIM, ParentCo retains all service admin roles	3.1.5, 3.1.6, 3.1.7	Req-6
C3PAO accepts OpCo-only assessment scope	Scoping	SPA inventory, control inheritance matrix, boundary diagram, evidence schedule	Scoping Guidance	Req-7
On-premises AD remains identity source of truth	Identity	CompanyCode stamped at OU level, cloud-only break-glass outside AD	3.1.1, 3.5.1	Req-8
OpCo metadata does not leak SPD context via group, site, or channel names	Identity+Data	Entra group naming policy with mandatory OpCo prefix and opaque suffix, restricted group creation, opaque SPO site URLs at provisioning, no program codenames in display names	3.1.3, 3.1.22, 3.8.2	Req-9
Shared Responsibility Matrix published and maintained	Scoping	Signed SRM defining every control by owner (ParentCo shared service, OpCo local, joint), with RACI, change-control path, and review cadence	3.12.4, 3.14.1	Req-10

Where shared services reduce OpCo scope

The ParentCo platform is not only a source of SPA entanglement — it is also a source of scope reduction when used deliberately:

• AVD enclave per OpCo. If OpCo CUI work happens inside ParentCo-managed AVD session hosts (one host pool per OpCo, scoped by Entra security group), then OpCo physical workstations never process CUI. Those endpoints become CRMAs at most, not CUI Assets, and fall out of OpCo's CMMC scope. ParentCo runs one Intune baseline, one MDE deployment, one set of session host hardening, and inherits that posture into every OpCo assessment. Pattern detail in Chapter 21 (AVD — Enclave in Existing Tenant).
• Sensitivity labels with encryption as a content-layer gate. Per-OpCo labels that encrypt to the OpCo's rights group mean a leaked file remains unreadable to sibling OpCos even if RAC, IB, or sharing controls misconfigure. Encryption travels with the content; it does not depend on the file's location. This converts a single-layer location-control failure into a contained event rather than a breach.
• Centralized DLP, Sentinel, MDE, and Purview Audit. ParentCo operates these once; every OpCo inherits the same monitoring and response posture rather than each OpCo standing up and proving its own SOC. The SPA narrative is real, but so is the operational and evidentiary leverage.

Net scope often comes out smaller, not larger, when AVD and label encryption are part of the design, even after accounting for the SPA expansion.

Operational concerns

What OpCos give up by sharing a tenant instead of owning their own:

• No independent IT autonomy — CA, Intune, DLP, retention, branding are all ParentCo-controlled.
• No raw log access — OpCo IR reviewers get sanitized workbooks or scoped Sentinel RBAC, not direct audit-log queries.
• Tenant-wide settings are one-size-fits-all — strictest OpCo requirement wins for external sharing, guest access, consent, enrollment restrictions.
• GCC High feature gaps apply to all OpCos equally — notably, "restricted site creation by users" is unavailable, so provisioning discipline replaces self-service.
• Change velocity is ParentCo-paced — OpCo urgency does not override ParentCo change windows.
• Divestiture is a migration, not a split — separating an OpCo later requires full tenant-to-tenant migration.
• Licensing and costs bill to ParentCo; chargeback to OpCos is manual via CompanyCode attribution.

Auditor concerns

warning

Security and trust boundaries between OpCos rely on critical controls in the ParentCo tenant. Inadvertent misconfiguration may break these boundaries. A Shared Responsibility Matrix is mandatory.

Where a C3PAO will push hardest on a single-tenant design:

• SPA entanglement is permanent. ParentCo identity, CA, Intune, Purview, DLP, Sentinel, and mail-flow rules protect every OpCo's CUI environment and therefore enter every OpCo assessment as Security Protection Assets. Single tenant does not reduce scope; it shares scope.
• Policy-enforced boundary, not platform boundary. Assessor will test each layer: IB segments and compatibility policy, ABPs, transport rules, RAC, sharing-outside-RAC setting, EEEU usage, group creation control, user consent, AllowedToReadOtherUsers, Graph/Azure Mgmt CA blocks. One missing layer is one finding.
• Continuous enforcement, not point-in-time config. Monthly evidence: DAG EEEU reports, IB audit events, group creation log, SPO external sharing report.
• Admin blast radius. A compromised ParentCo admin reaches all OpCo CUI by design. Mitigate with phishing-resistant MFA, PIM with approval, break-glass in RMAU, admin-workstation CA filtering, JIT activation, admin activity monitoring.
• Email boundary fragility. IB does not cover mail. Transport-rule change control is a first-class compliance artifact.
• AUs are not an isolation control. Present AUs only as delegated-admin scoping; do not claim them as the boundary.
• Group and site names are metadata, not content, and leak independently. A C3PAO will ask whether a group called "F-35 ECM Team" can be observed by sibling OpCos or ParentCo operators even without access to its content. The answer must be "the name itself reveals nothing" — enforced by a naming policy that strips program context, not by hoping no one reads the logs. See Req-9.
• Assessor variance. Select a C3PAO with GCC High multi-tenant experience before committing to single-tenant architecture.

Requirement sections

Each section follows the same shape: Requirement · Controls · Configuration · Evidence · Residual risk · 800-171 mapping. Sections forward-reference the Identity, Data, Device, and Monitoring phases where the pillar implementation already lives.

Req-1

Identity enumeration containment. Enumeration happens through multiple independent surfaces — Graph, Exchange address lists, the SharePoint/OneDrive people picker, Teams search, and the people-graph surfaces (Delve, Viva, Org Explorer). Each surface has its own control plane. The Req-1 stack must cover all of them.

Graph layer. Disable default user directory read (AllowedToReadOtherUsers=false) as the primary gate: Microsoft documents that with this setting a non-admin delegated caller receives a 401 from the /users endpoint regardless of which client or which granted scope is used.¹ Layer on: disable user app registration (AllowUsersToCreateApps=false), disable user consent, restricted Entra portal access, and CA block of Microsoft Graph Command Line Tools, Graph Explorer, Azure CLI, Azure Management, and WAAD for non-admins.

Teams layer. IB V2 (not V1) segments with allow-list compatibility. ParentCo oversight users in all segments.

Exchange layer. Per-OpCo ABP that explicitly assigns per-OpCo versions of every address list type — GAL, All Rooms, All Distribution Lists, All Public Folders, All Contacts. Tenant-wide default lists must not be inherited by OpCo mailboxes.

SharePoint / OneDrive people picker. The picker is a separate code path from Graph and Exchange; AllowedToReadOtherUsers=false and IB V1 do not cover it. Required controls:

• Enable Information Barriers V2 at the tenant and associate each OpCo site with its segment (Set-SPOSite -InformationBarriersMode). IB V1 leaves the picker open.
• Set-SPOTenant -SearchResolveExactEmailOrUPN $true — picker requires an exact UPN rather than fuzzy-searching the directory. Single most effective control against casual sibling browsing.
• Set-SPOTenant -ShowEveryoneClaim $false
• Set-SPOTenant -ShowEveryoneExceptExternalUsersClaim $false
• Set-SPOTenant -ShowAllUsersClaim $false
• Set-SPOTenant -ShowPeoplePickerSuggestionsForGuestUsers $false

People-graph surfaces. Disable Delve analytics (Set-SPOTenant -DelveAnalyticsEnabled $false), restrict Viva Insights people-graph features, and verify the Outlook "Organization Explorer" surface respects ABP.

Residual for standard users. Contact-graph surfaces (/me/people, recipient suggestions from prior interactions) remain scoped to people the user has already interacted with, which is exactly what IB V2 and ABP are there to constrain. Platform drift — new first-party apps, new Graph routes, new pickers — requires quarterly re-validation of this control set.

Req-2

Content isolation (SPO/OneDrive/Teams). IB policies, SPO Restricted Access Control driven by CompanyCode dynamic groups, disallow sharing outside RAC, EEEU ban with DAG monitoring, public Teams blocked, sensitivity labels enforcing private Groups. Add per-OpCo sensitivity labels with encryption keyed to the OpCo's rights group as a content-layer complement to the location-layer controls — RAC and IB are gates on where the file lives; encryption is a gate on what the file is. A sibling OpCo user who obtains the file through a misconfigured RAC, an exception, or a forwarded link still cannot decrypt it. This is the single most important defense-in-depth against location-control drift.

Req-3

Email isolation. Exchange transport rules blocking inter-OpCo SMTP with named ParentCo exception groups, ABP per OpCo, DLP for CUI mail, CAB-gated rule changes.

Req-4

Session and resource reach. CA per OpCo with CompanyCode dynamic groups, AVD host pools and application groups per OpCo, Intune scope tags and device filters. Use the AVD enclave pattern (Chapter 21) per OpCo as the default workplace for CUI work — it keeps OpCo physical workstations out of CUI Asset scope, lets ParentCo inherit a single hardened baseline into every OpCo assessment, and pairs with Req-2 label encryption so that data and session both remain inside the OpCo's enclave.

Req-5

Logging as a service. How Sentinel serves multiple OpCos depends on which architecture option is in play:

Option A (unified tenant). Single Sentinel workspace owned by ParentCo. Native connectors (XDR, Entra ID, M365, Defender for Cloud) all connect locally — no custom plumbing. Per-OpCo custom tables or workbooks segment the data for scoped access. OpCo RBAC scoped to own-OpCo data via Sentinel workspace-level RBAC or resource-context RBAC. Purview Audit retention per OpCo legal requirement. Evidence binder template reused per assessment.

Option B / C (separate tenants). Each OpCo tenant runs its own Sentinel workspace with native connectors (XDR, Entra, M365 all connect locally within the OpCo tenant — no cross-tenant plumbing needed). ParentCo uses Azure Lighthouse to delegate management access across all OpCo workspaces and cross-workspace queries for centralized hunting and incident correlation. This is Microsoft's recommended multi-tenant Sentinel pattern: each workspace ingests natively, ParentCo manages across workspaces from a single pane of glass. Cross-workspace queries (workspace('law-opco-a').SecurityEvent | union workspace('law-opco-b').SecurityEvent) are slower than local queries at high volume but avoid the engineering and maintenance cost of custom log-ingestion pipelines.

Why not ship all OpCo logs to one central workspace? The native M365 data connectors (XDR, Entra ID sign-in/audit, Office 365 audit) are tenant-scoped — they only ingest from their home tenant. Centralizing M365 logs from Tenant B into Tenant A's workspace requires custom pipelines (Logic Apps, Function Apps, or the Log Ingestion API calling the Management Activity API and Security Graph API). These pipelines work but add engineering cost, maintenance burden, and a failure mode that creates blind spots. Each pipeline also becomes an SPA in every OpCo's CMMC scope. The federated model (per-tenant workspace + Lighthouse) avoids all of this.

For workspace creation steps, naming conventions, and data-connector configuration, see SIEM Strategy.

Req-6

Delegated administration. Restricted Management AUs for OpCo helpdesk, PIM with approval for every eligible assignment, break-glass accounts in RMAU, phishing-resistant MFA on all admins. No OpCo user holds tenant-wide service admin roles.

Req-7

CMMC scoping narrative. SPA inventory (ParentCo shared services), OpCo asset inventory, control inheritance matrix, boundary diagram, evidence schedule. This is the document handed to the C3PAO on day one of an OpCo assessment.

Req-8

Identity source of truth. CompanyCode attribute provisioned at on-premises AD OU level, synced through Entra Connect, cloud-only break-glass accounts outside AD, group writeback posture decided and documented.

Req-9

Metadata hygiene — group, site, and channel naming. Group display names, SharePoint site URLs, and Teams channel names are queryable metadata that persists across audit logs, incident reports, NDRs, calendar invites, and every ParentCo shared-services operator's workspace. Even with IB V2 and label encryption blocking access to the underlying content, a name like "F-35 ECM Team" leaks the program's existence and scope to any observer of the log stream. Req-9 closes this by ensuring the name itself carries no SPD context:

• Enforced naming policy via Entra. Configure the unified group naming policy (Set-MgDirectorySetting against the Group.Unified template) to require an OpCo<X>- prefix followed by an opaque identifier (program register ID, sequential code, or random token). Block reserved substrings: program codenames, platform designators (F-35, AH-64, aircraft and missile names), customer names, contract numbers, and classified monikers.
• Restricted group creation. EnableGroupCreation=$false tenant-wide with a single ParentCo provisioning group permitted. Pairs with AllowUsersToCreateApps=false from Req-1.
• Opaque SharePoint URLs at provisioning. Site URL is generated once from the display name and persists through later renames. Provision with the opaque code (/sites/opcoa-p00472), set the human-readable display name separately. Renaming after the fact does not rewrite the URL. Consider Set-SPOTenant -UseRandomizedSiteNames $true for any residual self-service path.
• Human-readable program context lives in descriptions, not names. Group and site descriptions are not surfaced in URLs, NDRs, or calendar invites. Use them for program context; keep display names opaque.
• Teams channel names follow the same rule. General, Design, Test, Manufacturing beats F-35-Stealth-Coating.
• Pre-rollout audit. Inventory every existing group, site, and Team whose display name or URL would leak SPD context. Plan renames and, where URLs carry context, plan site recreation with content migration.

Residual acknowledgement. ParentCo shared-services operators (Sentinel analysts, Purview admins, SPO admins, Exchange admins) will see group and site names in the ordinary course of their work because those names appear in every log and incident record. This is unavoidable in a shared-services tenant. The Req-9 defense is that the names themselves mean nothing to anyone who reads them — not that no one reads them.

Req-10

Shared Responsibility Matrix. A single-tenant shared-services design is held together by a large number of individually small controls spread across ParentCo, each OpCo, and a handful of joint processes. Without a published, signed Shared Responsibility Matrix (SRM), no one knows who is accountable for what, and a C3PAO has no way to evaluate whether the claimed boundaries are operationally real.

The SRM must:

• Enumerate every control that participates in the OpCo boundary — the IB V2 policy, ABPs, transport rules, RAC, group naming policy, SPO tenant settings, CA policies, AVD host pool configuration, Sentinel content, DLP rules, label taxonomy, and every item listed in Req-1 through Req-9.
• Assign a single accountable owner to each control, framed as ParentCo shared service, OpCo local, or joint. "Joint" requires a named ParentCo contact and a named OpCo contact.
• Use RACI where joint. For joint controls (e.g., a CA policy that excludes an OpCo-specific group), spell out Responsible, Accountable, Consulted, Informed — so the OpCo knows when it must be consulted before a change and when it is merely informed.
• Specify the change-control path. Who submits, who approves, what CAB processes apply, what notice OpCos receive for changes to shared controls, and what veto or escalation rights OpCos have for changes that affect their boundary.
• Define evidence ownership. For each control, which party produces evidence for a CMMC assessment — ParentCo once for all OpCos (inheritance) or per-OpCo.
• Set a review cadence. At minimum quarterly, with a mandatory re-sign whenever an OpCo enters or exits the tenant, a significant architectural change ships, or Microsoft introduces a platform change that affects a listed control.
• Be signed by ParentCo CIO and each OpCo IT leader. The SRM is a contract between the entities that share the tenant.

The SRM is the primary document a C3PAO will ask for before assessing the SPA-inheritance claims in Req-7. If it does not exist, or is not current, every claimed inheritance is open to challenge. Publish it alongside the boundary diagram, the SPA inventory, and the control inheritance matrix from Req-7.

Risk acceptance

ParentCo leadership must sign, verbatim, before a single-tenant design is approved:

We understand that this is a policy-enforced segmentation model inside a single Entra tenant, not a true subsidiary-isolated boundary. We accept that ParentCo is the privileged bridge, that ParentCo shared services fall into CMMC scope as Security Protection Assets where they protect OpCo CUI environments, and that the model requires continuous governance over Information Barriers, Exchange mail flow, SharePoint Restricted Access Control, group creation, public/EEEU exposure, third-party app exceptions, and quarterly evidence review. We accept that a C3PAO may require any or all ParentCo shared services to be assessed concurrently with any OpCo assessment.

Footnotes

1. Microsoft Learn, Cannot look up users using the Microsoft Graph /users endpoint. ↩