Fast CREST penetration testing › Cloud testing permission
Everyone assumes the constraint on a fast penetration test is whether a tester is free. Sometimes it is. Far more often the engagement sits still for a week because nobody worked out, in advance, who had to say yes.
If your target sits on infrastructure you do not own, and for most organisations it does, then there are at least two parties whose authorisation matters and possibly four. Working out which applies to you takes an afternoon. Working it out after a tester has already started takes considerably longer, and in the worst case it means a provider suspending an engagement mid-window.
Shared responsibility, in the only sense that matters here
Every major cloud provider divides the stack between what they secure and what you secure. That model is usually explained in terms of who patches what. It has a second consequence people miss: it also divides what you may authorise somebody to attack.
You can authorise testing of the things you control and configure. You cannot authorise testing of the provider's own platform, because it is not yours to authorise, and consent from a customer is not consent from the owner. That line is what the rest of this article is about.
What is yours to authorise, broadly
Your applications and the code in them. Your virtual machines and containers and what runs on them. Your configuration: identity and access policy, network rules, storage permissions, key management setup. Your data. In practice this is where the overwhelming majority of real findings live anyway, and a test scoped to it is not a compromise, it is the right test.
What is never yours to authorise
The provider's hypervisor and physical infrastructure. Their management planes and consoles as software. Other tenants, including anything shared that you happen to be able to reach. Their underlying network. Testing any of this without the provider's own authorisation is testing a third party without consent, which is not a technicality.
The category that catches people out: managed and third-party services
A great many targets are not "your cloud" or "their cloud" but something in between, and this is where short-notice engagements actually stall.
| Arrangement | Whose authorisation you need | Typical lead time to get it |
|---|---|---|
| Your own cloud account, your own application | Yours, plus compliance with the provider's stated testing policy | Same day |
| Managed hosting or a managed service provider | Yours and theirs, in writing | Two days to two weeks, and highly variable |
| Shared hosting | The host's, and frequently refused outright | Assume it will be declined |
| SaaS you subscribe to | The vendor's, and usually governed by their own testing terms | Days to weeks, often with conditions |
| A CDN or WAF in front of your application | Yours, and you must decide whether to test through it or behind it | Same day, but it is a scoping decision |
| A supplier's API your application calls | The supplier's. Without it, out of scope | Often not obtainable at short notice |
The last row is the one that most often surprises people. Your application calls a partner's API, the partner's endpoint is part of how your system works, and it is still not yours to have attacked. It comes out of scope unless the partner authorises it in writing, and that is a conversation between you and them that no penetration testing provider can have on your behalf.
The CDN and WAF decision, which is a real one
If there is a content delivery network or web application firewall in front of your application, you have a choice to make and it changes what the test is worth.
Testing through it shows you what an internet attacker sees today. Realistic, and it will produce a shorter findings list, because the firewall will block a proportion of what the tester tries. The risk is a false sense of security: the findings behind the firewall still exist, and the day somebody bypasses it, or you change provider, or a rule is relaxed for a release, they are all still there.
Testing behind it, by allowlisting the tester's source addresses, shows you the actual state of the application. Longer findings list, more useful remediation, less realistic threat model.
The usual right answer is behind it, with a short unauthenticated pass from outside to confirm the protection is doing what you think. What you should not do is leave it unstated, discover on day three that half the test was absorbed by a firewall, and receive a clean-looking report that means very little.
Notification, rate limits and the practical conditions
Cloud providers' testing policies have shifted a great deal over the last few years, generally in the direction of permitting customer-initiated testing of your own assets without asking first, subject to conditions. The conditions are the part to read. They commonly cover denial of service and volumetric testing, which is nearly always excluded or requires separate approval; rate limits on what may be generated; specific managed services that are carved out; and in some cases a notification requirement rather than an approval one.
Because these terms change, the only safe practice is to read the current policy for your provider before each engagement rather than relying on what was true at the last one. Any competent testing provider will ask you to confirm this, and one that does not ask is not a provider whose rules of engagement you should trust.
Who signs, on your side
The other half of the delay, and the half nobody plans for. The authorisation and rules of engagement need a signature from somebody who can commit the organisation to it. That is not always the person who requested the test.
Three questions worth answering before you ask for a quote. Who internally can sign this, and are they available in the window you are working to? Does the target belong to your company or to a parent, subsidiary or joint venture, because if it is not your legal entity's asset, your signature may not be the one that counts. And is one signature enough, or does your organisation require two?
None of these are difficult. They are sequential, they involve people outside the security conversation, and each one that surfaces late costs days you do not have.
A pre-flight list
Settle these before you ask for dates and a short-notice test becomes genuinely short-notice.
- Every target is an asset your legal entity owns, or you hold written authorisation from whoever does.
- Your hosting or cloud provider's current testing policy has been read, and anything it requires has been done.
- Any third-party API, SaaS or partner system in scope has its owner's written consent, or it has been explicitly excluded.
- You have decided whether testing runs through the CDN or WAF, or behind it, and the allowlisting is arranged if behind.
- A named person can sign the authorisation and rules of engagement this week.
- Someone is on call during the window who can act on a critical finding out of hours.
Six answers, most of them one line. They are the difference between a test that starts when you want it to and one that starts when the paperwork catches up.
Do I still need my cloud provider’s permission if I own the application?
You need to comply with their current testing policy, which for the major providers generally permits testing of your own assets subject to stated conditions rather than requiring you to ask each time. The conditions are the part that matters: denial of service and volumetric testing are usually excluded, certain managed services are carved out, and terms change. Read the current policy before each engagement rather than relying on the last one.
Our application calls a partner’s API. Can the tester include it?
Not without the partner’s written authorisation. Their endpoint is their asset regardless of how central it is to how your system works, and your consent does not extend to it. Either obtain their authorisation in advance or explicitly exclude it in the rules of engagement. There is no third option.
Should we test through our web application firewall or behind it?
Usually behind it, with a short pass from outside to confirm the protection behaves as expected. Testing through a firewall produces a shorter findings list that reflects today’s configuration rather than the state of the application, and those findings still exist the moment a rule is relaxed or the provider changes.
We are on shared hosting. Can we have a penetration test at all?
Often not in the form you want. On shared infrastructure your activity can affect other tenants, and most hosts decline or heavily restrict testing as a result. Ask the host first, before you commission anything. If they decline, an application-layer test against your own code may still be possible with their agreement, but assume infrastructure testing is out.
Sort the authorisation first
Tell us what the target is and where it sits, and we will tell you which of these apply to you before you commit to anything. Most enquiries turn out to need two of the six, not all of them.