ISO 27001 pentest for banking: what auditors expect from credit institutions in 2026

ISO 27001:2022 is the security certificate a bank shows the outside world. It does not, on its own, govern ICT operational resilience: DORA does that, and has been enforceable since 17 January 2025. Read ISO 27001 literally and you will find no penetration-testing mandate. Read the certification auditor's checklist and you will find that no credit institution passes without one.

For a credit institution, the situation is a two-layer one. DORA is lex specialis for financial ICT resilience, the binding regulation your competent authority supervises. Internal prudential requirements (the SSM supervisory model for significant institutions, the national prudential authority for less significant ones) sit alongside it. ISO 27001 is voluntary on top: banks hold it as a commercial and supplier-assurance certificate, a way to tell corporate clients, banking counterparties, and procurement teams that the ISMS is independently certified, even though DORA is the framework that actually governs their ICT resilience.

This page explains the gap between what ISO 27001 says about testing and what auditors check, written for the CISO of a credit institution who already runs a DORA testing programme and wants the ISO certificate to sit cleanly on top of it.

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 bank:

• 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." This is the control every auditor reads as requiring a vulnerability-identification-and-remediation process, evidenced.
• A.8.29 Security testing in development and acceptance. "Security testing processes shall be defined and implemented in the development life cycle." For a bank shipping channel and portal changes weekly, this is the control that rewards continuous testing tied to the SDLC.
• A.5.34 Privacy and protection of PII. Banks process account data, KYC records, and transaction histories. Testing must demonstrate that the technical measures protecting personal data hold.
• A.8.25 / A.8.28 Secure development lifecycle and secure coding. Custom extensions to core, payments, and channel systems fall here. Auditors expect evidence that security testing applies to bank-built code, not only bought platforms.
• A.5.19 to A.5.22 Supplier relationships. Core banking vendors, payment processors, KYC providers, and cloud suppliers all fall inside these controls. Auditors check whether suppliers are themselves tested and whether your integration surfaces with them are in your pentest scope.

None of these says "run an annual pentest." Collectively they require a documented process that finds and fixes vulnerabilities, with evidence, across the in-scope estate. In practice, for a bank, that means an annual depth-test at minimum plus continuous validation on the surfaces that change between engagements. DORA Article 25 sets the harder floor underneath: annual testing for systems supporting critical or important functions.

What auditors actually look for

Three banking examples of how ISO 27001:2022 certification and surveillance audits play out:

A mid-size retail bank, second surveillance audit, ISMS scoped to digital channels. The auditor spent most of a day on A.8.8 evidence for the e-banking and mobile estate. The questions: which vulnerabilities did you find in the last 12 months, how did you rate them, who owned remediation priority, where is the retest evidence, and where are the risk-acceptance records for anything left open past its target date. The bank had a strong annual pentest on the channels but nothing between engagements and no formal retest closure. The outcome was a minor non-conformity with a corrective action plan: stand up continuous vulnerability management on the channel layer within 90 days. The annual snapshot alone did not satisfy A.8.8 for a weekly-shipping channel estate.

A neobank operating as a BaaS provider, first-time certification. The scoping conversation was the whole audit. As a banking-as-a-service platform, its customers are other regulated entities that inherit its controls, so the auditor pressed hard on where the Statement of Applicability drew the line around the open-banking APIs and the partner-facing admin console. The auditor's position: if the partner console and the API layer support your customers' critical functions, they must be in scope and tested, and the A.5.19-A.5.22 supplier evidence flows both ways (your suppliers to you, you to your banking partners). The neobank included the full API and partner-console perimeter. Its pentest scope grew accordingly, and the certificate became genuinely usable in partner due diligence rather than a narrow paper exercise.

A bank's third-party ICT supplier (a payments-orchestration vendor), certifying to win banking clients. Here ISO 27001 was the commercial gate: the vendor's bank prospects would not sign without it. The auditor focused on A.8.29 and A.8.25/A.8.28: which security tests run on every commit, which gate deployment, and whether findings on custom payment-routing code were tracked to closure. The vendor had scanner output but no deployment-gating tests and no depth pentest on the orchestration logic itself. The outcome was a corrective action before the certificate issued: add a gating security test in the pipeline and a human-led pentest on the money-movement code path. For a supplier selling to banks, the certificate is the product, so the finding was existential rather than cosmetic.

The pattern across all three: auditors care about the evidence chain, not the test in isolation. A polished pentest report on an out-of-scope environment is worthless. A modest, well-documented test on the in-scope perimeter, with remediation and retest, passes.

Where continuous AI pentest fits banking specifically

ISO 27001 for a credit institution rewards continuous validation for three concrete reasons:

1. Overlap with DORA Article 24 threat-led and baseline testing. The bank already runs a DORA testing programme (vulnerability assessments, network security assessments including penetration tests, source-code reviews, scenario-based tests). Continuous AI pentest on the channel and application layer produces evidence that maps to both DORA Article 24 categories and ISO Annex A.8.8 / A.8.29 in one cycle. The bank is not paying twice for the same coverage, it is repackaging one evidence stream into two audit formats.
2. A large, heterogeneous estate. Banks run legacy cores, modern channels, open-banking APIs, internal portals (loan origination, KYC, treasury tooling), and acquired-entity systems side by side. A single annual snapshot cannot keep pace with the parts that change weekly, and the parts that never change still need coverage. Continuous validation on the fast-moving surfaces, with human depth-tests reserved for the specialist cores, matches the estate's actual risk shape.
3. The supplier and third-party ICT chain. A bank's A.5.19-A.5.22 exposure runs through core vendors, payment processors, KYC providers, and cloud. Continuous testing of the integration points (API contracts, IAM boundaries, data-flow surfaces between the bank and its suppliers) generates the evidence that the third-party chain is not the back door, which is exactly what both ISO supplier controls and DORA Article 28-30 ask for.

The version that works: continuous validation on production-equivalent staging against every release candidate, an annual human-led depth pentest on production covering business logic and authorisation edges, supplier-integration testing on a quarterly cadence, and evidence generated automatically into the ISMS repository. The version that does not: a vendor handing over raw scanner output with no human triage, no retest, and no remediation tracking. Auditors read scanner output as vulnerability identification, not as the full A.8.8 process.

Procurement checklist for banking CISOs scoping ISO 27001 pentest

• Does the vendor produce evidence auditors specifically accept for A.8.8 (vulnerability process), A.8.29 (SDLC testing), A.8.25/A.8.28 (secure development of custom bank code), and A.5.19-A.5.22 (supplier integration)?
• Does the same evidence pack also map to DORA Article 24-25, so one testing cycle feeds both the ISO auditor and the competent authority without a duplicate engagement?
• Does the vendor scope flexibly to your Statement of Applicability boundary (a business line, the channels, a legal entity), or impose a fixed template that does not match a bank's estate?
• Does the vendor integrate natively with your CI/CD (GitHub Actions, GitLab CI, and equivalents) to satisfy A.8.29 directly, or only deliver post-release PDFs?
• Does the vendor produce a continuous evidence stream for the fast-moving channel and API surfaces, not just a single report per year?
• Does the vendor support a documented retest workflow with closure evidence, included in the contract rather than billed as a yearly extra?
• Where is the pentest finding data stored, and under which jurisdiction? For an EU credit institution, a US-hosted testing vendor is a documented finding under A.5.19-A.5.22 and a real procurement blocker under national IT-residency expectations.

Where Fleuret fits

Fleuret runs continuous AI pentest on banking environments: e-banking, mobile, open-banking APIs under PSD2 and the incoming PSD3 regime, internal portals (loan origination, KYC, treasury tooling), and the supplier-facing integration surfaces that fall inside your A.5.19-A.5.22 supplier scope. We produce ISO 27001:2022 Annex A-mapped evidence automatically, with the same findings also mapped to DORA Article 24-25, so one cycle feeds both the ISO certification file and your supervisory dialogue.

Fleuret does not test core banking platforms. Temenos, Avaloq, Mambu, mainframe cores: those are human-led specialist engagements, and we say so directly. We complement the specialist firms by keeping the channels and application layer validated between their deep engagements.

Fleuret data residency is EU by default (Scaleway, France). No US LLM sits in the data path, so there is no CLOUD Act exposure on your pentest findings, which is what national supervisors and your own A.5.19-A.5.22 review will ask about.

If you are scoping pentest for ISO 27001:2022 as a credit institution, book a demo.

Related compliance reading

• DORA pentest for banking: the Article 24-27 view of the same estate, written for the competent-authority audience and the TLPT designation question.
• ISO 27001 pentest for fintech: the same Annex A control set scoped for payment institutions and neobanks running ISO 27001 in parallel with DORA.