At only seven pages, SP 800‑145 is one of the shortest NIST Special Publications ever issued, but its influence is enormous. Published in 2011, it established the vocabulary and taxonomy that the entire cloud computing industry uses to this day (National Institute of Standards and Technology [NIST], 2011).
Document Background
By 2009, the term “cloud computing” had become a marketing catch‑all. Every vendor had a different definition, and government agencies struggling to adopt cloud services had no common vocabulary for procurement, risk assessment, or policy. NIST assembled a working group led by Peter Mell and Timothy Grance to produce a concise, vendor‑neutral definition (NIST, 2011).
The result, SP 800‑145, was finalized in September 2011 after two years of public comment and revision. It does not prescribe how to implement cloud computing or evaluate cloud providers. Its purpose is narrower and more fundamental: to define what cloud computing is, so that everyone in a conversation about it is talking about the same thing.
SP 800‑145 is referenced in federal acquisition regulations, FedRAMP authorization processes, and countless commercial contracts. When a request for proposal says “cloud services,” this document defines what that phrase means. It is also the definition used in most academic textbooks and certification exams, including CompTIA Security+, CCSP, and AWS certifications.
The Five Essential Characteristics
According to SP 800‑145, a system qualifies as cloud computing only if it exhibits all five of the following characteristics. If even one is missing, the system may be a hosted service or a managed service, but it is not cloud computing as NIST defines it (NIST, 2011).
| Characteristic | Description |
|---|---|
| On‑Demand Self‑Service | A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider. You click a button or call an API, and the resource appears. |
| Broad Network Access | Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations). Cloud services are not locked to a specific device or proprietary interface. |
| Resource Pooling | The provider's computing resources are pooled to serve multiple consumers using a multi‑tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. The customer generally has no control or knowledge over the exact location of the provided resources. |
| Rapid Elasticity | Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time. |
| Measured Service | Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer. |
Students frequently confuse rapid elasticity with on‑demand self‑service. Self‑service is about who provisions the resource (the consumer, without contacting the provider). Elasticity is about how much can be provisioned and how quickly it scales. A system could be self‑service without being elastic (fixed capacity, but you provision it yourself), or elastic without being self‑service (the provider scales it for you after you submit a ticket).
The Three Service Models
SP 800‑145 defines three service models that describe the level of abstraction at which the consumer interacts with the cloud. Each model shifts the boundary of responsibility between the provider and the consumer (NIST, 2011).
| Service Model | What the Consumer Gets | Consumer Manages | Example |
|---|---|---|---|
| Infrastructure as a Service (IaaS) | Processing, storage, networks, and other fundamental computing resources. The consumer can deploy and run arbitrary software, including operating systems and applications. | OS, middleware, runtime, applications, data | AWS EC2, Microsoft Azure VMs, Google Compute Engine |
| Platform as a Service (PaaS) | The capability to deploy consumer‑created or acquired applications onto the cloud infrastructure using programming languages, libraries, services, and tools supported by the provider. | Applications and data | Heroku, Google App Engine, AWS Elastic Beanstalk |
| Software as a Service (SaaS) | The capability to use the provider's applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface. | User‑level configuration only | Google Workspace, Microsoft 365, Salesforce |
The key insight is that as you move from IaaS to PaaS to SaaS, the consumer gives up control in exchange for convenience. An IaaS customer manages almost everything above the hypervisor. A SaaS customer manages almost nothing. Security responsibility shifts accordingly: the more the provider manages, the more the provider is responsible for securing (NIST, 2011).
SP 800‑145 does not use the phrase “shared responsibility,” but it establishes the conceptual foundation for it. Every major cloud provider's shared responsibility model (AWS, Azure, GCP) maps directly back to this three‑tier service model and the question of who manages what at each layer.
The Four Deployment Models
In addition to how cloud services are delivered (service models), SP 800‑145 defines four models for how cloud infrastructure is deployed and who has access to it (NIST, 2011).
-
Private Cloud
The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises.
-
Community Cloud
The cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, compliance considerations). It may be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination of them.
-
Public Cloud
The cloud infrastructure is provisioned for open use by the general public. It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider. AWS, Azure, and GCP are all public clouds.
-
Hybrid Cloud
The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability. A common pattern is keeping sensitive data in a private cloud while using a public cloud for less sensitive workloads.
Note that “private cloud” does not mean “on‑premises server room.” A private cloud must still exhibit the five essential characteristics (self‑service, elasticity, measured service, etc.) to qualify as cloud computing. A dedicated server in a closet that requires a sysadmin to provision each VM is not a private cloud under this definition, even if the vendor calls it one.
Why This Definition Matters
SP 800‑145 matters because vocabulary precision matters. When an organization says it is “moving to the cloud,” SP 800‑145 forces the follow‑up questions: Which service model? Which deployment model? Does the solution actually meet the five essential characteristics, or is it just a hosted service with a cloud label?
For security professionals specifically, the definition establishes the framework for thinking about where risk lives. In an IaaS deployment, the organization is responsible for patching the operating system and configuring network controls. In a SaaS deployment, those responsibilities belong to the provider. Misunderstanding the service model leads to misunderstanding who owns the risk, and that gap is where breaches happen.
For students preparing for certification exams (CompTIA Security+, CCSP, AWS Cloud Practitioner, and others), SP 800‑145 is the source material that exam writers draw from. The five characteristics, three service models, and four deployment models appear on virtually every cloud‑related certification exam.
Although SP 800‑145 has not been revised since 2011, its definitions have proven remarkably durable. Newer concepts like serverless computing (Functions as a Service) and container orchestration fit within the existing taxonomy rather than breaking it. Serverless, for example, is a refinement of PaaS, not a new service model. The framework scales.
Citing This Document (APA 7)
SP 800‑145 is cited as a group‑author technical report in APA 7 format. Note that the authors (Mell and Grance) are sometimes cited in older references, but APA 7 convention for government publications uses the agency as author.
- Reference list entry
- National Institute of Standards and Technology. (2011). The NIST definition of cloud computing (NIST Special Publication 800‑145). U.S. Department of Commerce. https://doi.org/10.6028/NIST.SP.800-145
- First in‑text citation
- (National Institute of Standards and Technology [NIST], 2011)
- Subsequent in‑text citations
- (NIST, 2011)
- Narrative citation
- The National Institute of Standards and Technology (NIST, 2011) identified five essential characteristics that distinguish cloud computing from traditional hosting.
References
- National Institute of Standards and Technology. (2011). The NIST definition of cloud computing (NIST Special Publication 800‑145). U.S. Department of Commerce. https://doi.org/10.6028/NIST.SP.800‑145