Overview
US companies on AWS, Azure or Google Cloud tend to fail in one place first: identity. Broad roles, forgotten access keys and trust between accounts turn a small foothold into wide access. We test with read access plus a scoped attacker identity, follow the privilege paths that exist, and report findings your platform team can turn into policy changes. Each provider's current testing policy is checked before work starts.
Cloud platforms shift the risk from unpatched software to how you configure identity and access. The provider secures the infrastructure; everything above it, who can do what, what is exposed to the internet, and how services trust one another, is yours to get right. A cloud assessment examines that configured surface the way an attacker with a leaked key or a foothold would, looking for the permissions and exposures that turn a small mistake into account-wide access.
We work through identity first, because it is where cloud compromise lives. Over-broad roles, unused but powerful permissions, keys that never expire, and policies that allow a principal to grant itself more access all create privilege-escalation paths that are invisible until mapped. From there we assess exposed storage buckets and databases, public services and network rules, secrets left in metadata or configuration, and the trust between accounts, subscriptions or projects.
This is a configuration and identity review conducted within your provider's testing policy, not an attempt to attack the provider's platform. Findings are tied to the specific resource and setting, scored with CVSS v4.0, and paired with the exact change, an IAM policy, a bucket setting, a network rule, that fixes them. Where you run across more than one provider, we normalize the findings so your team sees a single prioritized list.
How US engagements run
- Delivered remotely from India, 9.5 hours ahead of US Eastern in US daylight time and 10.5 hours in winter; calls and testing windows are set around your time zone at scoping
- Fixed-price proposals in US dollars, with scope, dates and the free retest written in before any work begins
- Written authorization signed by someone with authority over every target, because the federal Computer Fraud and Abuse Act and state laws make permission the dividing line
- Reports that name the requirement a test supports, such as PCI DSS 11.4, the FTC Safeguards Rule or SOC 2, without claiming a QSA, ASV or C3PAO role we don't hold
What's included
Our approach
- Scope & accessWe confirm accounts, provider policy and the access needed for the review.
- Configuration reviewWe assess identity, storage, network and service settings across the estate.
- Path analysisWe map privilege-escalation and lateral paths between identities and accounts.
- ValidationWe safely demonstrate impactful paths within the provider's testing policy.
- Report & debriefFindings are tied to resources and settings with exact remediation.
What you receive
- Identity and privilege-escalation path analysis
- Inventory of exposed storage, data and services
- Findings scored with CVSS v4.0 per resource
- Exact configuration changes to remediate
- Free retest of fixed issues and an attestation letter
Standards & frameworks
- CIS Benchmarks
- NIST SP 800-115
- MITRE ATT&CK
- OWASP WSTG
- CVSS v4.0
- CWE
- PCI DSS v4.0.1 Req. 11.4
- NIST SP 800-171
Frequently asked questions
Do you attack the cloud provider itself?
No. We test your configuration and identity within the provider's acceptable-use and testing policy. Attacking the provider's shared infrastructure is both prohibited and beside the point, since your risk lives in how you set up and permission your own account.
What access do you need?
A read-oriented review role across the accounts in scope lets us assess configuration thoroughly and safely. For targeted exploitation of a path we agree the specific permissions with you first, so the engagement stays within the access you intend to grant.
Can you test more than one provider at once?
Yes. Many organizations run across AWS, Azure and GCP, and we assess each against its own best practice while presenting a single normalized, prioritized list of findings so your team is not juggling three separate reports.
Does an internal and external test cover PCI DSS Requirement 11.4?
It can, when scoped for it. PCI DSS v4.0.1 wants penetration tests from inside and outside the network every year and after significant changes, following a documented methodology, plus proof that segmentation holds. We aren't a QSA or ASV, so quarterly ASV scans and the assessment itself stay with those firms.
Can you test our US networks without traveling?
Network, Active Directory, cloud and Kubernetes testing run remotely through a VPN account, jump host or small test device you place on the network. Wireless and hardware work need someone near the equipment; tell us the sites at scoping and we'll say plainly whether and how we can cover them.