In an SME the order for a penetration test rarely comes from security. It comes from a contract. A sentence about an annual penetration test appears in a large customer's framework agreement, procurement forwards it to IT, and two weeks later three quotes sit on the table that differ several times over in price and are barely comparable in content. The question that then lands with the management team is a commercial one: what are we buying here, and what do we hold afterwards?
A penetration test proves that a defined attack surface could or could not be breached at a given point in time. It does not prove that you are secure, and it does not replace taking stock of where you stand. It pays off when a decision depends on the result, when the findings have an owner and when capacity for remediation exists in the quarter that follows. Otherwise you are buying a list that will look the same a year later.
Whoever demands the test decides what it has to prove
In our experience four triggers bring most tests into the business, and each one wants something different.
- A customer. They need evidence for their own supplier management. What matters to them is mostly that an independent tester looked, less what was found in detail.
- An insurer. The questionnaire asks about regular testing. What counts there is the rhythm and the evidence that findings were fixed, less the depth of any single report.
- The board. Usually after an incident in the industry. The question behind it is whether the same thing could happen here. A test on one single system answers that only in part.
- Your own IT. Before a go-live or after a larger rebuild. That is the cleanest case, because a decision depends on the result.
The most common mistake follows immediately: the wording of the contract clause becomes the technical scope. "Annual penetration test of the productive systems" is not a scope. It is an invitation to buy ten test days, three of which hit the target the customer means. Clarify beforehand which question the test has to answer, and you buy less while getting more back.
What the test shows, and what it leaves open
A penetration test proves that a defined attack surface could be breached at a given point in time, by a given person, with given rights and limited time. Or that it could not. That is valuable, and it is narrower than the impression a sixty-page report leaves behind. No test answers whether your restore from backup works, whether anyone in operations would have noticed the attack, or who decides at three in the morning to take a site off the network.
| Instrument | Answers | Does not answer |
|---|---|---|
| Vulnerability scan | Which known gaps are visible from outside or inside? | Whether they are exploitable in your environment |
| Penetration test | Does an attacker get through at this defined point? | Whether operations notice, whether backups hold, who decides |
| Security assessment | Where does the organisation stand overall, what is the largest risk? | Whether one specific application can be broken technically |
| Certification audit | Does the management system meet the standard? | Whether the technology withstands an attack |
Two things often turn up together in our engagements: a fresh test report, and a folder holding last year's report in which a good share of the findings already appeared. That is not a security problem, that is a sizing problem. More protection. Fewer tools. Lower cost. The line holds for testing too: better a smaller test that gets fixed than a large one that gets administered.
When is a penetration test worth it?
A penetration test is worth it when a decision depends on the result: a release, evidence for a customer, an internally contested assumption about an exposed system. If no decision hangs on it, a PDF is what remains. Three conditions decide in practice whether the money turns into protection or into documentation.
- The findings have an owner before the test starts. A name, not "IT". Without an owner the report moves into the folder where the last one already sits.
- Capacity exists in the quarter after the test. Without a window for remediation and a retest, you are buying a snapshot that is already out of date as you read it.
- The target is exposed and business critical. The customer portal, an API, remote access, the application holding the data whose loss costs you the customer. The rest can wait.
Where there is no baseline at all yet, a test is the most expensive route to a first insight. If you want to know where the organisation stands overall, a structured self-assessment gives you more. BACS, the Swiss federal office for cyber security, publishes an assessment tool for the ICT minimum standard, binding for electricity providers since 1 July 2024 and for gas providers since 1 July 2025, and a recommendation for the remaining sectors. What a guided baseline adds beyond that is in our piece on the security assessment as a way of taking stock.
The test is the smaller part of the bill
The quote covers the test. It does not cover the work that makes the test worth something. After the report come prioritisation, remediation, maintenance windows, developer time and sometimes conversations with the vendor of software you did not build yourself. Then the retest, otherwise all that remains is the claim that it was fixed. In our experience the external testing effort is the smaller item. The larger one sits internally and lands on teams that already carry a backlog.
Remediation and retest therefore belong in the same decision as the test and not in next year's budget. A test without planned remediation is an expense, not protection. How security spending in an SME becomes visible at all, and which pots it needs, is something we took apart in our piece on the security budget in an SME.
How do you recognise a test worth having?
By the scoping conversation and by the report, not by the price. A usable quote names the methodology, the time budget, the rights granted to the tester and what is explicitly not examined. A provider who sends a quote within a day without asking what runs behind the application is mostly selling a scan under a better name.
- Methodology named. For web applications that might be the OWASP testing methodology for web applications, currently at version 4.2. A named methodology makes tests comparable, including across a change of provider.
- Findings with business impact. A finding that exposes another tenant's data is a different thing from an outdated library with no path leading to it. A report sorted by score alone pushes that distinction back to you.
- Evidence you can follow. Your developers have to be able to reproduce a finding without calling the tester.
- Retest included or offered at a fixed price. Without a retest the test ends on an assumption.
- A readout with a human being. Someone who explains the three most important findings in five minutes, to the management team as well, without jargon.
The difference between a scan and a test is manual work. A scan runs automatically and finds the known. That is useful and belongs in day-to-day operations, not in an annual invoice. A test finds logic errors, wrongly set permissions and chains that look harmless on their own. That manual work is what you are paying for, and it is the only thing that justifies the difference in price.
What this looks like in a real business
A software company with 230 employees in north-western Switzerland takes on an obligation to run an annual penetration test with its largest customer's new framework agreement. The first quote covers ten days: customer portal, internal network, mobile app, plus a phishing simulation. Scoping shows that the customer means something narrower. What interests them is the portal through which they deliver their data, and the separation from other tenants' data.
The scope is reduced to the portal, the API and the authentication flows. The test produces fourteen findings, three of them relevant, one of them serious: a manipulated parameter makes another tenant's records reachable. Remediation takes longer than the test, because two places in the permission model are affected. The retest six weeks later confirms the state. What goes to the customer is a one-page letter from the tester with scope, period, methodology and the statement after the retest.
The following year the same ground is not tested again. The new interface to the ERP, now in production, is. The scope got narrower, and the evidence towards the customer carried more weight. The internal network and the mobile app from the first quote were never tested, and nobody missed them, because no decision depended on them.
What the management team has to learn from a test
Three sentences are enough, and the third is the only one that moves anything: what was examined, what was explicitly not examined, and what changes about a decision because of the result. In our experience the second sentence regularly drops out of the reporting. That is exactly where a false sense of coverage comes from. Hear that the penetration test was passed, and you hear: we are secure.
So the non-scope deserves to be said out loud. The customer portal was examined, the restore from backup was not, and neither was payment release in the ERP. That sounds like playing things down and is the opposite: it keeps the open items in the management team's field of view instead of parking them behind a green tick. A test report is one data point in the risk picture, sitting next to the failover exercise and the supplier situation.
Who owns the report
The full report stays in the house. What goes outside is a summary or an attestation letter from the tester: scope, period, methodology, and the statement about the state after the retest. Customers need one page, not sixty, and handing a detailed list of weaknesses to third parties is a risk of its own. Where a contract explicitly demands the full report, that is a negotiating position and not a law of nature.
Internally every finding belongs in the risk register with an owner and a date, including the ones deliberately accepted. An accepted risk without a signature is only a forgotten finding. And when the same points appear again in the next report, the question worth asking is who was allowed to decide between the two tests.
Whether a test or a baseline comes first in your case depends on what you can already evidence. The order we work in on our engagements, with scope and prices, is in the package overview with fixed prices.
Common questions
Is a vulnerability scan enough instead of a penetration test?
For day-to-day operations a regular scan is often worth more than an annual test, because it makes changes visible quickly. As evidence towards a customer it rarely suffices, and it does not find logic or permission errors. The two do not replace each other, they answer different questions.
How often should an SME have a test done?
Driven by events rather than by the calendar, unless a contract demands otherwise. A relevant event is a change to an exposed system: a new interface, a new authentication flow, a larger rebuild. Where a customer demands an annual rhythm, it pays to put something different in scope each year instead of repeating the same examination.
Can we test internally instead of buying it in?
Running scans internally and checking configurations is sensible and cheap. For evidence towards the outside the independence is missing, and whoever runs a system rarely tests it against their own assumptions. In our experience internal testing mostly finds what was already suspected internally.