Access and configuration
Identity changes, privileged access, network rules, resource configuration and certificates.
DECISION GUIDE / OPERATIONS
Home/Guides/managed cloud responsibility matrix
Managed Cloud Responsibility Matrix Guide
A managed-cloud responsibility matrix assigns an owner, approver, execution scope, evidence and escalation path to each recurring infrastructure task, while keeping provider responsibilities and customer application ownership explicit.
01 / GUIDE
Rows to include
List concrete operating tasks rather than broad promises.
Monitoring and response
Signal ownership, triage, notification, escalation and incident records.
Data and maintenance
Backup, restore testing, patching, capacity, lifecycle and change windows.
02 / GUIDE
Columns to define
Ownership is more useful when execution conditions are visible.
Responsible and approving
Who performs the task and who authorizes material changes or risk acceptance.
Trigger and frequency
Whether the task is scheduled, event-driven, requested or tied to a threshold.
Evidence and escalation
What record proves completion and where exceptions or blocked decisions go.
03 / GUIDE
Review method
Walk through real operating events before accepting the matrix.
Routine change
Trace a normal configuration or patch change from request to closure.
Service incident
Confirm monitoring, triage, platform escalation, customer communication and recovery ownership.
Restore request
Confirm backup ownership, authorization, restoration execution and application validation.
04 / GUIDE
Expected outputs
The matrix becomes part of the operating baseline.
Responsibility matrix
A versioned task-by-task assignment across customer, WIDE IDC and provider.
Escalation map
Contacts, decision owners, severity path and provider support route.
Evidence register
Where monitoring, change, backup, access and review records are retained.
05 / EDITABLE TEMPLATE
Managed cloud responsibility matrix template
Version 1.0 · reviewed 7 October 2026. Replace each row with the environment's actual owners, approval conditions, execution scope, evidence and escalation path.
This template is a starting point for assigning responsibility, not an SLA, contract, legal opinion or fixed WIDE IDC service commitment. Use it with the applicable cloud service terms and the managed cloud service scope.
| Operating activity | Customer role | WIDE IDC | Cloud provider role | Control record |
|---|---|---|---|---|
| Identity and privileged access | Own the account, name users and approve privileged access. | Implement approved changes only when included in the agreed scope. | Operate the identity service and underlying platform controls. | Request, approver, access log and offboarding evidence. |
| Monitoring and alert triage | Define business impact, application owners and notification needs. | Triage agreed infrastructure signals and escalate within scope. | Publish platform health, service events and available metrics. | Alert, severity, owner, action, timestamp and escalation path. |
| Backup and restore testing | Approve retention and recovery objectives; validate application recovery. | Configure and check agreed backups; record restore tests. | Operate the selected backup or storage service under its terms. | Policy, job result, restore evidence, exception and next review. |
| Patching and infrastructure change | Approve the window, risk acceptance and application validation. | Coordinate or execute agreed infrastructure changes with rollback steps. | Maintain managed services and the underlying platform as documented. | Change request, approval, implementation, validation and rollback result. |
| Incident coordination | Own business decisions, application response and stakeholder communication. | Triage in-scope infrastructure and coordinate provider escalation. | Investigate platform events through the applicable support route. | Timeline, decisions, support case, recovery checks and follow-up owner. |
| Documentation and scope review | Confirm owners and accept material scope or risk changes. | Maintain agreed runbooks, responsibility records and open decisions. | Publish current service documentation, terms and advisories. | Version, reviewer, review date, open decision and next review. |
Official responsibility-model references
Use these sources to verify platform boundaries; their inclusion does not imply WIDE IDC partner status.
BOUNDARY
How to use this guide
A responsibility matrix defines work ownership; it does not replace the cloud provider's service terms or the customer's application, data and business responsibilities.
FAQ
Frequently asked questions
Answers are shown in full so they can be read, cited and reviewed independently.
01Is a responsibility matrix the same as an SLA?
No. It assigns operational responsibility and evidence. Any service levels or response commitments require a separate, explicit agreement.
02Who owns application incidents?
That depends on the agreed scope. Infrastructure triage can be assigned without transferring application code, product or business-process ownership.
03When should the matrix be reviewed?
Review it after material architecture, team, access or service-scope changes and at the agreed operating interval.
NEXT STEP
Define a managed-cloud responsibility matrix
Share the environments, current operators, recurring tasks and gaps that need clear ownership.
A specialist will review the service, workload, region, traffic, storage, backup and management scope with you.