This lands on a security team's desk in two forms, with legal waiting on an answer today. As the buyer, you are about to put regulated data into someone else's multi-tenant application and want a clause that lets you point a tester at it. As the seller, an enterprise customer has written "Customer may conduct penetration testing of the Services" into a security exhibit and you must accept, redline or counter. Both turn on one fact: authorization is the legal basis of a penetration test, and it must come from the party that owns and operates the asset.
What "right to test" actually means in a contract, and what it never means
A right-to-test clause grants permission from the entity that operates a system to a counterparty who wants to attack it under controlled conditions. A usable grant names the grantor, the permitted activity, and the bounds of scope, time and technique. Four things it never means:
Not a right to test whatever you can reach. Permission to test your instance is not permission to test the platform, or the tenants beside you.
Not a right to test the underlying cloud. AWS states that "Customers are not permitted to conduct any security assessments of AWS infrastructure or the AWS services themselves". Your vendor cannot grant what it does not hold.
Not a right to publish, and not a warranty. Atlassian treats results as "Atlassian's confidential information" requiring permission before public disclosure. Salesforce's Security Assessment Agreement says "Nothing in this Agreement shall be construed to mean that any Assessment performed shall constitute a certification or warranty that SFDC's services and systems are secure".
Not a right to audit. A right-to-audit clause grants inspection of documents, policies and control evidence. A right-to-test clause grants live technical interaction with a running system. Signing the first is not agreeing to attack traffic.
Silence is not permission: authorization is the whole legal basis of a pentest
Three jurisdictions, one element. In the United States, 18 U.S.C. 1030(a)(2)(C) reaches anyone who "intentionally accesses a computer without authorization or exceeds authorized access" and thereby obtains information from a protected computer. Van Buren v. United States, No. 19-783, decided 3 June 2021, narrowed the second phrase, holding that liability "stems from a gates-up-or-down inquiry". That narrowing helps people who had access and misused it, not an unauthorized pentester facing a gate that is down.
In the UK, section 1 of the Computer Misuse Act 1990 bites where "the access he intends to secure, or to enable to be secured, is unauthorised" and the person knows it, with a two-year maximum on indictment. In Canada, section 342.1 of the Criminal Code reaches anyone who "fraudulently and without colour of right" obtains any computer service, with a ten-year maximum. Authorization is established before testing, not assembled afterwards.
One refinement. Silence in the agreement is not permission, but permission may live elsewhere: Atlassian publishes standing rules stating that "Atlassian customers may carry out security assessments against their Atlassian Cloud Products (as defined below) without prior approval", and Salesforce publishes a Security Assessment Agreement, with prior approval not required since 31 January 2023. So the rule is not "the contract is silent, so refuse", but: find the written authorization, confirm it covers your target and techniques, and archive it.
The six variables a workable clause must fix
Clauses fail by being too vague to execute.
# | Variable | What the clause must state | If left open |
|---|---|---|---|
1 | Environment and tenant | Exact instance or account, and whether production, staging or a dedicated environment is in scope | Testers scope to whatever DNS resolves |
2 | Notice period | Business days of notice, to a named contact | The vendor SOC calls it an incident and blocks you |
3 | Testing window | Dates, permitted hours, limits on automated traffic | Load tools run at peak and an SLA breaks |
4 | Prohibited techniques | DoS and load testing, social engineering, physical attacks, any interaction with other tenants | A standard methodology includes one by default |
5 | Evidence handling | Storage, encryption, named recipients, destruction deadline | Live records sit in a file share indefinitely |
6 | Stop condition | Trigger, instruction to stop rather than confirm, notification path and deadline | The tester "proves" the bug with another tenant's data |
Variable 3 is more prescriptive than buyers expect: Salesforce's agreement states that "All automated testing must be restricted to the following times: Friday 21:00 PST - Sunday 23:59 PST".
The seventh item is liability, and every policy we reviewed puts damage on the party that ran the test. AWS: "you are responsible for any damages to AWS or other AWS customers that are caused by your testing or security assessment activities". Atlassian: "You are responsible for any damage to the Atlassian Cloud Platform and any negative impact to other customers' data ..." where that damage is caused by breach of its Security Test Rules or the Terms of Service. AWS extends it to resellers, and Atlassian to partners and resellers, so assume you own your tester's behaviour.
Clause language: the buyer-side ask, the seller-side redline, and the middle position
Drafting language, not legal advice; check final wording with counsel.
The buyer-side ask. "Customer may, at its discretion, conduct penetration testing of the Services." Unsignable for a multi-tenant vendor: "the Services" is the whole platform and "at its discretion" removes every control.
The seller-side redline. A flat prohibition plus an offer to share a summary of the provider's most recent independent test. Defensible, but a buyer with real regulatory exposure will not accept a summary alone.
The middle position that gets signed. Grant a bounded right and pre-commit the alternative evidence:
One assessment per contract year, at Customer's cost, against a Customer-specific environment identified in writing, with defined notice to a named contact.
Testing limited to that environment and to Customer's own tenant, data and accounts, with denial of service and load testing, social engineering against Provider personnel, physical attacks and any attempt to reach another tenant prohibited.
On identifying a path to another customer's data, the tester ceases immediately, does not confirm it, and notifies Provider within a stated number of hours; Provider may require suspension on notice.
Findings are Provider's confidential information, shared only under NDA, evidence destroyed after remediation.
Between windows, Provider supplies its current test report and completion letter under NDA, with remediation status by severity.
That last bullet turns the clause from a fight into a trade. Our red team rules of engagement buyer checklist covers the terms that carry over.
Why your cloud provider's pentest policy does not authorize you to test someone else's tenant
Someone always finds the AWS policy, sees that no prior approval is needed, and concludes the vendor's application is fair game because it runs on AWS. It is not.
Provider | Scoping language, verbatim |
|---|---|
AWS | "AWS customers are welcome to carry out security assessments or penetration tests of their AWS infrastructure without prior approval for the services listed in the next section under 'Permitted Services.'" |
Microsoft | "All encouraged testing activities must be performed within your own tenant or assets for which you have explicit authorization." |
Google Cloud | "ensure that your tests only affect your projects (and not other customers' applications)" |
Each is a first-party grant covering your own account, tenant or projects. A cloud provider does not own your vendor's application and cannot consent for it. Microsoft makes the exclusion an enumerated prohibition: "Attempting to access, scan, or test the security of a Microsoft Azure tenant, system logs, or databases that you do not own or have explicit permission to test".
AWS permission is also service-scoped. It names permitted services, prohibits DoS, DDoS and simulated DoS, port, protocol and request flooding, and S3 bucket and subdomain takeover, and requires a Simulated Events form for red, blue and purple team exercises, command and control hosting, simulated phishing and malware testing. The "no prior approval" headline does not cover those. We compare all three policies in cloud penetration testing rules of engagement for AWS, Azure and GCP.
The standard counter-offer: what to hand a customer instead of production access
Have the alternative pre-built so the argument never starts.
Salesforce's compliance site publishes an External Security Assessments category containing an "Attestation of the last 3 vulnerability test covering the full testing scope", noting that "The documents do not contain details of vulnerabilities or findings and is intended only to provide information on the tests performed and scope of testing". Downloads sit behind login. That is the model: recurring, dated, scope-bearing proof without exploitable detail. CSA Cloud Controls Matrix v4 control TVM-06, Penetration Testing, requires "the periodic performance of penetration testing by independent third parties", which asks the provider to commission testing, not to grant customers access.
Build the pack out of four documents:
A current independent test report under NDA to named recipients, naming the testing firm and its accreditation.
A completion letter with firm, scope, dates and an overall risk statement, no exploitable detail. See pentest completion letter vs full report.
A scope statement naming what was tested and what was not.
Remediation status by severity and a retest date. Unremediated highs with no retest date are worse than nothing.
Our recommended middle is that pack plus one bounded annual window per customer against a dedicated or staging environment at the customer's cost. Note what is verified: the evidence pack and restricted-window model are documented vendor practice, while the annual dedicated-tenant window is a negotiating position, not a norm. See unblocking an enterprise security review.
Multi-tenant stop conditions and what happens when a tester touches another customer's data
A tester's instinct on spotting an authorization flaw is to confirm it, because unconfirmed findings get triaged as false positives. On multi-tenant SaaS that instinct is wrong, and the published rules say so.
Atlassian: "if you believe you have found sensitive customer data (e.g., login credentials, API keys etc) or a way to access customer data (i.e., through a vulnerability) report it to Atlassian Support immediately, but do not attempt to validate the vulnerability or otherwise access a customer's account or data." Separately, Atlassian sets a 24-hour deadline for reporting any discovered security flaw. Microsoft is equivalent: "If you accidentally access any data that you do not have rights to, stop immediately. Notify MSRC with the details, delete the data, and acknowledge this in any vulnerability report. Do not share the accessed information."
Give the tester four executable things: the trigger (any sign of access to data not belonging to the customer), the action (stop, do not confirm, do not enumerate, do not exfiltrate), the notification path (a named contact, not a support queue), and a deadline in hours. Add the vendor's duty to confirm receipt and to say who carries any regulatory notification obligation. Where the crossing runs through an integration rather than the core app, see SaaS OAuth and connected app penetration test scope. Atlassian may also blocklist your IPs on an abuse report, so agree the unblock path in advance.
Decision table: when to demand live testing, and when the report pack is genuinely enough
Live testing is expensive and slow. Use the trigger, not the instinct.
Situation | Live testing | Report pack |
|---|---|---|
Regulated data, critical dependency | Yes, dedicated or staging | Not enough |
Product deeply customized for you | Yes, the vendor's test missed your config | Not enough |
Early-stage vendor, no independent report | Yes, or do not buy | Not enough |
Large SaaS, current testing, compliance portal | Rarely | Enough |
Risk sits in your own configuration | No, test your tenant instead | Enough for the platform |
Procurement wants a checkbox, no named risk | No | Enough |
A finding elsewhere suggests the same class | Yes, scoped to that class | Not enough |
The row people skip is the fifth. In many SaaS engagements the exploitable weakness is not in the vendor's code but in the roles, sharing rules, API tokens and connected apps you configured. That surface is yours, you already hold authorization, and no negotiation is needed. See how to scope a penetration test.
Stingrai is a CREST-accredited penetration testing service provider at firm level, founded in 2021 in Toronto with a London office, with 18 published CVEs and 5.0/5.0 across 19 Clutch reviews. Snipe, our autonomous agent, tests web applications and APIs and hunts the classes that decide multi-tenant risk: IDOR, broken authorization and business logic flaws. Hybrid adds human validation of every finding, and the autonomous and hybrid tiers carry the "No High or Critical Finding = Don't Pay" guarantee. See pricing.
Frequently Asked Questions
Can I penetration test a SaaS vendor I pay for?
Only with written authorization, because a subscription is not authorization. Some vendors publish standing permission: Atlassian's Guide to Security Assessments lets customers assess their own Atlassian Cloud Products without prior approval, subject to its Security Test Rules, and Salesforce publishes a Security Assessment Agreement. If your vendor publishes nothing and the contract is silent, negotiate a clause first.
Do I need written permission to pentest a third-party application?
Yes. Authorization is the element that separates a penetration test from an offence under 18 U.S.C. 1030(a)(2)(C), section 1 of the UK Computer Misuse Act 1990, and section 342.1 of the Criminal Code of Canada. It must come from the party that owns and operates the asset, name your organization and your tester, and be archived with the engagement file.
What should a right-to-test clause say?
It must fix six variables: the named environment and tenant in scope, the notice period and named vendor contact, the testing window and permitted hours, the prohibited techniques, evidence handling with a destruction deadline, and the shared-tenancy stop condition with its notification deadline. Prohibited techniques should cover denial of service and load testing, social engineering against vendor staff, physical attacks and any interaction with other tenants. It should also allocate liability for damage.
Our customer wants to pentest our production SaaS, do we have to allow it?
No, and most large SaaS vendors do not allow unrestricted production testing. The defensible counter is a pre-built evidence pack: a current independent test report and completion letter under NDA, a scope statement, remediation status by severity, and a retest date. Salesforce follows this model, publishing attestations that, in its own words, do not contain details of vulnerabilities or findings. If the risk genuinely requires live testing, offer one bounded window per contract year against a dedicated or staging environment.
Does AWS or Azure permission cover testing a SaaS product hosted there?
No. Every major cloud provider policy is a first-party grant scoped to your own account. AWS permits customers to test their AWS infrastructure and states that customers are not permitted to conduct security assessments of AWS infrastructure or the AWS services themselves. Microsoft requires testing within your own tenant or assets for which you have explicit authorization, and Google requires that your tests only affect your projects and not other customers' applications.
Is a right-to-audit clause the same as a right to test?
No. A right-to-audit clause grants inspection of documents, policies and control evidence, normally by an auditor. A right-to-test clause grants live technical interaction with a running system by someone attempting to exploit it. They carry different operational risk and insurance considerations, and signing the first is not agreeing to the second.
What do we offer instead of letting a customer pentest us?
A four-document pack: a current independent penetration test report under NDA to named recipients, a completion letter with firm, scope, dates and an overall risk statement, a scope statement naming what was and was not tested, and remediation status by severity with a retest date. This matches the evidence CSA Cloud Controls Matrix v4 control TVM-06 asks for, requiring periodic penetration testing by independent third parties. Reference a CSA STAR entry so reviewers can self-serve.
Who is liable if a customer's pentester breaks our production environment?
Published provider policies put it on the party that commissioned the test. AWS states that you are responsible for any damages to AWS or other AWS customers caused by your testing, and Atlassian states that you are responsible for any damage to the Atlassian Cloud Platform and any negative impact to other customers' data. AWS extends that obligation to resellers, and Atlassian to partners and resellers, so mirror the allocation in your clause and require the tester to carry insurance.
References
All sources fetched and verified 7 August 2026.
Amazon Web Services. AWS Customer Support Policy for Penetration Testing. https://aws.amazon.com/security/penetration-testing/
Microsoft. Security Testing Rules of Engagement. https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement
Google Cloud. Cloud Security FAQ. https://support.google.com/cloud/answer/6262505
Cornell LII. 18 U.S.C. 1030. https://www.law.cornell.edu/uscode/text/18/1030
US Supreme Court. Van Buren v. United States, No. 19-783, 3 June 2021. https://www.law.cornell.edu/supremecourt/text/19-783
UK Legislation. Computer Misuse Act 1990, s.1. https://www.legislation.gov.uk/ukpga/1990/18/section/1
Justice Laws Canada. Criminal Code, s.342.1. https://laws-lois.justice.gc.ca/eng/acts/c-46/section-342.1.html
Atlassian. Guide to Security Assessments. https://www.atlassian.com/trust/security/penetration-testing
Salesforce. Security Assessment Agreement. https://help.salesforce.com/s/articleView?id=000392845&language=en_US&type=1
Salesforce. Salesforce Security Assessments (source for the 31 January 2023 removal of the prior approval requirement). https://help.salesforce.com/s/articleView?id=000394469&language=en_US&type=1
Salesforce. Vulnerability/Penetration Report Summary, Salesforce Services (Full Scope). https://compliance.salesforce.com/en/documents/a005A00000newkxQAA
Cloud Security Alliance. Cloud Controls Matrix https://cloudsecurityalliance.org/research/cloud-controls-matrix and STAR Registry https://cloudsecurityalliance.org/star/
CSF Tools (secondary; reproduces CSA CCM v4.0). TVM-06: Penetration Testing control text. https://csf.tools/reference/cloud-controls-matrix/v4-0/tvm/tvm-06/
