Cloud security assessment
Human-led assessment of AWS, Azure or GCP for identity, exposure and attack paths. Not a CSPM spreadsheet. Findings are paths a person could walk, with a retest after you change them.
- Human-led
- Every reported finding reproduced
- Retest included
-
Human testers leadTooling widens coverage only
-
Scoped firstScope and rules agreed before testing
-
Retest includedIn-scope fixes retested
-
Reproduced findingsEvidence a developer can replay
What we test
Identity and privilege
Roles, policies, trust between accounts, and human access that outlived the project.
Details
Roles, policies, trust between accounts, and human access that outlived the project. We look for a path, not a percentage score.
Workload identities
Roles attached to compute, CI and serverless.
Details
Roles attached to compute, CI and serverless. A pipeline identity that can read production secrets is a finding; a theoretical admin star is context.
Public exposure
Details
Storage, snapshots, management ports and consoles reachable from the internet, checked against what you meant to publish.
Network edges
Security groups, firewalls and peering that collapse an account boundary.
Details
Security groups, firewalls and peering that collapse an account boundary. Compared with external infrastructure when the question is the internet perimeter rather than the account.
Data stores
Details
Who can read the database, the warehouse or the bucket, and whether backups are a second copy of the same mistake.
Logging you would actually use
Whether the trail exists for the actions that matter.
Details
Whether the trail exists for the actions that matter. We do not grade your entire SIEM.
Kubernetes, if agreed
Cluster auth, overly broad workload permissions and exposed dashboards.
Details
Cluster auth, overly broad workload permissions and exposed dashboards. Not included by default just because a cluster exists.
Attack-path narrative
Details
A short chain from a realistic starting point to sensitive data, written so an owner can break the chain. See cloud attack paths.
About this scope
Cloud risk is usually identity and exposure, not a missing patch on a logo. We start from the accounts you name and ask what an over-broad role, a public bucket or a workload identity could reach.
Not a CSPM export
Read more
Configuration tools are good at volume. They are poor at telling you which of the four hundred items a person could actually use. This assessment is manual judgement on the identities and exposures in scope, informed by your architecture, with evidence for the paths we stand behind. Background reading: cloud IAM and workload identities.
Shared responsibility still applies. We do not test the cloud provider’s hypervisor, and we do not claim your account is certified. We also do not need standing admin if a read-heavy role plus a few agreed actions is enough — that is a scoping choice, not a slogan.
Deliverables
- Executive summary of the paths that matter, not a dump of every benchmark row.
- Technical findings with the identity, the resource and the evidence.
- A note of accounts and regions actually reviewed.
- Retest status for fixes in the window.
More about the report
A report can support SOC 2 and ISO 27001 evidence. It does not certify the company, and it does not replace the auditor. PoCForge is not a certification body and does not claim CERT-In empanelment. If a contract names an empanelled auditor, read when CERT-In empanelment is required and check the official list before you shortlist.
Who this fits
A good fit
- Teams who already run a cloud and want an attacker’s reading of identity and exposure before a customer review, a migration, or an internal argument about which role to cut.
- It is a poor fit if you wanted someone to turn on a commercial CSPM and email the PDF.
- Application bugs in the product itself belong on the web or API pages.
- If you run Azure and Microsoft 365 and want the tenant and your security tooling’s detection reviewed as well, see the Microsoft cloud readiness assessment.
Investment
Indicative $5,000 – $8,000 before taxes. Price depends on account count and identity complexity. Multi-cloud and Kubernetes move the quote. Use the starting prices and the India cloud page.
TYPICAL INVESTMENT: $5K – $8K · taxes as applicable · final quote based on accounts and identity complexity.
What to send before a cloud assessment
Name the accounts, subscriptions or projects, the regions that hold production, and the identity model you think you operate: human SSO, long-lived keys, or workload roles. A diagram is welcome and will be checked, not trusted. If a landing zone or a sandbox must not be touched, list it. Kubernetes, CI and a data account are in only when you say they are.
Read-only access is the usual start. Where a path can only be confirmed by an agreed, reversible action, that action is written into the rules first. We will not “prove” impact by deleting a bucket or rotating a key you still need. Shared responsibility is stated in the report: provider platform bugs are out; your roles, exposure and trust policies are in.
Good remediation is a broken path: a trust policy tightened, a public grant removed, a workload role cut back to the API it calls. A screenshot of a benchmark at 80 percent is not the outcome this engagement is for. If you already pay for a CSPM, keep it. Send us the items you cannot tell apart, and we will say which ones an attacker would actually use.
Scope and rules
- Accounts and clouds. AWS, Azure, GCP or a named mix. Organisations, subscriptions, projects and what is out, including production change limits.
- Access model. Read-only where it answers the question. Any change or exploit attempt is named in the rules before it happens.
- Map identity and exposure. Humans, workloads, trust policies and internet-facing entry points inside the accounts.
- Test the plausible paths. Confirm the path with evidence. Drop findings that are true on paper and useless in this account.
- Report. Priorities for the people who own IAM and the platform, with the policy or resource named.
- Retest. The paths you close are checked again. A new account added next quarter is a new scope.
Cloud identity attack-path review
Anonymised cloud identity attack-path pattern: role chains, workload identities and data reachability — finding classes only.
Read the case study →- Human-led
- Every reported finding reproduced
- Retest included
Related
Frequently asked questions
Is this a CIS benchmark or CSPM export?
No. Benchmarks can be an input. The deliverable is judged paths and misconfigurations, with evidence, not a spreadsheet of every control.
Which clouds do you assess?
AWS, Azure and GCP, scoped per account or subscription. More than one cloud is fine when the trust between them is the point.
Do you need admin access?
Often a read role is enough to start. Anything that changes the account, or any exploit attempt, is agreed first.
Is Kubernetes included?
Only when the cluster is named in the scope. A cluster we were not told about is not silently tested.
Do you claim CERT-In empanelment?
No. PoCForge does not claim CERT-In empanelment.
Scope a cloud assessment
Name the cloud, the accounts and whether identity or internet exposure is the question.
Request a free scope review →