AWS security assessment
A human-led review of your AWS accounts: identity and access, network exposure, compute and data stores, keys and secrets, and logging — combined with attack-path testing that shows what a compromised identity or exposed service could actually reach.
- Read-only review
- Attack paths, not just a benchmark
- Retest included
-
Read-only accessA review role you create and revoke
-
Sized to scopeDates agreed after the scope call
-
Retest includedWithin 6 months, up to 10 issues
-
Walkthrough callEvidence, steps and fixes by team
What we test
Seven areas, ranked by what an attacker could reach. Open a card for the full checklist.
Identity and access
Who can do what, and how roles chain together.
Details
- IAM users, groups, roles and policies
- Cross-account trust and federation (including SAML and OIDC)
- Privilege-escalation paths between roles
- Root account protection and break-glass access
- Access keys, temporary credentials and instance profiles
IAM and Organisations. Users, roles, policies, permission boundaries, SCPs, account factories and break-glass.
Network and exposure
What the internet and peered networks can reach.
Details
- Public endpoints and internet-facing services
- Security groups and network ACLs
- VPC peering, Transit Gateway and PrivateLink
- Exposed management ports and open databases
Network. VPCs, subnets, route tables, security groups, NACLs, peering, Transit Gateway, endpoints and public load balancers.
Compute and containers
Instances, clusters and functions, and the roles they carry.
Details
- EC2 instance configuration and metadata exposure
- EKS and ECS task roles and cluster access
- Lambda permissions and environment secrets
- Auto Scaling and launch templates
Compute. EC2 metadata and IAM roles, AMIs, user data, EKS RBAC and node roles, ECS task roles, Lambda resource policies and environment variables.
Data stores
Buckets, databases and shared snapshots.
Details
- S3 bucket policies, ACLs and public access blocks
- RDS and other database exposure and encryption
- Backup and snapshot sharing
Data. S3 public access, bucket policies, RDS/Aurora exposure and encryption, snapshots shared outside the account.
Keys and secrets
Key policies, secret stores and leaked credentials.
Details
- KMS key policies and grants
- Secrets Manager and Parameter Store exposure
- Hard-coded secrets in images or pipelines
Keys and secrets. KMS key policies, Secrets Manager, Parameter Store, and secrets found in pipelines or images during the review.
Logging and detection
Whether alerts would fire on the paths we find.
Details
- CloudTrail coverage and integrity
- GuardDuty and Security Hub findings worth acting on
- Config rules and organisation-level logging gaps
Detection. CloudTrail (management and data events where enabled), GuardDuty, Security Hub, Config, and whether alerts would fire on the paths we mapped.
Organisation guardrails
Account structure, SCPs and baselines.
Details
- AWS Organisations structure
- Service control policies (SCPs)
- Account baseline and guardrails
How scope is sized
Scope is sized to the AWS services you run across the accounts you name. We use the AWS security benchmark and CIS-aligned control language as a checklist for coverage, then validate what matters with a tester. Findings are ranked by what an attacker could reach, not by a benchmark score.
Attack paths, not only misconfigurations
A bucket marked public is a finding. A developer role that can assume an admin role that can read production secrets is a path. We spend time on the second kind: chaining identity, compute and data permissions the way an attacker would after phish or a leaked key. The report shows the path, the blast radius and the smallest change that breaks it.
Read more
Where GuardDuty or Security Hub already flagged something we agree with, we say so and focus effort on what the tools missed or under-ranked.
What you receive
- An executive summary written for non-specialists.
- Technical findings with evidence and steps to reproduce.
- Severity based on what a realistic identity could reach.
- Remediation guidance mapped to the owning team (identity, network, platform).
- A walkthrough call.
- A retest of in-scope fixes that are ready within 6 months of the original test (up to 10 issues), with an updated closure note.
Who this is for
A good fit
- Production or staging workloads in AWS
- Before a major release
- After an organisation restructure
- When onboarding a new account model
- When a customer or auditor asks for evidence of a cloud penetration test
Not what this is
- A benchmark export on its own
- A change to your accounts: the review is read-only
- Azure or GCP: see the multi-cloud assessment
Full description
Organisations running production or staging workloads in AWS who want more than a benchmark export. Useful before a major release, after an organisation restructure, when onboarding a new account model, or when a customer or auditor asks for evidence of a cloud penetration test.
Common findings (examples)
- An identity with more privilege than its job needs, or a path from a low-privilege role to administrator.
- Storage buckets or databases reachable from the internet without a good reason.
- Security groups or firewall rules that leave management ports open to the world.
- Long-lived access keys or secrets in instance metadata, pipelines or code repositories.
- Logging turned off, or alerts that would not fire on the paths an attacker actually uses.
What we need from you
- List of in-scope accounts (and organisation or management structure if used).
- Read-only access for the review role, created by you and revoked when we finish.
- A named contact for production change windows and out-of-scope services.
- Architecture notes or diagrams if you have them (helpful, not required).
Typical timeline
Duration depends on how many accounts and services are in scope. A single account with a focused service set is often a short engagement; a multi-account organisation with containers, data stores and custom identity federation takes longer. Dates are agreed after the scope call.
What stays out of scope by default
- Denial-of-service against production.
- Changing IAM, network or data settings (review is read-only).
- Accounts or regions you did not name.
- Marketplace third-party products outside your AWS boundary, unless you add them.
Multi-account estates
Organisations with many accounts are normal. We follow trust across the accounts you name — SCPs, cross-account roles and shared services — so a developer account that can reach production secrets is visible as one path. Per-account checklist noise is filtered unless it changes blast radius.
Standards and method
Coverage is guided by the AWS security benchmark and CIS-aligned AWS controls, then validated by a tester. Network and application paths follow the assessment practices in NIST SP 800-115.
Scope and rules
- Scope call. Accounts, services in use, production limits and any services that must not be touched.
- Read-only access. You grant a least-privilege review role. We confirm it before testing starts.
- Configuration review. Identity, network, compute, data, keys and logging against the AWS security benchmark and common CIS control language.
- Attack-path analysis. From realistic starting identities (a developer role, a compromised instance profile, an over-permissive service account), we map what could be reached.
- Controlled validation. High-risk paths are checked safely where agreed. Destructive actions stay out of scope.
- Report and retest. Findings with evidence, a walkthrough and a retest of fixes that are ready within 6 months of the original test (up to 10 issues).
Cloud identity attack path
Anonymised pattern: role chains, workload identities and data reachability. Finding classes only.
Read the case study →- Human-led review, checked by a tester
- Read-only access; nothing changed in your accounts
- Retest within 6 months (up to 10 issues)
Related
Frequently asked questions
Is this just a benchmark scan of AWS?
No. Tooling helps with coverage, but findings are checked by a tester and ranked by what an attacker could reach, not by a benchmark score.
What access do you need?
Read-only access to the in-scope accounts. Any active testing is agreed separately in writing.
Can you cover more than one cloud?
Yes. Multi-cloud work can be scoped together through the cloud security assessment.
Will you change anything in our accounts?
No. The review is read-only. Controlled validation uses agreed test resources or stop points.
Do you test containers and serverless?
Yes, when those services are in the named scope.
How is this different from the multi-cloud assessment?
This page is AWS-only. The multi-cloud assessment covers AWS, Azure and GCP together.
Does the report help with SOC 2 or ISO 27001?
Yes, as evidence that cloud controls were tested. It does not replace the auditor.
Do you need Organisation administrator access?
No. Read-only organisation and account roles are enough for the review. We never ask for root.
Ready to scope this?
Tell us what is in scope and what you want to learn. We reply with a suggested approach.
