When a security incident occurs, the first question is often: "Whose fault is it?" In modern architectures, cloud, containers, managed services, the answer is never simple. This page explains the principle of shared responsibility: the rule that marks out what the provider secures and what always remains the customer's job. Written for dev, ops and security teams that use cloud, containers or external contractors, it covers the IaaS/PaaS/SaaS models, Kubernetes, serverless, open source and the RACI matrix to clarify who does what.
What you will learn
This page gives you a concrete reading grid to decide, faced with an incident or a given architecture, who must act. You will leave with reference points you can apply directly to your own cloud systems, containers or contractors.
- Distinguish the responsibilities of the provider from those of the customer under IaaS, PaaS and SaaS
- Identify the grey areas that cause the most incidents
- Apply the model to containers, Kubernetes and serverless
- Build a RACI matrix to clarify who does what between teams
- Anticipate the new regulatory obligations (Cyber Resilience Act) that weigh on open source software
The myth of total delegation
A common mistake is to believe that using an external service transfers the security responsibility. It is one of the most dangerous myths of cloud and managed services.
You often hear: "We're in the cloud, the provider handles security." Or again: "We use a managed service, we no longer have to deal with it." Some even think: "The contractor is ISO 27001 certified, we're covered" or "It's open source software maintained by a large community, it's safe."
These beliefs create grey areas where nobody really protects the critical assets. The provider secures its perimeter, not yours.
The principle of shared responsibility
Shared responsibility defines a clear boundary between what the provider secures and what the customer must secure.
The building metaphor
Imagine a rented building. The landlord (the provider) is responsible for the structure: load-bearing walls, roof, common areas, lifts. The tenant (the customer) is responsible for their flat: locks, alarm, what they store inside.
If someone gets in through a window the tenant left open, it is not the landlord's fault, even if the building is "secure".
Applying it to IT
The provider manages the physical infrastructure (datacentres, servers, network) and virtualisation (hypervisor, isolation). For the operating system, it depends on the service: in IaaS it is the customer, in PaaS it is shared. Applications (code, dependencies, configuration) and data (classification, encryption, access) are always the customer's responsibility. For identities, the provider offers the authentication service, but account management, MFA and passwords remain on the customer side.
Service levels and their boundaries
The exact split of responsibilities depends directly on the service model chosen. The more the provider automates (SaaS), the fewer technical levers you keep, but your responsibility for the data and access rights never disappears. The three following tabs detail, model by model, exactly what remains your job.
Infrastructure as a Service
The provider manages the hardware and virtualisation. The customer manages everything else: operating system, middleware, applications, data. It is the model that leaves the most control to the customer, but also the most responsibilities.
What the customer must do: Patch the operating system. Configure the firewalls and security groups. Harden the exposed services. Manage access and identities. Encrypt sensitive data. Back up and restore.
What the provider does NOT do: Update your servers. Close the ports you opened. Delete the accounts you created. Detect intrusions in your applications.
Platform as a Service
The provider also manages the operating system and the runtime. The customer manages the applications and the data. This model speeds up development by removing infrastructure management, but demands extra vigilance over the code and its dependencies.
What the customer must do: Secure the application code. Manage the dependencies and their vulnerabilities. Configure authentication and authorisation. Protect the stored data. Define the application network policies.
Software as a Service
The provider manages almost everything. The customer manages the data, the access rights and the configuration. It is the simplest model on the surface, but the risks concentrate on two critical aspects: identity management and data classification.
What the customer must do: Manage user accounts and their rights. Enable the available security options (MFA, SSO). Classify and protect uploaded data. Monitor usage and access. Comply with compliance policies.
Beyond the cloud: other sharing contexts
Containers and orchestration
With containers, responsibilities fragment further across several layers. The base image is the responsibility of its publisher (for example the Linux distribution). The application image is built by the development team. The container runtime is managed by the platform or ops team. The orchestrator (Kubernetes) is configured by the platform team. The workload configuration falls to the application team.
A vulnerability in the base image is not the application team's responsibility, but it is their problem if it is not fixed.
Open source software
Using open source components creates an implicit responsibility that is often misunderstood. The community develops and maintains the code. The user chooses to integrate it and bears the consequences. Nobody is contractually responsible for the flaws.
If a vulnerability is discovered in a library you use, it is your responsibility to update or mitigate it, not that of the volunteer maintainer.
This implicit responsibility is gradually becoming explicit on the regulatory side. The Cyber Resilience Act (CRA), the European regulation on cyber resilience, comes into force in stages: the obligations to report actively exploited vulnerabilities have applied since 11 September 2026, and most of the compliance obligations from 11 December 2027. Vendors that integrate open source components into a commercial product (the "manufacturers" in the sense of the text) will have to document and fix vulnerabilities throughout the lifecycle, even when the code comes from a community project. Volunteer maintainers and foundations that publish free software without commercialising it remain outside the scope of the CRA's penalties: the legal responsibility stays with the one who integrates and distributes, not with the one who codes for free.
Contractors and subcontractors
Outsourcing a function does not remove the responsibility: this is a fundamental principle that is often ignored. The contractor is responsible for delivering the service. The customer remains responsible for the choice of contractor and for oversight. In the event of an incident, both can be involved.
A compromised hosting provider may be technically at fault, but the customer who did not check its security practices or who had no plan B shares the responsibility for the outcome.
Concrete scenarios
Theoretical principles take on their full meaning when faced with real incidents. The two following scenarios, a data leak from a badly managed cloud configuration and an incident at an external contractor, show how to apply the "shared responsibility" reading grid to decide who must answer for what.
The data leak "in the cloud"
A company stores customer data in a cloud storage service. One day, this data becomes publicly accessible on the Internet.
Investigation: The storage bucket was configured for public access. No alert was configured on permission changes. The cloud provider had warned about the risky configuration (notification ignored).
Who is responsible? The provider supplied a securable service and raised an alert. The customer misconfigured it and ignored the warning. Verdict: customer responsibility.
The provider does not have to prevent its customers from making choices (legitimate in some cases, such as public hosting).
The incident at the contractor
A company uses a SaaS contractor for its HR management. The contractor is attacked and the employees' data leaks.
Situation: The contractor had unfixed known flaws. The company had not audited the contractor's security. The contract included no security clause or incident notification.
Who is responsible? The contractor is technically at fault. The company did not do its due diligence (the prior check of a partner's security practices, before entrusting it with data) and remains responsible for its employees' data towards them and towards the regulator. Verdict: shared responsibility.
The company cannot pass the buck to the contractor, especially if it did not check its practices.
Clarifying responsibilities in practice
Understanding the principle is not enough: you have to apply it systematically, system by system. The following four-step approach turns an abstract principle into a verifiable operational practice, and stops grey areas from settling in silently.
-
Map the actors
For each system, identify: Who develops the code? Who operates the infrastructure? Who configures access? Who oversees security? Who responds to incidents?
-
Document the boundaries
Formalise explicitly: what the provider guarantees (SLA, the contractual service level commitment, and certifications). What the customer must do (configuration, monitoring). The grey areas to clarify.
-
Avoid assumptions
Never assume that "someone else is taking care of it". If it is not written down and approved, it is probably an uncovered grey area.
-
Test the boundaries
Regularly check that each party takes on its responsibilities: audit of customer configurations, review of SLAs and provider commitments, incident response exercises involving all the actors.
Responsibilities by cloud provider
The three major cloud providers (AWS, Azure, GCP) share the same principle of shared responsibility, but with important nuances.
AWS, Shared Responsibility Model
AWS uses the term "Security OF the cloud" (its responsibility) vs "Security IN the cloud" (your responsibility) to distinguish, service by service, what belongs to its infrastructure from what remains under your configuration.
| Layer | AWS | Customer |
|---|---|---|
| Physical datacentres | Physical security, power, cooling | - |
| Global network | Backbone, edge locations, L3/L4 DDoS | - |
| Hypervisor | Instance isolation | - |
| EC2 (IaaS) | Hardware infrastructure | OS, patching, firewall, data |
| RDS (PaaS) | DB patching, backups (if enabled) | Configuration, users, data |
| S3 (Storage) | Durability, availability | Bucket policies, ACLs, encryption |
| Lambda (Serverless) | Runtime, scaling, infra | Code, dependencies, IAM permissions |
| IAM | Available and secure service | Policies, users, MFA |
Azure, Shared Responsibility Model
Azure distinguishes responsibilities according to the service model, from SaaS to on-premises, with a progressive gradation of the customer's perimeter: the further down you go towards infrastructure managed in-house, the larger the customer's share. The table reproduces the matrix from the Microsoft documentation, revised on 24 August 2026: the first three rows stay with the customer whatever the model.
| Responsibility | SaaS | PaaS | IaaS | On-prem |
|---|---|---|---|---|
| Customer data | Customer | Customer | Customer | Customer |
| Configurations and settings | Customer | Customer | Customer | Customer |
| Identities and users | Customer | Customer | Customer | Customer |
| Client devices | Shared | Customer | Customer | Customer |
| Applications | Shared | Shared | Customer | Customer |
| Network controls | Microsoft | Shared | Customer | Customer |
| Operating system | Microsoft | Microsoft | Customer | Customer |
| Physical hosts | Microsoft | Microsoft | Microsoft | Customer |
| Physical network | Microsoft | Microsoft | Microsoft | Customer |
| Physical datacentre | Microsoft | Microsoft | Microsoft | Customer |
In PaaS as in SaaS, "Shared" on applications means that Microsoft manages part of the application stack, but that the configuration, the security of the code and the access controls remain with the customer.
GCP, Shared Fate Model
Google Cloud goes further with the concept of "Shared Fate": Google commits to actively helping customers succeed with their security, not just to marking out responsibilities and leaving it there.
| Service | Google Cloud | Customer |
|---|---|---|
| Compute Engine | Infra, hypervisor | OS, applications, data |
| GKE (Kubernetes) | Control plane, upgrades | Workloads, RBAC, network policies |
| Cloud Run | Runtime, scaling | Code, dependencies, secrets |
| Cloud Storage | Durability, encryption at rest | IAM, ACLs, data classification |
| BigQuery | Infrastructure, encryption | Access, queries, data |
Kubernetes model, 5 layers of responsibility
With Kubernetes, responsibilities fragment across 5 distinct layers. The split depends on whether you use a managed service or a self-managed cluster.
| Layer | Managed K8s (EKS/GKE/AKS) | Self-managed |
|---|---|---|
| 1. Cluster (control plane) | Provider | Customer |
| 2. Nodes (workers) | Shared (AMI/images) | Customer |
| 3. Network (CNI, policies) | Shared | Customer |
| 4. Workloads (pods, deployments) | Customer | Customer |
| 5. Container images | Customer | Customer |
Layer-by-layer detail
Each layer deserves a separate look, because the level of delegation to the provider varies greatly from one to the next. Here, layer by layer, is what moves over to the provider and what remains, in every case, your job.
Layer 1, Control Plane:
- When managed: the provider manages etcd, the API server, the scheduler, the controller-manager
- You keep responsibility for the RBAC configuration
Layer 2, Nodes:
- When managed: the provider supplies secured AMIs/images
- You must enable automatic updates and monitor CVEs
Layer 3, Network:
- NetworkPolicies are YOUR responsibility: without any NetworkPolicy, all traffic between pods is allowed
- The provider manages the underlying CNI but not your rules, and a NetworkPolicy only takes effect if this CNI enforces them
Layer 4, Workloads:
- SecurityContext, Pod Security Standards: your responsibility
- Secrets: your responsibility (even if stored in managed etcd)
Layer 5, Images:
- Scanning images: your responsibility
- Fixing CVEs in your images: your responsibility
- The runtime is secured by the provider, not the content
Fully managed modes: EKS Auto Mode, GKE Autopilot, AKS Automatic
The three providers now offer modes that automate a growing share of layers 2 and 3. EKS Auto Mode hands AWS the complete lifecycle of the instances (patching, scaling, health), GKE Autopilot goes further by fully managing the data plane, and AKS Automatic takes charge of the core components of the platform. These modes reduce the day-to-day operational work but never remove your responsibility for layers 4 and 5: workload configuration, application RBAC, secrets and image content remain, in every case, your job. They redistribute the load, they do not eliminate it.
Serverless, fewer responsibilities, not zero
Serverless (Lambda, Cloud Functions, Azure Functions) drastically reduces the customer's perimeter, but does not eliminate it. It is the model where the provider takes on the most responsibilities, but beware: "fewer responsibilities" does not mean "zero responsibility". The table below details exactly what remains your job.
| Aspect | Provider | Customer |
|---|---|---|
| Infrastructure | Servers, scaling, availability | - |
| Runtime | Patching, runtime security | - |
| Code | - | Logic, vulnerabilities |
| Dependencies | - | Libraries, CVEs |
| Permissions | - | IAM roles (often too permissive) |
| Secrets | Service available | Management, rotation |
| Data | - | Encryption, classification |
Serverless anti-pattern: giving *:* (all permissions) to a Lambda
"because it's simpler". Least privilege applies even more in Serverless
because functions are often publicly exposed.
The RACI matrix to clarify responsibilities
When several teams work on the same system, responsibilities become blurred. The RACI matrix is a simple but powerful tool to formalise who does what and keep critical tasks from falling through the cracks.
| Letter | Meaning | Description |
|---|---|---|
| R | Responsible | Does the work |
| A | Accountable | Ultimately answerable (only 1 per task) |
| C | Consulted | Gives an opinion beforehand |
| I | Informed | Informed afterwards |
Example: Handling a vulnerability in a container image
Let us take a concrete case: a critical CVE (Common Vulnerabilities and Exposures, the public identifier of a known security flaw) is discovered in a container image used in production. Who must do what? Without a RACI matrix, each team waits for "the other one" to deal with it, and the flaw stays open for weeks.
| Action | Dev | Ops | Security | Management |
|---|---|---|---|---|
| Detect the CVE | I | R | A | I |
| Assess the impact | C | R | A | I |
| Fix the image | R | C | I | I |
| Validate the fix | C | R | A | I |
| Decide on deployment | I | C | C | A |
| Deploy | R | A | I | I |
Without this clarification, the CVE stays in limbo while each team waits for "the other one" to deal with it.
Key points
Remember these essential points: they sum up the reasoning to apply to any provider, managed service or external contractor.
Always shared
No provider takes on 100% of security. There is always a customer share.
No automatic transfer
Using an external service does not transfer responsibility. The customer remains responsible for its data, access and configurations.
Variable boundaries
IaaS leaves more responsibilities to the customer than PaaS, which leaves more than SaaS.
Grey areas = vulnerabilities
If nobody knows who is responsible for an aspect, nobody takes care of it.
Fully managed modes redistribute, they do not eliminate
EKS Auto Mode, GKE Autopilot, AKS Automatic reduce operational work but leave workloads, secrets and images to you.
Regulation formalises the implicit
The Cyber Resilience Act requires vendors that integrate open source to report exploited vulnerabilities since 11 September 2026, and to comply with the rest in December 2027.
Document and test
Implicit assumptions are the source of the most serious incidents. Formalise the boundaries with a RACI matrix.
Knowledge check
Check that you have the essentials of this guide. The questions cover only what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Security: a matter of trade-offs
A new full quiz with random questions
Work again only on the questions you missed
FAQ: frequently asked questions
These short answers cover the questions asked most often about shared responsibility: the IaaS, PaaS and SaaS models, managed Kubernetes, the Cyber Resilience Act. Each one can be read on its own.