In most of the engagements we run, the gap between those two bars is where the real risk lives. Here are three patterns we still see constantly, in applications that passed their compliance scan without issue.
1. Client-side validation masquerading as server-side control
Automated scanners are good at finding missing headers and outdated libraries. They're much worse at noticing that a price, a quantity, or a discount code is only validated in JavaScript running in the browser. We regularly intercept a checkout request, edit the price field directly, and watch the order go through unchanged.
2. Broken object-level authorisation on “compliant” APIs
PCI DSS cares about how card data is transmitted and stored — it doesn't automatically catch an API endpoint that returns another customer's order history because the object ID is guessable and nobody checks ownership server-side. This is consistently the single most common finding across our web and API engagements, compliant or not.
3. Third-party payment widget misconfiguration
Outsourcing card capture to a hosted payment widget is good practice, and it's often what makes PCI scope smaller in the first place. But we still find widgets embedded with permissive CSP rules, or checkout pages that load third-party scripts capable of altering the DOM around the payment iframe — reopening exactly the skimming risk the widget was meant to close.
“Compliant” tells you a control exists on paper. A penetration test tells you whether it holds up against someone actually trying.
None of these findings are exotic. They're the kind of thing a compliance scan structurally can't catch, because a scanner doesn't understand your business logic — it can only check for known signatures and missing configuration. That's the gap manual testing is built to close.