Regulation S-P: An Overview of the SEC’s Latest Cybersecurity Amendments

On June 3, 2024, the Securities and Exchange Commission (SEC) published a final rule titled Regulation S-P: Privacy of Consumer Financial Information and Safeguarding Customer Information. The rule amends 17 CFR Part 248 and enhances the SEC's cybersecurity and incident response requirements. 📃

Let's look at the updates and what they might mean for you.

Who does it apply to?

The Regulation S-P amendments apply to five categories of financial institutions:

• Brokers and dealers (a.k.a., broker-dealers)
• Investment companies (registered AND unregistered)
• Registered investment advisers
• Funding portals
• Transfer agents

Altogether, these are called "covered institutions" in the final rule. If you work for one of these kinds of institutions, then yes, this applies to you. 🫵

When do the Regulation S-P amendments go into effect?

The final rule's effective date is August 2, 2024.

It seems a little soon to implement a rule of this size. The SEC agrees and has given you some time to get your ducks in a row. 🦆

The mandatory compliance dates are 18-months and 24-months after the date of publication in the federal register, based on your organization's size.

Don't know how you qualify? See the Compliance Period section of the Federal Register notice.

What do the Regulation S-P amendments require?

While the Regulation S-P amendments require a lot of things, we're going to look at four key parts:

1. The incident response program requirements
2. The customer notification requirements
3. The service provider requirements
4. The records retention and destruction requirements

(For the sake of readability and avoiding all the legalese, I'm going to presume that if you're still with me, these rules probably apply to "you," and I'll refer to you as such.)

The Incident Response Program Requirements

The Regulation S-P amendments require you to create an incident response program.

The program should be designed to "detect, respond to, and recover from unauthorized access to or use of customer information." As part of this program, you need to be able to assess, contain, and control incidents.

If you're not sure where to get started, a lot of this language echoes NIST SP 800-61 Rev. 2 (Computer-Security Incident Handling Guide) and the NIST Cybersecurity Framework. If you're looking for the Readers' Digest Condensed Version, check out our blog on Incident Management: Seven Best Practices to Prepare for Security Incidents.

The Customer Notification Requirements

When an incident occurs, you will also be required to notify individuals "whose sensitive customer information was, or is reasonably likely to have been, accessed or used without authorization."

While it might seem straightforward, there are a lot of things to unpack here. 🎒

• Sensitive Customer Information: This definition is really important. It says: "Any component of customer information alone or in conjunction with any other information, the compromise of which could create a reasonably likely risk of substantial harm or inconvenience to an individual identified with the information." This is broader than many other incident notification requirements and could include things that aren't traditionally considered PII. So, if you think you know what "sensitive customer information" is because you comply with some state law that uses the same terminology, it might be good to double check. ✅✅
  
  
• Exception: Notice is NOT required if the investigation 🔍 shows the information was not (and is not likely to be) "used in a manner that would result in substantial harm or inconvenience" (e.g., theft, fraud, harassment, damaged reputation, impaired credit eligibility, etc.). This also means that even if a system is compromised, but you have "reasonably determined" that an individual's information on the system was not accessed or misused, giving notice is not required.
  
  
• Timing: The notice needs to be provided "as soon as practicable, but not later than 30 days, after becoming aware that unauthorized access to or use of customer information has occurred." (Yes, the word "practicable" is weird, but it is a real word. 🤷) The commentary acknowledges that while you "may still be working towards remediating the breach" when it comes time to notify, the notification needs to happen promptly to help the affected individuals protect themselves.
  
  
• Format: Notice must be provided in a "clear and conspicuous manner and by means designed to ensure that the customer can reasonably be expected to receive actual notice in writing." 📫 The "in writing" part can mean either physical or electronic, as long as the customer has agreed to receive information electronically and it meets the SEC's guidance on electronic delivery of documents.
  
  
• Contents: The notice will need to include (at minimum) the following elements:
  • General information about the incident and what information was compromised.
  • The actual date(s) of the incident or an estimation of when it occurred.
  • Your institution's contact info for further information and assistance, including:
    • A phone number.
    • An email address or similar means of contact (e.g., an online contact form).
    • The postal mailing address.
    • The name of a specific office.
  • And guidance on how to:
    • Review account statements and report suspicious activity.
    • Place a fraud alert in credit reports and what a fraud alert is.
    • Have fraudulent transactions deleted from credit reports.
    • Obtain a free credit report.
    • Protect against and report identity theft to the FTC (https://ftc.gov).

A few notes on some special scenarios that were addressed in the amendments and commentary.

• Scope: If the scope of an incident changes, notice may be required at that point. For example, if the compromised data was encrypted, but the encryption is rendered ineffectual at a future date (e.g., due to technology advancements, loss of decryption key, etc.), then notice may need to be provided based on your future assessment.
  
  
• Delay: The notice may be delayed only if the United States' Attorney General asks the SEC for one in the name of "national security and public safety."
  
  
• Regulator Notice: These amendments do NOT require you to notify the SEC. Just the affected individuals.

New to incident notifications? Check out our blog on Incident Response Plan Communication Guidelines.

The Service Provider Requirements

The Regulation S-P amendments also require you to implement a vendor management program. Specifically, they're looking for "written policies and procedures reasonably designed to require oversight, including through due diligence on and monitoring, of service providers, including to ensure that the covered institution satisfies the customer notification requirements."

To do this, the program needs to ensure service providers do two things:

1. Protect customer information from unauthorized access or use.
2. Notify the institution ASAP, but no later than 72 hours after becoming aware of a security breach resulting in unauthorized access to a customer information system maintained by the service provider.

A few key explanations here, as well.

• Service Providers: The rule defines service providers as "any person or entity that receives, maintains, processes, or otherwise is permitted access to customer information through its provision of services directly to a covered institution." So, anyone you give customer information to is going to be on that list.
  
  
• Becoming Aware Of: This is a very short timeframe! It isn't about "confirming" or "reasonably determining." The minute the service provider "becomes aware of" an incident, the 72-hour clock starts. Tick tock. ⌚
  
  
• Customer Information System: For the purpose of the customer notification, it isn't up to the service provider to determine if sensitive customer information was compromised or not. It's up to you. They just have to let you know about the system compromise, unless you agree to have them notify the customers on your behalf.

At this point, you might be wondering: How on earth am I supposed to get my service providers to agree to that? While the final amendments do not require you to have your service providers sign a contract saying they'll notify you in this timeframe, your service providers are under no obligation to fulfill these reporting requirements unless it is in a contract. So, while you don't have to, pursuing an amendment or addendum to your agreement with the service provider would be your safest bet. 📄🖊️🤝

Is this your first vendor management rodeo? Download our free Vendor Management Workbook to get started.

The Records Retention & Destruction Requirements

To make it easy for you to demonstrate compliance, the amendments to Regulation S-P also include updated records retention and destruction requirements.

Here's a summary of the retention requirements.

The amendments also require the secure disposal of consumer and customer information. To ensure this, the rule requires written policies and procedures to guide this process.

Got writers block? Check out Tandem Policies for a full set of information security policy templates, including one for Data Management (i.e., data retention and destruction). ♻️

Next Steps

The Regulation S-P amendments are a lot. Don't take my word for it though. The federal government itself has even designated this as a "major rule." If you're not sure where to get started, you're not alone.

The federal banking agencies (i.e., the FDIC, OCC, FRB, and NCUA) have required similar things for banks and credit unions for years. Because of that, here's where I'd recommend you start:

1. Identify and classify your customer information. You can't protect unknown data. Check out this guidance to get started: FFIEC AIO Booklet, III.A.1 Data Identification and Classification.
   
   
2. Create an IT asset inventory. You also can't protect your data if you don't know where it lives. Think about all the systems and vendors who have access to this data and make a list of it. Here's another resource: FFIEC AIO Booklet, III.B IT Asset Management.
   
   
3. Start shaping your incident response plan. You likely already have some plans in place that you'd enact if you had an incident. Even if your plan is "we'll call Steve 🙋‍♂️," that's a great place to start. Give him a call, start putting your pen to paper, and begin writing out your incident response plan. Here's one more resource for the road: FFIEC AIO Booklet, VI.C.4 Event, Incident, and Problem Management.

Jump Start the Process

If this all sounds a little daunting, I get it. Tandem has lived in this space since the federal banking agencies passed similar rules, and because of that, we have the experience and the expertise to help you grow. Visit Tandem.App/Demos to see how our integrated suite of products work together to help you create your incident response plan, vendor management program, information security policies, and beyond.