The Gramm-Leach-Bliley Act does not say the words "penetration testing" anywhere in its text. The obligation lives one level down, in the FTC's Safeguards Rule, and it is written in a way that surprises most teams reading it for the first time.
The annual pentest is conditional. This guide covers what 16 CFR 314.4(d) requires, the continuous monitoring alternative beside it, what a test has to actually do to be worth the line item, and whether any of it reaches insurers.
What CodeAnt AI solves here: CodeAnt AI runs continuous, code-aware penetration testing across code, cloud, network, and external surface, chaining findings into proven paths to customer data. Pricing is outcome-based, so you pay for confirmed critical exposure rather than researcher hours.
Does The FTC Safeguards Rule Apply To Insurance Companies?
This question derails a lot of compliance planning, and the answer is sharper than most summaries suggest. For the business of insurance, the FTC is generally not your regulator.
GLBA Section 505, codified at 15 U.S.C. 6805, splits enforcement across federal functional regulators, state insurance authorities, and the FTC, each covering institutions in their own jurisdiction. Persons engaged in providing insurance fall to state insurance authorities.
That allocation is why state-level rules exist at all. The safeguards obligation for insurers arrives through the NAIC Insurance Data Security Model Law and regulations like NYDFS 23 NYCRR 500 rather than through the FTC.
The line matters most for hybrid businesses. An entity providing services outside the business of insurance can sit under FTC jurisdiction for that activity, which is why insurtech platforms, premium finance operations, and vendors serving insurers end up reading the Safeguards Rule anyway.
What GLBA Safeguards Rule Requires For Penetration Testing
The testing obligation lives in Section 314.4(d), and it opens broadly. Covered institutions regularly test or otherwise monitor the effectiveness of their safeguards, key controls, systems, and procedures, including those built to detect actual and attempted attacks or intrusions.
Paragraph (d)(2) narrows it for information systems. Monitoring and testing has to include either continuous monitoring or periodic penetration testing plus vulnerability assessments.
The conditional clause deserves a second read. Absent effective continuous monitoring, or other systems that detect changes in information systems on an ongoing basis, the institution owes annual penetration testing scoped each year by identified risks, and vulnerability assessments at least every six months.
GLBA Continuous Monitoring Alternative Under 16 CFR 314.4(d)(2)
Read plainly, the rule offers two compliant routes and treats continuous monitoring as the primary one. The annual test is what you owe when you cannot detect change on an ongoing basis.
This stands out among security regulations. NYDFS Section 500.5 mandates an annual pentest outright with no alternative path, while the FTC rule accepts continuous monitoring in its place.
The practical implication runs one way. An institution that moves to genuine continuous testing satisfies the requirement and drops the annual scramble of scoping, scheduling, and waiting on a report.
What Counts As Effective Continuous Monitoring Under GLBA?
The rule sets the bar with a functional description rather than a product category. What qualifies is a system that detects, on an ongoing basis, changes in information systems that may create vulnerabilities.
Two words carry the weight. "Ongoing" rules out quarterly sampling, and "changes in information systems" points at deployments, configuration drift, and new services rather than only at newly published CVEs.
A scanner on a schedule struggles against that description. Testing that re-examines the surface when the surface actually changes, on every deployment, maps to the language far more closely.
Why an Annual Manual Engagement Cannot Meet That Standard
Continuous detection is a coverage problem before it is a tooling problem. To know whether a change created an exposure, the test has to understand how the business actually operates.
That means knowing how code ships and how developers push it, what security issues and malware already sit in the environment, and what the network, the cloud, and the external attack surface each look like today.
No human team re-derives all of that weekly. A manual engagement samples a slice of it, on a schedule set months earlier, and produces a snapshot that starts aging the moment the next release lands.
Meeting the standard takes one system that reads across every layer, including the whole SDLC, and holds the connections between them. That is what continuous penetration testing means in practice, and the penetration testing process guide walks the underlying phases.
How a Continuous Penetration Test Actually Runs
The mechanics matter more than the label. Here is the flow a serious engagement follows, from first contact with the external surface through to the evidence an examiner reads.
Stage 1. Reconnaissance of everything exposed
The first job is building the adversary's picture of you. That covers open ports, exposed IP ranges, CVEs present on the network, and third-party and vendor risk that rides in through your supply chain.
Two inputs are routinely skipped and matter enormously. Which threat actors are probing you right now, and which of your credentials are already sitting on the open internet.
Stage 2. Service discovery
Mapping addresses is not the same as knowing what answers on them. Service discovery identifies the software and versions behind each exposed port and which of those respond to an unauthenticated request.
The discovered surface is almost always wider than the asset inventory says. Forgotten staging hosts and legacy services are common entry points precisely because nobody is watching them.
Stage 3. Reachability analysis
Discovery produces far more findings than any team can act on, so the next filter is what an attacker can genuinely touch. Reachability separates the theoretically vulnerable from the actually exploitable.
This is the stage that turns volume into a shortlist. The question driving it is narrow, which of these paths could actually reach customer data.
Stage 4. Chaining into a proven data leak
A single flaw rarely tells the story. The damage comes from linking issues, threats, and root causes into one continuous path that ends at exfiltrated data.
That chain is the deliverable. Mapping each hop to MITRE ATT&CK techniques turns a list of findings into a business-impact narrative, and our walkthrough of how AI penetration testing traces a data leak end to end shows a full chain in practice.
For an institution under the Safeguards Rule, this stage is the one that answers the actual regulatory question. Section 314.4(d)(1) asks whether your safeguards detect real attacks, and a proven chain answers it directly.
Stage 5. Human revalidation
Automation gets you a chain. Researchers then re-run every finding, confirm it still holds against the live system, and push the chain further than the automation took it.
The point is that nothing unconfirmed reaches the report. A finding an examiner can reproduce carries weight, and one that evaporates under scrutiny costs you credibility.
Stage 6. Evidence collection
The last stage packages what the auditors and examiners need. Proof of exploit for each finding, the code path or configuration behind it, severity, remediation, and a retest confirming the fix held.
Framed against the frameworks, this is where SOC 2, ISO 27001, and HIPAA evidence comes from. Grounding the methodology in a recognized standard such as NIST SP 800-115 or the OWASP Web Security Testing Guide is what makes the whole package defensible.
What White Box Testing Adds That No External Test Can See
Everything above describes the view from outside, which is bounded by design. An adversary cannot read your source code while your network holds.
White box testing inverts the vantage point. It reads the codebase directly, every API call and every database call, and builds a threat model from what it finds, covering third-party dependency risk, infrastructure weaknesses, exposed secrets, and SBOM issues.
Then it pairs that with the cloud. Misconfigured WAF rules, weak network layers, and open storage each get mapped alongside the application picture rather than assessed in isolation.
The payoff is in the seams between them. Modeling how internal applications talk to the cloud surfaces the things nobody documents, like an unauthenticated internal API call reaching the database with no rate limiting, which is invisible from outside and devastating to anyone already inside.
Testing this way only works if it runs where the code is written. Integrating across the SDLC, from the developer's first commit through pull requests and CI/CD, lets the threat model update on every commit instead of once a year.
Gray Box Testing, Attacking From Outside With Inside Knowledge
Gray box is where the two views combine, and it is the mode that finds what neither alone will. You take the internal threat model from the white box work, step back outside the network, and attack as an adversary who happens to know the layout.
The classic case is an API chain. A public endpoint looks harmless in isolation, but internal knowledge reveals a downstream private API behind it that performs a database call, so the attack targets the public route with the internal path in mind.
Put simply with a house. An open front door is black box, learning the layout of rooms you are not supposed to enter is white box, and gray box is someone opening a window from inside so an adversary outside can study the layout and use it on the way in.
The reason serious teams run all three is coverage of both threat models, external and internal. Our full breakdown of black box, white box, and gray box testing covers where each fits, and the cloud testing guide covers the infrastructure layer.
Penetration Testing and Vulnerability Assessments Are Separate Obligations
The rule lists them as two distinct items with different cadences and different purposes. Treating a scan report as your pentest is the most common way institutions fall short.
Attribute | Penetration testing 314.4(d)(2)(i) | Vulnerability assessment 314.4(d)(2)(ii) |
|---|---|---|
Cadence | Annual | At least every six months |
Scope driver | Identified risks per the risk assessment, set each year | Systems reasonably designed to reveal publicly known vulnerabilities |
Method | Attempted exploitation of controls | Systemic scans or reviews |
Extra triggers | Risk-assessment driven | Material changes to operations or business arrangements |
What it proves | Whether a control can actually be defeated | Whether known weaknesses are present |
The distinction is between proving exploitability and cataloguing exposure. Both are required on the non-continuous path, and neither substitutes for the other.
GLBA Penetration Testing Exemption Under The 5,000-Consumer Threshold
Smaller institutions get relief, and it is narrower than it first appears. Section 314.6 lifts four specific provisions for financial institutions maintaining customer information on fewer than five thousand consumers.
Those four are the written risk assessment criteria in (b)(1), the testing requirement in (d)(2), the written incident response plan in (h), and the annual board report in (i).
Everything else still applies. The written security program, the Qualified Individual, access controls, multi-factor authentication, encryption, secure development practices, and service provider oversight stay in force regardless of size.
The counting rule catches people out. The threshold covers all consumers whose information you maintain, not only active customers, so historical records pull many institutions over the line.
Wider GLBA Safeguards Rule Obligations Around Testing
Testing does not sit in isolation. Several other elements of Section 314.4 depend on it, and an examiner reading your program will follow those threads.
Under paragraph (g), you evaluate and adjust the information security program in light of the results of the testing and monitoring required by (d). Testing that produces no actionable output cannot satisfy this.
Paragraph (i) requires the Qualified Individual to report in writing at least annually to the board or a senior officer, and that report explicitly covers testing results alongside risk management decisions and security events.
Application security is its own requirement. Paragraph (c)(4) calls for secure development practices for in-house applications and procedures for evaluating, assessing, or testing externally developed applications used to transmit, access, or store customer information.
GLBA Breach Notification And Why Testing Evidence Matters
The Safeguards Rule gained teeth in 2023. The amendment at 88 FR 77508 added Section 314.4(j), effective May 13, 2024, and the FTC's own guidance walks through what it covers.
The clock is tight. On discovering a notification event involving the information of at least 500 consumers, you notify the FTC as soon as possible and no later than 30 days after discovery.
Discovery is defined broadly, treating the event as known the first day it is known to any employee, officer, or agent other than the person who committed the breach. Your detection posture therefore drives your reporting clock.
Why Hours-Based Pricing Works Against the Outcome the Rule Wants
There is a structural problem underneath most compliance testing, and it is about incentives. The traditional engagement bills researcher hours, is paid upfront, and costs the same whether or not it surfaces anything critical.
That model rewards a clean report delivered on schedule. It does not reward pushing a chain from stage three to stage four, which is precisely the work that proves a real exposure.
The result is testing optimized for an audit signature rather than for security. Section 314.4(d)(1) asks whether your safeguards actually detect attacks, and an engagement paid for time has no particular reason to answer that question honestly.
Outcome-based pricing inverts it. Payment depends on finding a confirmed, critical, exploitable issue, so a shallow test that stops at a findings list earns nothing, and the economics of paying only when a test finds something real push the work all the way to a proven data leak.
How CodeAnt AI Supports GLBA Continuous Monitoring And Penetration Testing
CodeAnt is built around the route the rule prefers. It runs continuous, code-aware testing that re-examines applications, APIs, cloud configuration, and external surface as they change, which maps to the ongoing-detection standard in 314.4(d)(2).
Because it reads the codebase, it covers the secure development obligation in (c)(4) at the same time, testing in-house applications as they are built rather than after release.
It runs all three vantage points as one system. External reconnaissance and reachability from the outside, a code and cloud threat model from the inside, and gray box attacks that use the internal picture to drive an external intrusion.
Findings arrive with a working proof of exploit, the code path behind it, a risk priority, and a retest. That output feeds the program evaluation in (g) and the annual report in (i) directly, and you can see the format in the sample pentest report.
The commercial model matches the technical one. You pay for confirmed critical exposure rather than hours, which is the same standard the rule cares about.
For the wider regulatory picture, our compliance penetration testing guide covers SOC 2, PCI DSS, and HIPAA, and the pentesting page covers the offensive side.
Conclusion: Treat GLBA Testing As Continuous Evidence, Not A Yearly Task
GLBA penetration testing requirements are conditional in a way the summaries rarely capture. The Safeguards Rule asks for continuous monitoring or, failing that, an annual penetration test plus vulnerability assessments every six months, with the annual test as the fallback rather than the standard.
For insurers the first question is jurisdictional. The business of insurance answers to state insurance authorities under GLBA Section 505, so your operative rules are the NAIC model law and, in New York, 23 NYCRR 500, while non-insurance arms can still land under the FTC.
Whichever path applies, the test only counts if it reaches stage four. Reconnaissance, discovery, and reachability produce a list, and only a chained, revalidated exploit proves your safeguards can be defeated.
Use annual GLBA penetration testing as the fallback, not the ceiling. Build a testing program that detects system changes continuously, validates real exploit paths, retests fixes, and produces evidence your Qualified Individual can use for program evaluation and board reporting.
That is the model CodeAnt runs, priced on what it proves rather than the hours it takes.
Launch a free black box scan for one URL to see your exposed surface the way an adversary maps it, then book a walkthrough to see continuous, code-aware testing chained through to a proven data leak and packaged as GLBA evidence. For the insurance-specific rules, start with our guide to penetration testing for insurance companies.
