What a security testing authorization must contain

Why verbal consent is not enough

Sending a request to someone else's system without its owner's consent is a legal problem, not a matter of good manners. Verbal consent doesn't settle what exactly was agreed.

In practice the dispute is never about whether there was consent. It is about whether it covered the production environment, whether sending a thousand requests a minute was allowed and whether the test account was entitled to see that data.

A good authorization answers these questions in advance, in writing, and protects both parties. The party commissioning the test from someone doing something they didn't agree to. The tester from the allegation of acting without a legal basis.

Who signs

The person who actually has the right to dispose of the system. It sounds obvious, and it is the most common mistake.

If an agency commissions an assessment of its client's system, the client's consent is needed, not the agency's. The agency may have written the code, but that doesn't make it the owner of the environment the code runs in.

For a system bought from a vendor, consent must come from the vendor, unless the contract explicitly allows the customer to test it.

What it covers

Specific URLs, repositories, projects and databases. Listed by name.

Wording such as “the entire infrastructure” or “the company's systems” is not a scope, it is the absence of one. It gives you no way to tell whether testing this particular server was covered by the consent.

Which environment

Test, staging or production. This changes everything: when the tests run, the acceptable load, how data is handled and whether anything may be written at all.

If consent covers only the staging environment, the result applies only to that environment, and the report must say so explicitly.

Which tests, and the time window

The level of testing, from simply looking at what is public to tests that send real requests to a live system.

A time window with a start date and an end date. After that date the authorization expires. For us this isn't a note in a binder: a task without an active authorization technically cannot enter the queue.

Limits and prohibited actions

The maximum number of requests per unit of time, permitted test accounts, permitted methods.

A separate list of things that are not allowed, even if they are technically possible. Typically: changing production data, denial-of-service tests, social engineering against employees.

Emergency contact and how to stop

A person and a channel available during testing. Not a generic company address, but someone who will pick up.

A way to stop testing immediately, without giving a reason and without a procedure. One message has to be enough. If stopping requires the consent of three people, in practice it doesn't exist.