2026-07-15 · PRACTICE · The Offensive Technology team

Why every engagement starts with a signature

There is exactly one thing that separates a penetration test from a computer crime, and it is not skill, tooling, or intent. It is authorization. The same command run against the same server is a professional service on Tuesday and a felony on Wednesday, and the only difference is a piece of paper.

So before we touch anything, we get that paper right. Here is what that actually means in practice, and why we will not skip it even when a client is in a hurry.

Ownership before access

The first question is not "what do you want tested," it is "can you prove you control it." Anyone can type a domain into a form. That does not mean they own it, and if they do not, testing it puts us both on the wrong side of the law.

So we verify. Usually that means you place a token in a DNS record we can read, or confirm from an email address on the domain itself. It takes a few minutes and it is not negotiable. If you cannot prove control of the target, there is no engagement to have.

We do not rely on a signature alone either. We take written authorization from a named person and still want the technical proof behind it, because a signature on the wrong letterhead is exactly how a tester ends up pointed at the wrong target.

Scope is a fence, not a suggestion

Once ownership is settled, we write down exactly what is in bounds and what is not: which hosts, which applications, which techniques, and which are explicitly off the table. That document is the fence. We stay inside it even when something interesting is clearly reachable just outside.

• The assets we are allowed to touch, listed by name.
• The techniques you have approved, and any you have ruled out.
• Timing windows, so testing never surprises your team or your customers.
• A named contact who can stop the whole thing with one message.

The same document settles two things people forget until they matter. First, the environment: are we testing production, where a heavy request can affect real customers, or a staging copy that mirrors it? Both are valid choices, but the choice has to be made on purpose, not discovered mid-test. Second, the stop condition: who can call a halt, how they reach us, and what happens to any access already gained if they do. This is a signed pre-engagement agreement, not a friendly understanding. When it is done well, nobody has to improvise under pressure.

When the target is not entirely yours

Owning a domain name is not the same as owning everything it points to, and this is where well-meaning scopes go wrong. A common example: a client lists app.clientco.com as in scope. We look it up and it is a CNAME to a third-party SaaS platform the client subscribes to but does not run. They control the DNS name; they do not control the servers behind it. Testing that host means testing the vendor, who agreed to nothing. So it comes out of scope, or the client obtains written permission from the vendor first.

The same caution applies to assets on shared hosting or behind a shared CDN, where a single IP address can serve thousands of unrelated tenants, and to a domain acquired in a deal whose records still resolve to the seller's infrastructure. Major cloud providers publish their own acceptable-testing policies too, and some activity, denial-of-service and stress testing in particular, still needs their prior notice or approval even on resources you own. Untangling what is genuinely yours is part of mapping the external attack surface, and it happens before any test, not during.

The law behind the line

The reason we are inflexible about this is not internal policy. Most countries treat unauthorized access to a computer system as a crime in itself. In the United States it is the Computer Fraud and Abuse Act; in the United Kingdom, the Computer Misuse Act 1990; across the European Union, member states criminalize illegal access under national laws implementing the bloc's directive on attacks against information systems. The specifics differ by jurisdiction, but the through-line is the same: access without the owner's permission is the offense, and a helpful intent is not a defense. This is not legal advice, and your own lawyer is the right person to read the statute that applies to you. It is simply why not a single request goes out until authorization and ownership are settled.

Why we are strict about the boring part

Clients sometimes read this as bureaucracy. It is the opposite. A tight authorization is what lets us be aggressive inside the fence without either of us worrying. When the boundaries are written down and signed, we can chain attacks hard and prove real impact, because everyone already agreed on where the edges are.

The teams that get burned are the ones who treated scope as a formality. We treat it as the foundation, because it is.

Authorization first: quick answers

Do I need written authorization to test systems I already own?

In practice, yes. Written authorization proves your own team approved the test, which protects you internally, and it protects the operator running it. If any part of the environment sits on infrastructure you do not fully control, such as a cloud platform or a hosted SaaS product, you may also need that provider's permission. Get all of it in writing before anything runs.

What is a rules of engagement document?

It is the written agreement that defines the test: the exact targets in scope, the techniques allowed and forbidden, the testing window, the named contacts on both sides, and the conditions under which testing stops. It turns a vague "go test us" into something both sides can be held to.

Is it illegal to scan a website I do not own?

It can be. Many jurisdictions criminalize unauthorized access to computer systems, and the boundary between a scan and access is not always where people assume it is. Without authorization and proof you control the target, do not point anything at it. This is not legal advice; consult a qualified lawyer for your jurisdiction.

How do you confirm I own a target before testing it?

Usually a record we ask you to publish in the target's DNS, or a reply from a mailbox on the domain itself. Both prove control in a way a web form cannot. Until that check passes, there is no engagement.

Related reading

• Check, scan, or full pentest?
• How to prepare for your first penetration test
• What OSCP, OSEP, and CRTO actually prove