Regulators have responded by embedding penetration testing requirements directly into compliance law. This isn't optional security hygiene anymore — it's a legal obligation with teeth.
This article is written for compliance officers, CISOs, and IT leaders at banks, credit unions, and fintech companies who need to understand not just that penetration testing is required, but exactly what the regulations say, who they apply to, and what a compliant program must look like. We cover four regulatory frameworks: GLBA, FFIEC/FDIC, SOX, and PCI DSS.
TL;DR
- The GLBA Safeguards Rule explicitly mandates annual penetration testing and semi-annual vulnerability assessments for covered financial institutions
- FFIEC/FDIC guidelines require independent, real-world simulated attack testing — with frequency tied to the institution's own risk assessment
- SOX Section 404 requires robust internal controls over financial reporting, with security testing evidence needed to validate IT general controls assessments
- Cardholder data environments fall under PCI DSS Requirement 11.4, which mandates penetration testing at least annually and after significant infrastructure changes
- Automated vulnerability scans do not satisfy regulatory intent: examiners expect active exploitation testing that mirrors real attacker behavior
The Banking Regulations That Mandate Penetration Testing
US financial institutions operate under multiple overlapping federal regulations, each carrying its own testing mandate or examiner expectation. Unlike most industries, where security frameworks are voluntary or contractual, financial services organizations face legally enforceable requirements. The sections below cover what each regulation actually requires — and where pen testing fits in.
GLBA and the Safeguards Rule
The Gramm-Leach-Bliley Act, updated via the FTC's Safeguards Rule in 2021, contains one of the most explicit mandates in US financial regulation.
Under 16 CFR § 314.4(d)(2), covered institutions must — absent effective continuous monitoring systems — conduct:
- Annual penetration testing of information systems, determined each year based on relevant risks identified in the institution's risk assessment
- Vulnerability assessments no less than every six months, including system-wide scans to minimize risks to customer information
- Additional testing whenever there are material changes to operations, business arrangements, or circumstances that may have a material impact on the information security program
Compliance became effective June 9, 2023. The FTC defines penetration testing as "a test methodology in which assessors attempt to circumvent or defeat the security features of an information system."
One critical point about scope: the Safeguards Rule applies far beyond traditional banks. Covered entities include mortgage brokers, payday lenders, motor vehicle dealers offering financing, financial advisors, and check-cashing businesses — any entity engaged in activities the Federal Reserve Board determines to be financial in nature.
FDIC and FFIEC Guidelines
The FDIC, operating through the FFIEC, establishes IT security standards for federally regulated banks through 12 CFR Appendix B to Part 364, Section III.C.3, which requires institutions to:
"Regularly test the key controls, systems and procedures of the information security program. The frequency and nature of such tests should be determined by the institution's risk assessment. Tests should be conducted or reviewed by independent third parties or staff independent of those that develop or maintain the security programs."
The FFIEC IT Examination Handbook (Section IV.A.2(b)) goes further, defining penetration testing as something that "subjects a system to real-world attacks selected and conducted by the testers" to "identify weaknesses in business processes and technical controls and demonstrate a potential for loss."
This is explicitly distinguished from vulnerability scanning, which the Handbook describes as identifying "known vulnerabilities (e.g., Mitre's CVE) or known vulnerability classes." The FFIEC sets no minimum testing frequency; instead, frequency is driven by the institution's risk assessment, meaning higher-risk organizations are expected to test more often than annually.
SOX and PCI DSS
SOX Section 404 (15 U.S.C. § 7262) requires management to assess and report on the effectiveness of internal controls over financial reporting each fiscal year, with external auditors required to attest to those assessments under PCAOB AS 2201. SOX does not explicitly name penetration testing, but AS 2201 requires auditors to evaluate IT general controls covering access security and program change controls, and penetration testing evidence directly supports those evaluations.
Where SOX is indirect, PCI DSS v4.0 is explicit. Fully enforced since March 31, 2025, it moved penetration testing to Requirement 11.4 with more prescriptive expectations:
| Requirement | Scope | Frequency |
|---|---|---|
| 11.4.1 | Documented methodology using industry-accepted approaches | Ongoing |
| 11.4.2 | Internal penetration testing of the CDE and critical systems | At least every 12 months; after significant changes |
| 11.4.3 | External penetration testing | At least every 12 months; after significant changes |
| 11.4.5 | Segmentation testing confirming CDE isolation | Every 12 months (merchants); every 6 months (service providers) |
PCI DSS applies to any entity storing, processing, or transmitting cardholder data — banks, payment processors, and fintechs alike.
Who Must Comply: Financial Institutions Under These Regulations
"Financial institution" under these frameworks is broader than most compliance teams initially assume.
| Regulation | Who It Covers |
|---|---|
| GLBA Safeguards Rule | Non-bank financial institutions: mortgage brokers, auto dealers, payday lenders, financial advisors, fintechs engaged in financial activities |
| FFIEC/FDIC | Federally regulated banks and credit unions |
| PCI DSS | Any entity storing, processing, or transmitting cardholder data |
| SOX | Publicly traded companies and their financial reporting systems |
| NY DFS 23 NYCRR 500 | Any entity licensed under New York's Banking, Insurance, or Financial Services Laws |
The Fintech Question
Cloud-native SaaS fintechs are not exempt. If your company processes payments, extends credit, or handles financial data, you fall under GLBA's Safeguards Rule and/or PCI DSS. Being a startup or a technology company rather than a chartered bank provides no regulatory carve-out.
State-level rules extend this obligation further. NY DFS 23 NYCRR Part 500 applies the same annual penetration testing requirement (Section 500.05) to any fintech operating under a New York money transmitter license or similar DFS authorization — the same standard as a traditional bank.
Consequences of Non-Compliance
The FTC's 2022 action against Drizly illustrates what's at stake: a breach exposing 2.5 million consumers resulted in the CEO being personally bound to security requirements that follow him to future employers. GLBA violations can reach $100,000 per violation in fines.
Beyond financial penalties, institutions found lacking adequate testing programs during exams face regulatory findings, enforcement actions, and reputational damage that outlasts any fine.
What These Regulations Actually Require: Frequency, Scope, and Independence
Frequency Comparison
| Regulation | Pen Testing Frequency | Vulnerability Assessment Frequency | Triggered by Changes? |
|---|---|---|---|
| GLBA (16 CFR 314.4(d)(2)) | Annual | At least every 6 months | Yes — material operational changes |
| FDIC/FFIEC | Risk-assessment driven | Risk-assessment driven | Yes — per risk assessment |
| PCI DSS v4.0 (Req. 11.4) | At least every 12 months | Quarterly ASV scans (Req. 11.3) | Yes — significant infrastructure changes |
| NY DFS (23 NYCRR 500.05) | Annual | Bi-annual | Yes — absent continuous monitoring |
GLBA is the only framework that sets a fixed minimum frequency. FFIEC and FDIC defer entirely to the institution's risk assessment — which creates an expectation, not a floor.
The Independence Requirement
Both FDIC's 12 CFR Appendix B and the FFIEC IT Handbook specify that testing must be "conducted or reviewed by independent third parties or staff independent of those that develop or maintain the security programs."
This matters for practical reasons. Internal teams carry unconscious bias toward their own configurations and architectures. An engineer who built the authentication system is unlikely to approach it with genuine adversarial intent. Independent testers — with no stake in the findings — bring the skepticism regulators are actually looking for. That distinction drives how regulators evaluate testing quality — and why many institutions turn to external firms for this work.
Scope Requirements
Regulators expect testing to cover:
- External network perimeter and publicly facing systems
- Internal networks, including lateral movement paths
- Web applications and customer-facing portals
- Authentication systems and access controls
- Privileged access pathways to sensitive data environments
For PCI DSS, the cardholder data environment (CDE) and its network segmentation must be specifically tested. Segmentation controls that are assumed to isolate the CDE must be actively verified — not just documented.
Penetration Testing vs. Vulnerability Assessments
The GLBA Safeguards Rule treats these as distinct, complementary activities:
- Vulnerability assessments (required semi-annually): Systematic scanning for known weaknesses using automated tools
- Penetration testing (required annually): Active exploitation of vulnerabilities to demonstrate real-world risk
Regulators treat these as separate obligations. Submitting a vulnerability scan as penetration test evidence is a compliance failure — one that examiners are trained to catch.
Documented findings from penetration tests must include risk ratings and specific remediation steps. Institutions are also expected to conduct retesting to confirm vulnerabilities have been addressed. This requirement ties directly into the FFIEC's mandate for continuous improvement of the information security program.
Why Automated Vulnerability Scans Don't Satisfy Regulatory Requirements
The FFIEC IT Handbook is unambiguous: penetration testing involves "real-world attacks selected and conducted by the testers." This is fundamentally different from running a scanner.
What Automated Tools Cannot Do
Automated vulnerability scanners identify known signatures against CVE databases. They cannot:
- Chain vulnerabilities together — combining a low-severity misconfiguration with a privilege escalation path to achieve full system compromise
- Test business logic flaws — such as transaction manipulation, improper fund transfer validation, or authentication bypass in multi-step workflows
- Simulate lateral movement — understanding how an attacker would pivot through a network after initial access
- Assess human-layer risks — social engineering vectors that automated tools have no mechanism to evaluate
These are precisely the attack types regulators care about most. A scanner finding a missing patch is useful. Knowing how a real attacker would chain that patch into credential theft, then pivot laterally to core banking systems, is what regulators are actually asking for — and what only manual penetration testing can answer.
That distinction matters when examiners sit down with your documentation.
What Examiners Actually Evaluate
When regulators review your penetration testing documentation, they are not checking whether a scan report exists. They evaluate:
- Whether the test methodology was rigorous and documented
- Whether attack paths were actively exploited (not just identified)
- Whether the tester operated with genuine independence from the systems tested
- Whether findings were risk-rated and remediated with evidence
Institutions that submit automated scan exports in place of true penetration test reports face examination findings. The PCI DSS community has made this explicit: "The days of running an automated vulnerability scanner, exporting its output with a cover page, and calling it a penetration test are over."
Building a Regulation-Aligned Penetration Testing Program
A compliant bank penetration testing program requires more than scheduling an annual test. Here are the six components examiners expect to see:
- Formal scope definition tied to the institution's current risk assessment — updated annually, not carried over from prior cycles
- Independent tester selection with documented qualifications and no connection to the systems under test
- Test types aligned to regulatory requirements: external network, internal network, web application, and social engineering for institutions with significant human-layer exposure
- Documented findings with risk ratings, prioritized by business impact — not a flat vulnerability list
- Remediation tracking and retesting, with documented evidence that findings were closed, not just acknowledged
- Executive reporting formatted for board review and examiner scrutiny
Setting Frequency Based on Risk
The FFIEC's language is specific: "The frequency and scope of a penetration test should be a function of the level of assurance needed by the institution." Annual testing is a floor, not a target.
Institutions should test more frequently when any of the following apply:
- Attack surface has grown through new systems, integrations, or acquisitions
- A security incident or near-miss has occurred since the last test
- Major infrastructure changes have been deployed
- Sensitive data holdings have expanded significantly
Attackers don't wait for annual review cycles. Testing frequency should reflect that reality.
Choosing the Right Testing Partner
Examiners will scrutinize tester qualifications and methodology. A partner whose approach is built around threat-led manual testing — rather than compliance checkbox completion — produces findings that satisfy both regulators and actually reduce risk.
Vynox Security works with financial institutions navigating overlapping regulatory frameworks — delivering reports structured for both examiner review and internal technical teams, with proof-of-concept evidence, risk-rated findings, and retesting validation built in. For institutions managing FFIEC, PCI DSS, or state-level requirements simultaneously, having a single partner who understands the compliance landscape alongside the threat landscape removes significant operational friction.
Frequently Asked Questions
What is the purpose of penetration testing in banks?
Penetration testing proactively identifies vulnerabilities in systems, networks, and applications before attackers can exploit them. For banks, it also satisfies regulatory requirements under GLBA, FFIEC/FDIC guidelines, PCI DSS, and SOX — making it both a security necessity and a compliance obligation.
What cybersecurity standards should fintech companies follow?
US fintechs typically must comply with GLBA's Safeguards Rule, PCI DSS (if handling cardholder data), and NY DFS 23 NYCRR Part 500 (if licensed in New York). SOC 2 may also apply based on customer contracts, and FFIEC guidance applies when operating alongside a federally regulated institution.
How much does a bank penetration test cost?
Costs vary significantly based on scope, system complexity, and tester qualifications. Industry estimates range from roughly $5,000 for smaller engagements to $100,000+ for large enterprise assessments. Either figure is a fraction of what a regulatory enforcement action or data breach typically costs, both of which routinely reach into the millions.
What are the stages of penetration testing?
A standard engagement covers five phases: reconnaissance, vulnerability scanning, active exploitation, post-exploitation analysis, and remediation reporting. For financial institutions, thorough documentation at each phase is required to satisfy regulatory evidence standards.
What does penetration testing mean?
Penetration testing is a simulated cyberattack conducted by authorized security professionals who use real-world techniques to identify and exploit vulnerabilities in an organization's systems. The goal is to uncover those weaknesses before attackers do. Findings are delivered in a documented report covering both technical remediation steps and compliance review requirements.
