Every external test starts with a list of addresses, and the quality of that list decides the value of the work. Too narrow and you pay for a test that misses the exposed system nobody remembered. Too broad and you risk testing infrastructure belonging to somebody else, which is a legal problem rather than a technical one. Getting it right takes an afternoon and saves both.
What actually counts as yours
Ownership and responsibility are different questions. Address ranges allocated to your organisation are the easy part. Beyond them sit cloud addresses that change with each deployment, applications hosted on a vendor’s infrastructure where you own the configuration but not the address, content delivery endpoints, addresses at branch offices with their own broadband, and services a supplier runs on your behalf under your brand. Each needs a decision about whether it is in scope and whose permission is required, and third-party hosted systems usually need written authorisation from the provider before testing begins.
Building the list from evidence
Work from records rather than memory. Query the regional registry for ranges allocated to your organisation, export DNS records for every domain you own, pull public addresses from each cloud subscription and account, and search certificate transparency logs for hostnames issued in the past few years. Ask finance for hosting and domain payments, which reveals infrastructure IT has never seen. Then reconcile the results, and treat anything you cannot attribute as a question rather than an exclusion, because unattributed assets are exactly where the interesting findings live. Acquisitions deserve their own pass, since a company bought two years ago usually arrives with ranges and domains that were never merged into anybody’s records.
“The address that causes trouble is the one where the answer is nearly yours. A marketing platform on a shared host, a supplier’s portal branded with your logo, a subsidiary acquired last year with its own ranges. Get permission in writing or leave it out, and never let a tester decide the boundary on the day because the client was unavailable.”
William Fieldhouse, Director, Aardwolf Security Ltd
Keeping the list current between tests
A perimeter changes weekly in any organisation using cloud services, so an annual list is stale within a month. Automate discovery against your cloud accounts and DNS, and alert when a new public address or hostname appears. Register your ranges and domains with the NCSC’s Early Warning service, which is free to UK organisations and notifies you when their monitoring sees something on your infrastructure. Attack surface scanning fills the gap between engagements by checking the exposure continuously rather than once a year.
Handing the scope to a tester
Give the supplier the list with context rather than a bare set of ranges. Mark which addresses are third-party hosted and where authorisation exists, note anything fragile enough to need care, and identify the systems whose availability matters most so testing can be timed sensibly. External perimeter testing then covers what you own with the confidence that nothing outside your authority is touched, and the report describes your actual exposure rather than a subset chosen for convenience.
Frequently asked questions about external scope
These questions come up whenever an external engagement is being scoped.
Should you include addresses you are unsure about?
Investigate them before the test rather than including them speculatively. If ownership cannot be established in time, leave them out and resolve the question afterwards, because testing an address you do not control can breach the Computer Misuse Act.
Do you need permission from your cloud provider?
For your own resources on the major platforms, generally no, subject to their rules of engagement. Software as a service platforms are different, and testing one without written permission from the vendor is not acceptable.
