As a penetration tester, this wording is put forth in the Statement of Work however, as a tester, I don't recommend that you have the tester just stop the test once access is gained. The purpose of a penetration test is to gain access much similar to how an attacker would gain access. By stopping the test, you could never know what else is exploitable. Let's look at the following:
Let's state the the tester begins at 172.16.1.0 and gains access at 172.16.1.10, the tester comes across a highly exploitable machine, gains full control, and you stop the test. What have you benefited from if there were 244 machines left untested?
One of the biggest hurdles we (testers) face, is that we are at times limited in what we can test, and how we can test. Generally, I aim to use reliable exploits which don't affect a client's network (crash services, cause denials of service). Many times techniques a bonafide attacker would use are of the table for me. E.g., chaining exploits, where I can find a low level cross site script (XSS) but the only way for me to exploit it, would be to add a social engineering vector (emailing your employee a link).
There are pros and cons with performing pentests, and the standard: "Aim a tool at this network block, if you can't get in, we are safe" never works. This is because the testing is a loaded gun. As a professional tester, I know I can't do something to disrupt your operations, so I will not chance it. A bonafide attacker is never going to state: "well if I run this exploit, I might crash his system... Better not," or "well this is only an XSS attack... I better not use this in a crafted email," or "I found the first exploitable machine... I should stop exploiting the rest of the network." On the contrary, an attacker will run whatever exploit they want, they won't care if they crash anything, and they will chain exploits.
I prefer performing internal blackbox (anything goes) testing from the inside. With and without credentials versus remote testing. This is simple logic: "Let's assume they made it in the front door... What can they do." This enables me to have the client determine his security posture from the inside out, where external testing is performed AFTERWARDS. I found this approach yields much better results than firing off at an external IP.
Further, depending on your structure, I have run across too many third party hosting providers. This is where the client's web facing infrastructure is say on Amazon, or some other hosting provider, to which we cannot test, as cloud provider shun penetration tests. So you're likely going to get a skewed report.
My advice is, if you're going to let someone test, it should be all or nothing. Most competent testers are aware of the pitfalls I mentioned here. Most should already know: "thou shall never use exploits that will crash something" so they will be responsible. However, I would not stop testing, and you would get more bang for your buck performing internal testing first (blind, and with credentials) followed by external testing.