Most cloud incidents are not the provider failing but configuration. Exposed storage, over-broad permissions, missing logging.
Cloud providers' infrastructure is typically better protected than any in-house server room. Yet most cloud incidents still happen, and almost always for the same reason: nobody manages the customer side of shared responsibility.
The provider is responsible for infrastructure: hardware, hypervisor, physical security. The customer is responsible for data, access and configuration.
That boundary is clear in the contract, yet in practice many believe that moving to cloud moved security too. It does not.
The classic case: an object store opened during development and never closed. There is no sign-in, so anyone who knows the URL downloads it.
What to do: deny public access by default at account level, and check regularly that no exceptions exist.
Someone received a permissive policy during a project so work could progress, and nobody narrowed it afterwards. Months later that policy is still live.
What to do: most providers show which permissions are actually used. Anything unused for months can be removed.
A static API key that never expires, typically sitting in a config file or source code. If it leaks, it works indefinitely.
What to do: short-lived, automatically renewed authentication (role-based access) instead of static keys. Where unavoidable, rotation and a secrets manager.
The cloud administrator account is the most valuable target: from there every resource can be reached, deleted, and new ones spun up.
What to do: MFA without exception on all console access, preferably hardware keys for the highest-privileged.
Cloud logging is not the default with many providers, or is retained only briefly. In an incident it decides whether events can be reconstructed.
What to do: logging in every region, centrally collected into a separate account that cannot be deleted with day-to-day privileges.
Encryption is a single toggle with most providers, yet it is frequently omitted, particularly for backups and snapshots.
What to do: encryption by default, with customer-managed keys where data sensitivity warrants it.
A database or admin interface reachable from the whole internet, because it was simpler to set up that way.
What to do: management interfaces only from defined IP ranges or through ZTNA. Databases should never be public.
Shadow IT. A department opens its own account on a card and nobody knows. Proxy logs will list which cloud services are reached from the organisation.
Multiple accounts. With ten accounts you must configure the same thing in ten places. Organisation-level policy is what handles this centrally.
Changes without code. If configuration is made by hand in the console, there is no change management and no rollback. Infrastructure as code solves this.
A one-off review is insufficient, because cloud environments change daily. CSPM tools continuously inspect configuration and flag drift.
In smaller environments the provider's own built-in checks may suffice, provided somebody actually reads the reports. We covered logging in detail in our logging article.
Comprehensive IT security services including firewalls, WAF, IPS, SIEM, DLP and endpoint protection from…
Most incident investigations fail because the decisive log is missing or already rotated. Which sources to…
Why mandatory 90-day rotation is wrong, what the right length rule is, and how to roll out a password…
Our specialists are happy to discuss what this means in your organisation's environment.