Are You Wasting Money on VAPTs?

A finance director once forwarded us a VAPT report his bank had paid good money for the year before. Ninety-odd pages, a glossy cover, his logo top-right, a severity chart in three colours. It took us about twenty minutes to see that every finding in it had come straight out of an automated scanner, with nothing opened, exploited, or even confirmed by a person. The "critical" sitting at the top of the list was a false positive a senior penetration tester would have dismissed in ten seconds. He had renewed that contract three years running, which means he had bought the same scan three times and called it a penetration test each time.

This is the most common way Nigerian organizations waste money on security testing, and almost nobody who buys it realizes it is happening. The invoice says VAPT. What arrives is a vulnerability scan with a beautiful cover page. It looks like assurance, and it gives you a document you can hand to an auditor, but it tells you almost nothing about whether an attacker can actually get into your systems.

The Scan With a Cover Page

A vulnerability scanner is a useful tool. It runs through a list of known issues, checks software versions against a database, and reports anything that matches a signature. It is fast, it is cheap to run, and a competent tester uses one as a first pass. The problem begins when the scan is the whole engagement.

You can usually spot it in the report itself. The findings read like database entries because that is what they are. Severities are whatever the tool assigned. There is no narrative of how the tester moved through the network, because the tester never moved through anything. And the false positives are probably the biggest red flag.

A scanner cannot tell you that two medium-severity issues, chained together, hand an attacker your customer database. It cannot reason about your business logic. It does not know that your "internal only" admin panel is reachable from the guest network.

Where the Money Actually Goes

When a VAPT produces nothing useful, it usually fails in one of four ways.

• An automated scan sold as a manual test. The engagement is a scanner run plus light formatting. You pay senior-tester rates for software output. This is the single biggest source of wasted spend we see, and it is invisible unless you read the methodology and the findings closely.
• Scope sandbagging. The proposal may list your full environment, but the test only covers a fraction of it.
• No proof of concept. Findings are asserted, never demonstrated. "SQL injection possible on the search parameter" with no payload and no extracted record to back it up. You cannot tell a real, dangerous flaw from a tool's guess.
• No retest after you fix things. You receive the report, you spend weeks remediating, and the engagement is closed. Nobody ever confirms the fixes worked. Some "fixes" make the problem worse.

Any one of these empties part of the budget. Together they produce the worst outcome in security: a false sense of security.

What a Real Test Produces

The point of a penetration test is to answer a question a scan cannot: given the way your systems actually fit together, what can someone do? Answering that takes a human working the way an attacker works, and it produces things a scan never will.

• Proof of concept. A real report shows the record pulled from your database, the session that was hijacked, the file read off the server. When a tester has actually exploited a finding, the conversation about whether to fix it ends quickly.
• Reproducible steps. Every finding comes with the exact request, payload, or sequence that triggered it, so your engineers can reproduce the issue, fix it, and verify the fix themselves. Findings nobody can reproduce are usually findings nobody will act on.
• Business-logic and chained findings. The flaws that hurt most rarely appear in a signature database. A pricing flow that lets a user set their own discount, a password reset that leaks across accounts, two minor issues that combine into full compromise.
• A retest. After you remediate, the tester returns, attempts the same attacks again, and confirms in writing what is closed and what is still open.

This is also where it matters who does the work. Methodology mapped to NIST SP 800-115, PTES, and the OWASP Testing Guide only delivers value when senior penetration testers are the ones running it, exercising judgement the framework cannot encode. A junior following a checklist will miss the chain that a senior tester spots early on.

Why This Bites Harder in 2026

The cost of an untested gap stopped being theoretical for Nigerian firms this year. The Sterling Bank data breach and the FCMB heist of about N677 million, attributed in reporting to the actor known as ByteToBreach, were not exotic nation-state operations. They were the kind of access a real test is built to find first.

For listed firms the gap also carries a compliance edge. The NGX requires Trading Licence Holders that run online trading portals to complete VAPT at least twice per year. If both of those engagements are scans with cover pages, you have met the letter of the obligation and gained almost none of its protection. You are paying twice a year to look tested.

How to Get Value From the Next One

You do not need to become a tester to do testing well. You need to ask a handful of questions before you sign, and to treat vague answers as the warning that they are.

• Ask for the methodology. A serious vendor will tell you which parts of the OWASP Testing Guide, PTES, or NIST SP 800-115 the engagement follows, and where manual testing begins after the automated pass. "We use industry-leading tools" is not a methodology.
• Ask to see a sample finding from a past report. Redacted is fine. Look for a proven exploit with reproducible steps, not a scanner description. If every sample reads like a database entry, that is what you will receive.
• Define scope in writing. List the hosts, applications, and user roles to be tested, and confirm that authenticated testing is included.
• Insist the retest is in the contract. Make confirmation of your fixes a deliverable, not a favour you ask for later. If the engagement covers only one pass and no retest, you are buying half an engagement.