TLDR
Vulnerability scanning finds known problems. Penetration testing finds what an attacker would actually do with your environment. For banks, the gap between those two things is where real risk lives.
Opening
In 2019, Capital One disclosed one of the largest financial sector data breaches in U.S. history. Approximately 106 million customer records were compromised. The attacker, a former AWS engineer, exploited a misconfigured web application firewall to execute server-side request forgery, querying the AWS metadata service to obtain temporary credentials and access S3 buckets containing customer data.
There was no missing patch. No unresolved CVE. The attack moved through normal application behavior, exploiting how systems were configured and how they trusted each other, not a known vulnerability signature that a scanner would recognize.
This is a useful entry point for a conversation the banking industry still hasn’t fully resolved: what vulnerability scanning actually tells you about your security posture, what penetration testing tells you, and why conflating the two leaves institutions exposed in ways their reporting doesn’t reflect.
The technical differences between these two practices aren’t academic. For a bank, they determine whether your security program surfaces real risk or produces documentation.
What Vulnerability Scanning Actually Does
A vulnerability scanner works by comparing what it finds on your network against a database of known issues. It identifies software versions, checks configurations against known-bad signatures, flags unpatched systems, and produces a list of findings ranked by severity.
Done consistently, this is genuinely useful work. Scanners are good at finding the things they’re designed to find: outdated software, missing patches, exposed services, and common misconfigurations that match documented patterns.
The better enterprise scanners have gotten more sophisticated over time. Authenticated scanning gives deeper visibility into system internals. Continuous scanning cycles catch drift between point-in-time assessments. Integration with asset management means fewer blind spots from shadow IT or unregistered devices. A well-run vulnerability management program built on consistent scanning is a meaningful component of a mature security posture.
The constraint isn’t a flaw in the technology. It’s a boundary condition.
Scanners identify known vulnerabilities in isolation. They check whether a door has a known weak lock. They do not ask whether that door, even with a strong lock, opens into a room that connects to your core banking system through a trusted service account. They do not simulate what an attacker would do after getting through that door, or the next one.
What falls outside that frame, including configuration logic, business process vulnerabilities, and chained attack paths, doesn’t appear in the report.
What Penetration Testing Actually Does
Most banks have both vulnerability scanning and penetration testing in their programs. Fewer have a clear picture of how those two practices relate to each other, or where one stops being sufficient and the other becomes necessary.
Penetration testing starts where scanning stops. A skilled tester isn’t querying a database of known signatures. They’re thinking through how an attacker would approach your environment, what paths exist between systems, how trust relationships can be abused, and whether the logic governing your applications behaves the way your team assumes it does.
Reconnaissance involves understanding how your systems interact, not just what versions they’re running. Testing moves through an environment the way an attacker would: gaining an initial foothold, identifying what that access can reach, escalating privilege where possible, and documenting the realistic damage potential of a successful intrusion.
Findings aren’t a list of CVEs. They’re a narrative of how far an attacker could go and what they could do when they got there.
It’s worth being precise about terminology here because banks encounter it in vendor conversations. A penetration test and a red team engagement are related but distinct. A penetration test typically has defined scope, a specific timeframe, and a goal of identifying as many exploitable vulnerabilities as possible within that scope. A red team engagement simulates a full adversarial campaign against a specific objective, often without the security team’s knowledge, testing detection and response capability alongside technical controls.
Both are legitimate and useful. They answer different questions, and conflating them leads to scoping decisions that don’t match what the bank actually needs to learn.
Why the Distinction Hits Differently in Banking
Every industry has reasons to care about this gap. Banks have more of them, and they’re more consequential.
Verizon’s Data Breach Investigations Report has documented consistently over multiple years that a significant portion of breaches involve credential abuse and exploitation of system trust relationships rather than unpatched known vulnerabilities. Scanning addresses one part of that picture. The rest requires a different method.
Regional banks make this particularly acute. These environments carry decades of infrastructure layered on top of each other. Core banking platforms from the 1990s sit alongside modern APIs, cloud-hosted services, and third-party integrations for everything from mortgage origination to fraud detection. Each connection point between those systems represents a trust relationship. Vulnerability scanners assess the components. They don’t assess whether the relationships between them can be exploited.
Consider how wire transfer authorization typically works in a regional bank environment. The workflow touches multiple systems, often including a core banking platform, an authentication layer, an operator workstation, and sometimes a third-party payment processor.
A scanner can tell you whether each of those systems has known vulnerabilities. It cannot tell you whether an attacker with access to one system can manipulate the workflow logic to authorize a fraudulent transfer without triggering controls. That’s a penetration testing question, and it’s precisely the type of finding that doesn’t appear in scan reports.
The Capital One breach illustrates this directly. Once the attacker obtained temporary credentials through the WAF misconfiguration, the damage came from how those credentials were trusted by downstream systems. The lateral movement was possible not because of unpatched software but because of how access was scoped and how systems related to each other. That attack path would not have appeared on a vulnerability scan report.
The Compliance Trap
FFIEC guidance requires financial institutions to conduct penetration testing as part of a sound information security program. PCI-DSS requires it for any bank handling cardholder data. On paper, this means banks are getting tested, not just scanned.
In practice, the gap between satisfying a regulatory requirement and actually surfacing risk is wide enough to matter.
Minimum compliance thresholds don’t specify attacker sophistication, testing depth, or whether business logic gets examined. A test that checks network segmentation and a handful of external-facing systems can satisfy an examiner and leave an institution’s most consequential attack paths untouched.
Scope limitations that exclude legacy systems because they’re “too critical to test” are common. Timeboxed assessments that don’t allow testers enough time to move through an environment the way a real attacker would are equally common. The report gets filed, the box gets checked, and the security committee sees a finding count rather than an honest picture of exposure.
Regulators are not the adversary here. FFIEC examination procedures have pushed banks toward better practices over time. The problem is that institutions optimizing for examination outcomes rather than security outcomes tend to get exactly what they optimize for: documentation that satisfies a reviewer without necessarily improving their actual posture.
A penetration test scoped to pass is a different exercise than one scoped to find what an attacker would find.
How to Ask Better Questions of Security Vendors
The scoping conversation before an engagement starts is more revealing than most banks realize. A few questions worth asking any vendor before signing a statement of work:
How do you approach business logic testing? A vendor who responds primarily in terms of tools and scan coverage is telling you something important about their methodology.
What does your reconnaissance process look like before active testing begins? Testers who understand your environment before they start probing it find different things than testers who run a framework against your IP ranges.
Can you show us a sample report from a previous engagement? The difference between a finding list with CVSS scores and a narrative report that walks through an attack chain is visible immediately. One tells you what’s broken. The other tells you what’s at risk.
What have you found in environments similar to ours? Testers with genuine financial sector experience bring context that generalist firms don’t. The attack surface of a regional bank is specific enough that sector experience matters.
These aren’t adversarial questions. A competent vendor will have direct answers to all of them. If the answers are vague, that’s a finding in itself.
Closing
Those vendor conversations connect directly back to your actual exposure. The systems where your most sensitive workflows live, your wire transfer authorization logic, your third-party integration trust relationships, your legacy-to-modern infrastructure connections, are exactly the environments where scoping decisions determine whether a test finds what an attacker would find.
The technical distinction between vulnerability scanning and penetration testing ultimately comes back to a simple question: does your security program tell you what’s broken, or does it tell you what’s at risk?
For a bank, those are different questions with different answers. Scanning is a necessary part of that picture. It is not a sufficient one. The organizations that understand the difference and build their security programs accordingly are in a materially better position than those that don’t.