I’ve seen many startup security teams struggle with setting up a cloud security roadmap. They know it matters, but don’t know where to start and how to progress.
The common practice is to pick a Cloud Security Posture Management (CSPM) or Cloud Native Application Protection Platform (CNAPP) tool, enable it across all cloud accounts, and get their results. Then get overwhelmed by the volume of findings.
Misconfigurations, missing best practices, and alerts on anomalous activities and potential incidents.
And then make little to no progress.
As a cloud security consultant, I’ve helped startups build security programs. I’ve created roadmaps for engineering teams (Security, DevOps, etc.) defending their cloud environments. By the end of this post, I’ll share how to set up an effective cloud security roadmap.
Why a Cloud Security Roadmap?
A roadmap provides a structured plan to protect cloud infrastructure. It tells you “what” you should be working on to achieve the goal of reducing risk to an acceptable level for your cloud environment.
In practice, it does three things:
- prioritizes which security controls to implement first and which ones you’ll tackle next
- aligns security initiatives with business objectives wherever possible
- helps you track progress and communicate with stakeholders
I’ll highlight two things.
First, you can continue cloud security initiatives without a roadmap. The downside I’ve seen is you’ll end up working on many different problems that are seemingly urgent. These “urgent” tasks often aren’t truly critical, overlook quick wins, focus too narrowly, or address symptoms rather than root causes.
For example, two weeks you work on IAM permissions, next pivot to public resources, then some other findings from your CSPM tool. Meanwhile, you’ve overlooked implementing proper cloud backups, leaving your environment vulnerable to a potentially unrecoverable ransomware attack.
Having a roadmap solves this problem.
Second, following a roadmap doesn’t mean you’ll not work on ad hoc operational tasks. You might need to do infrastructure design reviews, handle incident response and forensics, etc. in parallel with roadmap initiatives.
The best time to set up a roadmap is when you start securing cloud infrastructure. The second best time (if you don’t have a roadmap already) is NOW.
To keep this article simple, I’ll focus on AWS, but the same strategy works for other clouds and multi-cloud.
Essential Questions for Effective Roadmaps
Before creating your roadmap, ask yourself these four critical questions:
- What cloud platforms is your startup using? Check with your finance team for Amazon, Google, or Microsoft in the bills. Look for minor usages. Ask around if any teams use other cloud platforms like DigitalOcean, Linode or OVH.
- What are your top 3 security priorities? Ask your manager, CTO, or even CEO about the top 3 security priorities from their individual perspective. These are your north stars for your roadmap or goals for the next few quarters. Few questions that can help reach the conclusion:
- What is your business trying to achieve around security?
- Are there any existential threats to your startup (ex: non compliance equals losing sales)?
- Is security improvement measured just by the reduction of vulnerabilities?
- What are the acceptable risks we are willing to carry forward for the time being (ex: insider threats, defending against cloud provider going rogue, etc)?
- Which cloud services connect to these top security priorities? Note them down. You’ll solve them from the first few phases.
- What’s the scope of your cloud security program? Is it just cloud misconfigurations, or securing the full cloud native stack (4Cs) including clusters and containers, or something in between?
Don’t try to create a roadmap without answers to these questions.
Your answers will shape your cloud security roadmap. It will define the time and budget needed to achieve them.
Here are a couple of examples:
B2B Startup (20 Engineers) |
B2C Startup (350+ Engineers) |
What cloud platforms is your startup using? |
|
We're all in on AWS - that's where our entire stack runs. We have about 30 EC2 instances, 15 S3 buckets, and a handful of other services. Also, we use GitHub for source control and CI/CD. |
Our primary infrastructure is on AWS. We have a dozen AWS accounts organized by team and environment. Our data teams use Big Query and our mobile app teams login to Firebase constantly. We run 14 Kubernetes clusters for our microservices. Also, we use GitHub Enterprise for source code and build pipeline. We’re trying to move away from AWS CodeCommit and will be done by the end of this year. |
What are your top 3 security priorities? |
|
1. If our customer data is leaked, we’re toast 2. We’re trying to close Enterprise Client X but they keep asking for SOC2 certification that we don’t have yet. 3. Pretty much all the engineers have admin access to our AWS account because we need to move fast. (Also, new interns will be joining in next quarter.) |
1. We had DDoS last month which took down our servers and caused revenue loss. 2. There’s a huge tech debt we’re trying to clean up this year. We just found a database instance containing unencrypted user data from our 2022 promotion, and if leaked, we’d face GDPR fines. 3. Our biggest product launch failed because sensitive details were leaked to competitors, and our engineers with AWS access could have viewed those confidential staging documents. |
Which cloud services connect to these top security priorities? |
|
1. We store our customer information in our prod-customer-db RDS instance and in our customer-exports S3 bucket. 2. For SOC2, we need to prove security across all our AWS services - EC2, RDS, S3, IAM, and Lambda 3. Our access control is done using AWS IAM. All users have their own AWS IAM users and AdministratorAccess policy attached to them. |
1. Our web apps and Kubernetes microservices are reachable from the internet using ALBs, API Gateways and some legacy EC2s have elastic IPs attached. 2. For the tech debt and unencrypted data, we discovered an old RDS database and two S3 buckets with unencrypted customer information from past campaigns. 3. Sensitive design documents and high level diagrams are now stored in Google Docs. Before the leak occurred, a portion of them were stored in markdown files in CodeCommit repos. |
What's the scope of your cloud security program? |
|
Right now we're just trying to fix AWS misconfigurations that could get us breached. We also need to focus on our AWS issues that HackerOne researchers keep reporting - public S3 buckets, subdomain takeovers, hardcoded AWS key in a JavaScript file, etc. |
We’ve had external cloud pentests that found common misconfigurations in AWS. We are good on that front. Now, we need to secure the full 4Cs - Cloud (AWS), Clusters (EKS), Containers, and Code (IaC). We need to focus on security guardrails across all of them. |
Do you see the difference?
Cloud security roadmaps for the above startups will differ and have different priorities (and different budgets to implement them).
Understanding Cloud Security Maturity Roadmaps
A cloud security maturity roadmap shows your current status and next improvement steps. It provides a bird’s eye view of your security posture and points to the north star direction.
Roadmaps are structured guides that highlight risks and issues for robust cloud security.
Good maturity roadmaps cover key domains like identity, access management, monitoring, and configurations (resources, networks, encryption, etc). They provide clear assessment criteria and the problems they aim to solve.
Now, you can do two things:
- Create your own roadmap from scratch
- Use an existing online cloud security roadmap
Both have pros and cons.
Creating your own roadmap from scratch can tailor it to your startup’s risks. While this looks simple, you must handle a few issues:
- Time and effort to create a roadmap from scratch
- Communicating the same with management and explaining why it’s better
- Ensuring the roadmap covers areas like backups, patch management, network security, etc
If you use a public roadmap, the opposite is true. The roadmap will consider different cloud security areas but won’t prioritize based on your startup’s priorities.
What’s often the best solution?
Combine both.
Choose a public cloud security maturity roadmap, check if it already covers your startup’s immediate security priorities and scope, adjust task priorities, and start working on it.
Let’s review the AWS public cloud security roadmaps.
Available AWS Security Roadmaps
Three roadmaps have been there for quite some time now:
AWS Security Maturity Roadmap by Scott Piper
This practitioner-friendly roadmap focuses on AWS platform security. It was last updated in 2021, but its recommendations remain solid in 2025.
The roadmap has 10 maturity stages that build upon each other, each with a short checklist. It focuses on Attack Surface Reduction and prioritizes addressing common security incidents first (publicly accessible resources, leaked access keys, etc).
Like any Cloud Security Roadmap, there are a few downsides.
This is an AWS-focused roadmap covering AWS security configurations and best practices. If you’re a multi-cloud shop or use other cloud providers, you need to create a checklist of things to implement from scratch.
This roadmap doesn’t focus on patch management, container, and serverless security - often under cloud security team’s responsibilities. It was last updated in 2021, so it doesn’t include recent AWS features (like RCPs, public account block across services) and few OSS tools have good alternatives or aren’t supported.
Roadmap Ideal for: Early-stage startups securing AWS environments to avoid common breaches.
Cloud Security Roadmap by Marco Lancini
The most comprehensive roadmap among the three. It takes a holistic view of cloud native security covering:
- Policies and standards
- Architecture
- Supply chain security
- Incident response
- Business continuity
It addresses all 4Cs - cloud, cluster, container, and code. This roadmap includes technical (OS hardening, preventing hardcoding secrets, etc) and non-technical aspects (policies and procedures).
This roadmap focuses on multi-cloud environments and kubernetes clusters. It aligns with industry standards like the Cloud Security Alliance Cloud Controls Matrix (CSA CCM), encourages DevSecOps integration with sections on CI/CD security, image/pod security, and supply chain integrity, and references modern tools (Cartography, Falco, etc).
The biggest downside?
This roadmap is overwhelming. It has 94 items across 7 categories.
Some sections like Business Continuity and Policy & Standards are great to have but often fall outside the cloud security team’s scope (maybe taken up by InfoSec & IT teams). Implementing many things from this roadmap needs a good budget (to hire security engineers and buy security tools).
Roadmap Ideal for: Larger startups (250+ engineers) or regulated companies aiming to implement security beyond compliance checklists.
AWS Security Maturity Model by AWS
It’s a maturity model created by AWS for AWS customers based on their experience.
This model is based on the AWS Cloud Adoption Framework: Security Perspective document.
The maturity model has four phases: quick wins, foundational, efficient, and optimized. It helps prioritize recommended actions and best practices to secure AWS. Each phase includes nine categories from Governance to IAM to Resiliency.
Each phase covers multiple categories. The quick wins phase addresses common misconfigurations.
The downside?
It’s a maturity model created by AWS for AWS customers that recommends using AWS services to solve security issues.
It often upsells recommends AWS services. (Like Nick Jones mentions, this maturity model feels focused on doing security work with AWS offerings, not doing good security.)
Roadmap Ideal for: Startups on AWS implementing all security best practices using AWS services.
Other cloud security roadmaps:
- Cloud Security Maturity Model by IANS Research (CSP Agnostic)
- CISO Scorecard & Cloud Security Maturity Model by SANS (CSP Agnostic) - more for leadership than practitioners
- (DRAFT) Multi-Cloud Security Maturity Roadmap based on NIST CyberSecurity Framework (CSP Agnostic)
Comparing Roadmap Options
Which roadmap you can choose and customize depends on your scope (answer to question 4):
- AWS Security Maturity Roadmap by Scott Piper is good if you’re:
- focused on cloud misconfigurations
- use only the AWS cloud platform
- not concerned about workload security (ex: scanning containers and clusters)
- Cloud Security Roadmap by Marco Lancini is good if you’re:
- focused on cloud native security (securing 4Cs - code, container, cluster & cloud)
- using multiple cloud platforms
- want a more holistic view on cloud security
- AWS Security Maturity Model by AWS is good if you’re:
- focused more than cloud misconfigurations
- using only AWS
- having a lot of credits that you can use for AWS security services
Crafting Your Customized Roadmap
Before I show you how to build your roadmap, remember: Be opinionated when creating your roadmap.
Cloud Security Roadmaps provide guidance, not strict rules.
If your scope changes, update your roadmap.
If you add or migrate to a new cloud, update your roadmap.
If there’s new leadership, update your roadmap.
Be ruthless in prioritizing your startup’s risks when building roadmaps, and be mindful when removing sections of public cloud security roadmaps.
Now that out of the way, here’s how to build your roadmap:
Check the base roadmap you picked for:
- Covers your cloud platform(s)
- Covers the top 3 security priorities for your startup
- Covers cloud services related to the top 3 security priorities
- Is it within your scope to secure (just cloud or 4Cs)?
Start customizing:
- If not following regulatory requirements is an existential risk to your startup, add them
- Did your startup have a security incident or breach? If so, start securing those services.
- Include both preventive and detective controls in the roadmap. Implement preventive controls in the first or second phase—if you prevent a misconfiguration, you don’t need to detect it later. However, you still need detective controls to ensure no one is tampering with your preventive controls.
By the end of this customization, you’ll get a roadmap that will help you decide what you’ll tackle in the immediate next 4 quarters and beyond.
Here are a few pro tips.
Get leadership buy-in for everything you plan to do in each phase of the roadmap. The best roadmap means nothing if issues aren’t fixed. As you progress the maturity ladder, security becomes a costly affair and you’ll need a slightly bigger budget allocated.
Don’t skip fundamental security controls for fancier projects like runtime security, adversary emulation, or red teaming. Once you fix basic issues like misconfigurations and long-lived hardcoded secrets, you will work on these areas.
An effective cloud security strategy should have preventive, detective, and reactive controls. If your roadmap focuses on just one, you’re doing it wrong.
Every two quarters, review your roadmap to decide whether to continue or update it.
Final Thoughts
There’s no silver bullet for Cloud Security Maturity Roadmaps. Public roadmaps provide a starting framework, but you must adapt it to your startup’s needs.
To create an effective roadmap:
- Understand your startup’s current cloud usage, top security priorities, and scope
- Choose a base roadmap that aligns with your needs
- Ruthlessly prioritize and customize the roadmap based on your startup’s context and security priorities
Remember, roadmaps are meant to be opinionated guides, not strict plans. Be ready to change them as new information emerges.
The most important thing is creating a roadmap that works for you.
Adapt the framework, make it your own, and use it to drive real cloud security progress — just like the practical roadmaps and implementable strategies I build for startups.
PS: Huge thanks to Daniel Grzelak, Deep Shankar Yadav and Mohit Singh for reviewing the drafts and improving this article.