Cloud Security Assessment. @cloud-security-assessment

Most cloud breaches start with configuration, not code: a public bucket, an over-privileged role, a forgotten asset. This sprint assesses a defined AWS, Azure, or GCP environment — inventorying assets, reviewing identity and access paths, and analyzing configurations against benchmarks and real attack paths.

Findings are ranked by exploitability and blast radius, not just benchmark score, so the register reads as a work plan. Scrums.com delivery teams build and run cloud environments for 400+ companies, and this assessment applies that operating experience. The finish state: a ranked risk register, quick wins remediated during the sprint, and a plan for the rest.

Environment inventory

Every asset in the agreed accounts enumerated — including the forgotten ones, which is usually where the trouble lives.

Identity & access review

Roles, policies, keys, and trust relationships reviewed for over-privilege and escalation paths — the routes an attacker chains to reach data.

Configuration & exposure analysis

Configurations checked against benchmarks and real attack paths: public storage, open security groups, unencrypted stores, missing logging.

Ranked remediation plan

Findings ranked by exploitability and blast radius, quick wins fixed during the sprint, and a plan for the rest.

1. Scope. Agree the accounts, subscriptions, or projects in scope, and set up read-level access.
2. Build. Inventory assets, review identity, analyze configuration and exposure; fix agreed quick wins.
3. Handover. Ranked risk register, remediation plan, and a debrief with your team.

The Cloud Security Assessment is a menu item on the Scrums.com delivery catalog, available at every plan tier. Add it to your plan backlog and your delivery team schedules it like any other item — scoped, tracked, and reported through the SEOP. See Delivery Plan Tiers.

Is this a penetration test?

No — it is a configuration, identity, and exposure assessment with attack-path analysis. It does not exploit systems. Many teams run it first, then point a penetration test at what remains.

What access do you need?

Read-level security-audit roles on the in-scope accounts and enough architecture context to judge intent — no write access is required for the assessment itself.

Who fixes the findings?

Quick wins are fixed during the sprint. The rest goes to your team with the plan, or to the Security Hardening & Remediation Sprint; the DevSecOps Security Automation item then keeps configuration drift from rebuilding the list.