A boundary, not a handoff
Moving a system to the cloud does not transfer all of its security work to the provider. The shared responsibility model describes a boundary: the provider secures the services and underlying infrastructure it operates, while the customer secures the parts it configures, deploys and uses. The exact boundary depends on the service. Renting a virtual machine leaves a team with more to manage than using a hosted application.
A useful starting distinction is security of the cloud versus security in the cloud. The provider typically protects its physical facilities, hardware and core service infrastructure. The customer typically decides who can access its account, which data to store, and how to configure the resources it creates. These are broad categories, not a substitute for a service’s terms and documentation. Some tasks also involve both parties: a provider may offer encryption tools, for example, while the customer chooses settings and controls access to keys.
How the boundary changes by service type
With infrastructure as a service (IaaS), a provider supplies building blocks such as virtual machines, storage and networking. It maintains the physical hosts and the platform that runs those resources. A customer running a virtual machine generally manages its operating system, installed software, application code, firewall rules, user access and data. An unpatched application on that machine remains a customer problem even though the machine runs in a provider’s data center.
With platform as a service (PaaS), the provider also manages more of the runtime environment, such as a managed database engine or application hosting platform. That reduces some maintenance work, but the customer still controls how the service is used. Database permissions, application code, data classification and connections to other systems need attention. With software as a service (SaaS), the provider operates the application itself. The customer’s main responsibilities often include managing users, choosing sharing settings, reviewing integrations and deciding what information belongs in the service.
What customers commonly need to secure
Identity is a good place to begin because one account can provide access to many resources. Teams should assign access according to each person’s role, remove access when it is no longer needed and protect privileged accounts with available authentication controls. They should also consider non-human identities, such as service accounts and application credentials. A provider can supply an identity system, but it cannot reliably decide which employee or application should see a particular customer dataset.
Configuration and data handling matter just as much. A storage service may support private access by default or provide controls to restrict it, yet a customer can still expose data through an unsuitable setting or an overly broad permission. Teams should decide what data they collect, where they place it, who can retrieve it and how long they retain it. Backups, recovery testing, logging and alert review also need assigned owners. A feature being available does not mean it has been enabled, configured appropriately or checked when something goes wrong.
Turn the model into a working checklist
Start with an inventory of the services your team actually uses. For each one, record the service type, the data it holds, the people and applications with access, and the settings your team controls. Then list the security tasks that matter for that service: updates, access reviews, network restrictions, backups, logging and recovery. Mark each task as provider-managed, customer-managed or shared, and name a person or team responsible for the customer side.
Consider a small website hosted on a managed platform with a managed database. The platform may handle host maintenance and parts of the runtime, while the team remains responsible for its application code, database users, secrets and data access rules. Its cloud storage for uploaded files may have yet another set of settings. Looking at each component separately makes the division clearer than applying one label to the entire website. Revisit the checklist when you add a service, change an integration or move from a virtual machine to a managed offering.
The key question to keep asking
The shared responsibility model is most useful when it prompts a concrete question: “Which security decisions can we make for this service?” Those decisions are usually the customer’s to understand and manage, even when the provider supplies the tools. Conversely, customers should not assume they can inspect or maintain infrastructure that the provider operates.
For any particular product, check its service documentation and your organization’s agreement before drawing a firm boundary. The goal is not to memorize a universal chart. It is to make sure every important task has an owner, especially at the points where provider features meet customer configuration.
