ISO 27001 pentest for payments: what auditors expect from PIs, EMIs, and PSPs

ISO 27001:2022 is the certification that payment institutions, e-money issuers, and PSPs put in front of banking partners, card schemes, and enterprise merchants. It does not explicitly require penetration testing. Read the standard literally and you will find no mandate. Read any payment-sector auditor's checklist and you will find that nobody certifies without one.

This page explains the gap between what the standard says and what auditors actually check, specifically for firms authorised under PSD2 as payment institutions (PIs), e-money institutions (EMIs), or operating as payment service providers and gateways. In payments, ISO 27001 rarely stands alone: it interlocks with PCI DSS 4.0 on the cardholder data environment and with DORA Article 24 on operational resilience testing. The smart move is to scope one pentest programme that feeds all three.

What ISO 27001 actually says about testing

ISO/IEC 27001:2022 Annex A is the control reference. The 2022 revision restructured controls into four themes (organisational, people, physical, technological) and reduced the count from 114 to 93. The controls that drive pentest scope for a payment firm:

• A.8.8 Management of technical vulnerabilities. "Information about technical vulnerabilities of information systems being used shall be obtained, the organisation's exposure to such vulnerabilities shall be evaluated, and appropriate measures shall be taken."
• A.8.29 Security testing in development and acceptance. "Security testing processes shall be defined and implemented in the development life cycle." For a payment platform shipping weekly, this is the control that bites.
• A.5.34 Privacy and protection of PII. Payment firms process customer PII (KYC records, transaction histories, cardholder data). Testing must demonstrate the technical and organisational measures protect it.
• A.8.25 Secure development life cycle and A.8.28 Secure coding. Auditors reviewing a payment gateway check that secure-development and secure-coding practices are verified through testing, not just policy.
• A.5.19, A.5.20, A.5.21, A.5.22 Supplier relationships. Payment firms sit on a stack of critical suppliers: card schemes, tokenization providers, cloud, HSM vendors, KYC/AML data providers. Supplier security must be addressed, and auditors check whether the integration points are tested.

None of these say "do an annual pentest." Collectively they require a documented process for finding and fixing vulnerabilities, with evidence. In practice, for a regulated payment firm, that means an annual depth-test at minimum plus continuous vulnerability management between engagements. Payment-sector auditors read a single yearly PDF as a starting point, not a complete answer.

What auditors actually look for

Three payment-sector examples that mirror what recent ISO 27001:2022 certification audits surface:

A payment institution, ~120 people, first-time certification. The auditor spent most of a day on A.8.8 evidence against the acquiring core and the merchant portal. The questions: which vulnerabilities did you find in the last 12 months, how did you rate them (CVSS), who decided remediation priority, what is your retest evidence, where are the risk-acceptance records for anything left open on the CDE. The firm had one annual pentest report but no continuous scanning and no formal retest closure. They passed with a minor non-conformity requiring a corrective action plan: stand up continuous vulnerability management within 90 days. On a cardholder data environment, a single annual snapshot was judged insufficient for A.8.8.

An e-money issuer, prepaid card programme, second surveillance audit. The auditor focused on A.8.29 and the SDLC behind the issuing platform. The questions: which security tests run on every commit, which tests gate deployment to the issuing core, what is the average time-to-remediation for high-severity findings on the customer-facing app, how do developers see findings. The firm had static analysis plus a quarterly external test. The auditor pressed on whether security tests blocked merges or merely warned. Warning-only tests were flagged as insufficient: deployment-gating tests were required for full A.8.29 conformance on the payment path.

A PSP operating a gateway plus a hosted checkout, pre-cert preparation. Their challenge was scope. The auditor's first question: is the tokenization service and the detokenization API in your Statement of Applicability? If yes, the pentest must cover the token vault, the surrogate mapping, and the segmentation that narrows PCI scope. If no, the SoA must explicitly exclude it with documented rationale, and no serious banking partner would accept that exclusion. They scoped it in. The pentest engagement grew to include the CDE segmentation testing, which doubled as PCI DSS 4.0 Requirement 11.4 evidence.

The pattern: auditors care about the evidence chain, not the test itself. A perfect pentest report on an out-of-scope environment is useless. A focused pentest on the in-scope payment environment, with documented remediation and retest, passes.

Where continuous AI pentest fits payments specifically

ISO 27001 for a payment firm rewards continuous validation for three concrete reasons:

1. PSD2 SCA flows change and must be re-tested. Strong customer authentication, step-up logic, fallback paths, and exemption handling get tuned constantly as fraud patterns shift. A pentest that fires once a year tests an SCA implementation that has already moved. Continuous validation on the authentication surface keeps A.8.8 and A.8.29 evidence current and simultaneously feeds the PSD2 SCA RTS compliance file.
2. Payment surfaces are API-heavy and ship weekly. Merchant onboarding APIs, payment initiation, webhook delivery, partner integrations, admin and reconciliation portals. These are the surfaces where A.8.29 (testing in the SDLC) is hardest to satisfy with an annual engagement. Continuous AI pentest tied to CI/CD tests each release candidate, which is what auditors now expect on a fast-moving payment platform.
3. Overlap with PCI DSS 4.0 Requirement 11.4 and DORA Article 24. One continuous programme on the customer-facing platform and the payment APIs produces evidence that maps three ways: A.8.8 and A.8.29 for the ISO auditor, Requirement 11.4 for the PCI assessor where the surface touches the CDE, and Article 24 resilience-testing evidence for the competent authority (in France, the ACPR). The underlying tests are the same; the packaging differs by auditor.

The version that works:

• Continuous validation on production-equivalent staging, against every release candidate, on the customer-facing platform, the merchant portal, and the payment APIs
• Annual depth-pentest on production, human-led, covering business logic, authorization edges, and the CDE segmentation controls
• Specialist human-led testing on the token vault, HSM, and key-management surfaces, on a quarterly-or-tighter cadence with narrow rules of engagement
• Evidence generated automatically into the ISMS evidence repository, mapped to the ISO control and the PCI requirement at export time

The version that does not work: a vendor that hands you scanner output with no human triage, no retest, and no remediation tracking. Auditors recognize scanner output as "vulnerability identification" but not as the full Annex A.8.8 process, and on a payment platform they say so.

Procurement checklist for payments CISOs scoping ISO 27001 pentest

• Does the vendor produce evidence that auditors accept for A.8.8 (process), A.8.29 (SDLC integration), and A.5.34 (PII protection) on a payment environment specifically?
• Does the same engagement also produce PCI DSS 4.0 Requirement 11.4 evidence on the CDE, so you do not commission two separate tests?
• Does the vendor map findings to the PSD2 SCA RTS overlay where the test surface touches authentication?
• Does the vendor understand PCI scope-narrowing and avoid expanding scope by testing outside the segmented CDE without explicit instruction?
• Is HSM, token-vault, and key-management testing explicitly in or out of the statement of work, with a clear handoff to the specialist firm that owns it?
• Does the vendor integrate with your CI/CD (GitHub Actions, GitLab CI, CircleCI) to satisfy A.8.29 directly, or only produce post-release reports?
• Where is your testing data stored, and under which jurisdiction? For EU payment firms, a US-hosted pentest vendor is a documented finding under A.5.19-A.5.22 and DORA third-party rules.

Where Fleuret fits

Fleuret runs continuous AI pentest on payment environments: the customer-facing platform, the merchant portal, the payment and partner APIs, the internal admin and reconciliation portals, the dispute and chargeback tooling. We produce ISO 27001:2022 Annex A-mapped evidence automatically (A.8.8, A.8.29, A.5.34), and where the surface touches authentication we feed the PSD2 SCA RTS overlay. Our findings stream into the ISMS evidence repository without manual export, and export side by side with PCI DSS 4.0 Requirement 11.4 and DORA Article 24 mapping. EU data residency by default (Scaleway, France), so no CLOUD Act exposure on pentest findings.

Fleuret is not a certification body and does not issue ISO 27001 certificates. Where the scope includes the token vault, HSM, or key-management surfaces, we redirect you to a specialist firm with that specific track record and provide the continuous validation layer around it. For a payment firm in the €1M-€100M revenue band, our typical engagement covers continuous validation against production-equivalent staging with every release candidate, plus a depth-pentest engagement once per certification cycle scoped to double as PCI DSS Requirement 11.4 evidence.

If you are scoping pentest for ISO 27001:2022 as a payment institution, e-money issuer, or PSP, book a demo.

Related compliance reading

• DORA pentest for payments: the operational-resilience view of the same environment, where TLPT designation and Article 24-27 scope drive the programme for PIs, EMIs, and acquirers.
• ISO 27001 pentest for fintech: the same control set scoped for the broader fintech segment, with the dual-certification path alongside DORA.