Privacy Impact Assessment for Mixed GLBA and Non-GLBA Data: Scope the Data, Not the Entity

TL;DR

• A data privacy impact assessment template for a fintech should classify the processing flow—not stamp the company, product, database, or person as “GLBA.”
• Record five facts before claiming an exemption: who the person is, how the data was obtained, why it is used, what decision it supports, and which jurisdiction applies.
• State-law GLBA exemptions differ. California’s CCPA provision is tied to personal information handled subject to GLBA; the Colorado Attorney General describes the Colorado Privacy Act as excluding financial institutions and affiliates subject to GLBA.

“We are a GLBA company” is not a data map. It is an entity-level conclusion being used to skip a processing-level analysis.

That shortcut breaks as soon as the same fintech handles a consumer’s loan application, an employee’s device data, a merchant owner’s business contact details, and an anonymous visitor’s advertising identifier. Those records can sit in the same warehouse and still have different legal scope.

A useful data privacy impact assessment template starts with the data flow: person, relationship, collection context, purpose, use, recipient, retention, and jurisdiction. Only then should Privacy or Legal record whether GLBA applies and whether a state law provides an entity-level, data-level, or activity-specific exclusion.

Why “GLBA data” needs a written basis

The FTC’s Privacy of Consumer Financial Information Rule, 16 CFR Part 313, supplies the starting logic for FTC-regulated financial institutions.

Section 313.1 says the rule applies to nonpublic personal information about individuals who obtain financial products or services primarily for personal, family, or household purposes. It also says the part does not apply to information about companies or individuals obtaining products or services for business, commercial, or agricultural purposes.

Section 313.3 then defines the data:

• Nonpublic personal information includes personally identifiable financial information and certain lists derived from it.
• Personally identifiable financial information includes information a consumer provides to obtain a financial product or service, information resulting from a transaction, and information otherwise obtained in connection with providing that service.
• The examples include application information, account balances, payment history, purchase information, customer status, collection information, certain cookie information, and consumer-report information.

The connection matters. “Email address” is not automatically GLBA-covered or automatically outside GLBA. An email supplied with a consumer credit application has a different provenance and purpose from a recruiting candidate’s email or a conference attendee’s email.

Use counsel for legal conclusions, especially where regulators or statutes outside the FTC rule govern the institution. The PIA’s job is to preserve the facts and rationale counsel needs—not bury the conclusion in a dropdown with no evidence.

State privacy exemptions do not use one pattern

Two official sources show why the state column cannot say only “GLBA: yes/no.”

California Civil Code § 1798.145(e) says the CCPA title does not apply to personal information “collected, processed, sold, or disclosed subject to” GLBA and implementing regulations. The same provision says that exclusion does not apply to the CCPA’s private-action section, § 1798.150. That text is data- and activity-focused; it does not simply erase the company from CCPA analysis.

By contrast, the Colorado Attorney General’s Colorado Privacy Act FAQ lists “financial institutions and affiliates subject to the Gramm-Leach-Bliley Act” among excluded entities. The page separately notes that certain data maintained under specified federal privacy laws is also outside the act.

Do not extrapolate California or Colorado to another state. Open the current statute, capture the section, record the date reviewed, and state whether the conclusion is entity-, data-, activity-, or obligation-specific. The broader state GLBA exemption guide is useful for issue spotting, but the PIA should point to the controlling provision used for the decision.

The mixed-scope data privacy impact assessment template

Use one row per processing flow, not one row per system or generic data category.

Add a purpose-change trigger. A row approved for fraud prevention should be reopened before the same event stream is used for targeted advertising, employee monitoring, or model training. Copying the original GLBA tag is not analysis.

A worked fintech example: one platform, six answers

The following is a realistic hypothetical, not a legal conclusion for any specific company.

A lending fintech operates a public website, accepts personal loan applications, services funded loans, supports small-business merchants, employs a remote workforce, and uses one analytics platform across several products.

The business will push for one answer because one answer is easier to implement. The defensible implementation is usually a classification field carried through the data pipeline: processing-flow ID, approved purposes, applicable restrictions, and review date. That gives Engineering something enforceable and gives Privacy something testable.

Example rationale that is too weak

GLBA exempt because the company provides loans.

Example control language

Flow LEND-APP-01 covers fields collected from an individual applying for a personal loan through Entity A. Privacy reviewed the flow under 16 CFR 313.1 and 313.3 on July 26, 2026. Approved purposes are eligibility review, fraud prevention, origination, required notices, and servicing setup. Targeted-advertising use is not approved under this determination and requires a separate privacy review. California treatment is recorded under Civil Code § 1798.145(e), including the § 1798.150 carve-out.

The second version is narrow enough to challenge when the product, entity, purpose, recipient, or law changes.

Test the decision in systems, not just the PIA

A perfect spreadsheet does not constrain a warehouse query. Convert the assessment into operating controls:

• Data catalog: tag fields with the processing-flow ID and approved purpose, not only “NPI.”
• Access control: grant access by use case and role; a Marketing analyst should not inherit access because the table also serves Fraud.
• Change management: require a PIA review when a team adds a data source, purpose, recipient, decision use, model, or retention period.
• Vendor intake: map each vendor to the flows it receives and prohibit secondary use outside documented instructions.
• Deletion: connect the retention decision to a system rule and retain deletion-job evidence.
• Rights operations: route requests using the person, entity, jurisdiction, and flow classification; do not reject every request with a GLBA macro.

For testing, select a sample from actual production lineage and trace both directions:

1. PIA row → source table → downstream destinations → user access → retention job.
2. Production field → originating flow → approved purpose → legal rationale → current owner.

A one-way inventory misses shadow copies. Also compare request dispositions to the underlying rows. If every California deletion request received the same GLBA denial while the warehouse contains applicant, employee, and advertising flows, that is a useful signal that the scoping logic is too blunt.

The existing guides to GLBA Regulation P privacy notices and DSAR response workflows cover the notices and rights process downstream. This assessment decides which data and activities should enter those workflows.

Ownership: who signs which part?

Do not ask Product to make the legal determination or Legal to reconstruct system lineage alone.

The evidence that this operating model works is not a RACI slide. It is a dated PIA showing comments resolved, technical controls linked to tickets, launch conditions verified, and purpose changes routed back through review.

So What?

Take one system currently labeled “GLBA” and pull ten fields from its catalog. For each field, identify:

• the person and relationship;
• the collection event and source;
• the exact purpose and decision use;
• every recipient and downstream copy;
• the GLBA subsection and facts supporting the conclusion;
• each applicable state law’s exemption structure and preserved obligations.

If the answers collapse to “financial institution data,” the classification is too coarse. Split the record into processing flows before the next product launch or rights request forces the analysis under a deadline.

The best first-week artifact is not a 50-state memo. It is a ten-row mixed-data pilot with source links, named owners, and one explicit purpose-change trigger. That small test will show whether the organization can actually distinguish a personal loan application from employee telemetry and an advertising event.

The Data Privacy Compliance Kit includes a data inventory, privacy impact assessment template, state-law applicability matrix, and consumer-rights workflows for operationalizing that analysis.