Drafting a pentest waiver: this is what belongs in it

Drafting a pentest waiver involves recording the rights holder's permission, the scope of the test, the indemnification of the pentester, and agreements regarding liability, confidentiality, and personal data in a single signed document. The waiver removes the criminal liability of computer intrusion (Article 138ab of the Dutch Criminal Code) by granting prior consent and clearly defining the boundaries of the test. Anyone who has the building blocks complete ensures that the test is conducted legally and that it is clear in advance who bears which risk. Below is a list of exactly what should be included.

The short answer

1. Parties and rights holder: who gives consent and who tests.
2. Scope and authorization: which systems, methods, and period.
3. Indemnification: the pentester is indemnified for actions within the scope.
4. Liability and damages in the event of unintended failure.
5. confidentiality, disclosure, and GDPR .

Drafting a pentest waiver: the core

The basis of any pentest waiver is the consent of the party holding the systems. Without that consent, intrusion falls under computer trespass, Article 138ab of the Dutch Criminal Code. Therefore, first establish who the rights holder is and who is authorized to sign on behalf of the organization. If the systems are hosted by a hosting provider or cloud service, you also need that party's consent, because your organization is not the rights holder of the underlying infrastructure. Only when this chain of consent is correct can you meaningfully structure the waiver.

Scope and authorization

The scope is the most important part, because the consent only applies within those boundaries. Define concretely:

• Systems in scope: which domains, IP ranges, applications, and networks may be tested.
• Expressly out of scope: third-party systems, payment providers, or production components that must not be affected.
• Permitted methods: for example, network and application testing are allowed, but no social engineering or denial-of-service, unless agreed separately.
• Time window: when the test takes place, so that the organization can distinguish it from a real attack.
• Contact persons: who can be reached if something goes wrong and the test needs to be stopped.

A clear scope protects both sides. The pentester knows what is allowed, and the client knows that testing is not being performed outside the agreements.

Indemnification, liability and damages

This block distributes the risks:

• Indemnification: the rights holder declares that the pentester is acting with permission and indemnifies them against liability for access and actions within the scope. This is what makes the test legally safe.
• Unintended damage: a penetration test can cause a malfunction or downtime. Specify who bears that risk, usually the client within the scope, and whether a backup or recovery plan is in place.
• Limits of the indemnity: intentional or grossly negligent damage and acts outside the scope fall outside the indemnity. Include this explicitly.
• Liability of the pentester: a reasonable limitation of liability, coupled with due care and possibly professional liability insurance.

An example. An SME has its customer portal tested. The waiver states that the client makes a backup beforehand, that the test runs outside office hours, and that unintended failures within the scope are at the client's expense. When a test caused a temporary malfunction, there was no dispute regarding the bill.

Confidentiality, disclosure and personal data

The final building blocks protect the information and those involved:

• Confidentiality: the pentester keeps found vulnerabilities and discovered data confidential, for a period that continues after the test.
• Responsible disclosure: findings are reported only to the client, not made public, and there is a time limit for rectification.
• Personal data and GDPR: if the test involves personal data, the requirements of the GDPR apply. Include a legal basis, appropriate safeguards pursuant to Article 32 of the GDPR, and usually a data processing agreement. Agree that any personal data found will not be retained.
• Return and destruction: what happens to collected data and the test report after the test.

Honest recommendation

For a simple, internal test on systems you manage entirely yourself, without personal data and without third-party systems, you can draft a concise, signed consent form. Ensure that the scope, timeframe, and signing authority are clear. This covers the minimum.

As soon as third-party systems, customer data, production environments, or an external penetration tester are involved, drafting a pentest waiver is no longer a simple fill-in-the-blanks exercise. The scope definition, indemnification, and GDPR provisions determine whether the test is legal and who bears the risk in the event of damage. An overly broad scope or a lack of consent from the hosting provider can render both the penetration tester and the client criminally liable or responsible. Have a lawyer draft or review the waiver before the test begins.

More about the explanation and costs: pentest waiver, what is a pentest waiver and have a pentest waiver drafted.

Frequently Asked Questions