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
A continuous penetration test moves from reconnaissance and service discovery to reachability, then chains reachable flaws into a proven path to customer data before researchers revalidate every finding. Our walkthrough of how AI penetration testing traces a data leak end to end shows each stage in practice.
Section 314.4(d)(1) asks whether your safeguards detect real attacks, and a proven chain answers it directly. Grounding the method in a standard such as NIST SP 800-115 is what makes the evidence defensible to an examiner.
What White Box And Gray Box Testing Add
White box testing reads the codebase and cloud configuration to build an internal threat model, and gray box testing uses that model to attack from outside with inside knowledge. Our breakdown of black box, white box, and gray box testing covers where each mode fits, and our cloud pentesting 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 |
Our explainer on the VAPT distinction covers the general difference.
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. Our remediation and retest guide covers what that retest should prove.
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. To compare vendors, see insurance pentesting tools compared.
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.
For how insurers apply these rules, see our insurance pentesting requirements guide.
