Planned changes in view
Upcoming Change Schedule
The change view should make timing, risk, and approval posture obvious before the window begins.
| Change | Window | Risk | Rollback / Approval State |
|---|---|---|---|
| Remote access gateway patch Core connectivity service change with dependency impact |
Saturday 8:00 PM | Elevated | Rollback plan attached; final approval pending infrastructure lead review |
| Energy Strategy site update Planned content and publishing release |
Friday 4:00 PM | Moderate | Publish package ready; content owner approval required |
| Public data refresh validation change Refresh workflow logic and pre-check alerting |
Thursday 6:30 PM | Moderate | Rollback tested; data owner approved |
| Teams retention standard update Governance rule adjustment across select workspaces |
Tuesday 7:30 PM | Low | Standard change; manager approval recorded |
Risk Factors
Risk should be visible as a combination of service impact, timing, reversibility, and dependency complexity.
Blast Radius
How many users, divisions, or services could be affected if the change goes wrong.
Dependency Complexity
Whether the change touches vendor-managed systems, shared infrastructure, or cross-service chains.
Rollback Confidence
Whether the team has a tested, time-bounded path back to last-known-good service.
Business Timing
Whether the change lands near reporting deadlines, leadership reviews, or critical public-facing windows.
Change Lanes
Different change types should move through different levels of review and control.
Standard
Low-risk, repeatable changes with known rollback and pre-approved control pattern.
Normal
Planned changes needing explicit review of timing, dependencies, and rollback readiness.
Emergency
Service-restoring changes executed under incident command with retrospective review and audit follow-up.