How do cloud service models change who secures your data and storage?

In cloud computing, who secures what depends on the service model. With infrastructure as a service you manage the operating system, applications and data. With platform as a service you manage applications and data. With software as a service you mostly manage who has access and how it is configured. In every model, you stay responsible for your data.

What are the models?

NIST SP 800-145 defines cloud computing as a model for on demand network access to a shared pool of configurable resources, such as networks, servers, storage, applications and services, that can be rapidly provisioned and released with minimal management effort or provider interaction. The model has five essential characteristics, three service models and four deployment models. The service models are software as a service, platform as a service and infrastructure as a service.

The stack works like a ladder. At the infrastructure level the provider runs the facility, network, storage hardware and virtualization, and you run what you install. At the platform level the provider also runs the runtime, and you run your code and data. At the software level the provider runs the application, and you decide who uses it, what they can reach and which settings are on.

What does NIST say about responsibility?

NIST SP 800-144, its guidance on public cloud security and privacy, says plainly that the responsibilities of the organization and of the cloud provider vary depending on the service model, and that organizations consuming cloud services must understand the delineation of responsibilities and what it implies for security and privacy. It also says that moving to a public cloud transfers responsibility and control to the provider over information and system components that used to be under direct control, which makes the organization dependent on the provider's cooperation for activities that span both parties, such as continuous monitoring and incident response.

And a caution on evidence: assurances from the provider, or from a review entity the provider pays for, should be verified through independent assessment when possible.

Where does storage go wrong?

Storage is where the customer side of the model is most visible, because misconfiguration is a customer action. The recurring problems are access settings that are broader than intended, such as public read; credentials with wide permissions stored in code or shared; no encryption policy or unclear key ownership; no logging of who accessed what; and forgotten copies in old projects or accounts.

None of these are provider failures. They are decisions made quickly by people who had permission to make them. Cloud makes creating storage a single command, so the speed is the risk.

What should a provider evaluation cover?

Ask what the provider is responsible for in the service you will use, in writing. Ask for independent audit reports and read their scope, since a report may cover only some services or regions. Ask about data location, encryption options and key control, logging you can access, how deletion works, and how incidents are communicated. Plan how you would leave: formats, tools and costs for exporting your data.

A constructed example

A team stores customer documents in an object storage service and in a hosted collaboration tool. For the object storage, an infrastructure style service, the team owns bucket policies, encryption settings, key management and logging. A review finds one bucket readable by any authenticated user of the cloud platform and no access logs. For the collaboration tool, a software service, the provider runs everything under the hood. The team's duties are sign in controls, sharing settings and who the administrators are, and the review finds 14 externally shared folders with no expiry. Different services, same lesson: find your side of the line, then check it.

How to check or apply this

1. List your cloud services and mark each as infrastructure, platform or software as a service.
2. For each, write what the provider handles and what you handle, using the provider's own documentation.
3. For storage, review access policies, public access settings, encryption and key ownership, and turn on access logging.
4. Remove long lived broad credentials and use short lived, narrowly scoped access.
5. Review third party audit reports for scope and date, and note the controls the report expects you to implement yourself.
6. Check external sharing in software services, and set expiry where the tool allows.
7. Write an exit plan for each critical service: export format, tools, time and cost.
8. Repeat reviews on a schedule, and when you add a service.

Quick check

Sources

• NIST SP 800-145, The NIST Definition of Cloud Computing
• NIST SP 800-144, Guidelines on Security and Privacy in Public Cloud Computing
• NIST SP 800-144 full text (PDF)

Last reviewed: 18 October 2026.