Penetration testing – how to order it right
Ordering a penetration test means having a security expert actively try to break into your system, unlike an automated vulnerability scan. The tester should be independent of the development vendor for the review to be honest. Findings are prioritized by severity and fixed on a reasonable timeline, with the most dangerous holes closed first.
Sooner or later, the question comes up: is our system actually secure? A penetration test is how you get an honest answer. Instead of guessing, you let a security expert try to break in, just like a real attacker would, and report what they found. But a test is only as good as how it’s ordered. This guide walks through what you’re actually buying, why the tester needs to be independent, and how to handle the findings so they make a real difference.
Vulnerability scan or a real penetration test
The first thing to sort out is what you’re actually asking for, since two fairly different things are sometimes called the same thing. The difference is big enough to affect both price and value.
A vulnerability scan is an automated tool that goes through the system and matches it against a list of known weaknesses. It’s fast, cheap, and good at catching the obvious – outdated components, known holes, misconfigurations. But it’s shallow. It can’t think, combine several small weaknesses into a serious one, or understand logical flaws in how your specific system works.
A penetration test is a person. An experienced tester actively tries to get in, tries unexpected paths, chains weaknesses together, and reasons like an attacker with a goal. It finds what a scan never sees: that one user can reach another’s data by manipulating a request, or that several individually harmless details together open a door. A common mistake is buying a scan while believing you’ve bought a pentest. The scan has its place, but it doesn’t replace a real review.
Why the tester should be independent
A crucial question is who performs the test. The tempting shortcut is to let the development vendor test their own build – after all, they know the system best. That’s exactly why it’s the wrong path.
No one is good at finding flaws in their own work. Whoever built the system reviews it with the same assumptions and blind spots that shaped the build, and has an unconscious interest in everything looking good. An independent tester comes in with nothing to defend and looks for what’s broken with no preconceptions. That independence is also what makes the result credible externally – to a customer, an investor, or an auditor, a passed test from an external party means something quite different from the vendor’s own word that everything is secure. Separating who builds from who reviews is a simple principle with a big effect.
Prioritize and fix the findings
A penetration test ends in a report, but the report isn’t the goal – the fixed flaws are. A report read once and then forgotten hasn’t made the system any safer. The key is turning the findings into action, in the right order.
Most reports grade findings by severity, and that grading sets the pace:
| Severity | Reasonable handling |
|---|---|
| Critical | Fixed immediately, ideally before the system goes live |
| High | Fixed as soon as possible on a clear, short timeline |
| Medium | Scheduled into the nearest upcoming development work |
| Low | Fixed when the opportunity arises or at the next major effort |
The point is not to be paralyzed by a long list. A handful of critical and high findings are what really matter, and they should go first. The rest can be handled methodically over time. Once the serious flaws are fixed, it’s wise to have the tester verify the holes are actually closed – an unverified fix is just a hope that the flaw is gone.
A concrete scenario
A business was set to launch a service handling personal data and payments. The development vendor assured them security was in order, but leadership wanted an independent confirmation before going live. They hired an external tester for a penetration test of the application, with good margin before the launch date.
The test found two serious flaws that an automated scan would have missed, both in the logic for how users accessed data. The findings were uncomfortable but invaluable – they could have become a real breach after launch. The developer fixed the critical holes, the tester verified the fixes, and the lower-priority findings were scheduled into ongoing work. The service launched with a documented, independent security clearance behind it – worth far more than the test cost.
Order the test so it makes a difference
A penetration test delivers the most value when you know what you’re buying, have someone independent perform it, and actually act on the findings. Buy a real test rather than just a scan where it matters, keep the tester separate from the developer, and prioritize fixes by severity. Then the test isn’t a paper exercise but a real boost to security.
At Weapp, we build with security in mind and welcome independent review of what we deliver, as a natural part of our services. Getting close to a launch and want to know the system holds up? Get in touch and we’ll think through how best to set up a test for your service.
Frequently asked questions
What's the difference between a vulnerability scan and a penetration test?
A vulnerability scan is an automated tool that looks for known weaknesses and produces a list. A penetration test is a person actively trying to get in, combining weaknesses and thinking like an attacker. The scan is broad and cheap but shallow; the test is deeper and finds what tools miss, such as logical flaws in how the system is built.
Why should the tester be independent of the development vendor?
Because no one is best at finding flaws in their own work. If the party that built the system also tests it, the code is reviewed by the same eyes that wrote it, with the same blind spots. An independent tester has nothing to defend and looks for weaknesses with no preconceptions. That independence is what makes the result credible, both to you and to customers or auditors.
When in the project should a penetration test happen?
Usually before launch, once the system is complete enough to reflect how it will run in production, but with margin to fix findings before go-live. For services handling sensitive data, the test should be repeated periodically, since both the system and the threat landscape change. A test is a snapshot – it says something about security at that moment, not for all time.
What do you do with the report from a penetration test?
You prioritize and fix. The report usually grades findings by severity, from critical to minor. The most serious holes should be closed quickly, ideally before launch, while lower-priority ones can be scheduled over time. The point of the test isn't the report itself but that the flaws actually get fixed – a report left in a drawer hasn't made the system a single degree safer.
What does a penetration test cost?
It depends on the system's scope and how deep the test needs to go – a defined web application is a smaller engagement than an entire platform with many parts. The price is usually set by the time the test requires. For a system handling sensitive data or payments, the cost is small compared to what a real breach would cost in money and trust.