External vulnerability scanning: agreeing scope and permission

What counts as permission

An external vulnerability scan looks at your internet-facing addresses from the outside and checks the services it finds against known weaknesses. A penetration test goes further and deliberately tries to exploit those weaknesses. This article covers scanning only. If anyone proposes exploitation, phishing or social engineering, that needs a separate and much more careful agreement.

The legal backdrop is the Computer Misuse Act 1990. Section 1 makes it an offence to cause a computer to perform a function intending to secure access to a program or data, where that access is unauthorised and you know it is. Section 17 explains what unauthorised means: you are not entitled to control that kind of access, and you do not have consent from someone who is. On conviction on indictment, section 1 carries up to two years in prison, a fine or both. Section 3 separately covers unauthorised acts intended to impair the operation of a computer, or reckless as to doing so, which is where a heavy-handed scan of a fragile system becomes a different conversation.

Whether a particular scan amounts to an offence depends on the facts, and that is a question for a solicitor, not for us. What we can say is how the wording shapes the paperwork. Consent has to come from someone entitled to control the access. For your own office firewall that is you. For a website sitting on a hosting company's server, the host also controls access to that server, so our practical reading is that your consent alone may not cover it.

Reform of the Act has been discussed for years and press reports in 2026 suggest changes are being considered. We could not confirm any enacted change that alters this, so plan around the Act as it reads today. When we checked on 4 November 2026, legislation.gov.uk showed the Act up to date to 1 November 2026 with no known outstanding changes to section 1.

Before you begin

You need very little equipment for this, but you do need the right standing.

• Authority. You must be the person entitled to authorise testing of the systems in question, or have been told in writing by that person. If you administer systems for a client, a login is not the same as their say-so.
• A rough idea of who will run the scan: your own administrator, a managed service provider, an outside firm or a hosted scanning service. The agreement is needed in every case. With a hosted service it also sits alongside that service's own terms.
• Access to whoever manages your DNS, hosting and firewall, or at least their documentation. You will use them to find out who controls what.

List what you want scanned and who controls each item

Scope is the exact list of what may be scanned. 'Our website' and 'the office network' are not a scope. Names and addresses are. Writing the list also forces the useful question: is each one actually yours to authorise?

If you use a tool that discovers assets automatically, review what it found before you scan. The NCSC's buyer's guide for external attack surface management products describes discovery of assets owned by or associated with your organisation, and says good tools let you exclude out-of-scope discoveries. 'Associated with' is not the same as 'yours to scan'.

1. Write down every domain name, subdomain and public IP address you intend to scan, with where each came from, such as firewall documentation, DNS records or internet provider paperwork.
2. For each website name, look up the address it points to. The command below is read-only: it sends an ordinary DNS query and does not touch the website. Run it in Command Prompt, PowerShell or a terminal, replacing YOUR_WEBSITE_ADDRESS with the name you are checking.
   cmdCopy

   nslookup YOUR_WEBSITE_ADDRESS

3. Record who controls each address: you, a hosting company, a CDN (content delivery network) or cloud provider, your internet provider or a software-as-a-service vendor. A registry search (often called a whois lookup) on an IP address names the organisation it is allocated to. An address on your office line may be yours. An address that a hosting company's server answers on belongs to the host even if the website content is yours, and a CDN address tells you about the CDN rather than your origin server.
4. Sort the list into three groups: addresses you can authorise alone, addresses you control but that sit on someone else's platform (these need the next section), and addresses that are not yours at all. Remove the third group. If your real worry is a software-as-a-service product, use the vendor's own security assurance rather than scanning it.
5. Check the result. Every line in the list should now have a named controller. Any line without one stays off until you find out.

Get consent for anything a supplier controls

Providers publish testing policies and they differ in detail. 'We only scanned it' is a poor opening line to a hosting company's abuse team, so find out the rules first. The GOV.UK service manual, written for government services but sound everywhere, says to get explicit consent from any third-party supplier whose software you use and to confirm whether you have permission to look at their systems.

These are the policies we checked for three common platforms. They change without much notice, so use them as a guide to what to look for, not as a substitute for reading the current page.

On AWS, the policy says customers can assess listed services without prior approval, but testing that involves command and control needs prior approval, denial-of-service testing is prohibited including simulated attacks, and services not on its list should be raised with AWS Support or your account representative. The page showed no revision date when we checked.

On Microsoft Azure, pre-approval has not been required since 15 June 2017, but you must follow Microsoft's Rules of Engagement. A third party testing for you needs explicit written authorisation from you as owner of the resource, and Microsoft does not grant that on your behalf. Testing must stay within your own tenant or assets, and denial-of-service testing and network-intensive automated testing are prohibited. Microsoft says the no-pre-approval position applies only to Azure, not its other cloud services.

On Cloudflare, the policy, last updated 20 April 2026 when we checked, allows customers to run scans and penetration tests on their own application and network-layer assets with restrictions. Scans should be rate-limited and identify vulnerabilities without trying to exploit them, and targets are limited to your own IPs, Cloudflare's designated public IPs and your registered DNS entries. The page lists extra WAF (web application firewall) and bot settings that must be configured on each zone before penetration testing, so read it to see what applies to the kind of testing you plan.

We did not review shared hosting companies, internet providers, other CDNs or software-as-a-service platforms, and their terms vary. Where a policy is silent or unclear, ask. You can still run a useful scan of the parts you do control while you wait for an answer.

1. Find each supplier's testing policy. Search their site for penetration testing or security testing, or ask their support team where it lives.
2. Save a dated copy and the URL. Pages like these change, and you may need to show what the rule was on the day.
3. If the policy needs notice or approval, or says nothing about your kind of scan, ask in writing and wait for a written reply before going ahead. Allow time: a supplier's answer can take longer than the scan itself.
4. Pass any conditions, such as rate limits or notice periods, to whoever runs the scan, and attach the policy copy or consent to your scope document.

Write the authorisation down

The NCSC's advice on scoping is that it should involve the people who own the risk, the technical staff who know the system and a representative of the test team, and that the output is a document stating the technical boundaries and the types of test expected. It also suggests agreeing timeframe and telling testers about out-of-hours needs or systems needing special handling. Its page does not cover authorisation as such, so the list below is our recommended minimum, built from that scoping advice and general practice. It is not a legal template, and liability and confidentiality wording belong to a solicitor.

A short document or a dated email chain from someone with authority is better than a verbal go-ahead. Keep it where you can find it in a year.

• Who is authorising, their role, and a statement that they are entitled to authorise testing of the listed systems.
• Who is testing: the company, the named individuals and any subcontractors.
• The exact assets in scope and an explicit out-of-scope list. State that anything discovered during testing stays out of scope until it is agreed in writing.
• The type of test. For a first scan we suggest an unauthenticated scan from the internet only, which means no logging in, with no exploitation, no denial-of-service and no password guessing.
• The dates, start and end times and the source IP addresses the scan will use, so your monitoring staff and suppliers can recognise it.
• How hard the scan may push: rate limits, and what happens to forms and other pages that create records.
• Named contacts on both sides who can be reached during the window, and a clear instruction that either side can stop the scan immediately.
• What happens to the results: where the data is held, who sees the report and how long it is kept. The NCSC says its own scanning stores full responses and metadata such as timestamps and IP addresses, so scan data can contain more than a list of open ports.
• Attachments: supplier consents or dated copies of their testing policies.

Example scope schedule (fictional - Harbour and Finch Accountants Ltd)

Authorised by: Managing Director (confirms entitlement to authorise testing of the assets below)
Tester: Example Security Services Ltd, two named staff

In scope:
- www.harbourfinch.example - company website, hosted by a third-party web host (host's testing policy saved on YOUR_DATE_CHECKED)
- 203.0.113.10 - office firewall, owned and managed by the company

Out of scope:
- mail.harbourfinch.example - hosted email service
- Any address not listed above, including anything discovered during testing

Type: unauthenticated external vulnerability scan only. No exploitation, no denial-of-service, no password guessing.
Window: 6 March 2027, 01:00 to 05:00 UK time. Scanner source address: YOUR_SCANNER_IP_ADDRESS
Stop: either party may stop the scan immediately by phoning the contact below.
Contacts: YOUR_COMPANY_CONTACT_NAME and YOUR_TESTER_CONTACT_NAME, with mobile numbers recorded in the signed copy.
Attachments: web host consent or policy copy.

Set the scan up so a live system can cope

The NCSC says infrastructure scanners are very unlikely to affect service availability, but still recommends trying non-production instances first where you can. Its penetration testing guidance is blunter: it is impossible to guarantee that no unexpected reactions will occur. Your agreement should cope with a bad day, not assume there will not be one.

Scan duration depends on how many addresses are involved and how the scanner is configured, so ask whoever runs it for an estimate rather than planning around a guess. Stay reachable until they confirm it has finished.

• Choose a quiet window and tell whoever would get the call if something wobbles.
• Web scanners can have side effects. The NCSC notes that repeated form submissions can create large numbers of database entries, so exclude contact forms and checkout flows or point the scanner at a test copy.
• Tell your managed service provider, security team and hosting provider about the window and source addresses. Whether to allowlist the scanner in your firewall or WAF is a judgement call. Allowing it means it is not mistaken for an attack, but it also means the scan no longer shows you what an outsider would meet. The GOV.UK service manual makes the same point about recognising testers unless detection itself is being tested.
• If a fragile host must be excluded, record it. The NCSC says exclusions should be temporary, for the shortest possible time, and entered in your risk register.
• If you later want logged-in checks, use a dedicated test account and ask how the scanner avoids locking accounts out. The NCSC lists that as something to ask vendors.

Check the paperwork before anyone starts

Run through this once the document exists and before the scan window opens. The test is whether you can answer 'who said we could scan this, and where is it written?' for every address within a minute.

• Every line in the scope list has a named controller, and the document is signed or confirmed by someone entitled to authorise it.
• Anything supplier-controlled has a saved copy of that supplier's testing policy or their written consent, and any conditions have reached the tester.
• The tester has the out-of-scope list in writing.
• Monitoring staff and providers know the window and source addresses.
• Both contacts have each other's phone numbers, and everyone understands the stop instruction.

If the scan strays or a supplier says no

Most problems here are about boundaries rather than technology, and the fix is usually to stop, write it down and agree a change in writing.

• The scan reports something on an address that is not in the list. The NCSC notes that testers may find out-of-scope components and that the risk owner decides whether to change the scope or record a limitation. Stop scanning that address and leave it alone. Then either amend the agreement in writing with whoever controls it, or record it as excluded.
• A supplier refuses or does not reply. Leave that asset out and record the exclusion. Ask the supplier for their own security assurance in place of your scan.
• The scan disrupts a service. Use the agreed stop instruction, phone the other contact, check the service and note what happened. Do not resume until the cause is understood. If customers or personal data are affected, treat it as an incident under your normal response process.
• You are unsure whether you are entitled to authorise something. Get legal advice before scanning it.