Cloud Security and the Shared Responsibility Model

What the shared responsibility model means

The shared responsibility model is a framework that assigns security tasks between a cloud provider and the organisation using its services. The provider is responsible for securing the underlying infrastructure, including physical facilities, hardware, network fabric and the virtualisation layer that separates tenants. The customer remains responsible for what it places on that infrastructure, such as its data, its configurations, its user accounts and its applications.

The exact split depends on the service model. In infrastructure-as-a-service arrangements the customer manages more of the stack, including operating systems and network rules. In software-as-a-service arrangements the provider manages most layers, leaving the customer with identity administration and data handling. Reading the provider's documentation for each service is therefore necessary, because a single account may combine several models.

A useful way to approach the model is to ask, for every control, who configures it and who is accountable if it fails. Some controls are inherited from the provider, some are shared, and some are entirely the customer's. Treating the model as a fixed rule rather than a service-specific map leads to gaps that are discovered only after an incident.

Provider duties in the service stack

Within the service stack, providers typically operate the physical data centres, power and cooling, and the controls that restrict physical access. They also maintain the hypervisor, the host networking and the hardware lifecycle, including decommissioning of storage media. Many providers publish independent assurance reports and certifications that describe these controls, which customers can review when assessing a platform.

Provider duties usually extend to the managed components a service exposes. For a managed database, the provider may patch the engine, replicate storage and manage availability zones. For a serverless function, the provider may maintain the runtime environment entirely. The degree of inherited protection rises as the customer relies on more managed components, although the provider's obligations never remove the customer's own tasks.

Provider commitments are defined in service terms and in published security documentation. These describe what the provider will and will not do, and they rarely cover the way a particular customer has configured its environment. Customers should therefore not assume that a provider certification automatically secures their own workloads, and should verify that the controls they depend on are actually in scope for the services they use.

• Physical facilities, power and environmental controls
• Hardware, hypervisor and host network infrastructure
• Managed service patching and availability
• Published compliance reports and certifications
• Service terms defining provider obligations

Customer duties for identity and data

Customers retain primary responsibility for identity and access. This includes creating accounts, assigning roles, enforcing strong authentication, reviewing permissions and removing access when people change duties or leave. Over-privileged accounts and unused credentials are among the most common weaknesses in cloud environments, and they belong to the customer to manage rather than to the provider.

Data remains the customer's responsibility in every service model. The customer decides what data is stored, where it is stored, how it is classified and who may read or modify it. Encryption choices, key management arrangements and retention periods are also customer decisions, even when the provider offers default encryption at rest. Clarity about data ownership supports both security and compliance obligations.

Identity and data controls interact closely. An identity with broad read access to sensitive storage creates exposure regardless of how well the storage itself is protected. Customers therefore benefit from reviewing identities and data flows together, mapping which accounts and services can reach which datasets, and limiting that reach to what each function genuinely requires.

Configuration risks that commonly arise

Configuration errors are one of the most frequent sources of exposure in cloud environments, and they rarely stem from a single dramatic mistake. More often, a storage location is left readable to a wider audience than intended, a network rule permits traffic from broader address ranges than required, or a default setting is kept because nobody reviewed it. Such gaps tend to accumulate quietly as teams add resources under time pressure. Because the provider's platform is generally secure by design, the risk lies in how the customer assembles and maintains the environment on top of it.

Several patterns recur across organisations. Overly permissive access policies granted for convenience are seldom removed once the original need has passed. Unencrypted data copies can persist in snapshots or development accounts that lack the controls applied to production. Management interfaces may be reachable from the public internet when they should only be accessible through a private route. Each of these conditions is easy to create and easy to overlook, which is why they deserve explicit attention in routine reviews.

Addressing these risks calls for a disciplined baseline rather than occasional clean-up. Organisations can define approved configuration standards, apply them through infrastructure-as-code templates, and check deployed resources against those standards continuously. Automated policy checks help catch drift before it becomes an incident. The aim is not to eliminate every deviation, which is unrealistic, but to make deviations visible, justified and time-bound so that responsibility for each setting remains clearly assigned.

Monitoring and audit logging practices

Monitoring and audit logging give the customer the evidence needed to understand what happens inside its own cloud environment. Activity logs record who performed which action, from where, and at what time, while resource logs capture events generated by individual services. Together they support investigation after a suspected incident, help confirm that controls operate as designed, and provide material for compliance reviews. Without them, a team may have no reliable way to reconstruct events, even when the underlying platform itself has behaved correctly.

Effective practice begins with deciding what to collect, for how long, and where it is stored. Logs should be centralised so that they cannot be altered by the same identities whose actions they record, and access to them should be restricted and itself logged. Retention periods should reflect legal, contractual and operational requirements rather than default settings alone. Alerts are most useful when tied to specific, high-value signals, such as changes to identity policies, disabled encryption, or unusual administrative sessions, rather than to every routine event.

Audit logging is only valuable if someone reviews it and acts on the results. Organisations benefit from defining who receives alerts, what response is expected, and how findings are recorded and followed up. Periodic reviews of logging coverage help identify services or accounts that are not being monitored at all. Clear ownership of these tasks prevents the common situation in which every team assumes another is watching. Documented procedures make the monitoring function consistent across changing staff and evolving infrastructure.

• Centralise logs in a location protected from modification by routine administrators
• Define retention periods based on applicable legal and contractual obligations
• Prioritise alerts for identity changes, disabled encryption and privileged sessions
• Assign named owners for reviewing alerts and recording follow-up actions
• Check periodically that every account and region is actually covered by logging

Reviewing responsibilities in contracts

Responsibilities in cloud services are shaped as much by contracts and service terms as by technical design, and they should be examined with the same care. Agreements typically describe the provider's commitments on availability, physical security, and the platform controls it maintains, along with the scope of any certifications or audit reports it offers. They also state the limits of those commitments, which is where customer obligations become concrete. Reading these documents closely reveals which duties the provider has accepted and which remain unassigned.

A useful review compares the contractual language against the internal responsibility matrix. Gaps often appear around topics such as incident notification timelines, data location, subprocessor changes, and the process for retrieving or deleting data at the end of a service. Where the contract is silent or ambiguous, the customer may be carrying risk it has not consciously accepted. Legal and security teams should therefore review terms together, and any shared-responsibility claims made in sales materials should be checked against the binding agreement.

Contract review should not be a one-time exercise performed at signing. Service terms change, new features are introduced, and organisational needs evolve, so responsibilities need periodic revalidation. Recording the outcome of each review in a shared register makes it easier to answer questions from auditors, regulators or business owners. Clear documentation of who holds each duty, and on what contractual basis, forms a foundation on which sound security decisions can be made.