Cloud Shared Responsibility Explained

Cloud shared responsibility describes the division of work between a cloud provider and the firm using its services. In broad terms, the provider is responsible for the security and resilience of the cloud itself, such as its physical facilities and underlying infrastructure, while the firm is responsible for security and resilience in the cloud, such as its data, its configuration, its access controls, and its applications. That broad division is a useful starting point, but it is not a contract and it is not a service design. The actual boundary moves with the service model, the configuration choices made by the firm, and the specific provider offering in use. Under DORA, the firm keeps responsibility for its service regardless of where that boundary sits, so it needs to know, for each service, which side of the boundary each task falls on and who will act when it fails.

Provider marketing diagrams often draw a clean line, with provider duties on one side and customer duties on the other, and a shaded middle for shared tasks. Real services are messier. A provider may manage patching for a platform while the firm manages patching for its own application on that platform. A provider may offer backup features that the firm must configure, schedule, and test before they protect anything. A provider may control network protections at its edge while the firm controls access rules for its own users and systems. Each of those middle tasks can become a gap if both sides assume the other is handling it, or a duplication if both sides act without coordination. The shared middle is therefore where responsibility needs the most explicit mapping, not the least.

Configuration is the most common source of shared responsibility failure. Cloud services offer powerful defaults, but defaults are general settings, not service-specific decisions. A storage setting, an access policy, a logging choice, or a backup schedule that is left at a default may expose data, hide an incident, or leave recovery untested, even though the provider platform itself is operating correctly. The firm owns those configuration decisions, because only the firm knows what its service requires, what its data means, and what its tolerance allows. Provider tooling can help the firm make good choices, and provider guidance can explain options, but neither transfers ownership of the choice. A configuration error is a firm error even when it occurs inside a provider console.

Identity and access illustrate the shared boundary from another angle. A provider supplies identity infrastructure, authentication mechanisms, and tools for managing accounts, while the firm decides who should have access to what, under what conditions, and how that access is reviewed. A payment initiation service, for example, depends on correct identity decisions at several points: customer authentication, staff access to operations tools, and system access between components. A failure in any of those decisions can undermine the service even when the underlying identity platform is healthy. Shared responsibility in this area therefore means more than using a provider tool. It means governing the decisions made with that tool, with records that show who approved access, for what purpose, and for how long.

Recovery also crosses the boundary, and it needs joint rehearsal. The provider may restore its platform, while the firm restores its data, reconfigures its service, checks integrity, and resumes customer operations. If those steps are planned separately, the combined sequence may fail: a platform restored before data is ready, or data restored into a configuration that no longer matches the service. Joint testing, even at a modest scale, reveals ordering problems, missing credentials, and unclear handover points. It also builds the working relationship that a disruption will require, between firm staff who know the service and provider staff who know the platform. That relationship cannot be created by a diagram during an incident.

A service-specific responsibility map is the practical output. For each important service, the map lists the tasks that keep it secure and recoverable, assigns each task to provider, firm, or joint action, and notes the evidence that shows the task was done. It covers configuration, patching, monitoring, incident response, backup and recovery, and change, rather than treating shared responsibility as a single statement. The map should be reviewed when the service model changes, when the provider changes its offering, or when a test or incident reveals a gap. A firm that can produce such a map, and show that it is used in governance and testing, has turned a marketing concept into an operating arrangement. A firm that cannot is relying on a diagram to do the work of governance.