Many organizations have successfully integrated penetration testing into their standard security processes. Every new application undergoes testing by a consulting firm, findings are discussed with the Security Officer, and an action plan is approved by the project lead. This should mean security is improving, right?

Unfortunately, that’s not always the case. A follow-up penetration test, conducted a couple of years later—whether as part of a routine check or after a major system upgrade—often reveals that little to nothing has changed.

This isn’t about minor misconfigurations like outdated encryption protocols or Clickjacking vulnerabilities. We’re talking about critical security flaws such as Stored XSS, SQL injections, and Insecure Direct Object References—issues that should never exist in a financial application, yet persist even after years.

So, where does the problem lie? Is it:

• The project lead, who allocates only a minimal budget for a comprehensive penetration test?
• The consulting firm, which assigns the task to an inexperienced intern to maximize profits?
• The intern, who lacks the knowledge to properly remediate SQL injections and likely overlooks a majority of vulnerabilities?
• The developer, who disregards the security recommendations due to poor documentation?
• The project lead, who fails to verify whether remediation steps were effectively implemented?
• The vendor, who offers a fix in an updated version but charges an exorbitant fee for the upgrade?
• The Security Officer, who has limited authority within the organization?

The reality is this: you can conduct as many penetration tests as you want, uncover vulnerabilities, and suggest fixes, but real security improvements depend on the organization itself. A penetration tester’s job is to highlight risks, but unless the client takes action, meaningful security enhancements remain out of reach.