What GLBA Actually Requires from Asset Manager Data Systems

The Gramm-Leach-Bliley Act is often treated as a background compliance obligation by asset managers, something the legal team handled once and that gets reviewed at annual audit time. That framing creates exposure. GLBA's data security and handling obligations are ongoing, operational, and they reach directly into the systems that manage customer financial records, which for asset managers includes ownership and position data.

Understanding what GLBA actually requires at the record level, not just at the policy level, is increasingly important as asset classes expand and the number of systems touching ownership data grows.

Who GLBA Covers and What That Means for Asset Managers

GLBA applies to "financial institutions" as defined under the Bank Secrecy Act, a category that includes registered investment advisers, broker-dealers, and investment companies, among others. If you manage assets on behalf of clients and those clients are natural persons, GLBA applies to you. Many asset managers focus primarily on the BSA/AML obligations and treat GLBA as a secondary concern. That prioritization made more sense when the range of systems touching client data was narrower. It makes less sense now.

The FTC's Safeguards Rule, which implements the data security provisions of GLBA, was significantly updated in 2023. The revised rule requires covered institutions to designate a qualified individual to oversee the information security program, conduct periodic risk assessments, maintain specific technical safeguards, and report material security events to the board or equivalent body within a defined timeframe. These are not one-time implementation requirements. They are ongoing operational obligations.

The Record-Level Obligations That Get Underestimated

The most specific and most often underestimated GLBA obligations for asset managers concern the handling of customer financial records at the record level. The Safeguards Rule requires covered institutions to implement access controls, encryption for data in transit and at rest, and audit logging for access to customer financial information.

For an asset manager whose ownership records are distributed across multiple systems, this creates a specific problem: the obligation to demonstrate access controls requires knowing, precisely, which systems hold which records and who can access them. When ownership data exists in custodian exports sitting in shared folders, in spreadsheets emailed between teams, and in reports generated by portfolio management systems, mapping the access control perimeter is genuinely difficult.

The FTC has been clear in guidance that the Safeguards Rule requires not just that access controls exist, but that the institution can demonstrate they are functioning. A "we have a policy" answer is not sufficient if the actual data handling practices do not match the policy.

Encryption and the Ownership Data Problem

The encryption requirements under the revised Safeguards Rule apply to customer information in transit and at rest. For ownership records, this creates a specific set of questions that teams need to answer concretely.

Does the encryption requirement apply to custodian data feeds? The practical answer is yes, but the mechanism varies. SFTP with appropriate key management satisfies the in-transit requirement for feed delivery. But what happens to that data when it lands? If the first thing your system does with an incoming custodian file is save it to an unencrypted network share while the reconciliation process runs, the in-transit encryption is providing incomplete coverage.

The same logic applies to data at rest in the reconciliation layer itself. If ownership records are stored in a database, is that database encrypted? Are the backups encrypted? Are the encryption keys managed separately from the data? These are operational questions, not architectural ones. They need operational answers that teams can verify, not just policies that state the right intention.

Audit Logging: What Regulators Actually Need

The audit logging requirement under GLBA is one where we see the most divergence between what firms think they have and what they would need to demonstrate in a regulatory examination. The Safeguards Rule requires audit trails sufficient to detect and respond to security events. In practice, this means logs that capture who accessed which records, when, and from where, in a form that can be queried and reported.

For ownership data specifically, the log needs to capture not just system-level access events but data-level access: which records were accessed, by which user or process, at what time. A system-level log that shows a user logged into the reconciliation platform does not tell you which ownership positions that user viewed or exported. The FTC's examination guidance has asked specifically for evidence that firms can reconstruct access to specific customer records.

We are not saying that every asset manager needs a SIEM platform with full packet-level logging of every database query. The requirement is proportionate to the scale and risk profile of the institution. But the logging needs to be sufficient to support the risk assessment and incident response obligations in the rule. That is a higher bar than most spreadsheet-based reconciliation processes can meet.

Third-Party Service Provider Oversight

One section of the Safeguards Rule that receives less attention than the encryption and access control provisions is the third-party service provider oversight requirement. Covered institutions must implement procedures to oversee service providers that have access to customer information, including by requiring those service providers to implement appropriate safeguards.

For asset managers, custodians are the primary third-party data holders. Most custodian agreements include representations about information security practices, but those representations vary significantly in specificity and are not always current relative to the revised rule's requirements. The institution has an ongoing obligation to understand what its service providers are doing with the data, not just to collect a certification once and file it.

This oversight obligation extends to the data feeds themselves. When a custodian delivers ownership data to an asset manager through a third-party data aggregation service, the chain of custody has lengthened. The asset manager needs to understand each link in that chain and ensure that the safeguards requirement is met throughout.

Incident Response and the Material Breach Threshold

The 2023 Safeguards Rule update introduced a notification requirement for security events that meet a material breach threshold: unauthorized access to, or unauthorized use of, the unencrypted information of 500 or more customers. The obligation is to notify the FTC within 30 days of discovering the breach.

What this requires operationally is a well-defined incident response process that includes a formal assessment of whether a security event meets the notification threshold. For an asset manager that holds positions for hundreds or thousands of clients, an unauthorized access event affecting ownership records could reach the threshold quickly. Discovering a breach, investigating its scope, and making a threshold determination all have to happen within the 30-day window.

Teams that have not drilled this process, including practicing the scope assessment for a hypothetical ownership data incident, are likely to find that 30 days is not as generous as it sounds when legal, compliance, and IT have to coordinate from a standing start.

What a Compliant Ownership Data Layer Looks Like

The common thread across GLBA's record-level requirements is demonstrability. It is not enough to have the right practices in place; the institution has to be able to show that those practices are functioning as intended. That means structured logging, documented access controls with evidence of enforcement, encryption with key management that has been tested, and vendor oversight processes that have been followed.

For ownership data specifically, a compliant data layer is one where every record knows where it came from, every access to that record is logged, the record is encrypted at rest, and the access control rules are maintained in the same system that stores the data rather than in a separate policy document that may or may not be current.

Building these properties into the data layer from the start is substantially easier than retrofitting them onto a system that was built for operational convenience. The firms that have the most difficulty with GLBA examination questions are generally those whose ownership data infrastructure was designed primarily for speed of reconciliation, with compliance controls added afterward. The controls and the data need to be codesigned, not bolted on.