Cloud security assessment: scope, steps and checklist
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
A cloud security assessment is a structured review of your AWS, Azure or Google Cloud environment that finds misconfigurations, excess access, unprotected data and gaps against frameworks such as CIS Benchmarks, NIST or NIS2. It ends with a prioritised list of risks, the evidence behind each one and a remediation plan with owners.
Key takeaways
- Most cloud incidents start with configuration and identity mistakes, not with flaws in the cloud provider. The assessment focuses on the part of the shared responsibility model that is yours.
- Cover six areas: identity and access, network exposure, data protection, logging and detection, workload hardening, and resilience.
- Use a recognised baseline so findings are objective: CIS Benchmarks, the AWS Well-Architected Security Pillar, the CSA Cloud Controls Matrix or the NIST Cybersecurity Framework.
- Combine automated posture scans with manual review. Tools find misconfigurations; people find risky designs and business-logic gaps.
- AWS and Microsoft allow customers to test their own resources within published rules, but read the rules before you run a penetration test.
- Repeat the assessment at least yearly and after major changes, and track findings to closure.
Why run a cloud security assessment?
Because the cloud provider secures the platform, but you secure what you build on it. The AWS shared responsibility model describes this split: AWS is responsible for security "of" the cloud, and the customer for security "in" the cloud, including data, identity, network configuration and operating systems.
That customer side changes every day. New accounts, new services and quick fixes during incidents create drift. An assessment gives you a point-in-time view of where you stand, and a baseline to measure improvement against. Typical triggers are:
- Before or after a migration to the cloud
- Before an ISO 27001 audit, a NIS2 review or a customer security questionnaire
- After a merger, when you inherit unknown accounts and subscriptions
- After an incident or a near miss
- When a new security lead or CTO needs an honest starting point
What does the assessment cover?
A good assessment looks at six areas. The checklist below is what we expect to see evidence for in each one.
| Area | What is checked | Common findings |
|---|---|---|
| Identity and access | Root and global admin use, MFA, SSO, role design, unused users and keys, cross-account trust | Long-lived access keys, admins without MFA, wildcard permissions |
| Network exposure | Security groups and NSGs, public IPs, load balancers, VPN and peering, WAF | Management ports open to the internet, flat networks between environments |
| Data protection | Encryption at rest and in transit, key management, public storage, backups, data classification | Public buckets or blobs, unencrypted snapshots, no data owner |
| Logging and detection | Audit logs in every account and region, central log storage, threat detection, alert routing | Logging off in unused regions, alerts nobody receives |
| Workload hardening | Operating system patching, container images, CIS hardening, secrets management, vulnerability scanning | Unpatched images, secrets in code or environment variables |
| Resilience and governance | Backup and restore tests, multi-AZ design, landing zone guardrails, tagging, incident response plan | Backups never restored, no account structure or policy guardrails |
Which frameworks should you assess against?
Pick one primary baseline and map others to it. Assessing against a known framework keeps findings objective and makes it easier to show progress to auditors and management.
- CIS Benchmarks are vendor-neutral configuration guides, with versions for AWS, Azure and Google Cloud foundations. They are the most practical baseline for configuration checks.
- The AWS Well-Architected Security Pillar covers design principles and best practices for identity, detection, infrastructure protection, data protection and incident response on AWS. Azure and Google Cloud publish equivalent frameworks.
- The CSA Cloud Controls Matrix has 197 control objectives in 17 domains. It suits organisations that want a cloud-specific control set that maps to ISO 27001 and other standards.
- The NIST Cybersecurity Framework organises security outcomes into functions (govern, identify, protect, detect, respond, recover) and works well for reporting to management.
- Regulation-driven requirements such as NIS2, GDPR, DORA for financial entities, or HIPAA and PCI DSS where they apply. Map them to your technical baseline rather than assessing them separately. Our NIS2 compliance guide explains the main obligations.
How to run the assessment step by step
Most assessments follow six steps and take from a few days for a single account to several weeks for a large multi-cloud estate.
- Agree scope and rules. List accounts, subscriptions and projects, the applications in scope, any testing restrictions and who receives findings.
- Collect context. Architecture diagrams, data classification, compliance obligations and recent incidents. Interview the platform and application owners.
- Run automated checks. Enable posture tools such as AWS Security Hub or Microsoft Defender for Cloud with CIS or provider best-practice standards, and scan workloads for vulnerabilities.
- Review manually. Look at identity design, network paths to sensitive data, logging coverage and how changes reach production. This is where most high-impact findings come from.
- Test where needed. Validate the riskiest findings with targeted penetration testing, within the provider's rules.
- Report and plan. Rate each finding by likelihood and impact, assign an owner and a target date, and separate quick fixes from design changes.
Can you penetration test your cloud environment?
Yes, within the provider's rules. The AWS penetration testing policy lets customers test their own infrastructure without prior approval for a list of permitted services, while activities such as denial-of-service testing have separate rules. Microsoft publishes rules of engagement for testing Azure and Microsoft cloud services. Always test only resources you own, and tell your security monitoring team or provider before you start.
What should the report include?
A useful report is short at the top and detailed underneath. Expect:
- An executive summary with the overall risk picture and the top five issues
- A findings register with severity, affected resources, evidence, business impact and the fix
- A score or compliance percentage against the chosen baseline, so you can track progress
- A remediation roadmap: quick wins in the first weeks, design changes over the next quarter
- Recommendations for preventive guardrails, so the same issues do not come back
Automated tools versus expert review
| Automated posture tools | Expert-led assessment | |
|---|---|---|
| Speed | Minutes to hours, continuous | Days to weeks |
| Strength | Finds known misconfigurations across every account | Finds risky designs, privilege paths and process gaps |
| Weakness | Many low-priority findings, no business context | A point-in-time view unless repeated |
| Best use | Daily guardrail and drift detection | Annual review, before audits, after major change |
Most organisations need both: an expert assessment to set the baseline and priorities, and continuous monitoring to keep it.
Example: a Well-Architected baseline at WorkBuster
WorkBuster, a SaaS recruitment platform used around the world, moved its platform to AWS with Opsio. According to the WorkBuster case study, the environment was built with CloudFormation templates as infrastructure as code and follows the AWS Well-Architected security best practices: encryption in transit at the load balancer, encryption at rest on RDS storage, and CloudWatch dashboards and alarms. Because the infrastructure is defined in code, security settings can be reviewed and changed like any other code, which makes repeat assessments faster.
How to choose an assessment provider
- Ask which baseline they assess against and ask for a sample report.
- Check they cover your clouds and your regulatory context, for example NIS2 in the EU or sector rules in India.
- Make sure manual review is included, not just a tool export.
- Ask how findings are prioritised and whether they help with remediation.
- Agree how data and access are handled during the assessment, and that access is removed afterwards.
How Opsio helps
Opsio runs cloud security assessments for AWS, Azure and Google Cloud, combining posture tooling with manual review against CIS, Well-Architected and NIS2 requirements. After the assessment we can fix findings and keep the environment monitored 24/7 through our cloud security services.
Frequently asked questions
How long does a cloud security assessment take?
A single account or subscription with a few applications can be reviewed in a few days. A multi-account, multi-cloud estate with compliance mapping usually takes several weeks, depending on scope and how quickly evidence is available.
How often should you assess cloud security?
At least once a year, plus after major changes such as a migration, a merger or a new regulatory requirement. Continuous posture monitoring should run in between.
What is the difference between a security assessment and a penetration test?
An assessment reviews configuration, design and processes across the whole environment. A penetration test tries to exploit specific weaknesses to prove impact. Assessments often include a targeted penetration test for the highest risks.
What tools are used to assess cloud security?
Provider tools such as AWS Security Hub and Microsoft Defender for Cloud, open-source scanners that check CIS controls, vulnerability scanners for workloads and containers, and manual review of identity and network design.
Does a cloud security assessment help with NIS2?
Yes. NIS2 requires risk management measures such as access control, logging, incident handling and supply chain security. An assessment shows where your cloud environment meets those measures and where it does not.
About the Author
Group COO & CISO
Fredrik is the Group Chief Operating Officer and Chief Information Security Officer at Opsio. He focuses on operational excellence, governance, and information security, working closely with delivery and leadership teams to align technology, risk, and business outcomes in complex IT environments. He leads Opsio's security practice including SOC services, penetration testing, and compliance frameworks.
Editorial standards: This article was written by a certified practitioner, named in the byline above. We revise it when the technology or regulation it covers changes; the dates above show the latest update. Opsio maintains editorial independence — we recommend solutions on technical merit, not commercial relationships.