How is a penetration test conducted — how do we manage the process without downtime on our live site?

The single most critical rule to avoid downtime is throttling the scan tools (rate limiting). Impose a hard ceiling of 5 to 10 requests per second on the testing team. Make it an absolute condition that bulk injection attacks against database-heavy search and filtering endpoints are done manually and under strict control.

Non-negotiable clauses for the pre-test specification: 1) DoS/DDoS and brute-force attacks will not be executed in production, 2) No deletion or alteration of records in the live database, 3) Testing is strictly restricted to the 01:00–06:00 window, 4) Any critical zero-day or high-severity flaw found must be reported immediately without waiting for the final report delivery.

During our first pen test, the tester ran an automated fuzzing run against our signup form and triggered our SMS verification gateway. It fired off 14,000 verification SMS messages in three hours, and our telecom provider blacklisted our account for suspected spamming. Make sure you mock or stub out third-party notification, SMS, and payment gateways before starting.

Is your client asking for a TSE-accredited penetration test, or will a report from an internationally certified outfit (CREST, OSCP, etc.) suffice? That distinction completely changes which vendors you can source quotes from and how much you'll end up paying.

We ran a grey-box pen test on our B2B platform of comparable size. The entire engagement took 5 business days. They flagged 2 critical and 4 medium-severity vulnerabilities. Because we scheduled the runs during off-peak hours, server CPU utilization never crept past 40 percent and we saw zero downtime.

If your infrastructure permits spin up a staging environment that mirrors production 1:1 using an anonymized sanitized dump of the live database. Running the test there eliminates any risk to your live orders and active user sessions.

Dont stress too much over it, no legit corporate pen tester is reckless enough to nuke a live production box. As long as you keep communications open and keep DoS strictly out of scope, the whole thing will go off without a hitch.

Edit: asked below, I wrote the answer in the second message.

Before any testing kicks off, an NDA and a formal Authorization Letter (Rules of Engagement) must be executed with physical wet signatures. Drawing clean boundaries around legal liability and keeping absolute emergency stop authority on your end is non-negotiable from an information security governance standpoint.

There is something to watch out for. People defend habits, not processes. Resistance comes from there.

We need to take it step by step. If the notification path is long, notifications don't arrive; missing notifications mean delayed incident detection.

Hope this helps.

Following.

I didn't know that.

The opposite happened to me, that's why I'm writing. Forgotten test environments are more often the entry point than live systems.

Proven by experience.

We got stuck at the same point for a while. If 2FA is on, a stolen password alone is useless.

Just leaving this note, it might be useful.

I dont think this advice fits everyone. If 2FA is on, a stolen password alone is useless.

Thanks for writing this, that's the right way. If you scold false alarms, nobody will report again.

Of course, it varies if your situation is different.

I think differently. Solutions that work at a small scale collapse when you grow; I learned this late.

If I were you I'd go this route.

Could you elaborate on that? The answer varies greatly by industry; there is no one-size-fits-all rule.

I'm also curious if anyone does it differently.