Monitoring and Operational Visibility¶
Scope
Release 1 operational visibility covers sign-in review, audit-log analysis, device-state checks, policy review, practical alerting, and Microsoft Graph PowerShell validation. The evidence route uses the Release 1 monitoring documentation and screenshot folders.
Release 1 monitoring is deliberately scoped to what an operator can review and act on. It is not presented as a full enterprise SOC or large-scale observability programme. It validates review and operation through Microsoft-native visibility, captured evidence, and script-assisted state checks.
Design decisions¶
- Start with native Microsoft visibility - Release 1 uses Entra ID, Intune, Microsoft 365, Defender, and portal-level operational views before introducing larger monitoring platforms.
- Review access behavior, not only policy existence - Conditional Access is more credible when sign-in behavior and grant-control outcomes can be inspected.
- Track device and control state - Compliance, device presence, policy status, dashboard views, and endpoint health are treated as operational signals.
- Capture evidence as part of operations - Screenshots and script outputs turn review activity into an auditable trail.
- Use Graph and PowerShell where portals are not enough - Graph-connected scripts provide repeatable visibility into pilot users, managed devices, and controlled administrative actions.
- Keep scope honest - Release 1 proves practical operational visibility. Release 2 expands the model with Sentinel, Azure Monitor, backup evidence, and automation control planes.
Sign-in visibility¶
Sign-in monitoring links identity, access policy, and device context into one operational signal.
The Release 1 monitoring evidence includes sign-in log views showing Conditional Access result visibility. The operator can verify access decisions through sign-in evidence rather than assumption.
| Review question | Evidence signal |
|---|---|
| Are access attempts visible? | Entra sign-in log screenshots. |
| Are Conditional Access outcomes visible? | Sign-in detail views showing Conditional Access result. |
| Are device and access controls connected? | Sign-in records interpreted alongside endpoint and compliance context. |
Conditional Access result visibility¶
Conditional Access policies protect the tenant; this note focuses on verification rather than description.
The monitoring model validates that policy results appear in sign-in records and that access behavior can be reviewed after a user or administrator attempts to access cloud resources.
| Claim | Evidence path | What to verify |
|---|---|---|
| Conditional Access result is visible in sign-in logs. | screenshots/release1/monitoring-and-operations/monitoring/sign-in-logs/ | Sign-in-log screenshot with Conditional Access result. |
| Identity and endpoint context can be interpreted together. | docs/release1/08-monitoring.md and Release 1 screenshots. | Monitoring narrative connects identity, access review, and device-context interpretation. |
Audit-log visibility¶
Audit logging gives administrative activity a review trail. Configuration changes, identity actions, and control adjustments become reviewable instead of relying on memory.
The Release 1 monitoring evidence includes Entra audit-log visibility, showing that operational history can be inspected during support or governance review.
| Claim | Evidence path | What to verify |
|---|---|---|
| Administrative activity is reviewable. | screenshots/release1/monitoring-and-operations/monitoring/audit-logs/ | Entra audit-log overview evidence. |
| Release 1 includes audit visibility as an operational control. | docs/release1/08-monitoring.md | Audit visibility section and related flagship evidence. |
Device and control visibility¶
Endpoint trust depends on visibility into the managed estate. Release 1 monitors device presence, compliance state, policy status, dashboard-level control views, and whether the managed estate appears healthy or inconsistent.
Policy existence is not enough. Administrators need to see whether devices are present, managed, compliant, and aligned with the expected control state.
| Claim | Evidence path | What to verify |
|---|---|---|
| Device compliance can be reviewed operationally. | screenshots/release1/monitoring-and-operations/monitoring/device-visibility/ | Intune device compliance status evidence. |
| Device and policy state are part of the monitoring model. | docs/release1/08-monitoring.md | Device and control visibility section. |
Practical alerting¶
Release 1 is scoped to practical alert visibility rather than a full enterprise alerting program. It includes practical alert visibility that supports endpoint administration and operational review.
The evidence includes example alerting in the administrative view, showing that the platform was operated rather than treated as a static build. Administrators need visibility when device configuration, compliance, or control posture requires attention.
| Claim | Evidence path | What to verify |
|---|---|---|
| Release 1 includes practical alert visibility. | screenshots/release1/monitoring-and-operations/monitoring/example-alert/ | Intune dashboard device configuration alert evidence. |
| Alerting is positioned as supportability, not full SOC maturity. | docs/release1/08-monitoring.md | Alerting and operational awareness section. |
Graph and PowerShell operational visibility¶
Release 1 extends portal-based monitoring with Microsoft Graph PowerShell tooling. This provides repeatable, operator-driven visibility into pilot user state, managed device state, and controlled administrative action.
The validated tooling includes:
- Connect-BelfastMgGraph.ps1 for Microsoft Graph connection and consent validation.
- Get-BelfastPilotUserState.ps1 for pilot user state review.
- Get-BelfastManagedDeviceState.ps1 for managed device state review.
- Rename-BelfastManagedDevice.ps1 for controlled device rename with dry-run and apply modes.
Modern Microsoft workplace operations increasingly require Microsoft Graph-aware administration alongside portal review.
| Claim | Evidence path | What to verify |
|---|---|---|
| Microsoft Graph connection and consent were validated. | screenshots/release1/identity-and-access/identity-operations/graph-powershell/ | Admin consent and successful Connect-MgGraph output. |
| Pilot user state can be queried. | Same folder. | Get-BelfastPilotUserState.ps1 evidence output. |
| Managed device state can be queried. | Same folder. | Get-BelfastManagedDeviceState.ps1 evidence output. |
| Device rename was controlled with dry-run and apply. | Same folder. | Dry-run and apply evidence for Rename-BelfastManagedDevice.ps1. |
See Graph and PowerShell Operations for the dedicated operator-tooling note.
Operational review model¶
The monitoring discipline is a review process, not only a tool choice.
A practical Release 1 review cycle examines:
- Sign-in logs and Conditional Access outcomes.
- Audit-log visibility for administrative activity.
- Device compliance and managed-device state.
- Policy and control status.
- Practical alerts that require administrator attention.
- Microsoft Graph PowerShell output where portal visibility is not enough.
- Evidence captured for future review.
This model is supportable by a single administrator and extends naturally into the Release 2 monitoring, Sentinel, backup, and automation model.
Architectural significance¶
- Validates that operational visibility existed before Release 2 automation and Sentinel expansion.
- Shows a review cadence grounded in Microsoft 365 and Entra administration.
- Connects dashboard-based review with Microsoft Graph-connected state queries and controlled administrative action.
- Builds a path from Release 1 operational visibility to Release 2 monitoring, backup, and automation evidence.
- Keeps the scope clear by separating practical monitoring from full enterprise SOC positioning.
Evidence map¶
| Claim | Repository location | What to verify |
|---|---|---|
| Sign-in logs were reviewed for access and Conditional Access outcomes. | screenshots/release1/monitoring-and-operations/monitoring/sign-in-logs/ | Conditional Access result visible in sign-in logs. |
| Administrative activity is visible through audit logs. | screenshots/release1/monitoring-and-operations/monitoring/audit-logs/ | Entra audit-log overview evidence. |
| Device compliance and control status are reviewable. | screenshots/release1/monitoring-and-operations/monitoring/device-visibility/ | Intune device compliance status evidence. |
| Practical alert visibility exists for endpoint administration. | screenshots/release1/monitoring-and-operations/monitoring/example-alert/ | Intune dashboard device configuration alert evidence. |
| Microsoft Graph PowerShell tooling was validated. | screenshots/release1/identity-and-access/identity-operations/graph-powershell/ | Microsoft Graph consent, connection, pilot user state, managed device state, dry-run rename, and apply rename evidence. |
| Monitoring scope and boundaries are documented. | Release 1 monitoring documentation | Practical monitoring scope, advanced Graph validation, evidence boundaries, and related documents. |