Proof Library Sample Overview Complete Review Portal Preview Demo Portal Method Brief
← Back to the sample overview
Synthetic Sample · No Customer Data · Complete Review

Endpoint Architecture Review — Cascade Industrial Group

The complete sample deliverable: how MG Cloud connects dated evidence, findings, accountable decisions, an approved deviation, a target state, a sequenced roadmap, and the continuity layer that keeps it all current.

Everything here is fictional. Cascade Industrial Group, its people, counts, configurations, and outcomes are invented for this public sample. Nothing on this page is a real client, a real result, or a compliance or security guarantee. Assessment date used in the scenario: 2026-07-10.
Section 0

How to read this review: the four layers

This review deliberately keeps four things separate, so the reader always knows what they are looking at:

1 · Observed

What the tenant reports — dated evidence items with stable ids (EVD-*).

2 · Assessed

What repeatable checks evaluated against recognized guidance.

3 · Judged

What a senior architect concluded from the evidence — and why.

4 · Decided

What a named owner accepted, with a date and a review point (ADR-*, DEV-*, OUTCOME-*).

A scanner gives you layer 2. Most consulting gives you layers 2–3 in a deck that is stale the day after delivery. This engagement produces all four — and leaves behind the discipline that keeps them current (Section 7).
Section 1

Executive summary

Cascade Industrial Group (CIG) is a fictional ~2,100-person manufacturing and logistics enterprise on a Microsoft-centric estate. It is not failing — it runs every day. But years of migrations, urgent fixes, and overlapping ownership produced an endpoint environment that is hard to explain and risky to change, and the lead endpoint architect departed three months before the assessment, taking undocumented intent along. A Windows 11 program and a cyber-insurance review are both underway, and both stalled on the same root cause.

The review found one dominant structural issue and a set of consequences that flow from it:

None of this is a catastrophe. It is the ordinary accumulated complexity a competent team runs into — which is exactly why the fix is not heroics, but a legible architecture plus a system that keeps it legible.
Section 2

Current state at assessment (2026-07-10)

DimensionCurrent state (synthetic)
Windows corporate1,850 — 1,180 co-managed (64%), 670 cloud-managed only
Other endpoints140 macOS (45 unmanaged), 85 Cloud PCs, 900 iOS, 260 Android, 420 BYOD Windows
Policy surface340 configuration profiles (190 settings-catalog), 12 compliance, 28 Conditional Access, 6 app-protection, 260 assignment groups
Management modelHybrid, mid-transition; legacy update path for 64%; ~40 linked group policies; workload ownership undocumented
Security coverageEndpoint detection 82%, disk encryption 91% reported (160 not confirmed), local-admin rotation on co-managed only, attack-surface rules audit-only
Lifecycle210 stale devices (90+ days), 240 end-of-life Windows builds
Team4 endpoint engineers, 9 service desk, 3 security, 1 external MSP — no shared architecture picture
The single most important fact in this table: the control set a device gets is determined by how it was historically managed, not by what the device is for. That is the seam every finding runs along.
Section 3

Findings — prioritized by judgment, not by a score

Every finding traces to dated evidence items (20 in the full package), and every finding carries its own stated limitations. Priority reflects exploitability and business impact — severity is never inflated to manufacture urgency.

IDFindingPriorityEvidence
FR-002Two-tier control gap: 670 cloud-managed devices under a thinner control setP1EVD-SEC-003/004/005, EVD-INTUNE-002, EVD-SCCM-001
FR-003Security-coverage tail: detection 82%, encryption 91% (160 unconfirmed), 45 unmanaged MacsP1EVD-SEC-001/002, EVD-DEVICE-003
FR-005Permissive, partly-legacy identity and enrollment postureP1EVD-CA-001/002/003, EVD-DEVICE-004
FR-001Policy sprawl, no authoritative winner (340 profiles / 260 groups)P2EVD-INTUNE-001/002, EVD-ASSIGN-001/002, EVD-SCCM-003
FR-006Legacy dependency drag (64% co-managed, legacy updates, 40 group policies)P2EVD-SCCM-001/002/003, EVD-DEVICE-002
FR-004Lifecycle backlog: 210 stale, 240 end-of-life, 45 unmanaged MacsP2EVD-DEVICE-001/002/003
FR-007Key-person and explainability risk: operable but not explainableP2EVD-OPS-001, EVD-INTUNE-001

Each finding in the full package carries five fields the summary table cannot show: the observation, the architecture judgment, the business impact, the recommendation, and the finding's own limitations — including where tenant-reported state could differ from on-device reality.

Section 4

Decisions and deviations — the memory

Findings that stop at a report get re-litigated at the next staff change. This engagement converts them into dated, owned records:

ADR-001 · One authoritative Windows baseline

Accepted · Owner: Head of Endpoint Engineering · Review 2026-10-16. Same security floor on every corporate Windows device, role-based targeting, versioned naming, the 670-device gap closed first. Addresses FR-001 / FR-002 / FR-003.

ADR-002 · Phased co-management cutover + modern update rings

Accepted (staged) · Owner: Director of Infrastructure · First ring gate 2026-09-16. End-of-life builds move first; each of the ~40 group policies retires only with an owner decision. Addresses FR-006 / FR-004.

DEV-001 · Accepted deviation: ~60 manufacturing-line devices

Vendor-certified line software blocks upgrade in the standard window. Risk accepted by the CISO with compensating controls (network isolation, tightened endpoint controls, no general-purpose use) and a 90-day review. A deliberate, owned risk — not an ignored finding.

OUTCOME-001 · Did the fix actually work? (illustrative)

The outcome record pattern: remediation is verified per device from reporting data. A silent device counts as not-done — never rounded up. Shown pre-remediation in this sample, clearly labeled illustrative.

Every record names an accountable owner and a review date. Nothing silently persists — a deviation still open at review is re-affirmed or revised with a dated note, on purpose.
Section 5

Target state

From a two-tier, dual-managed, undocumented estate to a single authoritative, cloud-primary, continuously-evidenced one. Five pillars:

Section 6

30 / 60 / 90 roadmap — every item traces to a finding or decision

PhaseFocusHighlights
Days 0–30Stabilize the exposureLocal-admin rotation to the 670; close the detection tail; triage the 160 unconfirmed-encryption devices; verify break-glass; start stale reconciliation; stand up the decision register
Days 31–60Converge the architecturePublish the authoritative baseline to ring 1; promote attack-surface rules from audit to enforce on a validated set; modern update ring 1 with end-of-life builds first; tighten enrollment; decide the 45 unmanaged Macs
Days 61–90Modernize and operationalizeBaseline to full fleet by ring; workload cutover stage 2 and group-policy retirement with owner decisions; document the Conditional Access model; verify outcomes per device; operating-model handoff
What “done” does not mean: this roadmap reduces risk and makes the estate legible and evidenced. It does not issue a compliance certification or guarantee, and the accepted deviation (DEV-001) is expected to remain open past 90 days by design — with its compensating controls verified at each review.
Section 7

Continuity: why this is not a one-time report

A point-in-time review decays the day after it is delivered — and this fictional client already lived that cost once, when the architect left. The engagement design addresses it in three layers:

Re-runnable, dated evidence

The assessment is repeatable tooling, not a one-off. Each re-run produces a new dated picture that compares against the last one — drift shows up as a difference between two dated views, not as a surprise two years later.

Verified outcomes

Remediation is proven from per-device reporting under a positive-evidence rule: success, partial results, failure, and missing data stay separate, and missing data is never counted as success.

Decision reviews on dates

Decisions and deviations carry review dates. The register surfaces what is due, what changed out-of-band, and what still lacks an owner — so judgment stays current alongside the facts.

Evidence your tools can use

Findings, decisions, and verification results are structured, dated data — built to be consumed by your own reporting and assistant tooling, with citations and honest refusal when the evidence is not there.

The rule that governs all of it: software refreshes the facts; accountable people make the decisions. Continuity options — including how often the review re-runs and where the evidence lives — are scoped per engagement.
Section 8

What you receive vs what stays with MG Cloud

LayerYou receiveMG Cloud retains
EvidenceDated assessment reports and evidence packages — your data, in your hands
RecordsThe decision / deviation / outcome register for your estateThe methodology and refusal discipline behind it
DesignTarget architecture, roadmap, runbooks, and handoff documentationThe content-authoring and validation system that produces them
OperationsAn operating model your team runs after handoffOngoing architecture judgment, by engagement

Plainly: you own your evidence, your records, and your operating model. There is no lock-in by hostage-holding — the ongoing relationship exists because keeping the judgment current is worth it, not because you cannot leave.

Honest scope: this is a read-only, point-in-time technical assessment with clearly stated limitations. Tenant-reported state can differ from on-device reality; where a finding depends on reported data, that is noted in the finding itself. Nothing in this review is a legal or compliance certification.
Request the Full Walkthrough Back to the Sample Overview
Continue exploring

These pages are one connected proof library.