Cloud Security
AWS, Azure, GCP — Configuration, identity and exposure review across your cloud estate. Most cloud incidents are not exotic — they are an over-permissioned role, a trust relationship nobody reviewed, or a storage bucket that outlived its owner. We look for the paths that turn one of those into account compromise.
Is this the right engagement?
- You run production workloads in AWS, Azure, or GCP
- Your cloud estate grew faster than your review process
- You need evidence of cloud control effectiveness for an audit or a customer
- You want to know which identities could escalate to account or organization control
Deliverables
- Per-account findings report with severity, affected resources and remediation guidance
- Identity and privilege-escalation path analysis — who can become whom, and how
- Exposure review across storage, compute, networking and secrets management
- Control-plane and logging gap analysis
- Executive summary of cloud risk posture
- Live technical debrief with the platform team
Engagements in this solution
Each engagement is scoped around what you are actually running. Where pricing is standardized you can estimate it online in a couple of minutes.
How the work is run
The same sequence runs underneath every engagement in this solution — specialised here for cloud security.
Scope & authorize
Accounts, subscriptions and projects in scope agreed in writing, with read-only assessment roles provisioned under executed authorization.
Inventory
Enumeration of resources, identities, trust relationships and network boundaries across the agreed accounts.
Analyse identity
Mapping of privilege-escalation and lateral-movement paths between principals, including cross-account trust.
Test exposure
Review of publicly reachable resources, secrets handling, data stores and workload configuration against provider benchmarks and real attack patterns.
Report & brief
Findings prioritized by exploitability rather than by benchmark severity, walked through live with the platform team.
Remediate & retest
One bounded retest validates fixes against every reported finding.
What to expect, and when
Indicative for a standard scope. Your dates are confirmed in writing before any testing begins.
| Stage | Duration | What happens |
|---|---|---|
| Scope & authorize | 2–5 business days | Targets, objectives and rules of engagement agreed in writing. Authorization signed before anything is touched. |
| Test & exploit | 6–12 business days | Manual testing mapped to real attacker tradecraft. Findings are exploited and chained, not just flagged. |
| Report & brief | 3–5 business days | Findings report delivered, then walked through live with the engineers and the executives who own the risk. |
| Remediate & retest | Within 30 days | One bounded retest validates fixes against every reported finding. |
| Total | 3–5 weeks | From signed authorization to retest report, for a standard scope. |
What you can hold us to
Commitments that are checkable, not adjectives.
Findings are prioritized by what an attacker can actually reach, not by a generic CIS severity.
Assessment roles are read-only unless you explicitly authorize more.
Assessed against AWS, Azure and GCP control planes directly — not through a single vendor's abstraction.
Accounts in scope and the fee are agreed before work starts.
One bounded remediation retest is part of the engagement.
Before you ask us
What access do you need?
A read-only assessment role per account in scope. Anything beyond read-only is requested explicitly and authorized in writing.
Do you test the applications running in the cloud?
Not under this engagement — that is an application penetration test. The two are often scoped together.
Can you assess multiple providers at once?
Yes. Multi-provider estates are priced as a single engagement.
