If you’ve ever heard someone say “it’s hosted on AWS, so it’s secure,” you’ve heard one of the most expensive misunderstandings in cloud computing. AWS is extraordinarily secure — at the layers it controls. Everything above that line is still yours to get right, and for a UK financial services firm, that line decides who’s accountable when something goes wrong.
AWS calls this split the Shared Responsibility Model, and some version of it appears in every AWS contract and most cloud security questionnaires you’ll ever be asked to complete. Few lines in those documents carry more weight, and few get read as carelessly.
The short version
AWS is responsible for security of the cloud. You’re responsible for security in the cloud.
AWS’s side covers the physical data centres, the hardware, the global network infrastructure connecting it all, and the virtualisation layer that keeps one customer’s workload isolated from another’s. None of that is yours to audit, patch or configure — and, in practice, none of it is where cloud security incidents actually originate.
Your side covers everything you put into that infrastructure: your data, your applications, your operating system (where you manage one), your network configuration, and — more than any other single factor — who and what has permission to access it. This is where almost every publicised cloud security incident has actually started, including some of the largest ever recorded. The infrastructure held; a customer-side control didn’t.
Where the line actually falls
The practical shape of the split depends entirely on which AWS service you’re using, because AWS takes on more of the stack the more “managed” the service is.
Run an EC2 instance, and you’re managing the operating system, its patches, any software installed on it, its firewall rules (security groups), and everything stored on it. AWS guarantees the physical host beneath it; you own everything running on top.
Move to a managed service like Amazon RDS, and AWS takes over the database engine’s patching and the underlying operating system. You’re still responsible for who can connect to it, how the data inside it is classified and protected, and your own application’s queries and access patterns.
Go further still, to something like S3 or Lambda, and AWS manages even more of the operational layer. But — and this is the detail that catches people out — your responsibility for access control doesn’t shrink to match. An S3 bucket is exactly as secure as its access policy, regardless of how much infrastructure AWS manages underneath it. Several of the best-known cloud data exposures of the past decade were S3 buckets AWS had secured perfectly at the infrastructure level, left open to the public by a one-line misconfiguration nobody caught.
The three mistakes we see most often
Assuming AWS’s certifications cover your workload. AWS holds a genuinely substantial stack of certifications and attestations — ISO 27001, PCI DSS, SOC 1/2/3, and others. None of them certify what you’ve built on top of AWS. If your firm needs to demonstrate PCI DSS or ISO 27001 compliance, you still need your own assessment, covering your own configuration, your own access controls and your own data handling. AWS’s certification is a useful input to that assessment, not a substitute for it.
Leaving IAM permissions wider than they need to be. Identity and Access Management is the single most consequential setting most firms under-invest in. One of the most widely reported cloud security incidents of the past decade — a 2019 breach affecting over 100 million customer records at a major US financial institution — traced back not to any flaw in AWS’s infrastructure, but to a misconfigured web application firewall paired with an IAM role on the customer’s side carrying far more permission than the task in front of it required. AWS’s infrastructure wasn’t the story. The permissions were.
Assuming encryption happens automatically, everywhere, by default. Some AWS services encrypt data at rest by default; others require you to switch it on, choose a key management approach, and configure it correctly for data in transit as well as at rest. “AWS encrypts everything” is close enough to true to be dangerous — worth checking the actual default behaviour of each service you use rather than assuming, since defaults differ from service to service and can change as services evolve. (A closer look at what’s on by default and what isn’t is worth its own post — for now, treat it as a question to actually answer, not assume.)
Why this matters more under FCA rules than it used to
UK financial services firms carry an added layer here. FCA operational resilience rules require regulated firms to understand and evidence how their important business services actually work — including the parts that depend on a third-party cloud provider. A shared responsibility boundary you haven’t mapped isn’t just a security gap; it’s a gap in the evidence a regulator will eventually expect to see. “We’re on AWS, so that’s covered” doesn’t hold up in a supervisory conversation, and it was never going to.
Where to start
A useful first exercise, and one that doesn’t require specialist tooling: for every AWS service your firm actually uses, write down what AWS handles and what you handle. For most firms, that list surfaces at least one gap nobody had explicitly owned — a role with more access than it needs, a bucket policy nobody’s reviewed since the day it was created, a database with no clear owner for its patching cadence (even on a managed service, someone still chooses when upgrades apply). AWS’s own Well-Architected Framework — specifically its Security pillar — is a reasonable structure to work through this against, rather than starting from a blank page.
This is exactly the starting point of a Yemberzal Disaster Recovery Assessment: mapping what your important systems actually depend on, who’s responsible for each layer, and where the evidence trail has gaps — before a regulator, or an incident, finds them for you.