Penetration testing is an authorised, simulated attack on a system by security specialists to find which weaknesses a real attacker could exploit and how far that access would reach. Unlike a vulnerability scan that lists possible flaws, a pen test tries to use them, chaining small issues into a working breach. A test moves through scoping, reconnaissance, exploitation, post-exploitation, reporting and a retest. PCI DSS requirement 11.4 demands internal and external tests at least every 12 months and after significant changes, while DORA requires threat-led testing at least every three years for designated EU financial entities. Buyers of a PSP or EMI request two years of reports and retest results.
What is penetration testing compared with scanning
A vulnerability scanner reports that a server runs an outdated library. A penetration tester checks whether that library can be exploited, uses it to get a foothold, then tries to move from the web server to the database holding card data. The output is a report ranking findings by real impact, with evidence such as screenshots of extracted records, and recommended fixes. Scans are cheap and frequent; pen tests are manual, scoped and periodic.
How does penetration testing work
A test runs in five stages. Scoping fixes targets, dates, rules of engagement and what is off-limits, such as production payment flows during peak hours. Reconnaissance maps domains, IP ranges, APIs and staff exposure. Exploitation attempts to break in. Post-exploitation tests lateral movement and privilege escalation. Reporting is followed by a retest to confirm fixes.
The tester's starting knowledge defines the style: black box (no information), grey box (user credentials and documentation) or white box (source code and architecture). Application tests commonly follow the OWASP testing methodology; API tests focus on broken authorization, such as reading another merchant's transactions by changing an ID in the request.
Penetration testing for payment systems
PCI DSS requirement 11.4 demands internal and external penetration tests at least once every 12 months and after any significant change to infrastructure or applications. If network segmentation is used to reduce scope, it must be tested too: annually for merchants, every six months for service providers.
In the EU, DORA requires financial entities identified by their supervisors to run threat-led penetration testing (TLPT) at least every three years, modelled on the TIBER-EU framework, with threat intelligence and red teams attacking live production systems. The UK's equivalent for systemically important firms is CBEST.
Typical payment findings include exposed admin panels, weak API key handling, webhook endpoints that accept unsigned messages, and card data left in application logs.
Risks of a poorly run test
A test against live payment infrastructure can trigger outages or fraud alerts, so rules of engagement define safe windows and emergency contacts. A narrow scope produces a clean report that proves little.
What a buyer reads in pen test reports
In due diligence on a PSP or EMI, a buyer asks for the last two years of reports and the retest results. Repeated critical findings, or reports scoped only to the marketing website, say more about the security culture than any policy document.