A multi-cloud security checklist should cover one identity source, a common baseline per provider, central logging, posture scanning across all accounts, infrastructure as code checks and one control framework to map everything to. Do these in that order and keep each item testable.
Key takeaways
- Multi-cloud multiplies consoles, not control objectives. Define controls once, implement per provider.
- Identity and logging come first because everything else depends on them.
- Use a shared framework such as the CSA Cloud Controls Matrix to avoid three separate checklists.
- Scanners that span providers reduce reporting effort.
- Review the checklist every quarter, not once.
What is a multi-cloud security checklist?
It is a short list of verifiable controls applied the same way across every cloud you run. The goal is one standard with provider specific settings, instead of a different security program per console.
Which framework should you map controls to?
Use a provider neutral one. The Cloud Security Alliance Cloud Controls Matrix is described as a cybersecurity control framework for cloud computing, with 197 control objectives in 17 domains, and mappings to standards such as ISO, NIST and PCI. Domains include identity and access management, logging and monitoring, and infrastructure and virtualization security.
The checklist
1. Identity and access
- One identity provider for people, federated into AWS, Azure and Google Cloud.
- MFA everywhere, phishing resistant for administrators. AWS recommends passkeys and security keys.
- Temporary credentials for people and workloads. AWS says to use roles, and lists web identity tokens and IAM Roles Anywhere for workloads outside AWS.
- Root or break glass accounts locked down, monitored and tested.
- Quarterly access reviews.
2. Account structure
- Separate production from non production in every cloud.
- Use organization level guardrails: AWS service control policies, and the equivalent controls in the other providers.
- One owner recorded per account or project.
3. Logging and monitoring
- Organization wide audit logs in every provider, sent to a store that workload admins cannot edit. On AWS, remember Event history keeps only 90 days of management events.
- One place to search, or at least a documented way to query each.
- Alerts on root or admin sign in, policy changes and new public exposure.
4. Posture management
- Scan every account in every provider against a benchmark such as CIS.
- Use native tools in each cloud, or a tool that spans providers. Microsoft's Defender CSPM connects Azure, AWS and GCP, Prowler lists official support for AWS, Azure, GCP and Kubernetes, and Scout Suite lists AWS, Azure and GCP. See our CSPM comparison.
- Track findings with owner, due date and accepted risk expiry.
5. Data protection
- Block public storage by default in every provider. On AWS, use all four S3 Block Public Access settings.
- Encrypt with managed keys, and decide who controls the keys.
- Know where sensitive data lives.
6. Infrastructure as code
- All changes through code review.
- Scan code in pull requests. Checkov covers Terraform, CloudFormation, Bicep, ARM templates and Kubernetes among others.
- Secure Terraform state. See how to secure Terraform state.
7. Containers and Kubernetes
- Scan images in CI and in the registry.
- Enforce Pod Security Standards. See Kubernetes security tools by job.
- Block workload access to cloud metadata endpoints where not needed.
8. Software supply chain
- Inventory dependencies per application.
- Check packages for known CVEs and malicious releases before deploy.
9. Incident response
- One runbook with provider specific steps for credential revocation and isolation.
- Practice it twice a year.
How do you start if you have no time?
Do three things this week: federate identity with MFA, turn on organization audit logs, and run one posture scan on every account. Fix the findings that expose data or grant admin before anything else.
See what connecting a cloud account looks like
Click through it at your own pace, or open it full screen.
For dependencies, Safeguard's free in-browser scan at gold.safeguard.sh/scan checks up to 100 dependencies and keeps your file on your machine.
Frequently asked questions
Is multi-cloud more secure than a single cloud?
Not by itself. It adds surfaces to secure. Any resilience benefit depends on your architecture.
Do I need a separate checklist per cloud?
No. Keep one control list and add provider specific settings under each item.
What is the Cloud Controls Matrix?
A CSA framework of 197 control objectives across 17 domains, with mappings to other standards.
Can one tool scan all clouds?
Several list support for multiple providers, including Prowler, Scout Suite and Microsoft Defender CSPM. Check the specific resource types you use.
How often should we review the checklist?
Quarterly, and after adding a new provider or major service.
Sources
- CSA Cloud Controls Matrix
- AWS IAM security best practices
- Amazon S3 Block Public Access
- AWS CloudTrail organization trails
- Microsoft Defender for Cloud, CSPM
- Prowler README
- Scout Suite README
- Checkov README
Last reviewed: 19 October 2026.