18
Mapped service components
Service Dependency Register
A dependency model becomes useful when it helps explain service risk, change impact, and incident scope.
| Service | Depends On | Owner | Risk Note |
|---|---|---|---|
| Remote access service | Gateway cluster, identity service, vendor support channel | Infrastructure lead | Vendor and gateway are shared choke points during high-severity incidents |
| Leadership dashboard reporting | Public data refresh jobs, reporting model, source system feed | Data / reporting owner | Source feed delays can affect both internal reporting and public updates |
| Energy Strategy publishing | CMS platform, content owner approvals, publish workflow | Web platform owner | Approval and content readiness often drive timing more than the publish action itself |
| Teams workspace governance | Workspace ownership rules, manager approvals, retention settings | Collaboration owner | Governance drift creates recurring cleanup and access churn |
Shared Dependency Hotspots
These are the components most likely to create cross-service impact when they degrade or change.
Affects remote access, onboarding, access changes, and approval-bound workflows.
Affects public-facing updates, leadership reporting, and confidence in published information.
Affects staff productivity broadly and carries high incident-command pressure when unstable.
Not a system dependency in the technical sense, but still a major operational dependency for delivery timing.