Making Cloud Threat Modelling Executable

I first started using the cloud way back in 2010 to operate a global project management platform. Whilst there were lots of sharp edges back then, you could see how it was going to change how we approached computing. I eventually ended up working at AWS in various roles helping customers securely adopt the cloud.

One recurring theme I saw was security-sensitive customers getting delayed around security: unknown risks, unclear controls, and frameworks that looked great on paper but were impossible to execute in reality. That's ultimately why we kicked off TrustOnCloud. I spend my days now working in a team intent on transforming security governance and helping customers accelerate their innovation in the cloud whilst ensuring they are secure.

Let's call it out: old-school threat modelling can be slow, abstract, and inconsistent based on the author. We flipped that on its head. TrustOnCloud gives you a completed threat model, with actionable, testable controls for each specific cloud service and delivers them right into the hands of engineers.

Our threat models aren't set-and-forget; they pull in live changes from the cloud providers and are scoped to real-world usage, not some theoretical best-case. Net result? Teams secure services before adoption, not months after go-live.

Every year, cloud providers release thousands of changes into the ecosystem via new APIs and permissions. We track those at scale and re-translate them into updated threat models — be it new or updated threats and controls. OverWatch, our update service, serves those changes up weekly, so your security doesn't need to wait for auditors to rediscover what's already shifted.

That's how our customers move from that once-every-three-years audit scramble to continuous, no-surprises governance.

Teams commonly start with abstract frameworks or repurpose vendor quick-starts — that's a fast way to get lost. We start with the service as it is: what it does, what components are present, and how data flows between them. That surfaces real attack paths and helps us put practical controls where they matter.

The most common mistake? Reviewing each service in a silo. Cloud is composable, but threats ignore org charts. Our approach maps both attacker entry points and downstream risks, giving teams visibility into what gets in — and what your resources could trigger next.

Every threat we model is tagged to MITRE ATT&CK, mapped to CVSS, and cross-linked to required IAM permissions and control objectives. All of these map back to over 300 frameworks — including CIS Benchmarks — through the Secure Control Framework.

But more than just mapping, each control comes with practical testing steps, an effort estimate, and clear info on operational impact — so you can prioritise security work by ROI, not by guesswork. It's about closing the gap between GRC wishlists and actual engineering sprints.

Our north star is simple: make security easier to execute for cloud teams. That's tighter IaC pipeline integration, smarter prioritisation using ROI models tied to real threats, and richer machine-readable control sets that plug straight into modern CNAPPs.

A big next step for us is helping teams secure emerging tech — especially AI services. Right now, there's a massive gulf between what AI can do and what's actually being approved by security. We're building the bridge: clear, actionable controls for AI services so business units can innovate without waiting on security to catch up.