Cloud Security Glossary of Terms

Cloud security operates through a dense technical and regulatory vocabulary that professionals must navigate precisely — misapplied terminology leads directly to misconfigured controls, failed audits, and exploitable gaps. This reference covers the authoritative definitions, operational scope, and classification boundaries of the core terms structuring cloud security practice in the United States. Each term is contextualized within the frameworks that govern how cloud environments are assessed, protected, and audited.

Definition and scope

The cloud security lexicon draws from standards published by the National Institute of Standards and Technology (NIST), the Cloud Security Alliance (CSA), and regulatory bodies including the Federal Risk and Authorization Management Program (FedRAMP). NIST Special Publication 800-145 formally defines cloud computing across 5 essential characteristics, 3 service models (IaaS, PaaS, SaaS), and 4 deployment models (public, private, community, hybrid) — terminology that anchors virtually every downstream security discussion.

Core definitional terms:

How it works

Cloud security terminology functions as a classification system: it assigns precise scope to threats, controls, and responsibilities so that practitioners, auditors, and regulators operate from shared definitions. The process of applying glossary terms within a security program follows a structured pattern:

  1. Identify the deployment model — Public, private, hybrid, or multi-cloud classification determines which provider security controls are inherited versus customer-managed. Hybrid environments are addressed in hybrid cloud security frameworks.
  2. Map the service model — IaaS, PaaS, and SaaS each shift the responsibility boundary. Under IaaS, the customer manages the operating system upward; under SaaS, the provider manages nearly the full stack.
  3. Apply the threat taxonomy — The CSA's Cloud Controls Matrix (CCM) organizes controls across 17 domains, each tied to specific threat categories such as data breaches, misconfiguration, and insider threats.
  4. Assign control ownership — Terms like compensating control, inherited control, and customer-responsible control specify which party implements and documents each safeguard. FedRAMP Authorization documentation mandates this assignment across all controls in NIST SP 800-53.
  5. Validate through audit language — Audit findings reference specific control identifiers (e.g., AC-2, SC-28) and glossary-defined failure modes such as misconfiguration, excessive privilege, and unencrypted data at rest.

Key technical terms within this workflow include encryption at rest and encryption in transit — both defined and required under frameworks like the Health Insurance Portability and Accountability Act (HIPAA) Security Rule and PCI DSS v4.0. Cloud encryption standards provides the technical classification of applicable algorithms and key management requirements.

Common scenarios

Compliance mapping — An organization undergoing FedRAMP authorization must align its System Security Plan (SSP) with 325 controls drawn from NIST SP 800-53 Rev 5. Each control entry references glossary-defined terms; auditors reject SSPs where terms like boundary protection, least privilege, or audit trail are applied inconsistently with NIST definitions.

Misconfiguration response — The term misconfiguration in cloud security refers specifically to a deviation from a provider's security baseline or a defined policy state — not simply an error. Cloud misconfigurations and risks documents the operational categories. When a security team receives a CSPM alert, the alert type maps to a defined misconfiguration class (e.g., publicly exposed storage bucket, overly permissive IAM policy), each requiring a distinct remediation pathway.

Incident classification — During a cloud incident, cloud incident response teams apply terms like indicator of compromise (IoC), lateral movement, and data exfiltration to classify event severity and trigger escalation thresholds. NIST SP 800-61 Rev 2 defines the 4-phase incident response lifecycle — preparation, detection and analysis, containment/eradication/recovery, and post-incident activity — and the glossary terms within each phase determine which teams are notified and what evidence is preserved.

Zero Trust implementationZero Trust Architecture (ZTA), defined by NIST SP 800-207, rests on the principle that no user, device, or network segment is implicitly trusted. Zero Trust architecture for cloud applies this vocabulary to cloud-specific access scenarios, where terms like policy enforcement point (PEP), policy decision point (PDP), and microsegmentation carry specific architectural meaning.

Decision boundaries

Precise terminology determines control applicability. Three common classification distinctions define where one security domain ends and another begins:

Shared Responsibility vs. Sole Responsibility — In IaaS environments, physical security, hypervisor security, and network fabric are provider-managed. Endpoint detection, identity governance, and data classification remain customer-managed. Conflating these boundaries is the primary audit failure mode cited in FedRAMP authorization reviews.

CASB vs. CSPM — A Cloud Access Security Broker (CASB) governs user-to-cloud traffic and applies data loss prevention (DLP) policies at the access layer. A CSPM tool continuously evaluates infrastructure configuration state. The 2 controls address different threat surfaces: CASB addresses cloud access security broker scenarios involving shadow IT and data movement, while CSPM addresses infrastructure drift.

Encryption vs. Tokenization — Encryption transforms data using a reversible cryptographic operation tied to a key. Tokenization replaces sensitive data with a non-sensitive surrogate with no mathematical relationship to the original. PCI DSS v4.0 treats the two as distinct and non-interchangeable controls for cardholder data environments.

References

📜 1 regulatory citation referenced  ·  🔍 Monitored by ANA Regulatory Watch  ·  View update log

Explore This Site