Enterprise customers increasingly write testing obligations into the contract rather than asking about them during procurement. The clauses are usually reasonable and they carry cost and operational consequences that nobody calculates before signing. Where personal data is involved, they sit alongside the processor obligations that UK GDPR already imposes and that the Information Commissioner’s Office expects to see reflected in your agreements.
The clauses that appear most often
Four recur. An obligation to test annually and on significant change, usually with a requirement that the tester is independent and accredited. A right for the customer to receive evidence, which needs defining as a summary rather than the full report. Remediation timescales by severity, often critical within seven days and high within thirty. Finally, a notification obligation requiring you to tell the customer about findings affecting their data, sometimes within a shorter window than your own incident process currently supports.
Right to audit and right to test
These are different and the second deserves attention. A right to audit typically means a review of documents and processes, occasionally on site, which is manageable with notice. A right to test means the customer or their contractor may run technical testing against your systems, and in a multi-tenant platform that raises immediate questions about the effect on other customers. Negotiate the scope, notice period and frequency, and offer your own current test report as the first option, which most customers accept when the report is recent and independent.
“Read the remediation timescales before you agree them, because seven days for a critical finding sounds fine until it applies to a third-party component with no patch available. Ask for the clause to allow documented compensating controls where a fix is outside your control, otherwise you have signed up to something you cannot always deliver.”
William Fieldhouse, Director, Aardwolf Security Ltd
Making the obligations affordable
Several customers with slightly different clauses can produce a testing programme that costs far more than it should. Standardise instead: run one thorough annual assessment covering the platform, plus retests, and make sure the report is written so it satisfies every customer rather than being tailored to one. Where a clause demands a specific accreditation, check it before signing rather than discovering later that your supplier does not hold it. If several contracts are in negotiation, discuss your testing requirements as a whole so the programme is designed once.
Flowing obligations down
If you depend on subcontractors or hosting partners, the commitments you make need to be reflected in your agreements with them. A promise to remediate a critical finding within seven days is difficult to keep when the affected component belongs to a supplier whose contract says nothing about timescales. Review your own supply chain against the strictest customer clause you have signed, and raise the gaps at renewal rather than discovering them during an incident. When you choose a penetration testing supplier, ask whether they will support you during a customer audit, since that request arrives eventually in every enterprise relationship.
Frequently asked questions about contract testing clauses
These questions come up when legal review meets a security schedule.
Should you ever agree to a customer testing your production platform?
With a defined scope, notice, agreed timing and a rule of engagement document, it can be workable. In a shared platform, offer a dedicated environment or your own report first, because a customer’s tester cannot be allowed to affect other tenants.
Who pays for testing the customer demands?
You do, in almost every case, which is why the obligation belongs in your pricing. Where a customer asks for testing beyond your normal programme, it is fair to discuss cost, particularly for a dedicated environment.
