Are banks required to have a penetration test?

In practice, yes. The Interagency Guidelines, the FFIEC handbook and the NCUA's rules expect banks and credit unions to test key controls independently and regularly, and examiners read that as at least an annual penetration test of internet-facing and payment systems. Non-bank institutions under the FTC Safeguards Rule and New York licensees under 23 NYCRR 500.5 have an explicit annual requirement.

How often should a bank perform a penetration test?

At least annually for systems that move money or hold customer information, and again after material change such as a core conversion, a new digital banking platform or a merger. Lower-tier systems can rotate on a two-year cycle if the risk assessment supports it.

What is the difference between a bank penetration test and a vulnerability scan?

A vulnerability scan is automated and lists known weaknesses; a penetration test is a manual, goal-driven attempt to reach customer data or payment functions by chaining weaknesses together. Examiners and the FTC Safeguards Rule treat them as separate obligations: scans every six months, a penetration test every year.

Can our core processor's penetration test count for us?

Only for the processor's environment. Your side of the interface, the administrative access, the file transfers, your digital banking configuration and your internal network remain yours to test. Examiners expect the processor's SOC report and your own test of what you control.

What should a credit union test if it runs on a shared core?

Its interfaces to the core, its administrative and service accounts, its digital banking and card platforms, its Microsoft 365 and Active Directory identity layer, its branch and remote access, and its managed service provider's access. The NCUA ISE expects evidence for each, and 748.1(c) requires 72-hour incident reporting if any of them fail.

Does one penetration test cover GLBA, NYDFS Part 500, PCI DSS and SWIFT CSP?

Yes, if the scope statement names each regime and includes the systems each one cares about: the cardholder data environment for PCI DSS, the secure zone for SWIFT, both internal and external components for Part 500. We write the report so each team can file its own section.

2 November 2026 · 11 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)

Penetration Testing for Banks and Credit Unions: What Examiners Expect, What to Test and How to Scope It

A bank penetration test is judged twice: by the attacker it simulates and by the examiner who reads the report. This guide explains what US banking and credit union supervisors expect from a testing programme, where the money moves in a modern institution, and how to scope and report a test that satisfies both readers.

Scope a bank penetration test

What makes bank penetration testing different

Bank penetration testing is an independent, examiner-facing security test of the systems that hold customer information or move customer money: online and mobile banking, payment origination, core banking interfaces, the internal network and identity platform, and the connections to processors, fintech partners and payment networks. It differs from a generic penetration test in four ways. The scope is anchored to the institution's own risk assessment rather than a list of IP addresses. The tester must be demonstrably independent of the people who run the systems. The report is read by a board committee and a federal or state examiner, not only by IT. And every finding is tracked to remediation and retested, because the examiner asks what happened to last year's findings before asking about this year's.

The population is broader than the money-centre banks. Community and regional banks, thrifts, credit unions, trust companies and the US subsidiaries of foreign banking groups all face the same expectation: independent testing of the controls over customer information, at least annually, from the internet and from the inside. Credit unions carry it under their own regulator, the National Credit Union Administration (NCUA), and the practical differences for them are covered below.

Two regulations have their own guides on this site because they contain explicit testing clauses: the Gramm-Leach-Bliley Act (GLBA) with the FFIEC examination framework, and New York's 23 NYCRR Part 500. This page does not repeat them. It gives you the whole stack in one table, then concentrates on what the regulations leave to judgement: scope, depth, cadence and the report.

The US financial regulatory stack in one table

Most institutions sit under three to five of these regimes at once. One well-scoped annual programme serves all of them if the scope statement names each regime it is meant to satisfy.

Regime	Who it reaches	What it says about testing	How a penetration test serves it
GLBA Interagency Guidelines (OCC, FDIC, Federal Reserve)	Banks, thrifts, holding companies	Regular testing of key controls by independent parties or independent staff	Annual external and internal test of the systems in the risk assessment, reported to the board
FTC Safeguards Rule, 16 CFR Part 314	Non-bank lenders, brokers, servicers, dealers that finance	Annual penetration test and six-monthly vulnerability assessments (314.4(d)(2))	A dated annual test plus six-monthly scans for the Qualified Individual's board report
FFIEC IT Examination Handbook	Every federally supervised bank and credit union	Information Security booklet expects independent penetration tests of internet-facing systems, scaled to risk	Scope, independence and remediation documented in the form examiners look for
NCUA Rules, 12 CFR Part 748, and the Information Security Examination (ISE)	Federally insured credit unions	Appendix A safeguards programme with regular testing; ISE procedures since 2023; 72-hour incident reporting since September 2023	Testing evidence mapped to the ISE statements, including vendor and shared-core interfaces
NYDFS 23 NYCRR Part 500	Banks, insurers, money transmitters and crypto licensees in New York	Annual penetration testing from inside and outside by a qualified independent party (500.5)	One engagement with both components and a scope statement citing the section
PCI DSS v4.0.1	Card issuers, acquirers, anyone storing or processing card data	Requirement 11.4: internal and external tests annually and after significant change, plus segmentation testing	Cardholder data environment in scope, segmentation tested, exploitable findings retested
Sarbanes-Oxley Section 404 (ITGC)	Public banks and holding companies	Effective IT general controls over financial reporting systems, tested by the external auditor	Access and change-management findings on reporting systems become ITGC deficiencies
Federal Reserve FedLine security and resiliency assurance	Institutions with FedLine access	Annual self-assessment and senior-management attestation against FedLine security requirements	Testing the FedLine access environment from an assumed-breach position supports the attestation

Which rules name the test, and where this site covers them in depth

GLBA itself names no test. Section 501(b) instructed the regulators to write safeguards standards, and they produced two tracks: the prescriptive FTC Safeguards Rule for non-bank institutions, which since June 2023 requires an annual penetration test and six-monthly vulnerability assessments, and the principles-based Interagency Guidelines for banks, examined against the FFIEC IT Examination Handbook. The FFIEC Cybersecurity Assessment Tool was retired on 31 August 2025 without changing the expectation of independent, risk-scaled testing. Our GLBA and FFIEC guide, linked below, covers both tracks and the NCUA equivalents in detail.

New York's Part 500 is the most explicit US rule for a bank penetration test. Since the Second Amendment, Section 500.5 requires covered entities to test their information systems from both inside and outside the boundary at least annually, using a qualified internal or external party independent of the systems tested, with results feeding the risk assessment and the CISO's annual certification. Banks chartered or licensed in New York, and out-of-state groups with a New York licensed entity, meet it alongside their federal obligations. Our NYDFS guide covers the section and the Class A duties around it.

What examiners expect from a penetration testing programme

Examiners rarely dispute that a test happened. They dispute whether it was the right test. These are the six points an IT examination probes, drawn from the FFIEC handbook, the NCUA ISE and supervisory letters.

1. Scope tied to the risk assessment

The scope statement names the systems the institution's own risk assessment rates as high-impact and explains any exclusions. A test that covers the marketing website but not online banking or the wire workflow is read as a gap.

2. Frequency scaled to risk and change

Annual is the floor for internet-facing and payment systems. A core conversion, a new digital banking vendor or a merger resets the clock. Examiners ask what was tested after the change, not whether the annual test was on schedule.

3. Independent, qualified, named testers

The tester must be organisationally independent from the teams that build and run the systems; for most community institutions that means an external firm. Certifications (OSCP, OSWE, CREST), the methodology (PTES, OWASP WSTG, NIST SP 800-115) and the testers' names belong in the report. An automated scan presented as a penetration test is a recurring examination finding.

4. Both external and internal perspectives

An external test measures the perimeter. An assumed-breach internal test from a standard workstation measures what a phished teller or a compromised vendor connection could reach. Examiners, and Part 500 explicitly, expect both.

5. Remediation tracking, retest evidence and board reporting

Every finding needs an owner, a risk-based deadline and closure evidence; a retest letter closes the loop. Results reach the board or its risk committee in a form directors can act on: what was tested, what was found, what remains open and why.

6. Coverage of vendors, processors and partners

The core processor's environment is covered by its own SOC reports, but the institution's side of each interface, the credentials, the file transfers and the fintech or banking-as-a-service connections are the institution's to test. Examiners ask about this specifically since the 2024 and 2025 enforcement actions against sponsor banks.

The digital banking attack surface

Where customer money and data are exposed in a modern institution, and what a test of each surface looks for. Described at control level; the techniques belong in the engagement, not on a web page.

Online and mobile banking

Enrolment and credential recovery, account takeover paths, MFA consistent with the FFIEC's 2021 authentication guidance, session handling, transaction authorisation, business banking entitlements and sub-user administration, and the APIs behind the mobile apps.

Open banking APIs and aggregators

Consent and token handling for aggregator access, FDX-aligned APIs where offered, rate limiting and data minimisation, and what a compromised aggregator credential could pull. The CFPB's Section 1033 rule, finalised in October 2024 and reopened for reconsideration in 2025, keeps this surface in focus whatever its final form.

ACH, wire and real-time payments

Origination workflows for ACH, wire, RTP and FedNow, dual-control and callback enforcement, the workstations and accounts that can initiate or approve payments, limits and positive pay, and the file-transfer paths to the processor and the Federal Reserve. Here a finding becomes a loss event within hours.

ATM, branch and teller networks

Segmentation between branch, ATM and back-office networks, teller workstation hardening, ATM management interfaces, network ports in public areas, and whether a branch compromise can reach the core or the payment environment.

Core processor and vendor interfaces

The institution's side of the core connection: service accounts, file transfers, batch jobs, administrative consoles and the privileged users who manage them. Shared and hosted cores move the environment but not the responsibility for the interface.

Microsoft 365, Active Directory and identity

Conditional access and MFA coverage for every account including service and break-glass accounts, privileged group membership, legacy authentication, hybrid identity sync, and the path from one phished mailbox to a payment approver's session.

Credit union specifics: shared cores, CUSOs and small teams

Credit unions carry the same testing expectation as banks under the NCUA's rules in 12 CFR Part 748, whose Appendix A requires a security programme with regular testing of key controls, and whose Section 748.1(c) has required reporting of a reportable cyber incident to the NCUA within 72 hours since 1 September 2023. The NCUA's Information Security Examination procedures, introduced in 2023 and scaled by asset size, are what the examiner works from; its voluntary Automated Cybersecurity Evaluation Toolbox is a self-assessment, not a substitute for a test. The NCUA's 2026 supervisory priorities letter again lists cybersecurity among the top risks.

Three structural features change how a credit union scopes a test. Most credit unions run on a shared or hosted core, so the test concentrates on the institution's interfaces, administrative access and data flows rather than the core itself. Credit union service organisations (CUSOs) often deliver digital banking, lending or card services for several institutions at once, which makes the CUSO connection a shared attack path that each institution must still assess from its own side. And internal teams are small and frequently supported by a managed service provider, so the test should include the provider's remote access and privileged accounts, and the report must let the provider execute remediation and the board verify it.

How to scope a bank penetration test by asset tier

Scoping by tier keeps the examiner's question ('did you test what matters?') and the budget question ('how many days?') in the same conversation. Tiers follow the institution's risk assessment; these examples are typical.

Tier 1: systems that move money

Online and mobile banking, wire and ACH origination, real-time payment connections, treasury portals, FedLine and SWIFT access environments, card management. Tested annually at minimum and after any material change, from the internet and from an assumed-breach position, with the detection record included.

Tier 2: systems that hold customer information and identity

Core interfaces, loan origination, document and imaging systems, CRM, Microsoft 365 and Active Directory, data warehouses. Annual internal assessment focused on access control, privilege and data exposure; the identity platform is tested every year because everything else depends on it.

Tier 3: corporate, branch and ATM networks

Segmentation, branch connectivity, teller and ATM networks, wireless, remote access, endpoint hardening. Tested on a rotating or biennial cycle unless the risk assessment or an incident moves a component up a tier.

Tier 4: vendors, processors and partners

The institution's side of every third-party connection, the credentials and file transfers involved, and what a compromised partner could reach. Reviewed annually alongside vendor management, with the partner's own test reports read for scope and currency rather than taken on trust.

What a bank-grade penetration test report contains

The report is what the examiner, the auditor and the board actually see. These sections let one document serve all three without rework.

A scope statement mapping each tested system to the risk assessment and to the regimes the test must satisfy (GLBA, Part 500, PCI DSS, SWIFT CSP), with exclusions explained
Methodology and standards followed (PTES, OWASP WSTG and MASTG, NIST SP 800-115), the testing window and rules of engagement
Named, certified testers and a statement of their independence from the systems tested
An executive summary for directors: what was tested, what an attacker could have done, what remains open, the priorities
Findings with CVSS v4 scores and, separately, business impact in banking terms (funds at risk, records exposed, regulatory exposure), each with reproducible evidence
An attack narrative showing how findings chain from the perimeter or a phished workstation towards payment or customer data, and a detection record of what monitoring saw and missed
A prioritised remediation plan with owners and deadlines, a retest letter once exploitable findings are closed, and an appendix of out-of-scope systems with the reason

How HackersHub tests banks and credit unions

We scope every engagement to the institution's risk assessment and asset tiers, then test in two movements: an external component against the perimeter, the digital banking platforms and their APIs, and an assumed-breach component from a standard workstation to measure what a compromised employee or vendor connection could reach in the identity platform, the core interfaces and the payment workflows. The detection record is part of the deliverable. Testers hold OSCP at minimum, with OSWE and CREST-certified testers on the team, and are named in the report. Methodology follows PTES, OWASP WSTG and MASTG and NIST SP 800-115, and each finding cites the regime it touches so compliance, audit and the board can each file it.

HackersHub is based in Amsterdam, Netherlands. US institutions are tested remotely within agreed windows and US business hours, with on-site days for branch, ATM and internal network work where the scope needs them. A verification retest of medium and higher findings within 90 days is included, which is the evidence the examiner asks for at the next cycle. With 10+ years of offensive security work and a 4.9/5 rating across 127 reviews, our reports are written to be read by supervisors as well as engineers.

Frequently asked questions

Related guides

Preparing for your next IT examination?

We scope to your risk assessment, test from the outside and the inside, and deliver a report your examiner, auditor and board can each read without translation. Talk to an expert.

Scope a bank penetration test Talk to an expert