What Can and Cannot Be Tested, and Why

Every scope has exclusions. Some exist because testing would break something, some because the test would tell you nothing useful, and some because the system is not yours to authorise.

The third category is the one that matters most, because getting it wrong is not a scoping error — it is unauthorised access to somebody else's computer.

The authorisation rule

A penetration test is a set of actions that would be an offence without permission. What makes it lawful is permission from the party entitled to give it, in writing, before the work starts.

The party entitled to give it is the owner of the system, which is not always you. Being a customer of a service does not make you able to authorise testing against it. Neither does paying for hosting.

So the first scoping question for anything in your list is not "can this be tested" but "who owns it, and have they agreed".

Things that are not yours

SaaS applications

Your CRM, your email platform, your payroll system. You own the data and your configuration; you do not own the application. Most vendors prohibit testing outright and run their own programmes.

What you can legitimately assess is your own configuration of it — who has administrative rights, whether multi-factor is enforced, how integrations are authenticated, what the sharing defaults are. That is a configuration review rather than a penetration test, and it is frequently the more valuable exercise, because misconfiguration is where the real risk in SaaS usually sits.

Third-party components inside your application

A payment page hosted by your processor. An embedded chat widget. An authentication provider. These appear inside your product and belong to somebody else. The boundary is normally drawn at your integration: how you call it, what you send, how you handle what comes back, and whether the integration can be abused — all yours. The provider's service itself — not yours.

Shared hosting

If other tenants share the infrastructure, your provider's agreement almost certainly restricts what can be tested. Check before scoping, not after.

Cloud

Cloud is where this gets misunderstood most often, and the shared responsibility model is the whole answer.

Yours to test: the applications you deploy, your configuration of the services you consume, your identity and access policies, your network rules, your storage permissions, your container images. This is where essentially all real cloud findings are — overly permissive roles, storage open to the internet, security groups that were widened for a migration and never narrowed, credentials in metadata or environment variables.

Not yours to test: the provider's underlying infrastructure — the hypervisor, the physical estate, the managed service internals. That is the provider's responsibility and their own assurance programme covers it.

The major providers permit customer-initiated testing of your own resources without prior approval in most cases, but each maintains its own policy with specific exceptions — commonly around simulated denial of service, and around certain managed services. Those policies change. Read the current one for your provider at scoping time rather than relying on what was true for a previous engagement, and keep a copy of what it said on the date you relied on it.

Where you use a managed database, a managed Kubernetes service or similar, the line runs through the middle of the service: your schemas, your access control and your exposed endpoints are in scope; the engine the provider operates is not.

Things excluded because of what they would do

Denial of service and stress testing

Normally excluded by default. The objective is to find weaknesses, not to demonstrate that a system can be overwhelmed — which is true of every system given enough traffic. Where availability genuinely matters, it is a separate, carefully planned exercise.

Note that some findings are identified without being exercised: a tester can establish that an endpoint has no rate limit without actually running it out of resources.

Destructive actions

Deleting data, modifying records irreversibly, or anything that cannot be undone. A tester demonstrating database access retrieves a row that proves it, not the table — and does not drop anything to prove they could.

Testing in production, sometimes

Not universally excluded, and often the only environment that reflects reality. But it needs deliberate agreement on timing, on what happens if something falls over, and on which actions are off-limits. The trade-off against a staging environment is covered in preparing for your first VAPT.

Things that need their own consent

Social engineering — phishing, pretexting, calling your service desk — targets your staff, which raises employment and privacy questions that technical testing does not. It needs explicit authorisation at the right level and a decision about how results are reported, because "which individuals clicked" is a different deliverable from "how many did".

Physical testing — entering premises, testing access controls — needs written authorisation carried by the tester, and named people who can confirm it at short notice.

Both are legitimate. Neither is included in a standard VAPT scope, and assuming otherwise is a recurring source of disappointment.

What to do with the exclusions

Write them down, with reasons, in the scope document. A scope listing only what was tested is half a scope.

The exclusions are what you will be asked about later — by an auditor, by a customer's security questionnaire, or by your own team a year on when nobody remembers why the payment page was left out. Reconstructing that from memory is not possible, and "it was out of scope" without a reason reads as an oversight even when it was a decision.

How the remaining surface gets counted and priced is in how a VAPT scope gets sized.