What do organisations get wrong when they assume cloud testing is the same as on-premises pentesting?

A common mistake is assuming the same methods work unchanged in the cloud. Cloud testing has to account for provider rules, shared infrastructure, incomplete visibility into underlying hardware, and the possibility that some server-side issues belong to the provider, not the tenant. Ignoring those differences can lead to invalid tests, missed gaps, or unnecessary conflict with the provider.

Why cloud testing is not just “pentesting in a different data centre”

Cloud assessment starts from a different trust model. In on-premises testing, the tester often has a relatively clear boundary around systems, hypervisors, and network controls. In cloud environments, the tenant, provider, and managed service layers share responsibility, so the test has to distinguish what the organisation controls from what the platform owns. That changes what can be safely tested, observed, and concluded.

The practical mistake is treating provider-managed layers like tenant-owned infrastructure. That leads to tests that either overreach, miss the real attack surface, or produce findings the organisation cannot actually fix. A cloud test should focus on exposed configuration, identity, APIs, storage, workload paths, and control-plane behaviour rather than assuming a traditional perimeter model.

Cloud security assessments also need to account for the fact that some evidence is intentionally inaccessible. You may not get hardware-level visibility, packet access, or the same agent-based telemetry you would expect on premises. That is not a gap in the test design if the platform does not expose it. The better question is whether the organisation has sufficient logging, permissions, and configuration control to prove its own security posture.

Where cloud tests usually go wrong

One common failure is using an on-premises exploit mindset against cloud-managed services. In a cloud environment, the highest-risk issues are often misconfiguration, excessive permissions, exposed interfaces, weak segregation between tenants or accounts, and insecure use of identity and secrets. Those problems are often more important than attempts to probe the underlying host.

Another error is assuming every server-side weakness belongs to the tenant. In reality, some issues sit inside the provider boundary, and some are only testable through the provider’s own program or approved methods. Ignoring that line can create false positives, duplicate effort, or conflict with acceptable-use terms. A useful cloud test therefore starts with scope, shared-responsibility boundaries, and permitted methods.

The difference shows up most clearly in access paths. Cloud compromise often follows the control plane rather than the guest OS, so testing should emphasise identity, role assignments, tokens, API access, storage exposure, and cross-account trust. The Azure Key Vault privilege escalation exposure case is a good reminder that mis-scoped access in cloud services can become a direct escalation path, not just a configuration issue.

Risk and Threat Considerations

Cloud testing assumptions become risky when they cause teams to validate the wrong layer, miss provider-owned constraints, or overlook identity-led attack paths. That can leave the organisation with a false sense of coverage while the actual exposure sits in permissions, secrets, or control-plane access.

Failure mechanism: A traditional pentest model may try to inspect or exploit infrastructure elements the tenant cannot observe or control, while failing to test the cloud-native relationships that attackers actually abuse, such as overprivileged roles, exposed APIs, or compromised secrets.

Impact: The result is incomplete assurance, wasted testing effort, and missed paths to compromise, including account takeover, lateral movement across cloud resources, and destructive misuse of managed services. In some cases, the team may also trigger unnecessary escalation with the provider by testing outside allowed boundaries.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS Control 6 — Access Control Management	Cloud testing often hinges on permissions, role scope, and account boundaries.
	CIS Control 8 — Audit Log Management	Cloud assessments depend on logging and visibility into control-plane activity.
	CIS Control 15 — Service Provider Management	Shared responsibility and provider-owned boundaries are central to cloud testing scope.
Recommendation — Review cloud roles and access paths for excessive privilege and remove unnecessary access. Enable and retain cloud audit logs so testing can verify access and administrative actions. Define provider responsibilities and test only the controls your organisation actually owns.
NIST CSF 2.0	GV.SC — Cyber Supply Chain Risk Management	Provider boundaries and managed-service dependencies shape what can be tested and assured.
	PR.AA — Identity Management, Authentication and Access Control	Cloud attack paths often run through identities, tokens, and role assignments.
	DE.CM — Continuous Monitoring	Cloud visibility gaps make monitoring and telemetry a core assessment concern.
Recommendation — Map cloud provider responsibilities and constraints before planning assessment activities. Validate cloud identity and access controls as the primary attack surface. Verify that cloud telemetry covers the actions and services the test needs to observe.

Practitioner Guidance

What to prioritise: Start by separating tenant-owned controls from provider-managed controls, then test the assets your organisation can actually change. In practice, that means validating IAM, secrets handling, network exposure, logging, and account boundaries before spending time on host-centric techniques that cloud services may hide or forbid.

What to verify: Confirm the rules of engagement, the provider’s testing policy, and the exact shared-responsibility model for each service in scope. If the test cannot produce evidence for a layer, document that limitation explicitly so “no finding” is not mistaken for “no exposure.”

Practitioner takeaway: Cloud testing is not weaker than on-premises pentesting, it is different in what counts as meaningful evidence. The best assessments prove whether your cloud configuration, identity model, and visibility are secure, rather than trying to force a host-based mindset onto a platform that is designed to abstract the host away.