Appendix E: GCC High Tenant Buildout Timeline
This timeline covers a greenfield, cloud-only GCC High tenant CMMC Level 2 baseline for Windows workstations: 25 users, 25 Entra-joined Windows 11 workstations, one engineer, ~80 hours budgeted (full parameters below). It stops at the tenant-wide baseline; the AVD secure enclave and its deployment timeline are a separate add-on engagement. Adjust phase durations proportionally if infrastructure is partially in place.
Every control configured here traces to the CMMC Control Matrix; use that matrix as the System Security Plan (SSP) backbone and this appendix as the build order.
Deployment Parameters
| Parameter | Value |
|---|---|
| Tenant state | Greenfield: no existing M365 GCC High or Azure Government configuration |
| Scope | Tenant-wide CMMC L2 baseline (identity, devices, data, SIEM); excludes AVD enclave |
| Identity topology | Cloud-only: no on-prem AD, no Entra Connect, no Password Hash Sync |
| Users | 25 |
| Workstations | 25 × Windows 11 Enterprise, Entra-joined, Intune-managed (Autopilot) |
| Licensing | Microsoft 365 G5 (see the Why G5 note below) |
| Team | One engineer |
| Total budget | ~80 hours |
| Azure region (Sentinel / Log Analytics) | US Gov Virginia (recommended) |
This baseline uses Entra ID P2 risk-based Conditional Access, Microsoft Sentinel, Insider Risk, and auto-labeling. On G3, those become optional upgrades rather than baseline steps; the rest of the build is unchanged. The per-feature split is in the Licensing & Compliance Matrix.
The following workstreams are out of scope for the 80 hours; each is separately scoped. If any apply, size and price them before committing to the budget.
| Excluded workstream | Note |
|---|---|
| Hybrid Entra join / Entra Connect / Password Hash Sync | On-premises AD integration; this build is cloud-only Entra join. |
| GPO-to-Intune migration | Translating an existing Group Policy estate into Intune policy (GPO-to-Intune Migration). |
| Data migration | Moving mailboxes, file shares, or SharePoint / OneDrive content into the tenant (from on-premises or another tenant). |
| Application migration & packaging | Repackaging and deploying line-of-business apps through Intune; only the OIB baseline and Defender are in scope here. |
| Mobile device management (iOS / Android) | MDM / MAM enrollment and app protection for phones and tablets; this build covers Windows workstations only. |
Required Access (Non-Negotiable)
Both grants must be in hand before Day 1.
| Access | Role Required | Why |
|---|---|---|
| GCC High Entra tenant | Global Administrator | Tenant-wide policy: Conditional Access, authentication methods, Intune enrollment, device compliance. Scoped roles are insufficient during initial build. |
| Azure Government subscription | Subscription Owner | Required for the Log Analytics workspace and Microsoft Sentinel (Phase 6), and to enable Microsoft Defender for Cloud. Contributor is insufficient for the RBAC assignments. |
Starting without Global Admin or Subscription Owner is the fastest path to a stalled engagement: you hit a permission wall in Phase 1 or Phase 6 and absorb the calendar slip while the client perceives a delivery failure. Make both a contract condition, not a courtesy request.
Provisioning Lead Times (Customer Responsibility)
Outside the engineer's control and the 80-hour clock. Surface them at the earliest opportunity, ideally before contract signing. These mirror the lead times in Appendix D.3.
| Item | Typical Lead Time | Notes |
|---|---|---|
| GCC High Entra tenant provisioning | 10–15 business days | Requires an AOS-G reseller and Microsoft vetting. Cannot be self-provisioned. |
| Azure Government subscription | 5–10 business days | Requires an existing EA or MCA-Gov agreement. New subscriptions occasionally need manual Microsoft approval. |
| M365 GCC High license procurement | 3–5 business days after EA is active | Must be in place before the identity and Intune phases begin. |
Prerequisites (Outside the 80-Hour Clock)
| Item | Owner | Blocks |
|---|---|---|
| Global Admin access to GCC High Entra tenant granted to engineer | Customer | All phases |
| Subscription Owner on Azure Government subscription granted to engineer | Customer | Phase 6 |
| M365 GCC High G5 licenses procured for all 25 users | Customer | Phases 1, 3 |
| List of 25 users with confirmed UPNs | Customer | Phase 1 |
| Custom domain(s) and DNS access (MX, SPF, DKIM, autodiscover) | Customer | Phase 1 |
| 25 workstation hardware hashes (or OEM/CSP Autopilot registration) | Customer | Phase 7 |
| "Users may join devices to Microsoft Entra ID" scope approved | Customer leadership | Phase 3 |
Phase Summary
| Phase | Focus | Hours | Cumulative |
|---|---|---|---|
| 1 | Tenant Foundation & Identity Settings | 8 | 8 |
| 2 | Conditional Access (Report-Only) | 6 | 14 |
| 3 | Intune Foundation & Layer 1 Baseline | 10 | 24 |
| 4 | Defender (MDE, MDO, MDCA) | 7 | 31 |
| 5 | Data Protection Baseline (Purview) | 9 | 40 |
| 6 | Microsoft Sentinel | 8 | 48 |
| 7 | Workstation Enrollment & Pilot | 6 | 54 |
| 8 | Conditional Access Enforcement | 3 | 57 |
| 9 | Validation & Audit Evidence | 9 | 66 |
| 10 | Documentation & SSP Handoff | 6 | 72 |
| Contingency | 8 | 80 |
Phase 1: Tenant Foundation & Identity Settings
Hours 1–8
| Activity | Hours |
|---|---|
| Custom domain verification; MX / SPF / DKIM / autodiscover; group-based licensing for 25 users | 1.5 |
| Tenant security settings (8-4): disable security defaults, lock down user/app consent (admin consent workflow), restrict the Entra admin portal, guest access, MFA registration policy | 2 |
Break-glass accounts (2): .onmicrosoft.com, FIDO2 key or long password in vault; Restricted Management AU | 1 |
| Authentication methods (8-2): passkey (FIDO2), TAP policy, phishing-resistant authentication-strength definition | 1.5 |
Entra security groups (EID_*) for CA scoping and licensing | 1 |
| PIM: onboard privileged directory roles to just-in-time (8-5) | 1 |
Break-glass first. Create and document the two emergency-access accounts before any Conditional Access exists, and confirm they are excluded from every policy in Phase 2. This is the single most common lockout cause in a greenfield build.
Phase 2: Conditional Access (Report-Only)
Hours 9–14
| Activity | Hours |
|---|---|
| Build the ~20 baseline policies (A/B/P series) from the CA catalog in Report-Only | 4 |
| Named locations, Terms of Use, sign-in/session controls | 1 |
| Verify break-glass excluded from all policies; confirm device-join scope | 1 |
Deploy the full A/B/P set (MFA, phishing-resistant auth, admin protection, legacy-auth and device-code blocks, risk-based controls, compliant-device gate, token protection). Exclude the Enclave set (B012–B015) — those belong to the AVD enclave, not the tenant baseline. Prefix every policy with EID per the chapter's naming convention.
Enabling Grant/Block controls — especially P006 Require Compliant Devices — before workstations are enrolled and compliant will lock users out of M365. Policies stay in Report-Only through Phase 7 and are enforced in Phase 8.
Phase 3: Intune Foundation & Layer 1 Baseline
Hours 15–24
| Activity | Hours |
|---|---|
| MDM user scope; enrollment restrictions (block personally-owned Windows); Autopilot profile + Enrollment Status Page | 2 |
| OIB import and assignment of the Layer 1 set (21 policies) | 2.5 |
| GCC High critical modifications: telemetry, cryptography, identity routing | 1 |
| Compliance policies (4) tuned to the matrix values | 1 |
| Manual creations: MDE onboarding, Device Control / removable media, Exploit Protection | 1.5 |
| Windows LAPS config; verify the retrieval and sign-in path | 1 |
| Windows Update rings | 1 |
Confirm the Entra Mobility MDM discovery/enrollment URLs resolve to *.microsoft.us, not the commercial .com defaults — the wrong URL fails Autopilot/Entra-join enrollment with 0x80192efd. Do not click "Restore default MDM URLs."
Phase 4: Defender (MDE, MDO, MDCA)
Hours 25–31
| Activity | Hours |
|---|---|
MDE: enable the Intune connector at security.microsoft.us; AV + EDR policies; verify sensor health (12-6) | 2 |
| Defender for Office 365: Safe Links, Safe Attachments, anti-phishing (preset security policies) | 2 |
| Defender for Cloud Apps: app governance, OAuth app policies (Threat Defense) | 1.5 |
| Microsoft Secure Score: capture baseline, action top recommendations | 1.5 |
EDR in block mode stays off for this Defender-AV-primary fleet — active Defender AV plus ASR already cover 3.14.2; block mode is for the third-party-AV/passive scenario only (12-6 § EDR in Block Mode).
Phase 5: Data Protection Baseline (Purview)
Hours 32–40
Lean baseline only; the full label/DLP/retention build is in chapters 13–14, and AI-grounding controls in Copilot Data Readiness.
| Activity | Hours |
|---|---|
| Enable Purview Audit and confirm logging is on (prerequisite for everything downstream) | 0.5 |
| Compliance Manager: create the CMMC L2 / NIST 800-171 assessment, assign improvement actions | 1 |
| Starter sensitivity-label taxonomy (3-tier): design, publish policy, validate | 3 |
| Baseline DLP (Exchange / SharePoint / OneDrive / Teams): build, run in simulation, review false positives, then enforce | 3 |
| Retention baseline for mail and SharePoint | 1.5 |
Labels are the keystone. Publish at least the starter taxonomy here; DLP, auto-labeling, and Copilot grounding controls all sit idle until a label set exists. See Data Protection Requirements for the full sequence.
Phase 6: Microsoft Sentinel
Hours 41–48
| Activity | Hours |
|---|---|
| Log Analytics workspace (US Gov Virginia); onboard Microsoft Sentinel | 1 |
| Data connectors: Defender XDR, Entra ID (sign-in + audit), Office 365, Azure Activity | 2.5 |
| Enable Microsoft Defender for Cloud (prerequisite for regulatory-compliance data) | 1 |
| Analytics rules from templates; basic automation/playbooks | 1.5 |
| Retention: 365-day hot + 2-year archive, configured per-table | 1 |
| Workbooks: Entra sign-in/audit, control-coverage (SIEM Strategy) | 1 |
After enabling the connectors and Defender for Cloud, the Sentinel regulatory-compliance views take 12–24 hours to populate. Schedule this early in the phase so it is ready by Phase 9 validation, and do not flag the empty view as a misconfiguration before then.
Phase 7: Workstation Enrollment & Pilot
Hours 49–54
| Activity | Hours |
|---|---|
| Autopilot registration of 25 devices (hardware hashes or OEM/CSP); assign profile and group | 2 |
| Pilot enroll 5 devices; verify all Layer 1 policies, compliance, and MDE sensor health | 2 |
| Roll the remaining 20 in waves; monitor assignment failures and per-policy status | 1.5 |
| WHfB / passkey pre-registration communication to users | 0.5 |
Verify the pilot fully before the wave. A policy error caught on device 1 is a 30-minute fix; the same error across all 25 is 25 remediations. Confirm every device shows Compliant in Intune before Phase 8 — P006 enforcement depends on it.
Phase 8: Conditional Access Enforcement
Hours 55–57
Flip CA policies from Report-Only to Enforced in risk order, allowing 15–30 minutes between high-risk policies to confirm no unexpected blocks in Entra sign-in logs. Follow the chapter's rollout methodology.
| Order | Policy | Risk |
|---|---|---|
| 1 | B001 Block Legacy Authentication | Low |
| 2 | B003 Block Device Code Flow | Low |
| 3 | B006 / B007 Block Non-Approved Registration | Low |
| 4 | B002 Block Non-Approved Locations | Medium |
| 5 | A001 Require MFA | Medium (verify all users MFA-registered) |
| 6 | A002 Require Phishing-Resistant Auth | High (verify passkey/WHfB enrolled) |
| 7 | P006 Require Compliant Devices | High (verify all 25 devices Compliant) |
| 8 | B008 / B009 High-Risk Sign-In Controls | Low operational impact |
If any of the 25 workstations is non-compliant when P006 is enforced, that user is blocked from all M365 resources. Confirm Intune → Devices → All Devices shows every device Compliant first.
Phase 9: Validation & Audit Evidence
Hours 58–66
| Activity | Hours |
|---|---|
| Per-control verification: confirm policies are enforced, not just assigned (Intune Diagnostics & Audit Evidence) | 3 |
| Sentinel: confirm ingestion and that regulatory-compliance data has populated | 1 |
| Secure Score and compliance-manager dashboards reviewed against target | 1 |
| Evidence capture for the SSP (per-control exports, screenshots, sample-device proof) | 4 |
Design for the assessor's question: "Show me your baseline, the mapping from each policy to a NIST 800-171 practice, and a sample device on which the baseline is enforced — not just assigned." Phases 1–8 produce the first two; this phase produces the third.
Phase 10: Documentation & SSP Handoff
Hours 67–72
| Deliverable | Hours |
|---|---|
| SSP control mapping built from the CMMC Control Matrix | 2 |
| As-built: CA policy list, Intune policy inventory, Sentinel configuration | 1.5 |
| Runbooks: user on/offboarding, device replacement, break-glass use, LAPS retrieval | 1.5 |
| Customer walkthrough: Defender portal, Intune compliance, Sentinel, compliance dashboards | 1 |
Contingency Reserve: 8 Hours
| Likely Draw | Estimated Hours |
|---|---|
| CA enforcement rollback: diagnosing unexpected blocks after A002 or P006 | 1–2 |
| Sentinel connector or regulatory-compliance-data delay (calendar wait, but unblocking takes time) | 1–2 |
| Sensitivity-label / DLP false-positive tuning during simulation | 1–2 |
| Autopilot hardware-hash collection or enrollment-URL (sovereign) issues | 1–2 |
The 8-hour contingency is adequate for a well-prepared, cloud-only engagement. It does not cover the out-of-scope workstreams listed above (hybrid identity, data and app migration, GPO-to-Intune, mobile device management) — each is a separately scoped phase to size and price before committing to 80 hours.
📩 Don't Miss the Next Solution
Join the list to see the real-time solutions I'm delivering to my GCC High clients.