Introduction
Moving to the cloud was, among other things, a security decision. AWS, Microsoft, and Google operate physical infrastructure with armed facilities, redundant power, dedicated security staff, and compliance programs no mid-sized business could replicate. Handing that off was sound judgment.
It’s also only half the picture, and most businesses never examine the other half.
Every major cloud provider operates on a “shared responsibility” model. The provider secures the cloud itself, while you secure what you put in it. That sounds obvious when written out, but the practical effect is that a large set of security controls became your responsibility the moment you signed up, and in most organizations, nobody was told which ones.
Where the Line Actually Falls
AWS publishes its version of this model openly, and Microsoft and Google publish equivalents. The documents aren’t hidden, they’re just rarely read by the people who’d act on them.
On your side of the line, in nearly every arrangement:
- Identity and permissions. Who can access what, which accounts hold administrative rights, and whether those permissions still match what people do. This is yours regardless of which provider or service model you use.
- Data classification and encryption. Whether sensitive data is encrypted, who holds the keys, and what’s stored where.
- Storage and network exposure. Whether a storage container is publicly reachable, whether a database accepts connections from the open internet, and how your security groups are written.
- Operating systems and patching, if you run virtual machines. The provider patches the hypervisor. The server you built on top is yours.
- Logging and monitoring. Most providers can record extensive activity, but the default settings are modest and somebody has to turn the rest on and watch it.
- Backup and retention. Infrastructure durability is not the same thing as your data being recoverable after a deletion or a bad deployment.
Why This Gets Missed
This can be explained in two reasons, and neither involves anyone being careless.
The first is that the line moves. It sits in a different place for infrastructure services than for platform services, and different again for software delivered as a service. A business running Microsoft 365, a few Azure virtual machines, and a handful of managed databases has three different responsibility boundaries operating at once, and nobody receives a notification when they cross from one to another.
The second is that cloud environments grow through ordinary work rather than through projects. A developer spins up a resource to test something. A vendor integration needs a service account. A team needs storage and creates it. Each action is small and reasonable, and the aggregate is an environment nobody has looked at as a whole since it was first set up.
What It Looks Like When It Goes Wrong
Capital One remains the clearest public example. In 2019 the company disclosed a breach affecting roughly 100 million customers, which led to an $80 million regulatory penalty. The root cause wasn’t a failure in Amazon’s infrastructure. It was a misconfigured web application firewall on the customer side of the line, combined with permissions broader than the task required.
What makes it instructive isn’t the scale, it’s that the underlying mistake was an ordinary one. A configuration was set incorrectly which nobody caught, and the gap between those two facts lasted long enough to matter. That same pattern exists in a great many environments right now at smaller scales, which is the part worth sitting with.
Why You Can't Assess This From the Inside
Here’s the uncomfortable part. Your cloud console will not tell you that you have a problem.
The dashboards report that services are healthy, which they are. The provider’s own security tooling flags a subset of issues against generic baselines, and most organizations see those alerts, find them unactionable, and stop looking. Nothing in the interface says that a storage bucket’s permissions are wider than its contents warrant, because the platform has no way to know what the contents are worth.
Evaluating this requires somebody who knows what a well-built environment looks like in practice: which permission patterns indicate drift, which defaults are safe and which are merely common, how a given configuration behaves under the conditions that matter rather than on paper. That’s an architecture review, not a checklist, and it’s not something a business owner can perform by reading an article or asking their team whether things look fine. They’ll say yes, and they’ll believe it.
Final Perspective
Cloud adoption didn’t reduce the amount of security work a business has to do. It changed the nature of it, from maintaining hardware to configuring and governing an environment that expands continuously through normal use.
The businesses that handle this well have had someone competent look at the whole thing, with fresh eyes, at least once. Most businesses have never done that, which is why the same categories of finding turn up again and again.
At Secutor, our assessments and security architecture work examine exactly this: what your cloud environment actually permits, where configuration has drifted from intent, and which findings genuinely matter given what your business does. If nobody independent has reviewed your side of the line, we’d be glad to take a look.
Your provider secured their half. The other half is still your project.
Connect with an Expert for a Free Consultation
Secutor is your team of world-class problem solvers with vast expertise and experience delivering complete solutions keeping your organization protected, audit-ready, and running smoothly. Use the form below to contact us for a free consultation.
