- › Every assessment has an out-of-scope list, agreed during sales and never revisited.
- › Systems get excluded for reasons that correlate almost perfectly with being fragile, undocumented, or owned by nobody.
- › The report you receive describes the tested portion, and the clean result is frequently read as a statement about the whole organization.
- › Attackers do not honor your scope, so the exclusion list reads as a target list to anyone who obtains it.
- › Ask for the exclusions before you ask for the findings, and require a written reason and an owner for each one.
Pull out your most recent security assessment and turn to the scope section. Not the findings, the scope. Somewhere in there is a list of what the testers were not permitted to touch.
Most executives have never read that list. It was agreed months earlier during a procurement conversation, usually between a vendor’s project manager and somebody in IT, and it has never been discussed since. It is also, in my experience, the most informative page in the document.
Why Things End Up Out of Scope
The exclusions are rarely arbitrary. There is always a reason, and the reasons fall into a small number of categories that are worth naming plainly.
It is fragile. The system cannot take a scan without falling over, so it gets carved out. Everyone involved understands that a system too delicate to be scanned is a system with problems, and carving it out is still the path of least resistance.
Nobody owns it. The testers ask who authorizes testing against a particular platform and no name comes back. Without an owner to sign the authorization, the platform leaves scope by default.
A third party runs it. Your contract with the vendor does not permit testing, or permits it only with 30 days notice and their supervision, so it drops out for this cycle and every subsequent one.
It is production and somebody is nervous. This is the honest one, and it is not unreasonable. Nobody wants the assessment to be the thing that takes down the order system.
The budget only stretched so far. Scope is priced. A number was agreed and the scope was cut to match it, which is a commercial decision that arrives dressed as a technical one.
Look at that list again with an attacker’s eyes, because fragile, unowned, third-party operated, business-critical, and cheap to overlook is not a description of the boring parts of your estate. Those are the parts where a real intrusion would go best, and a process that was solving for cost and convenience selected them for you.
The Report Says Less Than People Hear
Here is where this stops being a technical problem and becomes a governance one. An assessment report describes the systems that were tested. It says so, usually in a methodology section that is scrupulous about it. But the result that travels upward is a summary, and the summary becomes “we had a penetration test and came back clean,” and the board hears a statement about the organization.
Nobody lied. The report was accurate, the tester was competent, and the finding count was genuinely low. The compression happened somewhere between the document and the slide, and by the time it reaches the audit committee the exclusions have vanished entirely.
We wrote last week about the SOC that detected nothing, where a red team achieved full domain compromise at an organization whose dashboards were all green for entirely correct reasons. This is the same shape of problem one layer up. A clean report and an untested estate look identical on a slide.
The Exclusion List Is a Target List
There is a harder version of this that I raise with clients who push back. Your scope document is a written inventory of the systems your organization believes are too fragile, too unowned, or too sensitive to test. It exists in email, in a shared drive, and at your vendor. It has probably never been classified.
If an attacker obtained it, they would not need to do reconnaissance. You have already done it for them and arrived at the same answer they would have, because the selection criteria overlap almost completely. That is worth knowing regardless of whether it ever happens, because it tells you what the document actually is.
Five Questions to Ask Before the Next One
None of this requires spending more. It requires reading the scope with the same attention people give the findings.
Ask for the exclusions before the findings
When the report arrives, read the scope section first and the executive summary second. If you cannot tell from the document what was excluded, that is your first finding and it belongs to the vendor.
Require a written reason and a named owner for every exclusion
Not a category, a reason. “The billing platform was excluded because the vendor contract requires 30 days notice, owner: Sarah in Finance.” An exclusion with a name attached becomes somebody’s problem, and an exclusion without one stays invisible forever.
Check whether this year’s exclusions match last year’s
This is the question that produces the most uncomfortable silences. If the same three systems have been out of scope for four consecutive assessments, they have never been tested, and your organization has been describing itself as assessed for four years.
Ask what a compensating check would cost
Full testing is not the only option. A configuration review, a credential audit, or an architecture walkthrough covers ground without touching production, and it is far cheaper than the test somebody vetoed. Something is available for almost every exclusion, and it is rarely offered because nobody asked.
Put the exclusion list in front of whoever accepts the risk
The person who agreed the scope was solving a project problem. The person who owns the risk is usually somebody else and has never seen the list. Getting those two facts into the same room is the entire intervention, and it costs a meeting.
What Good Looks Like
The strongest security programs I have seen do something small and unusual with this. They treat the exclusion list as a standing register rather than a per-engagement artifact.
Each entry carries a reason, an owner, a compensating control if one exists, and a date by which the exclusion will be revisited. It gets reviewed alongside the findings, not filed with the contract. When a system comes into scope for the first time in three years, that is recorded as an achievement, because it is one.
That register is a more honest description of your security posture than any report, since it tells you what you know, what you do not, and which of those you chose.
The One Thing to Do This Week
Find your most recent assessment, extract the out-of-scope list, and send it to whoever signs off on risk with a single question: were you aware these were excluded?
The answer will tell you whether your assessment program is producing assurance or producing paperwork. Our guide to what a cybersecurity assessment includes covers the scope side from the buyer’s perspective, and this is the question it leads to.
Want an assessment that starts with what you have never tested? Contact Grab The Axe for a security assessment, or start with our free Human Attack Surface Score.
A PhD candidate in Health Psychology and former Corrections Officer, Jeff founded GTA to dismantle passive security models. He focuses on the 'Human Zero-Day', mitigating executive burnout and decision fatigue before they become security breaches.
View Author Page →
