Key takeaways

  • Prove ownership first: a DNS record or file on the target shows the person requesting a scan controls it. Without this, anyone could point a scanner at someone else's site.
  • Written authorization and rules of engagement define scope, methods, dates, contacts and stop conditions. They protect you and the tester.
  • The federal Computer Fraud and Abuse Act (18 U.S.C. 1030) makes access without authorization, or beyond it, a potential crime. Authorization in writing is the cleanest answer to that question.
  • Third parties such as hosting and cloud providers have their own testing policies. Authorization from you does not replace theirs.

Start with the answer: no reputable security firm should scan or test your website until it has verified that you control it and you have signed a written authorization. If a vendor offers to "just run a quick scan" of a site without either step, treat that as a warning sign about how they will handle the rest of your data.

Why verification comes first

A scan sends traffic that looks like an attack: many requests, odd inputs, probes for known flaws. If a service let anyone enter any domain, it would become a tool for probing other people's systems. Ownership verification prevents that. Common methods are a DNS TXT record at the domain, a specific file at a known path on the web server, or a reply from an administrative email address. Each proves control in a way a stranger cannot fake.

Verification also protects you from mistakes. A typo in a domain name, a staging site run by a different company, or a subdomain that points at a vendor's platform could send test traffic to a system you do not own. Checking first catches those.

What the written authorization contains

A signed authorization, often called rules of engagement, turns a scan from a risky act into a managed one. It should state:

  • Who is authorized: the named company and the individuals who sign for it, with their authority to do so
  • Exactly what is in scope: domains, IP ranges, applications and environments, and what is out of scope
  • What methods are allowed: passive review, vulnerability scanning, authenticated testing, or exploitation, and anything banned such as denial-of-service or social engineering
  • When testing runs: dates, hours and blackout periods, such as month-end close or a product launch
  • Who to call: emergency contacts on both sides, and a clear way to pause or stop
  • How findings and data are handled: where results are stored, who sees them, how long they are kept, and what happens if testers encounter personal or regulated data

Good documents also say what the tester will not do: change data, keep copies of customer records, or leave tools behind. This is the same structure NIST SP 800-115 describes when it covers planning an assessment.

The legal context, in general terms

The main federal law is the Computer Fraud and Abuse Act, 18 U.S.C. 1030. In general terms, it prohibits intentionally accessing a computer without authorization, or exceeding authorized access, and then obtaining information or causing damage, among other things. Many states have similar laws, and some activities may also touch wiretap or stored-communications statutes.

Two developments are worth knowing. In 2021 the Supreme Court decided Van Buren v. United States and read the phrase "exceeds authorized access" narrowly, focusing on whether a person was entitled to access certain areas of a system at all. In 2022 the Department of Justice announced a charging policy under which good-faith security research is not meant to be prosecuted. Neither change makes unauthorized testing safe. Policy is not law, it can change, and it does not bind state prosecutors or private parties who may sue. The practical lesson is the same: get authorization in writing, and stay inside it.

Nothing here is legal advice. Your counsel should review the authorization language, especially if the test touches regulated data, a shared platform or systems in more than one state or country.

Third parties and cloud platforms

Your website probably runs on someone else's infrastructure. Your authorization covers your assets. It does not cover your hosting company, content delivery network or software-as-a-service provider. Some providers allow customer testing of their own resources within published rules. Amazon Web Services publishes a policy for penetration testing of customer resources, and Microsoft publishes rules of engagement for testing Microsoft cloud services. Others require advance notice or forbid it. Your tester should read the relevant policy and, if needed, request permission before the test.

What this means in practice

  • Expect a short onboarding step with a DNS record or file check before any test starts
  • Expect a signed scope document, and read it. If it is too broad, narrow it
  • Give the tester a named contact who can answer at short notice
  • Tell your hosting provider and your internal team about the test window so nobody mistakes it for an attack, and so your own alerts can be tested on purpose
  • Keep the authorization with the report. It is part of your audit trail

Our team starts every assessment this way. To plan one, see our Cybersecurity service, the Security category in our shop at the security section of our shop, and our companion article on what a code and endpoint review finds in the first 24 hours.

Sources

This article is general information, not legal advice. The Computer Fraud and Abuse Act and state laws turn on specific facts. Have your counsel review any authorization before testing begins. Last reviewed .

Keep reading

Need help with this?

We find out whether everything you run is safe from attackers, then we fix it.

Cybersecurity