Shared Responsibility as a Boundary Model

Goal

Shared responsibility is a practical model for deciding who performs an operational task, who verifies it, and who remains accountable for the outcome. It is not a promise that using cloud services transfers all risk to the provider.

The Short Version

The provider operates the physical facilities and foundational cloud infrastructure. The customer always owns its business purpose, identities, data, access intent, workload configuration, and risk decisions. Between those ends is a moving boundary: the more managed the service, the more platform tasks the provider performs.

Customer always decides: data use | access intent | configuration | outcomes | risk
Moving boundary:          application | runtime | operating system | platform
Provider operates:        facilities | hardware | foundational cloud infrastructure

The exact division depends on the service, configuration, integration, and applicable requirements. It must be checked per workload rather than remembered as one universal diagram.

Task Ownership, Control Ownership, and Risk Ownership

These three ideas are related but distinct:

• Task ownership identifies who performs work such as patching an operating system.

• Control ownership identifies who implements or verifies a safeguard such as encryption, logging, or access review.

• Risk ownership identifies who accepts the business consequence if the workload fails or data is mishandled.

A provider may patch the host and supply encryption features. The customer still decides whether its data requires encryption, configures the appropriate options, controls access to keys where applicable, and verifies that the resulting control meets the requirement. Provider assurance reports can support customer evidence; they do not describe the customer's workload configuration.

Example: A Managed Database

A managed relational database can remove hardware, base operating-system, and database-engine maintenance from the application team. The remaining customer responsibilities still include:

• classifying the stored data and selecting an allowed location;

• granting people and workloads appropriate access;

• choosing network exposure and encryption configuration;

• setting retention, backup, restore, and recovery expectations;

• monitoring application-visible health, capacity, and cost;

• designing the application for dependency failure;

• testing that recovery works.

Even where automated backups are a service feature, the team must decide whether the retention and recovery behavior meets the business requirement. "The service has backups" is not the same as "the workload can recover within its target."

Build a Responsibility Register

For important workloads, record each responsibility with five fields:

Revisit the register when the service model changes. Moving from virtual machines to a managed platform should remove obsolete tasks and assign the remaining ones explicitly.

Common Mistakes

• Treating "managed" as a complete security, backup, or monitoring strategy.

• Applying one shared-responsibility diagram to every service.

• Recording who operates a control but not who verifies it.

• Assuming provider availability removes the need for workload resilience.

If Someone Asks You

What does shared responsibility mean in practical terms?

It means the provider and customer operate different layers, and that boundary changes by service model. The customer must still define the required outcome, configure its part, verify controls, and own the workload's business risk.

What You Should Remember

Shared responsibility changes who operates layers, not who owns the outcome.

Questions to Check Your Understanding

1. Why is task ownership different from risk ownership?

2. Which decisions remain with the customer for a managed database?

3. When should a responsibility register be reviewed?

Further Study

• AWS Shared Responsibility Model - Review AWS's distinction between security of and security in the cloud.

• Shared responsibility in the cloud - Compare how Microsoft describes responsibility across service models.