Name the service before assigning responsibility

Infrastructure, operating systems, runtimes, applications, identities and data may have different owners. Go further than assigning a general label. Identify who collects the logs, investigates an event, restores service and removes access. A provider can operate the feature while the customer is responsible for configuring it.

For EC2, AWS assigns the guest operating system and installed applications to the customer. In Azure PaaS, Microsoft handles the operating system. These differences are why the record needs the named service, deployment and relevant documentation. Saying that a system is hosted in the cloud does not explain who does the work.

Check what replaced the old monitoring

Suppose a fictional portal moves from a virtual machine to a managed application service. The provider now performs more maintenance, but the customer still needs to manage dependencies, tenant authorization, administrative access and customer exports.

The old host log collector may no longer work in that environment. Find the replacement telemetry, generate a test event and confirm that it reaches the investigation system. Then update the runbook. Removing the host-maintenance task did not automatically transfer responsibility for detecting misuse of the application.

Give each task an owner and a check

A responsibility worksheet should say how to tell whether the task was completed. Otherwise, both parties may describe their own responsibilities correctly while a required handoff remains untested.

TaskResponsibility to establishHow to check it
Platform maintenanceProvider or customer, for this service layer.Retain version and maintenance evidence.
Access policyCustomer identity owner.Verify that unauthorized access fails.
Application dependenciesEngineering owner.Confirm the deployed versions were reviewed.
Telemetry and responseOperations and the provider escalation contact.Confirm that a test event can be investigated.
RecoveryExplicit tasks assigned to each party.Restore the service and validate it.

Exercise the work that crosses organizations

Walk through a lost administrative credential or suspected exposure. Check detection, evidence collection, escalation and containment, including the point at which the provider must act. Verify support access and contacts while the situation is routine, rather than discovering during an incident that no one can open the required case.

Use owned test accounts and synthetic data to examine tenant isolation. Include exports, background jobs, caches and administrative tools. A successful check through the main interface does not establish what happens through those other paths.

Recheck the division of work when the service changes

A new tier, region, identity integration or data flow may change what each party needs to do. Update the worksheet when that happens. Keep provider statements, actual configuration and test results separate so that a documented feature is not mistaken for a control that has been configured and verified.

Sources and reference editions

  1. AWS Shared Responsibility ModelOfficial guidance checked October 4, 2026; page does not state an edition date
  2. Microsoft Azure: Shared responsibility in the cloudUpdated August 24, 2026; checked October 4, 2026