NIST SP 800-145

Classify each cloud service against the four deployment models defined in NIST SP 800-145 Section 4: Private Cloud (the cloud infrastructure is provisioned for exclusive use by a single organisation comprising multiple consumers, may be owned, managed and operated by the organisation, a third party, or some combination, and may exist on or off premises); Community Cloud (the cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organisations that have shared concerns such as mission, security requirements, policy, and compliance considerations); Public Cloud (the cloud infrastructure is provisioned for open use by the general public, may be owned, managed and operated by a business, academic, or government organisation, or some combination, and exists on the premises of the cloud provider); Hybrid Cloud (the cloud infrastructure is a composition

• service catalogue entry recording private / community / public / hybrid classification
• ownership and management record (provider-owned, consumer-owned, hybrid)
• on/off-premise location declaration and tenancy attribute (single-tenant vs multi-tenant)

• hybrid label used without documenting which components are private vs public
• community cloud declared without documenting the community membership criteria
• deployment model never re-validated after provider re-architects the service

Establish and document that a cloud service exhibits the two consumer-facing essential characteristics defined in NIST SP 800-145 Section 2: 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) and Broad Network Access (capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms such as mobile phones, tablets, laptops, and workstations). Capture evidence in the cloud service catalogue, the cloud procurement scoring sheet, and the architecture decision record that confirms self-service portal or API exists and that platform-agnostic protocols (HTTPS REST, OAuth, OIDC) are supported.

• service catalogue entry showing self-service portal or API for the cloud service
• screenshot or runbook showing consumer-initiated provisioning without provider intervention
• architecture decision record documenting standard network protocols supported (HTTPS REST + OAuth/OIDC) and client-platform independence

• service classified as cloud but provisioning still requires a provider ticket
• access restricted to a single proprietary fat client and not platform-agnostic
• no documented evidence of either characteristic in the service catalogue

Verify and document that a cloud service exhibits the Rapid Elasticity characteristic per NIST SP 800-145 Section 2: 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. Document the elasticity automation mechanism (autoscaling group, horizontal pod autoscaler, serverless concurrency), the provisioning latency target, the maximum tested scale, and the cost-control guardrails. Address the elastic threat surface (quota exhaustion, denial of wallet, runaway autoscaling) in the architecture risk register.

• autoscaling configuration evidence (autoscaling group, HPA manifest, serverless concurrency settings)
• load-test or scale-test results demonstrating elasticity behaviour
• budget alerts, quota caps, and emergency manual scale-down runbook

• autoscaling enabled with no maximum cap (runaway scaling risk)
• no budget alert or quota guardrail (denial of wallet risk)
• elasticity claimed but never tested under realistic peak load

Verify and document that a cloud service exhibits the Measured Service characteristic per NIST SP 800-145 Section 2: cloud systems automatically control and optimise resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (for example storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilised service. Capture the metering granularity, billing dimension list, usage reporting API or dashboard, and the dispute or reconciliation mechanism in the cloud service record.

• machine-readable usage report (API export or dashboard CSV) showing per-project / per-cost-centre consumption
• billing reconciliation evidence comparing invoice to metered usage
• documented dispute or reconciliation process with provider

• consolidated invoice only with no per-consumer breakdown
• no API or dashboard for live usage
• billing dispute process undocumented

Verify and document that a cloud service exhibits the Resource Pooling characteristic per NIST SP 800-145 Section 2: 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. Capture location independence in the procurement record (consumer generally has no control or knowledge over the exact location but may be able to specify location at higher abstraction such as country, state, or datacentre). Resources include storage, processing, memory, and network bandwidth. Record the data residency capability the provider exposes and the tenancy isolation guarantee in the architecture decision record.

• provider documentation of multi-tenant model and tenancy isolation guarantee (physical, hypervisor, container, logical)
• data-residency configuration record showing region or jurisdiction selection
• architecture decision record listing the location-specification granularity (country, state, region, availability zone)

• tenancy isolation model not declared by provider
• no record of selected data residency or sovereignty option
• service procured without verifying resource pooling characteristic

Establish governance that uses the NIST SP 800-145 definition as the canonical taxonomy in board reporting, regulator reporting, audit reporting, and stakeholder education. Cloud posture dashboards must aggregate the active service portfolio by service model and deployment model. Annual training for procurement officers, architects, risk owners, and audit staff must cover the five essential characteristics, three service models, and four deployment models. The CISO function must publish a quarterly cloud conformance report stating the count of services meeting all five characteristics, the count by service model, the count by deployment model, and any deviations or remediation in flight. Definition-update tracking must monitor NIST CSRC for revisions or replacement standards (such as ISO 17788 and ISO 22123 alignment) and update the canonical taxonomy accordingly.

• quarterly cloud conformance report listing portfolio by service model and deployment model
• training curriculum and completion records for procurement, architecture, risk, audit staff
• evidence of NIST CSRC / ISO 22123 monitoring and definition-update record

• no portfolio-level conformance reporting to the board or audit committee
• training never refreshed after ISO 22123 publication
• definition taxonomy not maintained as canonical reference across procurement, architecture, audit, regulator reporting

Embed the NIST SP 800-145 cloud definition into procurement standards, vendor questionnaires, and service catalogue intake. Procurement evaluation must score every candidate against (a) presence of all five essential characteristics, (b) declared service model SaaS PaaS IaaS, (c) declared deployment model private community public hybrid. Procurement contracts and statements of work must include the cloud-definition conformance clause, the right-to-audit conformance evidence, and the obligation to notify the consumer of any change to service-model or deployment-model declaration. The service catalogue must record the cloud-definition triple (characteristics, service model, deployment model) for every active service.

• procurement evaluation scoring sheet covering all five characteristics + service model + deployment model
• vendor questionnaire and signed cloud-definition conformance clause in contract or SOW
• service catalogue showing the cloud-definition triple for every active service

• procurement accepts vendor `cloud' marketing label without scoring characteristics
• no contractual notification clause for service-model / deployment-model change
• service catalogue does not record cloud-definition attributes

Classify each cloud service the organisation consumes against the three service models defined in NIST SP 800-145 Section 3: Software as a Service (SaaS) where the consumer uses the provider's applications running on a cloud infrastructure, accessible from various client devices through either a thin client interface such as a web browser, or a program interface, and the consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities with the possible exception of limited user-specific application configuration settings; Platform as a Service (PaaS) where the consumer deploys onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider, and the consumer does not manage or contro

• service catalogue entry recording SaaS / PaaS / IaaS classification
• shared responsibility matrix aligned to declared service model
• provider compliance package consistent with service model (SOC 2, ISO 27001, FedRAMP, IRAP, etc.)

• service classified inconsistently between procurement, architecture, and audit
• shared responsibility matrix absent or generic
• service model declared but underlying compliance package does not cover the right scope