On the awkward conversation where the scope of a test shrinks for the wrong reasons.
We were two weeks out from a penetration test (where somebody is paid to try to break into a system so you can find the gaps before an attacker does) and the scope call had been going well. The client’s IT lead had walked us through their estate. We’d agreed targets: the corporate identity (the system that decides who gets to log in to what), the cloud file storage, the customer-facing portal, the VPN (virtual private network, the secure tunnel staff use to log in from outside the office).
Then he said, “Can we leave the warehouse system out of scope?”
Fair question on its face. There are reasons to exclude something from a test. The system’s mid-migration. There’s a vendor support agreement that excludes pen testing without notice. It’s an isolated network with no path to anything sensitive. We’ve left things out for all of those reasons.
This one wasn’t one of those reasons. He’d already told us the warehouse system was old. He told us the credentials were “a bit informal”, shared between four shift leads, hadn’t been changed in three years. He told us the database it ran on was a Windows version that had been out of mainstream support for years. And he told us, with a small smile, that he’d rather we didn’t poke at it because he didn’t want what we’d find to go in the report.
The awkward conversation
We had to say no. Not loudly (this isn’t a confrontation, the IT lead was being honest with us and we appreciated it) but firmly. The whole point of a pen test is to find the things the client would rather not find. Excluding the system the client most wants you not to look at is excluding the system you most need to look at.
We spent an hour on the call talking it through. Three things ended up mattering.
The report exists for the board, not for him. If the warehouse system is the weakest link, the board needs to know it’s the weakest link. Leaving it out so the report looks better is a disservice to the people commissioning the test.
An attacker won’t leave it out of scope. Real adversaries don’t read your statement of work. They look for the path of least resistance. If the path of least resistance is a 2019-vintage database with shared credentials, that’s the path they take. A test that pretends that path doesn’t exist isn’t a test.
The fix doesn’t need to be in this quarter. Finding the gap doesn’t oblige anyone to fix it tomorrow, only to put it on the list with a date next to it. The conversation about budgeting the fix is a separate conversation from the test that surfaces the gap.
We agreed to include the warehouse system in scope, agreed to flag findings against it in a separate annex of the report, and agreed that the IT lead could brief the board himself on the remediation plan before they read the annex. That gave him control of the narrative without us hiding the substance.
Why this comes up more than people think
The pure version of “don’t test this because I don’t want to know” is rare, but the diluted version of it is everywhere.
“Can you test the new system but not the legacy one, we know the legacy one’s bad.”
“Can you stay off the finance servers during this quarter, it’s a busy time.”
“Can you test the office but not the remote workers, the remote setup is a mess.”
“Can we exclude the third-party platform, they’re contractually responsible for security.”
Each of those has a defensible version and an indefensible version. Some legacy systems are genuinely scheduled for decommissioning in six weeks and there’s no value in testing them. Some finance windows are genuinely the wrong time for a test that might cause an outage. Some third-party platforms genuinely have their own attestation reports that cover what you’d find.
The indefensible version of each is the same shape: testing the thing would surface something the requester would rather not have on a page they have to sign. That’s the version we push back on.
The role of the tester
We’re not auditors and we’re not the police. The client buys the test, the client owns the scope, the client owns the report. We don’t get to override that.
What we do get to do is tell the client, in writing, when we think the scope is hiding the answer the test is supposed to find. Sometimes they push back and we proceed anyway, on the narrower scope, with our concern noted. Sometimes they hear it, sleep on it, and come back saying expand the scope. Sometimes they go quiet for a week and then come back with “OK, but find a way to make the report digestible”.
What we don’t do is shrug, take the narrower scope, and write a report that pretends the gap isn’t there.
There’s a version of this work where you give the client whatever they ask for, and it’s a less awkward business to run, but it’s also a worse one, because eighteen months later when the warehouse system gets breached and the board reads the test report from two years ago, the report says nothing about the warehouse system. And the unanswered question becomes whether the tester didn’t look, or looked and didn’t say.
Where this lands with us
This is the part of our Security Solutions practice that doesn’t show up in the marketing material. We’ll run the test, write the report, walk you through the findings, but we’ll also have the scoping conversation honestly, and we’ll tell you when we think the scope’s been written to protect somebody’s reputation rather than the company’s posture.
That tends to make the first conversation slightly more uncomfortable and the relationship that follows more useful. The trade is one we’re happy with.
In summary
If you don’t want it tested, you probably need it tested. A scope written around the embarrassing parts is a report your insurer can use against you, a board paper that misses the actual risk, and an eighteen-month head start handed to whoever finds the gap first. Run the test. Argue about the remediation timeline after.
Scoping a pen test and not sure which conversations to have first? Drop us a note at info@jmopartners.co.uk. One of us will read it.
JMO|Partners · Enterprise IT, sized for SMEs.