A client ran an unannounced security test against our platform and took it down for everyone else

For the forward-looking part: offering a customer testing policy proactively is worth more than it costs.

Enterprise customers increasingly want to test their suppliers, and a supplier who says "here is the process, here is the window, here is the staging environment" looks far more mature than one who has never considered it. It also means the next customer who wants this asks you first, which is the actual outcome you want.

Many platforms publish exactly such a policy. It turns an awkward request into a form.

The core principle in this field is worth stating plainly, because it is the whole basis of your position: what separates a penetration test from an attack is authorisation. Not intent, not professionalism, not the quality of the report afterwards. Written permission from the party who owns the system.

Your customer owns their account. They do not own your platform, and on a multi-tenant system they cannot authorise testing that affects infrastructure shared with other customers. They gave permission they did not have to give.

So you are not being unreasonable and you are not obliged to treat the findings as a favour. A competent testing firm asks who owns the target and requires authorisation from them before starting — if the firm did not ask, that is a finding about the firm.

How hard to press this is a commercial decision. But go into the conversation knowing you are the party who was wronged, not the party who failed an exam.

The practical sequence that keeps the relationship while making the point, which is what you asked for:

1. Handle it as an incident first. Whatever your process is for a suspected attack, follow it, including any notification you owe your other customers. Do not skip that because you now know the source.
2. Contact the client at a senior level, calmly, in writing. State what happened, what the impact on other customers was, and that testing requires prior written authorisation from you.
3. Say yes to the underlying request. They wanted assurance about your security. That is a legitimate thing for a customer to want and the answer should be a process, not a refusal.
4. Put that process in writing and offer it to everyone: a defined testing window, a staging environment, scope limits, a contact, and rate limits. Ask for notice.
5. Get it into the contract at renewal, along with the corresponding prohibition on unauthorised testing.

Step 3 is what converts this from a dispute into an improvement, and it is the difference between keeping the account and winning an argument.

Two things worth noticing about the test itself, because they inform how much weight to give the findings.

A flood of unauthenticated requests as the opening move is not a competent assessment. A good tester scopes, coordinates and avoids volumetric effects precisely because taking the target down produces no findings and a lot of collateral. If the first phase brought your service down, either the tester was careless or the exercise was not what it was described as.

The findings are still worth reading. Whatever the process failure, if they found something real then it is real, and the person who reported it badly is not a reason to leave it unfixed. Triage it on the merits, separately from the conversation about authorisation.

Also worth taking seriously: the fact that this took you down is itself a finding. An unauthenticated request flood should degrade gracefully rather than affect other tenants. That is a rate limiting and isolation issue you now know about, and it is the most valuable thing to come out of the whole episode.