A client called us with a request that started the way these usually do. Their biggest customer had sent a security questionnaire, and one line said the vendor must perform annual penetration testing. They wanted to know the cost and how fast we could get it done.
Our first question was not about scope or price. It was whether they had ever run a vulnerability scan and fixed what it found. They had not. That is the honest heart of this topic: a penetration test is a legitimate thing to buy, and most small businesses buying one would get more security for less money doing something simpler first. Here is how to tell which you are.
Three Different Things People Call a Pen Test
The words get used interchangeably in sales conversations, which is how businesses pay for one thing and expect another.
- A vulnerability scan is automated inventory and comparison. Software examines your systems and compares what it finds against a database of known weaknesses. NIST’s guide to security testing describes it as identifying hosts and their attributes while “attempting to identify vulnerabilities rather than relying on human interpretation.” It runs in hours, costs little, and can run monthly.
- A penetration test is a person trying to break in. A tester works out how to chain weaknesses together into actual access. NIST lays out a four-stage methodology: planning, discovery, attack, and reporting. It takes days or weeks of skilled human labor, and it is priced accordingly.
- A red team exercise tests whether you notice. A team simulates a real adversary over weeks, quietly, with a goal like reaching payroll data. The subject under test is not your systems. It is your detection and response. Most small businesses have nothing to detect with yet.
One more distinction, because it changes the price sheet: a tool advertising itself as continuous penetration testing is generally a scanner with better reporting. Useful, but not a human adversary, and you should not represent it as one on a compliance form.
What a Scan Is Good At, and Where It Stops
Scanning is unglamorous and it earns its keep. It finds outdated software, missing patches, and misconfigurations across your whole estate, consistently, without getting tired. If your firewall has a management interface exposed to the internet, a scan tells you today. It can only look at what you know you have, which is one more reason the unsanctioned apps and devices in our piece on shadow IT matter here.
NIST is also clear about the limits. Scanners find what it calls “surface vulnerabilities” and are “unable to address the overall risk level of a scanned network.” The deeper issue is that “vulnerabilities rarely exist in isolation.” Real compromises chain unremarkable findings together: an information leak reveals a username, an old service allows a weak login, that account has more rights than it should, and someone is inside. Each link might rank medium or low on a scan report. Together they are a breach.
Scanners also produce noise. NIST notes that application vulnerability scanners “typically have high false positive rates” and advises calibrating them. Someone must read the output, discard what does not apply, and decide what to fix. That work is the value, and it is the step most often skipped.
What a Penetration Test Adds
A pen test answers what a scan cannot: given everything wrong here, what could someone actually accomplish? NIST frames it as the more reliable way to identify the risk of vulnerabilities in aggregate rather than one at a time.
That produces two things worth paying for. First, a demonstrated attack path, far more persuasive than a severity rating. “We reached the file share with your customer contracts, and here is how” moves budget conversations that a list of vulnerability numbers never will. Second, discovery of flaws no database contains: business logic that can be abused, a permissions structure that made sense when it was built, a process that lets someone reset a password by calling the front desk.
Be clear-eyed, though. A penetration test is a snapshot of a specific scope on specific dates. It is not a warranty. Your environment changes the week after, when someone installs a new application, and the report ages from that day.
Who Actually Needs One
Our honest read:
- You have a compliance or contract requirement. The most common legitimate reason. Read it carefully, because it usually specifies scope and frequency, and some frameworks accept a scan where people assume a full test is required.
- You build software or run a customer-facing application. If customers log into something you host, a human tester probing authentication, access controls, and business logic finds problems no scanner will.
- You handle unusually sensitive data. Health records, financial account access, or anything where a breach ends the business rather than embarrassing it.
- You have already done the basics. Multi-factor authentication everywhere, patching that happens, backups you have restored from, least privilege, scan findings remediated. Now a pen test tells you something new instead of confirming what you already ignored.
- You are being acquired, or acquiring someone. Diligence on both sides tends to want independent evidence.
If none of those describe you, spend the money on continuous scanning plus the labor to fix findings, and revisit in a year. CISA offers a vulnerability scanning service that continuously assesses internet-facing assets for known vulnerabilities, weak configurations, and suboptimal security practices, which tells you where a federal agency puts the baseline. Baseline first, then the deep dive. We made the broader case in why cybersecurity stopped being optional for mid-sized businesses.
How to Read the Report
The report arrives, it is 60 pages, and it opens with a color-coded chart. Here is how to get value from it without panicking or filing it away.
- Read the attack narrative before the findings list. Any report worth its price walks through what the tester did, in order. That story tells you where your real weaknesses are. The findings list tells you what to file tickets for.
- Treat severity ratings as a starting point, not a verdict. A rating reflects the general case. A medium finding on the server holding customer data outranks a high finding on the guest printer. Ask about items marked informational too, since testers park useful observations there.
- Look for repeated root causes. Twelve findings often trace to three habits: patching that misses systems, accounts with more rights than the job needs, default configurations left in place. Fix the habit and the findings go together.
- Turn it into dated, owned tasks. Every finding you intend to address gets a name and a date. Every risk you accept gets written down as accepted, with a reason. An unremediated report is worse than none, because now you have documented knowledge of a problem you ignored.
- Agree on retesting up front. Confirm before signing whether the tester will verify your fixes, and whether that is included or billed separately.
The Bottom Line
A penetration test buys evidence: proof of what an attacker could reach, found by a person who thinks like one. That is real value, and if a customer or regulator requires it, buy it and do it well. What it does not buy is security. Security comes from remediation, which is work you schedule and staff whether the findings came from a scanner or a specialist.
The contrarian version: a monthly scan with the findings actually fixed beats an annual pen test that gets filed. If you can fund only one, fund the one that changes your systems. If you can fund both, do them in that order, because a pen test against an environment that has never been scanned mostly buys an expensive list of things a cheaper tool would have caught.
If you are staring at a security questionnaire and trying to work out what it is really asking for, we can help you read the requirement, scope the right assessment, and build a remediation plan you will finish. Contact us today.
Sources:
Comments are closed