Reg S-P and other firms' clients: does data you received count?

Does Reg S-P customer information include another firm's clients?

Yes. Under 17 CFR 248.30(d)(5), customer information includes records about your own customers and records about "the customers of other financial institutions where such information has been provided to the covered institution." If it is nonpublic personal information about someone's financial customer and it sits in your systems, the safeguards policy, the incident response program and the disposal rule all reach it.

The SEC wrote this into the 2024 amendments on purpose. The adopting release says the broader scope is designed to help ensure that all information covered by the Gramm-Leach-Bliley Act is appropriately safeguarded, and that firms assess enough information to support the customer notice obligation. Both compliance dates have now passed: December 3, 2025 for larger entities and June 3, 2026 for smaller ones, according to the SEC's small entity compliance guide.

Why does this change the scope of your program?

Because most firms scoped their written policies around their own client list, and the rule now asks about a wider set of records. A safeguards policy that protects "our clients' data" can leave out files that belong to someone else's clients but still live on your file server, in your CRM or in a vendor's platform.

The practical test is the source of the record, not the relationship. If another financial institution's customer data arrived in your environment, it is customer information for Reg S-P purposes. If any part of it is sensitive customer information, defined in 248.30(d)(9) to include items such as a Social Security number or a government-issued ID number, it can also trigger the notice requirement after an incident.

Where does other institutions' customer data show up?

In the ordinary flow of business between firms. A few places to look:

• Introducing and clearing arrangements, where account records pass between two broker-dealers.
• Sub-advisory, model provider and platform relationships, where an adviser receives account-level data about another adviser's clients.
• Account transfer paperwork and statements received from the delivering firm.
• Due diligence files from an acquisition or a book-of-business transaction, including data rooms that were never cleaned up.
• Shared drives and inboxes. The SEC's release describes commenters raising exactly this case: an employee account compromise that exposes a shared file server where other financial institutions' contracts may reside.

None of these is unusual. The risk is that nobody wrote them down, so they sit outside the data inventory, the retention schedule and the incident playbook.

Who notifies the individuals if that data is breached?

The institution where the incident happened. The SEC changed its original proposal to avoid duplicate notices, reasoning in the adopting release that the firm with the incident "will have information about the incident itself that is necessary to properly inform affected individuals."

That means a breach of your systems can leave you notifying people who are not your clients. The SEC anticipated the contact information problem: the firm without contact details "can coordinate with the covered institution that has a customer relationship to receive contact information as needed for the notices," and the two institutions "can coordinate with each other as to which institution will send the notice." Under 248.30(a)(4), notice is due as soon as practicable and no later than 30 days after you become aware of the incident, unless a reasonable investigation shows the sensitive customer information has not been, and is not reasonably likely to be, used in a way that would result in substantial harm or inconvenience.

Thirty days is not much time to find out whose data was in a folder, which firm holds the relationship, and who will send the letter. Those questions are easier to answer before an incident.

Does the 72-hour service provider notice apply here too?

Yes. The rule defines a service provider in 248.30(d)(10) as any person or entity that "receives, maintains, processes, or otherwise is permitted access to customer information," and customer information includes other institutions' customers. Your oversight duty under 248.30(a)(5) follows that definition. A vendor hosting a data room, a CRM or a document platform that holds those records is in scope, and your policies must require it to notify you as soon as possible, and no later than 72 hours, after it becomes aware of a breach that results in unauthorized access to a customer information system it maintains.

If you cannot tell which vendors hold other firms' data, you cannot tell which contracts need that language checked first. Our article on Reg S-P service provider notice terms covers the contract review.

How do you scope data you received from other institutions?

Start with a source list, then map it to systems. For each inbound data flow, record who sends it, what fields it contains, where it lands, who can access it, how long you keep it, and which service providers touch it. Flag any flow that carries sensitive customer information.

Then decide what you actually need. The disposal requirement in 248.30(b) applies to consumer information, which the rule also defines to include information about customers of other financial institutions provided to you. Old acquisition files and closed sub-advisory data you no longer need are both a disposal question and an incident-scope question. Every record you dispose of properly is one fewer record to assess, contain and notify on later.

Finally, tie the inventory to your incident response program. When an alert comes in, the person running the response should be able to see whether the affected system holds other institutions' customer data and which firm to call.

What records will an examiner expect?

Written evidence that the program covers this data. Advisers must keep Reg S-P records under Rule 204-2(a)(25), and broker-dealers under Rule 17a-4(e)(14). Those records include the written policies and procedures, documentation of detected unauthorized access and notification determinations, and service provider contracts. Our Reg S-P recordkeeping guide covers how long each must be kept.

A data map that names inbound sources, a retention decision for each, and vendor contracts with current notice terms gives an examiner something concrete. A policy that only says "client data" invites the follow-up question of whose data you mean.

What should you do this quarter?

• List every inbound data flow from another financial institution, including one-time transfers such as acquisitions.
• Mark which flows carry sensitive customer information and which systems they land in.
• Confirm a retention and disposal decision for each, and dispose of what you no longer need.
• Check that vendors holding this data have the 72-hour notice term in their contracts.
• Add a step to your incident playbook: identify other institutions whose customers may be affected, and agree in advance who sends notice.
• Update the written safeguards policy so its scope language matches 248.30(d)(5).

How can s90 help?

s90 maps where customer information lives across your Microsoft 365 tenant, file shares and line-of-business systems, including data that came from other firms, and keeps that inventory current as part of managed IT. Our agreements include a 72-hour breach notification commitment and 24-hour evidence production, so your incident timeline and exam requests start with facts. If you want a second look at your data map before the next exam cycle, we are happy to talk.