Shared Responsibility in the Cloud: Know Which Layer You Own

Moving to the cloud changes who operates each technology layer.

It does not make security, reliability, privacy, backup, or access somebody else's problem in general. The provider owns defined parts of the service; the customer owns how the service is configured and used.

Shared responsibility is a layer-by-layer contract whose boundary changes with the service model.

Unowned assumptions form the gap where many cloud incidents begin.

A concrete example: patching a virtual machine

A cloud provider patches the physical host and hypervisor beneath a virtual machine.

The customer still runs an operating system inside that VM. If the customer leaves its internet-facing web server unpatched, the provider's host security does not remove the application vulnerability.

With a managed application platform, the provider may patch more of that runtime layer.

Security of the cloud

Providers commonly describe their role as security of the cloud.

It may include:

facilities,
physical servers,
hardware disposal,
backbone networks,
hypervisors,
and managed-service infrastructure.

Exact commitments appear in service documentation, contracts, and compliance reports.

Security in the cloud

Customers commonly own security in what they deploy:

identities,
permissions,
data classification,
application code,
network exposure,
configuration,
encryption choices,
and user behavior.

The dividing line moves, but these business decisions cannot be outsourced blindly.

IaaS boundary

With IaaS, the provider manages:

facilities,
hardware,
and virtualization.

The customer normally manages:

guest operating system,
patches,
applications,
host firewall,
workload identity,
data,
and backup configuration.

IaaS gives flexibility because the customer owns more layers.

PaaS boundary

With PaaS, the provider often also manages:

operating system,
language runtime,
process supervision,
and deployment platform.

The customer still owns:

application code,
dependencies,
routes,
secrets,
data,
authorization,
and configuration.

The provider cannot determine whether your endpoint exposes another user's record.

SaaS boundary

With SaaS, the provider operates the complete application stack.

The customer still governs:

user accounts,
administrator roles,
single sign-on,
shared links,
data entered,
retention choices,
integrations,
and exports.

A misconfigured public document is a customer-side incident even when the SaaS platform is functioning correctly.

Managed databases

The provider may handle:

host patching,
replication,
failover,
and backup machinery.

The customer owns:

schema,
query behavior,
credentials,
network rules,
retention,
restore objectives,
and data correctness.

The service can faithfully replicate an accidental deletion.

Containers and orchestration

Responsibilities can split further:

provider secures control-plane infrastructure,
customer configures cluster permissions,
provider patches managed nodes in some modes,
customer patches self-managed nodes,
customer secures container images and workloads.

Read the exact service mode rather than assuming "managed Kubernetes" has one boundary.

Serverless functions

The provider manages servers, runtime patching, and scaling.

The customer owns:

function code,
dependency vulnerabilities,
trigger permissions,
secrets,
input validation,
concurrency settings,
and downstream effects.

No server management does not mean no security configuration.

Data

Customers decide what data enters the cloud and how it is classified.

Responsibilities include:

legal basis,
residency,
access,
retention,
deletion,
backup,
masking,
and incident notification.

Provider encryption features support controls; they do not define the organization's data policy.

Identity

Cloud accounts and privileges are nearly always a major customer responsibility.

Use:

federation,
multi-factor authentication,
least privilege,
short-lived roles,
access review,
and protected emergency accounts.

The provider supplies IAM mechanisms; customers create the policy.

Configuration

Many cloud breaches come from legitimate features configured unsafely:

public storage,
broad firewall rules,
unrestricted roles,
exposed management interfaces,
disabled logs,
or unencrypted backups.

Configuration should be versioned, reviewed, scanned, and continuously evaluated.

Availability

Providers publish availability commitments for services.

Customers choose:

number of zones,
regional design,
capacity,
retries,
dependency fallback,
backup,
and disaster recovery.

Running one instance in one zone does not inherit the resilience of the provider's global cloud.

Backup

Provider durability does not equal customer backup.

Customers need protection against:

deletion,
corruption,
ransomware,
account compromise,
and retention mistakes.

Confirm who creates backups, who can delete them, where they live, and how restoration is tested.

Compliance

Provider certifications cover specific services, regions, periods, and controls.

Customers must map their responsibilities:

configuration,
evidence,
data handling,
access review,
application controls,
and vendor governance.

Using a compliant cloud service does not make every workload compliant automatically.

Support and incident response

The provider investigates its infrastructure and service faults.

The customer investigates:

account activity,
workload logs,
application behavior,
identity compromise,
and data impact.

Incident plans should define escalation paths and evidence available from both sides.

Third parties and marketplaces

Marketplace images, SaaS add-ons, and managed partners introduce another responsibility boundary.

Clarify:

who patches,
who receives data,
which contract applies,
where support begins,
and how the component is removed.

"Available in the cloud console" does not mean operated by the cloud provider.

Building a responsibility matrix

For every service and control, record:

Area	Provider	Customer	Evidence
Physical host patching	Yes	No	Provider report
Guest OS patching	No	Yes	Patch dashboard
Database restore test	Tooling	Procedure and result	Recovery record
User access review	Mechanism	Policy and review	IAM report

Avoid vague labels such as "shared" without describing each action.

Responsibility changes over time

Upgrading from a VM database to a managed database moves some tasks to the provider.

New features, service modes, and contracts can move boundaries again. Review responsibility when architecture changes, not only during initial cloud adoption.

Ownership must follow the current deployed service.

Knowledge check

What is the difference between security of and security in the cloud?
How does customer responsibility change from IaaS to PaaS?
Why does provider durability not replace customer backup?
Which responsibility remains when using SaaS?
What should a responsibility matrix add beyond the word shared?

The one idea to remember

Cloud services divide operation by layer. The provider protects the infrastructure and managed capabilities it promises; the customer still owns identities, data, configuration, application behavior, resilience choices, and evidence for every control on its side of the boundary.