The Shared Responsibility Model — Security Fundamentals: Shared Responsibility

Every system has duties: someone must lock the doors, patch the software, choose who can sign in, back up the data, and respond when something breaks. The shared responsibility model is the simple idea that, when you use a cloud or managed technology service, those duties are split between you and the provider. The hard part is not the slogan. The hard part is knowing exactly where the split lands for each service, each risk, and each decision.

Start with responsibility, not technology

Before cloud computing, a company that owned its own data center was usually responsible for almost everything: the building, power, network cables, servers, operating systems, applications, user accounts, and data. It might hire specialists, but it could not usually point to a separate provider and say, “That part is yours.”

Cloud computing changed the ownership of physical and software layers. A provider may run the buildings, hardware, networks, storage systems, databases, or application platform. The customer still brings business intent: what data matters, who should access it, how it should be configured, and what level of risk is acceptable.

The shared responsibility model is a map of those duties. It says that security, reliability, compliance, and recovery are not handed off as one package. They are divided. Some controls belong mostly to the provider. Some belong mostly to the customer. Some require both sides to do their part in sequence.

Cloud shifts physical and platform layers to a provider, but intent stays with the customer.

What the provider usually owns

A provider usually owns the parts that make the service exist before any customer uses it. That often includes data center facilities, physical servers, core networking, storage hardware, and the software that delivers the managed service. If the provider offers a database service, for example, it may maintain the database engine, replace failed hardware, and keep the service reachable.

Provider responsibility is not the same as provider perfection. A provider can promise controls, publish certifications, and offer service level agreements, which are formal commitments about availability or support. But every provider has limits, outages, maintenance windows, and assumptions. You still need to understand what the provider promises, what it excludes, and what evidence it gives you.

The provider side is sometimes described as security of the cloud: protecting the infrastructure and managed service itself. That phrase is useful, but it is incomplete. Reliability, resilience, privacy support, logging features, and compliance evidence also live partly on the provider side.

Physical security for provider-operated facilities.
Maintenance of provider-owned hardware and core service software.
Service features such as encryption options, logging options, and backup capabilities.
Published documentation that explains defaults, limits, and customer obligations.
Operational response when provider-controlled components fail.

What the customer usually owns

The customer usually owns the way the service is used. This includes choosing regions, naming administrators, granting permissions, deciding which data to store, configuring network exposure, setting retention rules, and monitoring for behavior that does not fit the business.

A common mistake is to treat managed services as automatically safe. A storage service may be strongly built by the provider, yet a customer can still make a storage bucket public by mistake. A database may be patched by the provider, yet a customer can still give too many people the ability to export records. A collaboration tool may encrypt data in transit, yet a customer can still invite the wrong external users.

This is sometimes called security in the cloud: the controls you apply inside the service. It includes identity and access management, often shortened to IAM, which means the policies and systems that decide who can do what. IAM is one of the most important customer duties because many incidents begin with a valid account being misused.

⚠️

Managed is not magic. A managed service can remove maintenance work while still leaving you responsible for unsafe configuration and poor access control.

The split changes by service type

The model is not one fixed line. It moves depending on how much of the technology stack the provider manages. In infrastructure as a service, or IaaS, the provider supplies basic computing resources such as virtual machines, storage, and networks, while the customer manages operating systems, runtime software, applications, and data. In platform as a service, or PaaS, the provider also manages more of the operating environment. In software as a service, or SaaS, the provider runs the application itself, while the customer configures users, data, workflows, and policies.

The more managed the service, the more operational work shifts to the provider. But business accountability does not disappear. If a SaaS customer stores regulated personal data in the wrong place, shares it too widely, or fails to remove a departed employee, those are still customer problems even though the provider runs the application.

This is why a useful shared responsibility model must be specific. “The provider handles security” is too vague. “The provider patches the database engine; the customer defines network access, account permissions, backup retention, and data classification” is the kind of statement that can be tested.

Moving from IaaS to SaaS shifts more responsibility to the provider and less to the customer.

The dangerous areas are between the boxes

Incidents often happen in the seams. The provider may offer logs, but the customer must turn them on, store them long enough, and review them. The provider may support encryption, which means making data unreadable without the right key, but the customer may choose whether to enable it, who holds the keys, and which data needs it. The provider may support backups, but the customer may set retention too short or never test a restore.

These shared controls need two successful actions: the provider must make a reliable capability available, and the customer must use it correctly. If either side fails, the control fails. That is why the model should be read as an operating checklist, not a legal diagram.

There is also a human seam. Sales material may imply that a service is compliant or secure, while the contract, documentation, and configuration guide state narrower facts. Compliance, in this context, means meeting a specific rule, law, industry standard, or internal policy. A provider’s certification can help, but it does not automatically certify every way a customer uses the service.

⚠️

Mind the seam. A feature that exists but is not enabled, monitored, or tested is not a working control.

The riskiest duties are the ones each side assumes the other is handling.

How teams make the model operational

A shared responsibility model becomes useful when it is translated into decisions, owners, and evidence. Start with one service and one important business process. List what must be true for that process to be safe and reliable. Then mark each duty as provider-owned, customer-owned, or shared. For shared duties, write both halves.

The next step is to assign real owners. “The customer” is not a person. Someone must own identity settings, network rules, backup policy, incident response, vendor review, and change approval. Good teams also define evidence: screenshots, logs, policy files, test results, audit reports, or tickets that prove the duty is being performed.

This work should repeat because services change. Providers release features, defaults change, applications grow, regulations shift, and people leave the organization. A responsibility map that is correct once can become wrong quietly.

Choose a service and the business process it supports.
List the duties needed for security, reliability, privacy, and recovery.
Mark each duty as provider-owned, customer-owned, or shared.
Name the internal owner for every customer and shared duty.
Define the evidence that will prove each duty is being met.
Review the map after major service, contract, architecture, or regulatory changes.

Teams turn the model into practice by mapping duties, assigning owners, and testing them.

The decisions leaders and practitioners face

For leaders, the shared responsibility model is a way to avoid two opposite errors. One error is paying for a managed service and still staffing as if the organization runs every layer itself. The other is assuming the provider has absorbed risk that still belongs to the customer. Both errors waste money and create blind spots.

Procurement teams should ask what the provider operates, what the customer must configure, what evidence is available, and what happens during an incident. Security and engineering teams should ask which controls are mandatory, which defaults are unsafe, which logs are needed, and how recovery will be tested. Legal and compliance teams should ask whether the provider’s commitments match the organization’s obligations.

A practical decision is whether to buy a more managed service or build more yourself. More management can reduce patching and operational burden, but it may limit customization and require trust in provider controls. Less management can increase flexibility, but it expands the customer’s responsibility for maintenance, hardening, monitoring, and recovery. The right answer depends on risk, skill, cost, speed, and the importance of the system.

If the team lacks deep operational skill, prefer managed services but invest in configuration governance.
If the system needs unusual controls, confirm the provider can support them before committing.
If the workload is critical, require documented recovery roles for both provider and customer.
If regulated data is involved, map legal obligations to specific provider and customer controls.

A useful model is explicit, tested, and revisited

The shared responsibility model is not a shield against blame. It is a tool for making work visible before failure does. A good model names the duty, names the owner, names the evidence, and names the moment when the duty will be tested.

The best version is plain enough for a business owner to understand and precise enough for an engineer to act on. It does not rely on trust alone, and it does not confuse provider capability with customer implementation. It says, in practical terms, “Here is what they do, here is what we do, and here is how we know.”

✅

The useful test. If a duty has no owner, no evidence, and no test, it is not truly assigned.

Key takeaways

The shared responsibility model divides duties between a provider and a customer; it does not transfer all risk to the provider.
Provider duties usually cover the service foundation, while customer duties usually cover configuration, access, data, and business use.
The responsibility boundary moves by service type: IaaS leaves more to the customer, while SaaS shifts more operations to the provider.
Shared controls fail when either side does not do its part, such as when logging, encryption, or backups are available but not properly used.
A useful model names owners, evidence, and tests, then gets reviewed as services, contracts, and risks change.

Glossary

Shared responsibility model: A way to describe which duties belong to a technology provider, which belong to the customer, and which require both.
Cloud computing: The use of computing services such as servers, storage, databases, or applications that are delivered over a network by a provider.
Identity and access management: The policies and systems that decide who can sign in and what actions they are allowed to perform.
Infrastructure as a service: A cloud model where the provider supplies basic computing resources and the customer manages much of the software above them.
Platform as a service: A cloud model where the provider manages the underlying platform so the customer can focus more on applications and data.
Software as a service: A cloud model where the provider runs the application and the customer mainly manages users, settings, data, and business workflows.
Encryption: A method of making data unreadable unless someone has the correct key to decode it.
Compliance: Meeting a specific rule, law, industry standard, contract requirement, or internal policy.