GLBA Pentest Scoping Guide: How to Define What to Test

A penetration test can uncover serious security weaknesses, but only if it covers the right systems. For financial institutions, the challenge is knowing which applications, networks, cloud services, and third-party connections could expose customer information.

This guide explains how to scope a GLBA penetration test in five steps, document exclusions, and prepare for an audit.

GLBA Penetration Testing Scope: What the Safeguards Rule Requires

The FTC Safeguards Rule, under 16 CFR 314.4, requires covered financial institutions to maintain an information security program.

Section 314.4(d)(2) addresses security testing. Unless an institution uses an eligible alternative based on effective continuous monitoring, it must conduct:

• Penetration testing at least annually, with scope determined each year based on relevant identified risks.
• Vulnerability assessments at least every six months, with additional assessments when circumstances warrant them.

The rule defines penetration testing in terms of attempts to penetrate an institution’s information systems from outside or inside. It does not prescribe one universal toolset or identical asset list for every organization.

Two terms matter when defining scope:

• Customer information: Records containing nonpublic personal information about a customer, whether held by the institution or on its behalf.
• Information systems: The electronic resources used to collect, process, maintain, or store information, or to dispose of it.

The rule also provides an exemption from certain provisions, including the testing requirements in Section 314.4(d)(2), for financial institutions that maintain customer information concerning fewer than 5,000 consumers. Check the applicable requirements before relying on this exemption.

• For example, a financial app that provides personal loans collects customers’ Social Security numbers, income details, and bank statements. These records may be stored in its loan application system, shared through third-party credit-check APIs, and accessed via its customer portal. A GLBA penetration test should consider all these connected systems, not just the app’s servers, to identify potential paths attackers could use to access sensitive customer data. 

Step 1: Build a Customer Information Inventory

The first step is to determine the data that you safeguard and the location of that data.

According to the Code of Federal Regulations, covered institutions must identify and control data, personnel, devices, systems and facilities. Your inventory provides the testing team with a starting point to tie the technology handling the customer information to that information.

• + if your bank’s loan origination system handles loan applications, income statements, and credit reports, your inventory should identify where these records are stored, which teams can access them, and which systems or third-party services they connect to. This helps the testing team identify potential entry points attackers could exploit to access sensitive customer financial information. 

Follow the information along five steps:

1. Gathered: Where is information being gathered from by the customer?
2. Stored: What applications, databases or files hold it?
3. Processed: What systems use it, or modify it?
4. Transmitted: What APIs, integrations or services pass it on?
5. Records disposed of: Where records are deleted, archived, or kept?

Record the findings in a simple inventory.

Data Type	system	Owner	Location	Sensitivity
Social Security numbers	CRM or customer database	IT	Cloud	High
Account Numbers	Banking or loan platform	Application Owner	On-premises or cloud	High
Tax Returns	Tax software and client portal	Tax operations	Vendor-hosted	High
Loan Applications	Loan origination system	Lending team	Cloud	High
Student aid records	Financial aid system	Financial aid office	Hybrid	High

Avoid limiting applications to the primary use. A lot of customer information may be found in more unexpected areas:

• Marketing emails and shared drives
• Scanned documents and multifunction printers or copiers that retain files in local storage can contain customer information. 
• Backups and archived databases.
• The laptops and mobile devices of employees.
• Electronic signature platforms
• Development and test environments with production data in it.
• Services and file-transfer tools from other parties

For instance, a mortgage lender may store mortgage applications on its main website and also also distribute supporting documents via email and an e-signature service. Failure to consider those connections may result in important exposures being missed.

The inventory should be able to recognize the system and its connection with customer data. This is the relationship that brings what needs further investigation.

Step 2: Turn the Inventory Into a Scope List

Once you know where customer information lives, determine which assets could expose it.

Use the path-to-customer-data test:

• If an attacker compromised this asset, could they reach customer information, bypass a security control, or move toward a system that holds it?

If the answer is yes, include the asset or its relevant security boundary in your scope analysis.

This matters because attackers exploit connections, not just individual applications. Verizon’s 2025 Data Breach Investigations Report found that exploitation of vulnerabilities was an initial access vector in 20% of breaches studied, while third-party involvement doubled from 15% to 30%. These findings reinforce why internet-facing systems and vendor connections deserve attention.

Use the following table to make scope decisions.

Asset type	Scope decision	Why it matters
Public customer portals	Include when relevant	May expose customer records or account functions
Firewalls, VPNs, and remote access	Assess for inclusion	May provide a route into internal systems
Internal networks and directory services	Include where connected to customer data	Can enable privilege escalation or lateral movement
Cloud environments	Include relevant resources	Misconfigurations and excessive permissions may expose records
SaaS platforms and CRMs	Assess access, configuration, and integrations	Customer data may be stored or exchanged through these services
Systems with no path to customer data	Potentially exclude with evidence	Verified segmentation may reduce risk

A scope decision is not just a yes-or-no entry. Record the reason.

For example:

A payroll system might be excluded if it has no customer information and is demonstrably isolated from customer information systems. But if its credentials or network connection could provide access to those systems, exclusion needs to be reconsidered.

• Test segmentation before relying on it. A network diagram alone does not prove that one environment cannot reach another. Use access-control reviews, configuration evidence, and appropriate testing to support exclusions.

Also distinguish between testing a vendor-hosted service and testing the vendor’s underlying infrastructure. You may be able to assess your configuration, permissions, and integrations without authorization to test the provider’s infrastructure.

Step 3: Choose the Right Test Types and Depth

Your GLBA penetration testing requirements do not mean every institution needs the same combination of tests. Choose methods according to the risks identified in your assessment.

Test Type	When to Consider It
External Network Testing	Infrastructure exposed to the internet or remote access, internet-facing services
Internal Network Testing	Systems that can be accessed once initial compromise is made
Web Application Testing	Connecting with customers through customer portals, account dashboards, online applications
API Testing	Integrations that connect applications and transfer customer information
Cloud Security Testing	Cloud configurations, network rules, storage exposure, identity premissions
Wireless Testing	Possible corporate network or quest network that can lead to sensitive systems
Social Engineering	If human access and phishing risks are applicable to assessment, they need to be considered

While social engineering can be helpful in providing extra comfort, it is not specifically required for GLBA penetration tests. Add to when the risk assessment is appropriate.

Black-box testing starts with little or no internal knowledge. Gray-box testing gives testers limited information, such as user accounts, architecture details, or selected access privileges.

Gray-box testing can be a practical option for small and midsize institutions because it lets testers examine realistic attack paths without spending the entire engagement discovering basic system information. Black-box testing can still be valuable when assessing an attacker’s external perspective.

The right choice depends on your objectives, available time, and threat model.

Which to use: black-box testing or gray-box testing?

• Black-box testing: When there is minimal or no insight into the internal working of the system.
•  Gray-box testing: Provides a partial amount of information to the testers, such as some user accounts, architecture information, or chosen access privileges.

This selection depends on: 

• What are the objectives 
• How much time you have to devote 
• What threats are you facing 

When the budget is limited, gray-box testing has the potential to be a worthwhile alternative to full engagement testing for small and midsize institutions because it allows testers to explore realistic attack paths, all the while avoiding the effort of having to discover basic system information throughout the engagement. Even when evaluating an attacker’s external view, black-box testing can be helpful.

GLBA pentest vs. vulnerability assessment

These activities build on one another, but not each other.

Penetration Testing	Vulnerability Assessment
An effort to take advantage of potential weaknesses and impacts.	Knows and recognizes identified vulnerabilities
Explores realistic attack routes	Gives a more comprehensive view of security vulnerabilities
Required at least once a year, unless the eligible continuous-monitoring alternative applies	Under that provision, required every six months unless otherwise provided

A good starting point is to perform vulnerability assessments, patch simple problems and then perform penetration testing against those high-risk paths that were not patched. The time frame should be tailored to your risk assessment and testing goals.

While automation and AI can identify weaknesses and assist with testing, a tool’s automated report does not constitute compliance with testing obligations. If you plan to use continuous monitoring instead of periodic testing, ensure your program is compliant with the rule’s conditions and receive appropriate guidance to determine compliance.

If you want to learn more about testing strategies, check out  Kualitatem’s penetration testing services.

Step 4: Set Rules of Engagement Before Testing

If the testing team does not understand the scope, then it is no help.

Rules of engagement refer to the limits of the evaluation and how it helps to prevent the disruption of business activity or the unnecessary disclosure of customer data.

Agree on the following before testing begins:

• Targets: Approved domains, IP ranges, applications, APIs, cloud accounts, and environments.
• Testing window: Dates, working hours, and any business-critical periods to avoid.
• Production access: Whether production testing is permitted or staging environments must be used.
• Restricted activities: Define whether denial-of-service testing, destructive actions, or social engineering are excluded.
• Third-party permissions: Obtain authorization before testing cloud or SaaS services where provider terms require it.
• Emergency contacts: Identify who can pause or stop testing if a system becomes unstable.
• Data handling: Specify how testers may access, record, protect, and securely destroy evidence containing customer information.

The final one is particularly significant for GLBA-regulated organizations. The testers need to expose a vulnerability, but not gather any extra customer information. If possible, avoid extracting sensitive data and only use minimal proof-of-access.

Establish beforehand:

• Criteria to stop or pause 
• Escalation Plans 
• Contractual Insurance 
• Cyber Insurance
• Notification Requirements applicable to engagement 

Obtain written permission from appropriate system owners and security leadership before testing is to begin. No verbal permission is sufficient to replace a clearly documented permission.

Step 5: Document Scope So It Survives an Audit

A pentest report should be complete enough to explain what it was testing for, and what the results were. Your scope documentation should also include an explanation of why the targets were chosen.

Develop a scope justification memo that includes the following:

• Risk assessment: The risks that led to the testing decision.
• Systems covered: Applications, Networks, Cloud Resources, APIs, and relevant 3rd party.
• Exclusions: List of all exclusions and rationale for each.
• Approach to testing: Types of testing, depth of testing, environments, and key limitations.
• Timing: Approval date, testing dates and next review date.
• Information for the testers: Provider, qualifications, authorization.
• Approval: The person responsible for the project, or an approved representative.
• Findings and remediation: weakness identified, owner, due dates, closure evidence.

What are the reasons for an exclusion?

Maintain documentation to show why an asset is not within the boundary of the test. This could involve network diagrams, validated segmentation results, access-control configurations, data-flow records or relevant vendor documentation.

While a vendor’s SOC 2 report can help inform your assessment, it alone cannot be used to determine if your configurations, integrations, or attack paths are being sufficiently tested.

Documentation from scope should also tie in to your written information security program. The report to the board or equivalent governing body of the program by the Qualified Individual shall include the status of the program, material risks and material testing results.

Finally, track remediation. The completion of the assessment does not imply the reduction of risk through a penetration test. Findings must include ownership, priorities, deadlines and evidence for effectiveness of corrective actions.

To assist in Audit Evidence and Control review, check out  Kualitatem’s Compliance Audit Services.

Sample GLBA Pentest Scopes by Organization Type

The range of coverage will vary depending on the institution’s systems and data flows and risk assessment. The examples present where scoping discussions typically start.

1. Auto dealership offering financing

Think about dealer management systems, finance and insurance solutions, online credit application portal, remote access and integrations with lenders. Verify if customer financial documents are also sent via email or third party document platforms.

2. Tax preparer or CPA firm

Examine tax preparation software, client portals, e-filing systems, remote desktops, document storage and backup services. Focus on systems containing tax returns and personal identifiers.

3. Mortgage broker/lender

Add-on the loan origination system, document portals, credit-check integrations, customer authentication, and relevant cloud storage. Review if employee accounts can be compromised to expose loan applications.

4. College or university

Evaluate financial aid systems, student portals, ERP integration, payment systems and third-party financial aid servicers as appropriate. Identify customers and systems related to GLBA requirements for the institution.

5. Investment adviser

Think about the client relationship management (CRM) platform, client portal, custodian integrations, remote access and systems that hold or send nonpublic personal information.

• These are starting points, not automatic asset lists. Test each one in your physical environment and the requirements it must meet.

The following is a list of common GLBA Pentest Scoping Mistakes.

When determining your scope of GLBA penetration testing, steer clear of these pitfalls:

Even with high IP numbers, a big asset list might not include such systems.

1. Scoping by IP count: A large asset list can still miss the systems that matter most.
2. Only external perimeter tested: Internal access or lateral movement may provide other routes to customer data.
3. Legacy systems: Older applications also can hold sensitive records and/or have access to critical systems.
4. Third parties: integration tools, SaaS and vendors can be integrated into data flow.
5. Reusing last year’s scope: An old scope may not be a good fit if new applications, migrations, or shifting risks result in an incomplete scope.
6. Assuming vendor reports are enough: Third-party assurance does not necessarily include configuration and integration risks.
7. Not documenting exclusions: If you don’t document exclusions, you may not be able to justify why you excluded an asset.

• The solution is simple: Tie all inclusions and exclusions to inventory, risk assessment and supporting evidence.

How Kualitatem Supports GLBA Penetration Testing

Kualitatem offers penetration testing services to help organizations identify vulnerabilities in their applications, APIs and infrastructure. To have a clear engagement, it is essential to understand the systems involved, what risks exist in them, the testing boundaries and documentation of findings for remediation.

Final Takeaway

Defensible GLBA penetration testing scope starts with customer data, traces paths that may be vulnerable, and prioritizes tests based on risks identified. Including exclusions, test methods, approvals, and remediation in a penetration test report makes it more a security assurance and less a once-a-year exercise.