Cloud Security Best Practices

The shared responsibility model, properly explained

Every major cloud provider — Microsoft, Amazon, Google — operates on a shared responsibility model, and it's the single most misunderstood concept in cloud security. The provider secures the physical infrastructure: data centres, hardware, the underlying network fabric, the hypervisor. You are responsible for everything running on top of that: how identity is configured, who has access to what, how data is encrypted, and whether a storage bucket is quietly exposed to the public internet.

This split matters because it explains why "we're on Azure/AWS/Google Cloud, so we're secure" is a category error. The platform being secure and your configuration of it being secure are two entirely different questions, and the second one is where almost every real-world cloud breach actually happens.

What actually causes cloud breaches

Ask any cybersecurity team what causes the incidents they actually investigate, and the pattern repeats with tedious consistency: a storage bucket left with public read access, a former employee's account that was never disabled, multi-factor authentication switched off temporarily for convenience and never switched back on, or an identity role granted far broader access than the job it was created for actually requires. Sophisticated, novel attacks make headlines. Misconfiguration is what actually gets exploited, day after day, across every provider.

Identity and access management

Identity is the practical perimeter of a cloud environment — more so than any firewall. Getting this right means a small number of specific, unglamorous practices, applied consistently rather than occasionally:

• Multi-factor authentication enforced for every account, with no standing exceptions
• Least-privilege access — roles granted only what a job genuinely requires, reviewed periodically
• Same-day offboarding when someone leaves, not "whenever IT gets to it"
• Conditional access policies restricting sign-in by location or device risk where appropriate
• Service account and API key rotation, since these are frequently forgotten in favour of user account security

Network configuration and segmentation

A cloud network configured with everything able to talk to everything else is a single breach away from a much larger problem than it needed to be. Proper segmentation — separating production from development environments, isolating databases from public-facing applications, restricting traffic between resources to only what's genuinely required — limits how far an attacker can move if they do get a foothold somewhere. This is a core part of what a properly architected hybrid cloud or private cloud environment is actually designed around, rather than an afterthought bolted on once something's gone wrong.

Backup as a security control, not just a recovery tool

Backup often gets filed under "disaster recovery" rather than "security," which undersells its role. A tested, immutable backup is one of the most effective controls against ransomware specifically, because it removes the leverage an attacker has: if you can restore clean data quickly, encryption of your live environment stops being an existential threat and becomes an inconvenience. The critical word is tested — a backup that has never actually been restored from is an assumption, not a control.

Continuous monitoring and detection

Configuration alone isn't sufficient; something also needs to be watching for the moment configuration fails or an account behaves unusually. That means genuine 24/7 monitoring — unusual sign-in locations, privilege escalation attempts, abnormal data transfer volumes — with alerts routed to a person who can act on them within minutes, not a dashboard nobody checks until the following Monday. This is typically the point where a business moves from managing security informally to bringing in a dedicated managed cybersecurity service.

Platform-specific weak points

While the underlying discipline is consistent, each major provider has characteristic places where things tend to go wrong. On Azure, it's typically conditional access policy gaps and over-permissioned Azure AD roles. On AWS, it's public S3 bucket policies and overly broad IAM roles, almost a cliché at this point but still the most common finding in real audits. On Google Cloud, it's unrotated service account keys and permissive IAM bindings at the project level. Knowing where each platform's specific risk tends to cluster is a large part of what a specialist review actually finds that a generic checklist misses.

Where compliance and certification fit in

For UK businesses, Cyber Essentials and Cyber Essentials Plus certification provide an externally verified baseline that maps closely onto the practices above — access control, secure configuration, patch management. Increasingly, this certification is a genuine commercial requirement rather than a nice-to-have: public sector contracts, insurers and larger clients are asking for it before they'll sign. Getting cloud security fundamentals right isn't just about avoiding an incident — it's increasingly a prerequisite for winning the work in the first place.