Skip to main content
BilgeQor

Security Services

Cloud Misconfiguration: Top Risks and a Practical Checklist

4 min read

Most cloud security incidents do not involve breaking the cloud provider's own infrastructure. They involve customer configuration: a storage bucket left public, an access key committed to a repository, an administrator account without multi-factor authentication, or a database reachable from the whole internet. Cloud providers operate a shared responsibility model, in which they secure the underlying platform and you secure what you configure on it. This guide lists the most common cloud misconfiguration risks and practical checks for each.

What It Is

Cloud misconfiguration is any setting in your cloud accounts that exposes data or systems more than intended, or leaves you unable to detect and recover from problems. It tends to accumulate as teams grow, projects are created quickly, and temporary changes become permanent. The main categories are consistent across AWS, Microsoft Azure, and Google Cloud. Identity and access: overly broad roles, long-lived access keys, shared accounts, and missing MFA. Storage: buckets, blobs, or snapshots readable by anyone or shared too widely. Network: security groups or firewall rules open to all addresses, management ports exposed, and flat networks without segmentation. Secrets: credentials in code, environment files, or container images. Logging: audit logs disabled, not retained, or never reviewed. Encryption: sensitive data stored without encryption or with poorly managed keys. Resilience: backups missing, untested, or stored in the same account they protect. Governance: unknown accounts, untagged resources, and no owner for projects.

Who It Is For

This checklist is useful for:

  • Startups and SMEs whose cloud environment grew quickly without a formal design
  • Teams preparing for a customer security review or due diligence
  • Organisations planning to run AI or data workloads in the cloud
  • Managers who inherited cloud accounts from former staff or suppliers

What It Helps Clarify

Working through the checklist helps clarify:

  • Who has administrative access, and whether it is protected and still needed
  • Which data is publicly reachable, intentionally or not
  • Whether you would notice and could investigate suspicious activity
  • Whether you could restore critical systems if an account were compromised

What's Included

  • Enforce MFA for all human users, especially administrators and the root or owner account
  • Replace long-lived access keys with roles or short-lived credentials where possible
  • Review roles for least privilege and remove unused users and permissions
  • Block public access to storage by default and review any exceptions
  • Restrict management ports and databases to known networks or private access
  • Move secrets into a managed secrets service and scan repositories for leaked keys
  • Enable audit logging in every account and region in use, and retain logs securely
  • Set alerts for high-risk events such as new administrators, disabled logging, or public storage
  • Encrypt sensitive data at rest and control who can manage keys
  • Back up critical data to a separate account or location and test restoration
  • Maintain an inventory of accounts, projects, and resource owners
  • Use infrastructure as code and review changes before they are applied

What's Not Included

  • A claim that a reviewed environment cannot be compromised
  • A formal cloud audit, certification, or compliance approval
  • Penetration testing unless separately scoped
  • Continuous monitoring or managed operations unless separately agreed

When to Choose It

Use this checklist when you have not reviewed your cloud accounts for some time, before a customer or investor security review, after staff or supplier changes, and before introducing AI or large data workloads. If you cannot quickly answer who has administrative access to every account, start there.

Our Approach

Prioritise identity first, because most other controls depend on it. Then remove public exposure, secure secrets, and make sure logging and backups would support detection and recovery. Treat fixes as engineering work with owners and change control, not a one-off clean-up. Our Cloud Platform & Production Engineering service covers architecture decisions, release pipelines, observability, backup, and recovery runbooks for agreed environments, with production changes made only under an approved plan and explicit written authorisation. If you first need a documented view of where things stand, a Security Baseline Review can provide severity-graded observations, and an AI & Cloud Readiness review provides a readiness scorecard and decision record focused on foundations for AI workloads. Penetration testing of cloud-hosted applications can be scoped separately. Revisit the checklist regularly; configuration drifts as teams and projects change.

Cloud Platform & Production Engineering

View the Cloud Platform & Production Engineering service page

Frequently Asked Questions

Related Articles

Get Started

Want a clearer view of your cloud configuration?

Share which providers and accounts you use, what runs there, and any upcoming review or migration. We will propose a written scope.

Request a written scope