Cloud Security Controls: Types, Frameworks & Checklist

Key Takeaways

• A cloud security control has four attributes: a function, a class, an owner, and an evidence source. A framework line missing all four states a requirement, and the requirement is not the control.
• Controls sort along two axes at once. By function they are preventive, detective, corrective, deterrent, or compensating. By class they are administrative, technical, or physical.
• Frameworks are libraries of the same requirements under different identifiers. Encrypting data at rest is CEK-03 in the CSA Cloud Controls Matrix and SC-28 in NIST SP 800-53 Rev. 5.
• One control set scales by impact instead of multiplying. FedRAMP selects from a single catalog into Li-SaaS, Low, Moderate, and High baselines, then attaches its own parameter values.
• Orca checks cloud configurations and policies against more than 150 industry and regulatory frameworks, so a control set carries live evidence instead of a quarterly screenshot.

A cloud security control is a mechanism that makes one security requirement true in a running environment. Default encryption on a storage account is a control. A policy that rejects a public bucket at deployment time is a control. The framework line saying data must be protected at rest states the requirement those two controls satisfy.

The distinction sounds academic and decides whether a control set works. A spreadsheet row carries a requirement and an identifier. It does not say which team changes the setting, which log proves the setting held overnight, or what happens when a system cannot support it.

This guide covers the five functional types and three classes of control. It maps the domains a control set spans, traces one control through four framework libraries, and sets out an implementation sequence. The checklist near the end is written to run against a live environment. A final section covers how deployment model changes what you owe.

What Are Cloud Security Controls?

Security controls for cloud computing are the mechanisms that turn a stated security requirement into an enforced condition. Each one does a specific job in a specific place. It blocks an action, records it, reverses it, discourages it, or substitutes for a control the system cannot support. Requirements describe an outcome, and controls produce it.

Four attributes separate a control from a line in a compliance spreadsheet:

• Function. What the control does at the moment it fires, covered in the next section.
• Class. Whether a person, a system, or a facility enforces it.
• Owner. The named team that can change the setting and is answerable when it drifts.
• Evidence source. The log, API response, or configuration snapshot that proves the control held.

Mapping to a framework does not produce a control set, which is the point an audit surfaces first. A single requirement usually decomposes into several controls with different owners. Protecting data at rest becomes an account-level encryption default owned by the platform team. Key management owns the rotation schedule, and identity owns the access policy on the key itself.

NIST’s glossary names the controls you do not build yourself. A common control is “a security or privacy control that is inherited by multiple information systems or programs.” In a public cloud the physical, facility, and hypervisor controls all arrive that way. The rest of a cloud security program sits on top of that inherited base.

Types of Cloud Security Controls

Different types of cloud security controls sort along two axes at the same time, and a usable control set names both for every entry. Function tells you what happens when the control fires. Class tells you what enforces it, which in turn tells you how fast it can fail without anyone noticing.

By Function: Preventive, Detective, Corrective, Deterrent, and Compensating

• Preventive controls stop the action before it happens. A service control policy that denies a region or an API call across an organization is preventive. So is a deployment policy that rejects a template carrying an open security group.
• Detective controls find the condition after it exists. A configuration rule that flags a storage bucket the moment its public access block is removed is detective. It changes nothing on its own.
• Corrective controls return the environment to its intended state. An event-driven function that re-applies the public access block and notifies the owning team is corrective, and its evidence is the invocation record.
• Deterrent controls raise the perceived cost of an action without blocking it. A login banner, a break-glass workflow that names the requester publicly, and session recording on privileged access all work by being visible.
• Compensating controls stand in for a control you cannot run. NIST’s glossary calls one a control employed “in lieu of a recommended security control in the low, moderate, or high baselines that provides equivalent or comparable protection.” A web application firewall rule in front of a legacy service you are not allowed to patch is the cloud version.

By Class: Administrative, Technical, and Physical

Administrative controls are written rules and human procedures: an access review, an approval gate, a documented standard for how a production account gets created. Technical controls are enforced by a system and hold between reviews without anyone acting. Physical controls protect facilities and hardware. In public cloud the physical class is inherited whole from the provider, so the entry in your set is the provider’s attestation.

The class mix decides how a control set fails. Administrative controls degrade quietly, because a gap opens between the written rule and the running configuration the day after a review. A set weighted toward administrative controls looks complete on paper and drifts in production. The migration path for a maturing program runs from administrative toward technical wherever the platform supports it.

Key Security Domains in Cloud Environments

Control sets get organized by domain so that ownership and evidence stay legible. These five domains are where cloud controls live, and each one exists for a different reason.

Identity and Access

Identity is the layer every other control depends on. An identity with permission to change a control can disable it faster than any detective control reports it. Controls here define who and what can act, under which conditions, and for how long. Role-based access control supplies the structure, and least privilege supplies the sizing rule.

Data Protection

Data outlives the workload that created it, so controls here have to survive the deletion of everything around them. That means encryption defaults set at the account level, key policies held separate from resource policies, and a classification produced by a scan. Data security posture management supplies the discovery half, and data loss prevention supplies the egress half.

Network Boundaries

Network controls decide reachability, and reachability decides how far a single compromised workload gets. The cloud version turns on explicit paths: which routes to the internet exist, which services are reachable privately, and which flows you can reconstruct afterward. Network segmentation is the organizing control, and flow records are its evidence source.

Workload and Compute

Workload controls govern what runs and what it is allowed to do while running. Image provenance, the permissions attached to a workload’s own role, and the state of the operating system underneath it all belong here. This is where cloud misconfigurations surface, because every workload inherits settings from a template someone wrote once and rarely revisits.

Logging and Monitoring

Logging is the domain that makes the other four provable. Every control in the set should name the log entry or API response that demonstrates it fired. That artifact has to exist before the control counts as implemented. Audit logs carry the control-plane record, and their own controls cover coverage, retention, and tamper resistance.

Cloud Security Controls Frameworks and Standards

A cloud security controls framework is a library of requirements with identifiers attached. The same requirement often appears across multiple frameworks under different identifiers and proof obligations, which is why treating a framework as the implementation itself usually produces an unusable control set.

Which standard applies to your organization is a separate question, covered in cloud security standards for compliance. Here, the focus is how the major control libraries structure the requirements themselves.

The CSA Cloud Controls Matrix v4.1 includes 207 controls across 17 cloud-specific domains. NIST SP 800-53 Rev. 5 organizes security and privacy controls into 20 families, while CIS Benchmarks provide prescriptive configuration recommendations for specific products and services. ISO/IEC 27002:2022 adds detailed controls for organizations operating an ISO/IEC 27001 management system.

The crosswalk below traces one requirement, encrypting data at rest, through all four.

Control library	What it publishes	Where “encrypt data at rest” lands	What it asks you to produce
CSA Cloud Controls Matrix v4.1	207 controls across 17 cloud-specific domains, with mappings to other standards	CEK-03, Data Encryption, in the Cryptography, Encryption and Key Management domain	A questionnaire answer plus the provider and customer split for that control
NIST SP 800-53 Rev. 5	20 control families spanning security and privacy for any system type	SC-28, Protection of Information at Rest, with enhancement SC-28(1), Cryptographic Protection	An implementation statement and a matching assessment procedure
CIS Benchmarks	Prescriptive configuration recommendations for named products and services	A per-service setting, such as the default encryption option on one storage service	A pass or fail result against that named setting
FedRAMP	Baselines selected from the SP 800-53 catalog for federal impact levels	The same 800-53 control, selected into a baseline with FedRAMP parameter values	Ongoing monitoring evidence rather than a point-in-time answer

Choosing the Right Control Framework

Two practical conclusions follow from the comparison above. First, pick one library as your system of record and crosswalk the others into it. Four parallel control sets drift apart as soon as one framework is updated. Second, choose that system of record based on the job it needs to do:

• Setting-level correctness on a named service. This is the question CIS cloud security controls are built to answer.
• Capability-level implementation by a system. This is where NIST cloud security controls fit, with an assessment procedure attached.
• Responsibility splits in a shared cloud. The Cloud Security Alliance Cloud Controls Matrix treats the provider/customer responsibility split as a first-class attribute of every control.

Frameworks such as NIST CSF operate at a different level. They define security outcomes rather than implementation controls, so they complement rather than replace the control libraries above.

Best Practices for Implementing Cloud Security Controls

Implementation runs in a sequence, and taking the steps out of order produces control sets that go unmaintained. Start with what you already have, encode what remains, and verify continuously.

Inherit before you build. Record the controls the provider operates as inherited, naming the provider’s attestation as the evidence source. Physical security, hypervisor isolation, and hardware lifecycle controls all land there. Rewriting them as if you operate them inflates the set and buries the controls that need attention, which is what a structured cloud security assessment is for.

Encode what remains as policy. Wherever the platform supports it, encode controls as machine-evaluated policy rather than relying only on written requirements. Open Policy Agent covers admission and deployment decisions, and infrastructure as code scanning covers the template before it ships. Give each encoded control the identifier it carries in your system of record, so a failure maps back without a translation step.

Verify on the environment’s clock. Controls are assertions about a system that changes hourly, so verification cadence has to match the change rate and not the audit calendar. Continuous posture checking through CSPM is what closes that gap on deployed state. FedRAMP put the principle plainly while designing its next-generation program: “Continuous evidence of what is happening is stronger than a policy saying it should happen.”

Cloud Security Controls Checklist

This cloud security controls checklist is written as statements you can confirm or refute against a live environment, grouped by the same five domains above. A statement you cannot check with a query is a policy, not a control.

Identity and access

• The root or global administrator account has multi-factor authentication enforced and carries no long-lived access keys.
• Permissions attach to groups or roles, and no policy is attached directly to an individual user.
• Every non-human identity has a recorded owner and an expiry date.
• Cross-account trust policies name specific principals and conditions instead of a wildcard.

Data protection

• Default encryption is set at the account level, so a new resource inherits it without a template change.
• Key deletion requires a mandatory waiting period, and key policies are maintained separately from resource policies.
• Every store holding regulated data carries a classification a scan produced.
• Public access blocks are enforced at the account level, not resource by resource.

Network boundaries

• Every route to the internet passes a control you can name, and default routes are documented.
• Security group rules reference other groups or prefix lists, not open address ranges.
• Private connectivity to managed services is in place wherever the service supports it.
• Flow logging is enabled for every network you would need to reconstruct after an incident.

Workload and compute

• Images come from a registry you control, and build provenance is recorded for each one.
• No workload runs with a role that permits it to modify its own permissions.
• Instance metadata access requires session-oriented requests, the setting AWS documents as defense in depth against server-side request forgery.
• Patch state for every running workload is queryable without logging into the workload.

Logging and monitoring

• Control-plane logging is enabled in every region and every account, including unused ones.
• Log destinations are write-once for the full retention period the policy states.
• A log delivery failure raises an alert, because a silent stop is the failure mode that matters.
• Every control in the set names the log entry or API response that proves it fired.

How Controls Vary by Deployment Model

Two variables move when the deployment model changes: who implements the control, and how strong the implementation has to be. Missing the first produces gaps with no owner. Missing the second applies one uniform strength to systems whose failures carry very different consequences.

FedRAMP handles the second variable in a way worth copying. Its baselines pull FedRAMP cloud security controls from the SP 800-53 catalog into four impact levels: Li-SaaS, Low, Moderate, and High. The stated reasoning is that services carry different requirements for confidentiality, integrity, and availability. One highest-risk profile applied to all of them serves neither agencies nor providers.

That model is being rebuilt, and the dates matter to anyone citing it:

• FedRAMP 20x is in Phase 3, with final certification rules for Class A, Class B, and Class C.
• Class B covers the Li-SaaS and Low baselines, and Class C covers Moderate. Class D, for High, is still ahead.
• FedRAMP stops accepting new Rev5 certifications on 11 June 2027.

Controls Across IaaS, PaaS, and SaaS

The service model sets the boundary of what you can implement. Under IaaS you own the operating system, the network configuration, and everything above them. Every technical control above the hypervisor is yours to build. Under PaaS the provider absorbs the runtime, and your set shifts toward identity, data, and configuration of the managed service.

Under SaaS almost nothing at the infrastructure layer is yours. What remains is tenant configuration, identity federation, and data handling, which is the territory SaaS security posture management covers. The shared responsibility model draws the line for each service model, and the line moves with every managed service you adopt.

Public, Private, and Hybrid Deployments

Deployment model changes where the control runs and who can attest to it. In a private cloud the physical and facility classes return to you, together with the hardware lifecycle controls a public provider carried. The set grows even though the requirements did not change.

Hybrid estates carry the harder problem. One requirement now needs two implementations, on two platforms, with two evidence sources that have to reconcile. Treat it as one entry with two implementation records, or the set drifts apart at the seam.

How Orca Turns Cloud Security Controls Into Continuous Evidence

No platform decides which controls you owe. That answer comes from your contracts, your regulators, and your own risk decisions. A platform closes the gap between defining a control and proving it still holds, which is where control sets often fail between audits. The Orca Cloud Security Platform continuously checks cloud configurations and policies against more than 150 industry and regulatory frameworks, backed by more than 2,500 configuration controls across authentication, data protection, logging and monitoring, network configuration, Kubernetes, and system integrity. Agentless SideScanning™ reads workload data from runtime block storage without deploying agents, so coverage does not depend on which teams completed an agent rollout.

Findings are correlated in Orca’s Unified Data Model, which connects every asset, configuration, identity, network path, and data store. That context helps identify the owner, understand the impact of a failed control, and prioritize remediation without a separate investigation. Get a Demo to see your control coverage across your own cloud.

Frequently Asked Questions about Cloud Security Controls