CLOUD SECURITY ASSESSMENT
Every major cloud provider operates on the same contract: the shared responsibility model. The provider secures the cloud — the physical data centres, the hypervisors, the underlying network. You secure what you put in it — your identities, your configurations, your data, your workloads. That line is where cloud security lives and dies, because the provider's side of it is very well defended and yours is entirely up to you. In practice, most cloud breaches are not provider failures at all; they are misconfigurations on the customer's side of the line — a storage bucket left public, an over-privileged role, a security group open to the world. The provider did its job; the configuration didn't. A cloud security assessment checks your side of that line, across Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).
Why does misconfiguration dominate? Because the cloud makes everything a setting. In a traditional data centre, exposing a database to the Internet takes deliberate work — cables, firewall changes, someone noticing. In the cloud it takes one flag on one resource, set once by someone under deadline pressure, and it stays that way silently until someone finds it. The same consoles and APIs that make the cloud fast to build on make it fast to misconfigure, and the defaults are not always the safe choice. Meanwhile the number of services, options, and interactions grows every year, so the surface a team has to reason about grows faster than any team's ability to review it by hand. That is the gap an assessment closes: a systematic, structured look at the configuration decisions that have accumulated across your environment, made by different people at different times, measured against what the provider itself says a secure setup looks like.
A configuration review is also a different exercise from a penetration test, and the difference matters. A pentest asks "can we get in?" — it proves exploitability from an attacker's vantage point, and its answer is only as broad as the paths the tester found. A configuration review asks "is this set up correctly?" — it works from the inside with visibility into the environment, so it catches the weak settings an attacker hasn't found yet, not just the ones already reachable. The two are complementary: the review gives breadth across the whole environment, targeted testing gives proof of impact where it counts. Our assessment combines both.
What we assess
The common misconfiguration classes recur across every provider, even though the service names differ. Our review covers:
- Identity and access management (IAM) — over-privileged roles and policies, unused credentials, weak or missing MFA, and trust relationships that grant more than anyone intended. In the cloud, identity is the perimeter — a compromised over-privileged credential bypasses every network control you have.
- Network configuration — services exposed to the Internet that should not be, security groups and firewall rules that are broader than the workload needs, and missing segmentation between environments.
- Storage exposure — public buckets and blobs, permissive access policies on object storage, and data shared more widely than its sensitivity warrants.
- Logging and monitoring — whether audit logging is enabled where it matters, whether logs are protected from tampering, and whether anyone would actually notice an incident in progress.
- Encryption — data at rest and in transit: what is encrypted, what isn't, and how the keys are managed.
- API security — the management and application APIs your cloud footprint exposes, and the access controls in front of them.
These are the classes; the exact checklist is not fixed. The exact scope adapts to your environment and constraints — we start from the services you actually run and agree the checklist with you. An environment built on managed containers raises different questions than one built on virtual machines and serverless functions, and reviewing services you don't use helps no one.
How we work
- Scope the environment — We map your cloud footprint with you: which provider(s), which accounts or subscriptions, which services are in play, and what matters most to the business. The checklist for the engagement is agreed here, before any review begins.
- Access and configuration review — With read-level visibility into the environment, we review the configuration systematically against the agreed checklist — IAM, network, storage, logging, encryption, and API controls — benchmarked against the CIS Benchmarks for your provider and the provider's own security best-practice guidance.
- Targeted testing — Where a finding suggests real exposure — a reachable service, a permissive policy, an exposed store — we validate it, so the report distinguishes between a deviation on paper and a weakness an attacker could actually use.
- Reporting — Findings are written up with severity, evidence, and remediation guidance tied to your environment, plus an executive summary for management.
- Retest — After your team applies the fixes, we re-verify each finding and update the report to reflect what has been closed.
What you get
Every report contains, at minimum:
- Executive summary — the business-level risk picture, suitable for management and auditors.
- Findings by Risk Level — each issue rated Critical, High, Medium, or Low so remediation can be prioritised objectively.
- Reproduction steps and POC where applicable — for validated exposures, the exact steps that demonstrate the issue; for configuration deviations, the precise setting and where to find it.
- Remediation guidance — practical fixes tied to your environment and provider, not generic boilerplate.
- Retest verification — findings are re-checked after your fixes and the report is updated to reflect closed items.
Team credentials
The assessment is performed by our in-house team holding industry certifications including OSCP, OSCE, CREST CRT, CREST CPSA, and GIAC GREM — credentials earned through rigorous, hands-on examination. The same offensive-security background informs the review: we assess configurations the way an attacker would use them, not just against a checklist. See the full list of certifications the team holds.
Standards
The review is benchmarked against the CIS Benchmarks for the relevant provider — the community-maintained hardening baselines for AWS, Azure, and GCP — together with each provider's own well-architected and security best-practice guidance. These are the references your cloud team already works from, so findings map directly onto actions.
A cloud assessment covers the configuration layer; the workloads running on top of it deserve their own scrutiny. When your servers and applications run in the cloud, the assessment pairs naturally with our infrastructure and web application penetration tests — the assessment secures the platform your workloads sit on, and the pentests attack the workloads themselves.
Last reviewed: 11 Jul 2026
Book a scoping callFrequently asked questions
What is the shared responsibility model, and what do you assess?
Every major cloud provider operates on the same contract: the provider secures the cloud — the data centres, hypervisors, and underlying network — and you secure what you put in it: your identities, configurations, data, and workloads. A cloud security assessment checks your side of that line across AWS, Azure, and GCP — IAM, network configuration, storage exposure, logging and monitoring, encryption, and API security.
Why do most cloud breaches come from misconfiguration?
Because the cloud makes everything a setting. Exposing a database to the Internet in a traditional data centre takes deliberate work; in the cloud it takes one flag on one resource, set once under deadline pressure, and it stays that way silently until someone finds it. The number of services and options grows every year, so the surface a team must reason about grows faster than any team can review by hand.
How is a cloud assessment different from a penetration test?
A pentest asks 'can we get in?' — it proves exploitability from an attacker's vantage point, and its answer is only as broad as the paths the tester found. A configuration review asks 'is this set up correctly?' — it works from the inside with visibility into the environment, so it catches weak settings an attacker hasn't found yet. The two are complementary, and our assessment combines both.
Which providers and benchmarks do you use?
AWS, Azure, and GCP. The review is benchmarked against the CIS Benchmarks for the relevant provider — the community-maintained hardening baselines — together with each provider's own well-architected and security best-practice guidance, so findings map directly onto actions your cloud team already works from.

