Cloud vs on-premises penetration testing

Cloud penetration testing vs on-premises penetration testing: which fits your estate

For a workload that runs entirely in one AWS, Azure or Google Cloud account, a cloud penetration test scoped to that account is the right primary test. For systems that run in your own data center or air-gapped network, an on-premises test is the right primary test, because the provider rules, identity boundary and network paths are yours to define. If your estate spans both, you need two scopes, not one, and the shortlist decision is really about which target carries the most business risk. NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, and a hybrid estate is the clearest case for that combination.

Choose a cloud-scoped test when the workload, its identities and its configuration live in a provider account and the main exposure is the services you configured, such as an internet-facing load balancer, serverless functions, container services or a storage bucket. Under the AWS shared responsibility model, AWS secures the cloud while you own configuration choices such as data, operating system and firewall settings, so the tester must work inside your account boundary. Before you sign, confirm the provider's current rules for your services: AWS publishes a list of services that need no prior approval, prohibits activities such as denial of service and S3 bucket takeover, and requires advance notice for simulated red or purple team work. Microsoft and Google Cloud publish their own rules, which differ in notice and prohibited activity, so the scope must follow the provider you run on.

Choose an on-premises test when the target is hardware, hypervisors, flat internal networks, or applications that you operate directly, and when your main risk is lateral movement inside your own network. Plan for the identity layer either way: in cloud estates, the largest exposures are usually roles, trust relationships and misconfigured access rather than open ports, so ask the provider whether the test will include identity paths and privilege escalation. Evidence also differs. A cloud test should record account IDs, resource identifiers and the exact configuration state, while an on-premises test records hosts, segments and network paths. Ask any tester to name the rules of engagement, the accounts and subscriptions in scope and how they will avoid testing out-of-scope tenants.

How cloud and on-premises penetration tests differ on each factor

This table compares how a penetration test changes when the target runs on AWS, Azure or Google Cloud versus a data center or on-premises estate. Read each row as a question to put to your provider: what changes for your team, what you must approve, and what evidence you should expect. The main takeaway is that cloud tests shift weight toward identity and configuration, and each provider sets its own notice and prohibited-test rules.

Factor	On-premises penetration test	Cloud penetration test (AWS, Azure, Google Cloud)
Goal	Find weaknesses in hosts, networks and applications you run, and prove whether they can be chained to reach sensitive systems.	Find the same kinds of weaknesses, plus misuse of cloud identities, roles and service configuration that the provider does not manage for you.
Scope definition	Scope is usually defined by IP ranges, domains and named systems you own and operate.	Scope must name accounts, subscriptions or projects, and the services inside them. Confirm which services the provider's policy covers before you list them.
Rules of engagement	Written by you and the tester, following the structure of NIST SP 800-115 Appendix B, with testing windows and escalation contacts.	Written under the same structure, but also constrained by each provider's own terms. Your rules must not conflict with provider policy.
Access and credentials	Commonly network access, standard user accounts or domain credentials supplied by you.	Often a tester role or identity in your tenant with defined permissions. Ask whether the tester needs read-only or write access and who holds the keys.
Identity weight	Directory services and local accounts are one important part of the attack path.	Identity is usually central. Misconfigured roles, trust relationships and overly broad permissions often decide the outcome of the test.
Configuration weight	Hardening of operating systems, network devices and middleware is tested mainly through live exploitation and host review.	Service settings such as storage access, network rules and logging are a major source of findings. Pair the test with a configuration review against a benchmark such as the CIS AWS Foundations Benchmark.
Notice requirements	Usually only internal change control and notice to hosting or network partners where contracts require it.	Notice rules differ by provider. Google Cloud states customers do not need to notify before testing their own infrastructure. AWS requires advance approval for some activities and a request at least 2 weeks ahead for simulated red, blue or purple team events.
Prohibited tests	Limits are set by your own rules of engagement and any third-party hosting contracts.	Provider policies prohibit specific activities. AWS bars DNS zone walking, denial of service and S3 bucket or subdomain takeover. Microsoft bars DDoS under all circumstances and phishing of its staff. Confirm each list before the test starts.
Evidence produced	Host and network evidence such as captured credentials, system screenshots and exploit logs tied to IP addresses and hosts.	Evidence centers on identity paths, role assumptions, misconfigured resources and the account or project each one affects. Ask for evidence that names each cloud resource.
Typical testing team skills	Network, operating system and Active Directory skills, plus exploitation and reporting.	Adds cloud platform skills in IAM, networking and managed services, and knowledge of each provider's testing rules. Ask providers to show current experience on your platform.

What the scope covers on AWS, Azure, Google Cloud and in the data center

Under the AWS shared responsibility model, AWS is responsible for security of the cloud, meaning the underlying infrastructure. Customer responsibility for security in the cloud depends on which services you choose, and it covers configuration such as your data, operating systems and firewall settings. Scope therefore follows your service inventory, not your data center floor plan.

Pre-approved services: AWS lets customers run security assessments or penetration tests without prior approval against a listed set of services, including EC2, RDS, CloudFront, API Gateway, Lambda, ECS and Fargate.
Activities needing approval: Testing that includes command and control requires prior approval under AWS's penetration testing policy.
Simulated events: Red, blue or purple team exercises and simulated phishing require a request at least 2 weeks ahead.
Prohibited in customer testing: DNS zone walking, denial of service, port, protocol or request flooding, and S3 bucket or subdomain takeover.
Services outside the list: Services not on the listed set may still need review, so confirm each one before the test window.

Confirm the current policy text and the service list directly with AWS before you sign the rules of engagement, because both change over time.

What a cloud penetration test finds and misses, and what an on-premises test finds and misses

Cloud and on-premises penetration tests reach different layers of the same estate. In a cloud test, identity, configuration and exposed endpoints usually decide the outcome, while in a data center test, network segmentation and physical access carry more weight. Each card below names what a test finds, what it misses, and the check that fills the gap.

Misconfigured storage and access paths

Object storage buckets, snapshots and shared access policies are often exposed through settings rather than code flaws. A penetration test can find a readable bucket or an overly broad policy only when the tester's access path reaches it, and it may miss buckets created after the test window or behind rules the tester never triggered. Use a cloud configuration review against the CIS AWS Foundations Benchmark to check every account, not only the reachable ones. AWS prohibits S3 bucket or subdomain takeover in customer testing, so confirm what a tester may touch before scoping.

Identity and privilege escalation paths

In cloud estates, roles, federated trusts and access tokens often matter more than network position. A test can show that a compromised workload assumes a role with excessive permissions, but it may miss dormant trust relationships, unused keys and permissions granted through policy inheritance across accounts. Pair the test with a review of every role and trust policy, because a single test path rarely enumerates them all. Ask the provider to state which identity sources and token types were in scope.

Exposed services and APIs

Internet-facing functions, API gateways and container services are reachable from outside the network, so an external penetration test can exercise them directly. The test finds authentication gaps, injection flaws and verbose errors that are visible through the endpoint. It misses flaws in code paths the tester never reached and logic that depends on authenticated user states the tester did not hold. Application security testing and API testing cover that depth. Confirm which services sit under each provider's permitted list before testing begins.

Internal movement in a data center

On-premises tests can measure how far a foothold travels across VLANs, flat subnets, shared administrative hosts and legacy protocols. That path is visible because the tester can use the same network the attacker would reach. A test usually misses segments that were excluded for stability reasons and paths that depend on physical cabling or out-of-band management networks. Use an internal penetration test with agreed lateral movement goals, and where Active Directory is involved, add an Active Directory assessment for privileged paths.

Physical and facility exposure

Data center tests can include badge systems, cages, cabling access and staff tailgating, which a cloud test cannot reach because the provider controls the facility. The test finds gaps in access control and visitor handling, but it misses behavior on shifts it did not observe and controls owned by facility operators the customer does not manage. Confirm in writing whether facility testing is in scope, who must approve it, and how the provider's own physical controls are handled. Do not assume a cloud test covers any of this.

Gaps in provider-managed layers

Managed databases, serverless runtimes and hypervisor layers run under the provider's responsibility, so a customer test cannot validate their internal security. Under the AWS shared responsibility model, AWS owns security of the cloud while the customer owns configuration and data. A penetration test may show a misconfigured customer setting but cannot confirm the provider's patching or isolation. Ask the provider for its third-party attestation reports for those layers and treat them as evidence of provider controls, not as test results.

What provider rules of engagement permit, prohibit and require before a cloud test

Each provider sets its own rules of engagement, and those rules decide which tests you may run without asking, which need approval and which are banned outright. AWS allows security assessments and penetration tests without prior approval against a listed set of services, including EC2, RDS, CloudFront, API Gateway, Lambda, ECS and Fargate. Testing that includes command and control needs prior approval. AWS also prohibits DNS zone walking, denial of service, port, protocol or request flooding, and S3 bucket or subdomain takeover, and it requires a request at least 2 weeks ahead for simulated red, blue or purple team testing and simulated phishing. A red team plan that includes a phishing lure or a persistent implant therefore needs a dated request before the first step, not a note after the fact.

Microsoft takes a narrower, more prohibitive position. Its cloud rules of engagement ban DDoS attacks under all circumstances, phishing or social engineering of Microsoft employees, accessing data or tenants the tester does not own, and network-intensive fuzzing. Any vulnerability found in a Microsoft service must be reported to MSRC. For a tester working against a customer tenant, the practical check is whether every identity, subscription and data store in scope belongs to your organization. A test that wanders into a partner tenant or a shared resource breaks the rules even if the customer approved the work.

Google Cloud takes the most permissive stance on notice. Customers do not need to notify Google before penetration testing their own Google Cloud infrastructure, but the work must follow the Acceptable Use Policy and Terms of Service, and every test must affect only the customer's own projects. Notice being unnecessary does not make the scope self-defining. Confirm project boundaries, shared VPC dependencies and third-party SaaS integrations before testing begins. Provider terms change, so confirm the current text on each provider's page with your counsel and your provider account team before you write the rules of engagement into the statement of work.

What you receive from each test and what evidence an assessor can use

This table compares what a cloud penetration test and an on-premises test hand back, and how far each deliverable can support an assessor's questions. Read each row as a question to ask the provider before work starts, because the same report label can contain very different evidence.

Deliverable	Cloud penetration test	On-premises penetration test
Rules of engagement and authorization	Should name the cloud account IDs, subscriptions or projects in scope, the listed services tested, and any provider notice or approval taken. NIST SP 800-115 provides a rules of engagement template in Appendix B that can be adapted.	Should name IP ranges, hosts, network segments and testing windows. NIST SP 800-115 Appendix B template applies equally, but authorization usually covers owned address space rather than provider-granted accounts.
Scope and provider policy record	Should record which provider testing policy applied, which services were tested without prior approval, and which activities were excluded, such as denial of service or social engineering of provider staff.	Usually records network boundaries, excluded systems and fragile assets. Provider policy records are not normally needed.
Attack narratives	Should show how an identity, misconfigured role or exposed service led to access across accounts or workloads, with the steps tried and the ones blocked.	Should show how a foothold led to lateral movement, credential reuse or domain-level access, with the path and the systems touched.
Evidence of exploitation	Screenshots, command output or logged API calls showing access, with account, region and resource identifiers. Ask whether the test stayed within the tester's own projects.	Screenshots, captured sessions, hashes or shell output tied to host names and timestamps, with clear cleanup records.
Configuration and identity findings	Should separate misconfigurations, excessive permissions, trust relationships and token exposure. Ask whether findings were checked against a named baseline such as the CIS Amazon Web Services Foundations Benchmark.	Should cover patch levels, service configuration, directory privileges and segmentation gaps, with the affected systems listed.
Retest records	Should show which findings were fixed, when configuration changes were confirmed and which evidence was re-collected from the same accounts.	Should show which hosts were rechecked, with before and after output, and any accepted risks recorded by the client.
Detection validation	The report alone rarely proves detection coverage. Under CIS Safeguard 18.4, security measures should be validated after each test so that alerts cover the techniques the testers used. Ask for a separate validation record from the security monitoring team.	Same requirement applies. Ask for a record showing which techniques were detected, which alerts fired and which gaps were logged for follow-up.
Remediation guidance	Should tie each fix to the provider's shared responsibility boundary, so the owner knows whether the change belongs to the customer's configuration, identity policy or the provider's service.	Should name the owning team for each host, service or network control and the change path for patching or hardening.

Why identity and configuration carry more of a cloud test

In a cloud estate, identity and configuration are usually the main attack paths, because the provider owns the physical facilities and the hypervisor layer while the customer owns how accounts, roles, keys and service settings are set up. Under the AWS shared responsibility model, AWS is responsible for security of the cloud, while customer responsibility for security in the cloud depends on the services chosen and covers settings such as data, operating systems and firewall configuration. In an on-premises test, the tester usually starts from a network segment and works toward systems. In a cloud test, a valid low-privilege role, an overly broad trust policy or an exposed access key may open more than any single host, so a test that does not examine identities and permissions misses much of the exposure.

NIST SP 800-115 describes system configuration review as identifying weaknesses in security configuration controls by comparing settings against security configuration guides or checklists, and it says automated checks are preferable where feasible because they are fast and repeatable. For cloud accounts, this means comparing IAM policies, logging, storage access settings and network rules against a recognized baseline. The CIS Amazon Web Services Foundations Benchmark, version 7.1.0 (October 2026), is one such baseline. Reviewers can use it to confirm known settings across every account, while an attack-led test checks whether those settings can be chained together. Ask the provider or testing firm which baseline version they map to and whether the review covers all accounts in scope.

A practical plan is to run the configuration review first, then direct the penetration test at the identity paths it surfaces, such as privilege escalation through role assumption or access to data stores from a compromised workload. Confirm in writing which identities the tester may use, whether the test may read or change production configuration, and how findings from each method will be separated in the report. Also confirm with the provider which activities need prior approval, since testing that includes command and control requires approval under AWS's penetration testing policy, and check the rules for Azure and Google Cloud before the test is scheduled.

What drives the cost and effort of a cloud test compared with a data center test

A cloud test is priced and planned around things a data center test rarely has: multiple accounts, provider notice rules, identity links and proof that fixes hold. The cards below set out who pays for each driver, whether it is one-time or recurring, and what to put in a written quote.

Number and type of cloud accounts

Each AWS account, Azure subscription or Google Cloud project is a separate boundary to scope, inventory and test. The testing firm is paid for the time to map them, and your internal staff pay in time to confirm which accounts belong to the engagement and which are owned by third parties. Mapping is largely one-time per engagement, but it recurs when new accounts appear. Ask the quote to list every account, subscription or project in scope and to state what happens if the count changes.

Services in scope

Each managed service adds a test surface with its own rules. Provider policies differ on which services can be tested without prior approval, so the list of services drives both the testing hours and the approval work. Ask the quote to name each service, the test types planned against it, and which items need provider approval before work starts.

Identity complexity and hybrid links

Cloud tests often spend more time on roles, federation, service identities and trust paths than on network hosts. Where cloud identity is synchronized with an on-premises directory, the test must cover both sides, which adds analysis and coordination with your identity team. This effort is largely one-time for the baseline, then recurs with each significant identity change. Ask the quote whether hybrid paths are in scope and who supplies the directory access.

Provider notice and approval lead time

Notice rules are set by the provider, not the client. Some providers allow standard tests without notice, while simulated events such as red team or phishing exercises require a request well in advance. Your internal staff or project manager usually submits these requests, so the cost is coordination time, not a fee. Ask the quote to show which notices are needed, who files them, and how the schedule absorbs a rejected or delayed request.

Simulated red team or phishing events

Red team exercises and simulated phishing add planning, approvals, deconfliction and a separate reporting stream, so they are priced apart from a standard penetration test. The testing firm is paid for design and execution, your staff for approvals, stakeholder briefings and monitoring-team coordination. These are usually one-time per exercise. Ask the quote to state whether the work is a standard test or a simulated event, and who signs the rules of engagement.

Evidence and retest requirements

Cloud findings often depend on configuration state, so evidence must show the setting, the account and the time it was checked, and retests must confirm the fix in the same account. The firm is paid for evidence collection and retest effort, while your staff pay in time to apply and document fixes. Retests recur after each remediation cycle. Ask the quote how many retest rounds are included, what evidence format is delivered, and who keeps the records.

When compliance frameworks call for each kind of penetration test

Compliance frameworks rarely say "test the cloud" or "test the data center" in so many words, so the first decision is which test type each framework asks for. NIST SP 800-53 Rev. 5 control CA-8, Penetration Testing, carries enhancements for an independent penetration testing agent or team, red team exercises and facility penetration testing. The SP 800-53B baselines select CA-8 only in the high baseline (Release 5.2.0), so a moderate or low system may not carry it as a required control at all. Check which baseline your system is categorized under before you write a statement of work that assumes CA-8 applies. The NIST OSCAL content for SP 800-53 Rev. 5 is the natural place to confirm the control text and baseline selections yourself.

PCI SSC's Penetration Testing Guidance describes penetration testing as essentially a manual process and states that simply running an automated tool does not satisfy the penetration testing requirement. For a cloud estate, this matters because teams often believe a scheduled cloud posture scan covers the obligation. It does not on its own. Ask your assessor whether they expect manual testing of the in-scope cloud services, whether that includes the identity and network paths between accounts, and how they will treat a provider's permitted-services list when the scope covers managed services that are not on it. The PCI SSC penetration testing guidance is the document to bring into that conversation.

Under DORA, Article 25(1) lists penetration testing among the digital operational resilience tests a financial entity must run, alongside vulnerability assessments and scans, open source analyses, source code reviews where feasible and scenario-based tests. Article 26 adds threat-led penetration testing at least every 3 years for entities that their competent authority identifies. Neither article tells you whether the test must cover your cloud accounts, your data center or both, so that scoping question goes to your competent authority or your assessor in writing. Treat the answer as a decision with an owner, because a test scoped only to on-premises systems can leave the cloud identity and configuration paths untested for the entire cycle.

What buyers ask before they hire a cloud or on-premises penetration tester

What does a cloud penetration test cost and what drives the price?

No supplied source gives a price for cloud or on-premises penetration tests, so the figure depends on written scope. The main cost drivers are the number of accounts, subscriptions and projects in scope, how many services and applications are tested, whether identity and configuration review is included, and how many test windows and retests are needed. Ask each provider to price the same scope list, separate one-time fees from any recurring retainer, and state what is excluded, such as remediation support or a retest. Cloud tests often add effort for mapping the provider's permitted services, which is a cost component to confirm in the quote.

How far ahead do cloud penetration tests need to be scheduled?

Timing depends on the provider's rules and your written scope. AWS does not require prior approval for assessments against its listed services, but it asks for a request at least 2 weeks ahead for simulated events such as red, blue or purple team testing and simulated phishing. Testing that includes command and control needs prior approval under the same policy. Microsoft and Google Cloud set their own conditions, so check each provider's current rules before fixing dates. Build time for the provider's review of the scope, the engagement window and the retest.

Does a cloud provider have to approve a penetration test before it starts?

It depends on the provider and the activity. Under AWS's penetration testing policy, many common assessments against listed services need no prior approval, but command and control testing does, and simulated events need advance notice. Google Cloud states that customers do not need to notify Google before testing their own infrastructure, but they must follow its Acceptable Use Policy and Terms of Service and keep tests within their own projects. Microsoft's rules of engagement prohibit certain activities outright and require vulnerabilities found in its services to be reported to MSRC. Ask your provider to map each planned test to the relevant policy before testing begins.

What access do penetration testers need to a cloud environment?

Testers usually need an account or role with the access level the scope requires, and the access should be documented and time-limited. A black-box external test needs little more than the target list, while an authenticated test needs roles that reflect the attacker profile you want to simulate. Ask for the specific roles, the accounts or subscriptions they will use, the logging that will record their activity, and how credentials are revoked at the end. Confirm that the tester's access stays within projects or tenants you own, since both Microsoft and Google Cloud prohibit or limit reaching resources outside your own.

Can our internal team run a cloud or on-premises penetration test?

An internal team can run tests, but the question is whether it has the independence, skills and tooling the test needs. NIST SP 800-115 describes penetration testing as a technique that uses real exploits against production systems and carries high risk, so the team needs clear rules of engagement and a plan for outages. Compliance programs may expect an independent tester; NIST SP 800-53 control CA-8 includes an enhancement for an independent penetration testing team. For cloud work, confirm the team understands each provider's permitted services and prohibited activities. Many organizations combine internal scanning with an external tester for periodic deeper work.

Can a single engagement combine cloud and data center penetration testing?

Yes, many organizations combine them, but the rules differ for each environment. In a hybrid estate, the cloud part follows the provider's policy and the data center part follows your own rules of engagement. NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, and its Appendix B rules of engagement template is a useful starting point. Ask the provider to produce one scope document with separate sections for each environment, separate test windows, and clear ownership of each finding. Also confirm that identity links between on-premises directories and cloud tenants are included, because attack paths often cross that boundary.

Does a penetration test satisfy a compliance requirement?

A penetration test can support a compliance requirement, but it does not satisfy one by itself. The requirement, the framework and the assessor decide what counts. PCI SSC's penetration testing guidance says that simply running an automated tool does not meet the penetration testing requirement, so the work must be manual and methodical. CIS Controls v8.1 Safeguards 18.2 and 18.5 ask for external and internal penetration tests at least annually. Ask your assessor which methodology and report format they accept, and whether the test must be independent. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications.

How DeployOpen scopes, runs and supports cloud and on-premises penetration tests

DeployOpen plans and runs penetration tests inside the client's own environments, including their cloud accounts and data centers. Each engagement is fixed-scope, with the target, rules of engagement and deliverables agreed in writing before any testing starts.

How we scope

Written scope names each cloud account, subscription or project, or each data center network segment, that is in bounds.
Scope records the provider testing policy that applies, including services that need prior approval or notice.
Rules of engagement list prohibited activities, test windows, emergency contacts and how findings are reported.
Scope states whether testing starts from an assumed breach, an external view or an authenticated user account.

How we build

Test plans separate identity and configuration checks from exploitation of workloads, so each finding has a clear route.
Test accounts and access levels are provisioned in the client's environment and removed when testing ends.
Testers confirm tooling and traffic limits against the agreed rules before any active step runs against production.
Where a provider needs notice, DeployOpen prepares the request for the client to submit, with the agreed dates.

How we hand over

Reports tie each finding to the affected account, configuration, host or identity and to a reproducible step.
Each finding includes a remediation owner suggestion and a retest plan agreed with the client.
Evidence packs record what was tested, when, from where and under which provider policy or internal approval.
A readout walks the client team through findings, residual risk and what an independent assessor will ask to see.

How we support

Retesting after fixes is quoted from the written scope as a separate, fixed-scope item.
Ongoing support, upgrades and continuous testing are available as a retainer for teams that test more than once a year.
Recurring tests can reuse the same scope template, so each cycle starts from a known baseline.
Ask for the retainer terms, response expectations and reporting cadence in the written proposal before signing.

Cloud penetration testing vs on-premises penetration testing