Cloud Security Assessment
Assess the security of authorized cloud environments across identity, configuration, network controls, workloads and data.
Cloud environments are assembled quickly and changed constantly. A role is widened to unblock a deployment, a storage bucket is opened for a migration, a service is stood up for a proof of concept and never removed. Individually these are reasonable decisions; together they become the environment's actual security posture.
A cloud assessment establishes what that posture is. Not what the architecture diagram says, but what the configuration currently permits — which identities can reach which resources, what is exposed beyond its intended audience, and where a single misconfiguration would matter.
What is a cloud security assessment?
A cloud security assessment reviews identity and access, cloud configuration, network security, storage access, compute configuration, exposed services, privilege escalation paths, and security boundaries between accounts, subscriptions, projects and environments, measuring the gap between the architecture as designed and the environment as actually configured. Scope is tailored to the specific cloud environment and engagement; TMG Security does not claim uniform depth across every service of every provider.
Who needs it? Organizations migrating to the cloud and establishing security boundaries before production load, organizations with a multi-account estate where separation has grown organically, teams running a post-incident review to establish what an identity or service could actually have reached, and organizations due for periodic validation, since configuration drifts even when nothing is deliberately changed.
How TMG Security helps. TMG Security assesses identity and access, configuration, network security, storage, compute and privilege management against the environment as actually configured, and delivers findings your team can act on.
Configuration drifts faster than documentation
Cloud permissions are easy to widen and difficult to narrow. Broadening a policy unblocks a deployment immediately; narrowing it risks breaking something nobody can fully test. So permissions accumulate, and the effective access in an environment quietly diverges from what anyone intended.
The same applies to network controls, storage settings and service exposure. None of it is negligence — it is the natural result of a system that many people change under time pressure. Assessment measures the gap between the architecture as designed and the environment as configured.
The layers this assessment covers.
CONTROL
PLANE
Depending on environment and engagement scope. We do not claim automatic support for every service of every provider.
Each layer is a boundary. Cloud attack paths tend to run through permissions rather than through the network.
- IDENTITYIdentity & accessRoles, policies and trust relationships
- NETWORKNetwork controlsSecurity groups, routing, segmentation
- WORKLOADSCompute & servicesInstances, functions, managed services
- STORAGEStorageObject and block storage, and who can read it
- DATADataThe records the layers above ultimately protect
Conceptual view. Assessment scope is tailored to the cloud environment and engagement.
What we assess
Assessment scope is tailored to the cloud environment and engagement. We do not claim uniform depth across every service of every provider.
Cloud Security Assessment vs. Cloud Penetration Testing
A cloud security assessment reviews configuration against best practice, identity and access, cloud configuration, storage, network controls and privilege boundaries, measuring the gap between the architecture as designed and the environment as actually configured. Cloud penetration testing goes further: it authorises scope with the cloud provider and actively traces realistic escalation and access paths to establish what an identity can actually reach, rather than reviewing configuration alone.
Organizations early in a cloud programme, or wanting a broad baseline, typically start with an assessment. Organizations wanting to validate whether a real attacker could exploit what the assessment finds typically add a penetration test on top of it. Neither engagement claims uniform depth across every service of every cloud provider.
How a cloud assessment runs
- 01AUTHORIZEConfirm scope and satisfy the cloud provider's testing requirements.
- 02INVENTORYEstablish which accounts, services and identities are in scope.
- 03IDENTITYAnalyse permissions, trust relationships and effective access.
- 04CONFIGReview service configuration, exposure and network controls.
- 05PATHTrace realistic access and escalation paths within scope.
- 06REPORTFindings, affected resources and remediation guidance.
When Should a Cloud Environment Be Assessed?
Findings your team can act on.
Which of these apply depends on engagement scope.
Weaknesses identified across the environment in scope, with the reasoning behind each.
Settings that widen exposure or weaken a boundary, described precisely enough to locate.
What a finding means in your environment rather than against a generic scoring table.
Supporting detail so findings can be verified rather than taken on trust.
Practical direction on addressing each finding, including where the change belongs.
An order of work, so limited engineering time goes to what matters most.
Verification that addressed findings no longer reproduce, within the agreed retest scope.
Adjacent parts of the infrastructure.
How pricing and scope are determined
There is no published fixed price for a cloud security assessment. Each engagement is scoped and priced individually based on factors such as the number of cloud accounts or subscriptions in scope, the number of services assessed, and whether the environment is single-cloud, multi-cloud or hybrid. These factors are discussed during scoping before a quote is provided.
Questions we get asked before an engagement.
Major providers permit customer testing of their own resources under published policies, with some activities restricted or requiring notification. Those requirements are confirmed during scoping and testing stays inside them.
Cloud assessment is offered across major platforms, but we would rather scope honestly than claim uniform depth everywhere. Which platforms and services an engagement covers — and what it will meaningfully assess — is agreed before work starts.
They overlap. A configuration review assesses settings against a baseline; an assessment works from an identity or position and establishes what can actually be reached. The second is what turns a list of settings into an attack path.
For identity-focused work, yes — an identity to start from is what makes access-path analysis possible. Unauthenticated assessment of externally exposed cloud resources can be scoped separately.
Timelines depend on the number of cloud accounts or subscriptions in scope, the number of services assessed, and whether the environment is single-cloud, multi-cloud or hybrid. These factors are discussed during scoping.
Request a Cloud Security Assessment
Tell us how your accounts are structured and where the sensitive workloads sit. We will scope around the identities that reach them.