CloudScale Advisory

CloudScale Advisory

CloudScale Advisory

The Cloud Security Question Changed. Did Your Answer?

The Cloud Security Question Changed. Did Your Answer?

The Cloud Security Question Changed. Did Your Answer?

I wrote a series of posts about cloud security fears in 2016. Rereading them a decade later was humbling in an unexpected way.

In 2016 I was Director of Product Management at Datapipe, and I spent a good chunk of that year writing about the same tension from different angles. Companies wanted to move to the cloud. A Cloud Security Alliance study at the time found 71 percent of companies had a formal process for users to request new cloud services, and nearly two-thirds of IT professionals trusted cloud security as much as or more than their on-premise systems. Yet almost 68 percent said the inability to enforce their corporate security policies in the cloud was still a barrier to adoption.

I called it a catch-22 back then. Everyone knew there was strong security in the cloud, but security was still the biggest obstacle to getting there.

Reading those posts now, what strikes me is that nobody asks the 2016 question anymore. The providers won that argument years ago. The question that matters today is whether you're operating the cloud securely, and for a lot of organizations the honest answer is no. Gartner spent years predicting that nearly all cloud security failures would be the customer's fault rather than the provider's. That prediction aged well. The risk didn't go away when the industry crossed the adoption chasm. It moved inside the account.

Three themes from those old posts held up better than I expected. Each one looks different now.

Security is a people problem, and "people" now includes machines

My core argument in 2016 was that cloud security couldn't live in the IT department alone. Everyone in the company had a role, security teams needed ongoing training, and there was a stat in that CSA study that still bothers me: 82 percent of companies claimed a proactive approach to security, but fewer than half had a complete incident response plan.

That gap between intending to be secure and actually operationalizing security is still where most cloud programs fail. CSA's Top Threats research has put misconfiguration and inadequate change control at the top of the list for consecutive years now, and when researchers dig into those incidents, the overwhelming majority trace back to human error rather than software failure. Ten years of tooling didn't fix the people problem.

What I couldn't have anticipated in 2016 is that the fastest-growing population of "users" in a cloud environment isn't human. Service accounts, API keys, CI/CD pipelines, workload identities, and now AI agents outnumber people in most cloud estates, often by a wide margin. All the identity hygiene we preached for humans applies to machines too, except the machine population is bigger, changes faster, and mostly sits outside anyone's governance process. An unrotated key or an orphaned service account with admin rights is this decade's version of the password taped under the keyboard.

We were right to obsess over access control

The same CSA study found 87 percent of companies considered access control essential to cloud security. At Datapipe we built our managed AWS practice around exactly that. Our access model let customers delegate operational access to us without ever handing over their credentials, with role-based permissions and a full record of who did what. At the time it was a differentiator. Looking back, it was an early version of what the industry now treats as standard doctrine.

Identity has since overtaken everything else as the top cloud risk. In CSA's State of Cloud and AI Security 2025 research, insecure identities and risky permissions ranked as the number-one risk to cloud infrastructure, and among organizations that had suffered a cloud breach, three of the top four causes were identity-related. "Identity is the new perimeter" used to be a keynote line. In a multi-cloud, hybrid, SaaS-heavy environment, it's just an accurate description of the architecture, because identity is the only control plane that spans all of it.

The practical version for 2026: least privilege is ongoing operations, not a one-time project. Just-in-time access, short-lived credentials, regular entitlement reviews, and getting to zero standing privileges where you can. If the only IAM metric your team reports is MFA adoption rate, you're measuring a problem that was mostly solved years ago and missing the ones that aren't.

Frameworks won, and they grew up along with the threat

In December 2016 I wrote a walkthrough of the Security Perspective in the AWS Cloud Adoption Framework, which at the time organized cloud security into four components: Directive, Preventive, Detective, and Responsive. What I liked about it then is what I still like about framework-driven security. It treats security as a program that matures through iteration instead of a box you check during migration.

The CAF itself is a decent proxy for how much the job grew. AWS has since rebuilt the framework around six perspectives, and the Security Perspective alone expanded from four components to nine capabilities: security governance, security assurance, identity and access management, threat detection, vulnerability management, infrastructure protection, data protection, application security, and incident response. The old model wasn't wrong. The surface area just kept expanding as DevSecOps, infrastructure-as-code, software supply chain security, and Zero Trust went from emerging ideas to baseline expectations.

The takeaway holds on any cloud. You're no longer securing the perimeter of an environment. You're securing a delivery lifecycle, an identity fabric, and a data estate, and you're doing it continuously.

What's genuinely new

Two things reshaped the landscape in ways nobody I knew was writing about in 2016.

AI workloads showed up before AI security did. More than half of organizations now run AI for real business needs, and roughly a third of those with AI workloads have already had an AI-related breach. Here's the part worth sitting with: the breach causes are familiar. Exploited software vulnerabilities, misconfigured cloud settings, and identity failures around the service accounts and APIs that connect training pipelines and inference endpoints. There's a temptation to chase exotic AI-native threats while the same fundamentals that leaked S3 buckets in 2016 quietly leak model endpoints and training data. The boring stuff is now attached to more valuable assets, so secure the boring stuff first.

Complexity itself became the attack surface. In 2016, cloud adoption usually meant one provider plus a hybrid bridge back to the data center. Today most organizations run multiple clouds and the large majority maintain some hybrid footprint. Attackers increasingly move across domains, from a SaaS identity to a cloud workload to an on-prem system, precisely because defenses are still organized in silos. Fragmented tooling and fragmented visibility used to be an operational annoyance. Now they're something adversaries actively count on.

The parts I'd still defend

Strip out the dated statistics and the product references, and the 2016 posts argued for a few things I believe more strongly now than I did then.

Proactive beats reactive, and most of it is finally automatable. In 2016, proactive meant having a plan and doing regular security testing. Today it means continuous posture management, guardrails enforced in the deployment pipeline, and incident response that's rehearsed and largely automated, so the security team spends its time on root cause and threat hunting instead of firefighting the same misconfiguration for the fortieth time.

The reasons companies leaned on managed service providers back then, scarce expertise, 24/7 coverage, accountable delegated access, haven't gone anywhere. If anything the skills gap in cloud and AI security is wider than it was a decade ago. What's changed is the scope of the conversation. It used to be "run my environment." Now the partners earning their keep are the ones helping clients govern identity, cost, and security as one operating discipline instead of three separate arguments at renewal time.

And I ended one of those 2016 posts by saying the only truly wrong approach to cloud security is not having one. I'll stand by that with a small amendment: in 2026, the wrong approach is having a 2016 one. If your program still assumes human users, static infrastructure, a single cloud, and an annual review cycle, the landscape has moved on without you.

Ten years is a long time in this industry. The fears about whether to trust the cloud dissolved, and what's left is the harder work of deserving that trust in your own operations. The fundamentals from 2016, people, access, frameworks, proactive posture, turned out to be the right fundamentals. They just apply to a world with far more identities, far less perimeter, and AI on both sides of the fight.

David Lucky is the founder of CloudScale Advisory, where he advises cloud and SaaS companies on partner-led go-to-market strategy. He has spent 15+ years in the AWS, Microsoft, and Google Cloud ecosystems, including product management and marketing leadership roles at Datapipe and Rackspace.

Originally published

This piece revisits and updates three posts I wrote in 2016:

Current statistics and framework references draw on the Cloud Security Alliance's State of Cloud and AI Security 2025 and Top Threats to Cloud Computing research, and the current AWS Cloud Adoption Framework documentation.