Cloud Security Controls: Categories, Examples and How to Prove Them

Short answer: Cloud security controls are the safeguards you configure to protect your cloud accounts, workloads and data. They fall into eight practical categories: identity and access, network, data protection, logging and monitoring, configuration, vulnerability management, backup and recovery, and incident response. The provider secures the infrastructure, but configuring these controls is your job.

Related guides:

• ISO 27017 cloud security controls explained
• Cloud migration security checklist
• Multi-cloud security

Key takeaways

• Under the shared responsibility model, identities, access policies, configuration and data are always the customer's to secure, whichever cloud you use.
• Start with identity, public exposure, encryption, logging and configuration drift, where one mistake exposes the most.
• Each control should be preventive (stops a problem), detective (spots it) or corrective (fixes it). Strong programmes pair a preventive guardrail with a detective check for the same risk.
• One cloud control usually satisfies several frameworks at once. Map it once to ISO 27001, SOC 2, NIST SP 800-53 and the CIS Controls instead of maintaining separate lists.
• Auditors test whether a control operated over time, not whether it was switched on once. Keep configuration exports, scan history and review records.

What are cloud security controls?

Cloud security controls are the technical and procedural safeguards that protect the confidentiality, integrity and availability of what you run in the cloud.

The provider protects the physical data centres, hardware and the virtualisation layer. You protect what you build on top. AWS describes this split as "security of the cloud" versus "security in the cloud", and Microsoft's shared responsibility documentation states that for every deployment type, you own your data and identities. The NSA puts the same point first in its Top Ten Cloud Security Mitigation Strategies: uphold the shared responsibility model.

Controls are usually described by what they do. Our guide to types of security controls covers these in more depth.

Type	What it does	Cloud example
Preventive	Stops an unsafe action or configuration	An organisation policy that blocks public storage buckets
Detective	Finds a problem after it happens	An alert when audit logging is turned off
Corrective	Restores a safe state	Automatic remediation that re-enables encryption, or a restore from backup

What are the main categories of cloud security controls?

Most cloud control frameworks, including the Cloud Security Alliance's Cloud Controls Matrix (overview), group controls into similar domains. For a SaaS or HealthTech team, eight categories cover what auditors and customers ask about.

Category	Example controls
1. Identity and access	Single sign-on with MFA for all console and CLI access, no daily use of root or global admin, least-privilege roles, temporary credentials for workloads instead of long-lived keys, quarterly access reviews
2. Network	Separate accounts or projects for production and non-production, databases in private subnets, no management ports open to the internet, restricted egress
3. Data protection	Encryption at rest by default, TLS for data in transit, managed keys with limited key administrators, public access blocked on storage, data classified by sensitivity
4. Logging and monitoring	Control-plane audit logs enabled in every account and region, logs sent to a separate archive with deletion restricted, alerts on high-risk events such as root sign-in or logging changes
5. Configuration management	A written baseline (for example the CIS Benchmarks), infrastructure as code with peer review, guardrail policies, continuous drift detection
6. Vulnerability management	Scanning of VM images, containers and dependencies, patching SLAs by severity, secrets scanning in code and pipelines
7. Backup and recovery	Automated backups, backups stored in a separate account or with immutability, restore tests on a schedule
8. Incident response	A cloud-specific runbook, a break-glass account, the ability to isolate a workload and revoke credentials quickly

AWS's IAM security best practices are a good reference for category 1, including federation, temporary credentials, phishing-resistant MFA and least privilege. For SaaS tools such as Microsoft 365 and Google Workspace, CISA's Secure Cloud Business Applications (SCuBA) project publishes secure configuration baselines you can adopt.

What do these controls look like in AWS, Azure and Google Cloud?

Each provider offers native services for the same control categories. The names differ, but the job is the same.

Control	AWS	Microsoft Azure	Google Cloud
Central identity and SSO	IAM Identity Center	Microsoft Entra ID	Cloud Identity
Audit logging	CloudTrail	Azure Monitor activity log	Cloud Audit Logs
Key management	AWS KMS	Azure Key Vault	Cloud KMS
Guardrail policies	Service control policies	Azure Policy	Organization Policy Service
Configuration and posture checks	AWS Config, Security Hub	Microsoft Defender for Cloud	Security Command Center
Backup	AWS Backup	Azure Backup	Backup and DR Service

A few defaults are worth checking rather than assuming. For example, S3 Block Public Access is on by default for new buckets, but it can be switched off per bucket or per account, and older buckets may predate the default. If you run across more than one provider, our multi-cloud security guide covers keeping these controls consistent.

How do cloud security controls map to ISO 27001, SOC 2, NIST and CIS?

One well-implemented cloud control usually satisfies requirements in several frameworks at once. The table maps each category to the closest references.

Category	ISO/IEC 27001:2022 Annex A	SOC 2 (2017 TSC)	NIST SP 800-53 Rev. 5 families	CIS Controls v8.1
Identity and access	5.15 to 5.18, 8.2, 8.5	CC6.1 to CC6.3	AC, IA	5, 6
Network	8.20, 8.22	CC6.6	SC	12, 13
Data protection	8.24	CC6.1, CC6.7	SC	3
Logging and monitoring	8.15, 8.16	CC7.2	AU, SI	8, 13
Configuration management	8.9, 8.32	CC8.1	CM	4
Vulnerability management	8.8	CC7.1	RA, SI	7
Backup and recovery	8.13	A1.2, A1.3	CP	11
Incident response	5.24 to 5.26	CC7.3 to CC7.5	IR	17

Sources: ISO/IEC 27001:2022, the AICPA 2017 Trust Services Criteria, NIST SP 800-53 Rev. 5 and the CIS Controls. Treat the mapping as a starting point: your auditor decides how a control is tested.

Two references are cloud-specific. ISO 27001:2022 added Annex A 5.23, information security for use of cloud services, which covers how you select, use, manage and exit cloud services. ISO/IEC 27017 adds cloud-specific guidance for both providers and customers; our ISO 27017 guide covers it in detail.

Which cloud security controls should a small team implement first?

Start with the controls that prevent the most common and most damaging failures, then add detection and evidence.

1. Lock down identity. SSO with MFA for everyone, root or global admin locked away with MFA, and no long-lived access keys for people.
2. Separate production. Put production in its own account, subscription or project.
3. Turn on audit logging everywhere and send it to a location most admins cannot delete.
4. Block public exposure. Account-level public access blocks on storage and no management ports open to the internet.
5. Encrypt by default at rest and in transit, and limit who can administer keys.
6. Write a baseline and scan against it. The CIS Benchmarks for AWS, Azure and Google Cloud are a common starting point. Our minimum baseline security standard guide explains how to turn them into your own standard.
7. Back up and test a restore for every production data store.
8. Review access quarterly and remove anything unused.

Most of these are configuration, not new tools. If you are moving workloads into the cloud now, build them in from the start. Our cloud migration security checklist shows how, phase by phase.

How do you prove cloud security controls to an auditor?

Show that each control is designed properly and that it operated throughout the audit period. A screenshot from audit week proves only that it was on that day.

Control	Evidence auditors usually ask for
MFA and SSO	Identity provider policy export, list of users with MFA status, cloud accounts with local users disabled
Access reviews	Dated review records with reviewer sign-off and the removals that followed
Audit logging	Logging configuration for each account and region, log retention settings, proof logs are protected from deletion
Encryption	Default encryption settings, key policies, list of key administrators
Configuration baseline	The written baseline, posture scan history over the period, tickets for findings and their fixes
Change management	Pull requests or change tickets for infrastructure changes, with approvals
Backups	Backup policy, job history, restore test records
Incident response	Runbook, tabletop or incident records, post-incident reviews

For a SOC 2 Type 2 report, the auditor will sample evidence across the whole period. Our SOC 2 evidence for change management guide shows what a good change record looks like.

What are the most common cloud control gaps?

• Long-lived access keys in code, CI variables or laptops, often with admin rights.
• Logging that is on in one region or account but not the others, so the gap is exactly where an attacker works.
• Storage made public "temporarily" for a demo or data transfer, then forgotten.
• Controls applied by hand in the console, so drift is invisible and nothing shows when or why a setting changed.
• Backups in the same account as production, where the same compromised credentials can delete both.
• Former employees and contractors who still hold cloud roles because access reviews skip the cloud console.

How SecureSlate helps

SecureSlate helps you run and prove cloud security controls in one place:

• Cloud misconfiguration detection uses agentless, read-only scanning of AWS, Azure and Google Cloud, prioritises findings by risk and maps them to SOC 2 and ISO 27001 controls, with scheduled re-scans.
• Cloud asset inventory and IAM access reviews show who can reach what and record each review.
• Multi-framework control mapping links one cloud control to SOC 2, ISO 27001, HIPAA and other built-in frameworks.
• Secrets detection and code security flag hard-coded keys before they reach your cloud.
• Risk management and vendor risk management track cloud risks and record your providers.
• Audit management keeps configuration exports, scan history and review records ready for the auditor.

FAQ

What is the difference between cloud security controls and cloud compliance?

Controls are the safeguards themselves, such as MFA, encryption or logging. Compliance is showing that those controls meet a framework's requirements, such as SOC 2 or ISO 27001, usually through evidence an auditor tests.

Who is responsible for cloud security controls, the provider or the customer?

Both, for different layers. The provider secures the infrastructure it runs. The customer always secures its identities, access policies, data and configuration. How much else the customer owns depends on whether it uses IaaS, PaaS or SaaS.

Is a CSPM tool enough to cover cloud security controls?

No. Cloud security posture management finds misconfigurations, which covers much of the configuration, network and data protection categories. You still need identity governance, backups, vulnerability management and incident response, plus the processes and records around them.

How often should cloud security controls be reviewed?

Configuration checks work best when they run continuously or daily. Access reviews are commonly done quarterly, and the baseline itself is usually reviewed at least yearly or when you adopt a new service. Your framework and risk assessment may require more often.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.