Regulation S-P for RIAs: A Practical Implementation Guide (and Checklist) for 2026

Disclaimer: This article is for informational purposes only and does not constitute legal or regulatory advice.

1. What Changed in the Amended Reg S-P?

At a high level, the amendments require covered institutions (including all SEC-registered RIAs) to maintain written policies and procedures for an incident response program. That program must be reasonably designed to detect, respond to, and recover from unauthorized access to or use of customer information. It must also include procedures for notifying affected individuals when sensitive customer information is compromised.

The amendments also broadened the safeguards and disposal rules so that they cover customer information an RIA receives from another financial institution about that institution's customers, added transfer agents to the list of covered institutions, codified the FAST Act exception to the annual privacy notice requirement, and added recordkeeping requirements (for RIAs, under Advisers Act Rule 204-2).

The SEC's small entity compliance guide summarizes these operational requirements clearly and maps well to what most RIAs need to build from scratch or substantially upgrade.

2. Who Needs to Comply, and by When?

The amendments became effective on August 2, 2024, with a tiered compliance schedule based on firm size.

• Larger entities (RIAs with $1.5 billion or more in assets under management) were required to comply by December 3, 2025.
• Smaller entities (RIAs below the $1.5 billion AUM threshold) must comply by June 3, 2026.

For the majority of SEC-registered RIAs, the relevant deadline is June 3, 2026. If your firm falls below the $1.5 billion mark, that date is your target. But given the operational build required, waiting until May is not a viable strategy.

3. The Two Deadlines That Matter Operationally

A. Client Notification: No Later Than 30 Days

When the firm becomes aware that customer information was, or is reasonably likely to have been, accessed or used without authorization, the amended rule requires notice to each affected individual whose sensitive customer information was, or is reasonably likely to have been, accessed or used without authorization. Notice must go out as soon as practicable, but no later than 30 days after the firm becomes aware of the incident. The clock runs from awareness of the incident, not from the end of the firm's investigation. Notice is not required only if the firm determines, after a reasonable investigation of the facts and circumstances, that sensitive customer information has not been, and is not reasonably likely to be, used in a manner that would result in substantial harm or inconvenience. That investigation must be completed within the 30 days; it does not extend them. The only provision that delays the deadline is a written determination by the U.S. Attorney General that notice would pose a substantial risk to national security or public safety. And if the firm cannot determine which specific individuals' sensitive customer information was affected, it must notify every individual whose sensitive customer information resides in the system that was, or was reasonably likely to have been, accessed. The default posture under the rule favors notification when there is any doubt.

B. Vendor Notification to the RIA: No Later Than 72 Hours

The amendments require that your written policies provide for oversight of service providers, through due diligence and monitoring, reasonably designed to ensure they notify the RIA as soon as possible, and no later than 72 hours after they become aware of a breach involving a customer information system they maintain. This is not aspirational language. The rule does not prescribe contract language; the SEC dropped the proposed written-contract requirement in the final rule and said firms may rely on contractual provisions, independent certifications or attestations, or other reasonable assurances. In practice, a contract clause is the cleanest way to evidence the obligation, and the SEC expects it to be documented, tested operationally, and overseen through due diligence and monitoring.

These two timelines are where most RIA compliance programs have the largest gaps. Meeting them requires more than policy language. It requires workflows, contract provisions or equivalent assurances, and evidence of execution.

4. What Does an RIA Actually Need to Build?

Below is the practical build list that an SEC examiner, or a real incident, will stress test.

A Written Incident Response Program

This is not your IT provider's disaster recovery plan. Your incident response program must address how the firm detects incidents (through internal alerts and vendor notifications), how it assesses scope and determines whether sensitive customer information is implicated, how it contains and controls the event, and how it recovers. The rule itself requires procedures to assess the nature and scope of an incident, to contain and control it, and to notify affected individuals; recovery is part of the program's stated purpose. Preventing recurrence is not a separately enumerated element, but it is what examiners will expect a mature program to show.

A "Sensitive Customer Information" Decision Framework

Your team needs a repeatable, documented method for determining what data was impacted, whether it qualifies as "sensitive customer information" under the rule, and whether misuse is reasonably likely. The rule defines "sensitive customer information" as 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 the individual identified with the information. The rule itself lists examples: information reasonably likely to be used to authenticate an individual's identity, such as a Social Security number, driver's license or passport number, or biometric record; and information identifying an individual or an account (such as a name, account number, or user name) in combination with authenticating information such as a password, security question answer, or partial Social Security number. That said, the determination is inherently fact-specific. Build a decision tree, not a checklist you hope to figure out in the moment.

Vendor Oversight That Is Contract-Backed and Testable

For a mid-sized RIA, a defensible vendor oversight program typically includes a vendor inventory identifying every party that touches customer information, risk tiering that distinguishes critical from non-critical providers, contract clauses (or, where a vendor will not negotiate, documented alternative assurances) that operationalize the 72-hour notification requirement, annual attestations or SOC reports where appropriate, and documented evidence that exceptions are tracked and resolved. The standard is policies and procedures that are reasonably designed, not perfection. In our experience, examiners look for a credible, documented effort to manage risk proportional to the firm's size and complexity.

Recordkeeping You Can Produce Quickly

The amendments added explicit recordkeeping requirements. For RIAs these sit in Advisers Act Rule 204-2 and cover the written safeguards and disposal policies, the incident response program, documentation of any detected unauthorized access to or use of customer information, the firm's investigation and notification determinations, copies of any notices sent, and service provider oversight records. These records carry the standard Rule 204-2 retention period: five years from the end of the fiscal year in which the last entry was made, the first two years in an appropriate office of the adviser. In practice, the standard is straightforward: if your policy says you do something, you should be able to show that you actually did it, and when.

5. Vendor Contract Clauses to Prioritize

When reviewing vendor agreements, MSAs, and data processing addenda, focus first on the clauses that operationalize the regulatory timelines. The rule does not prescribe contract terms, but the clauses below are the most direct way to evidence the oversight the rule does require.

High priority (must-have):

• Breach notification to the RIA as soon as possible, and no later than 72 hours after the vendor becomes aware of a security incident involving customer information systems.
• Cooperation obligations covering forensic investigation, scope assessment, impacted data fields, and log access.
• Subcontractor flow-down provisions ensuring the same obligations apply to any downstream parties with access to customer information.
• Right to obtain security artifacts such as SOC 2 reports, penetration test summaries, or equivalent documentation.

Strongly recommended:

• Clear allocation of responsibilities for client notification. The amended rule permits a service provider to notify affected individuals on the RIA's behalf through a written agreement, but the RIA retains ultimate responsibility for ensuring that notice is timely and compliant.
• Annual incident response tabletop participation, at minimum for critical vendors.

6. A 30/60/90-Day Implementation Plan for Lean Teams

Days 1 to 30: Establish the Foundation

Build your vendor inventory and identify every touchpoint where customer information is accessed, stored, or transmitted. Draft an incident response program outline that includes defined roles, escalation paths, and a decision tree for notification determinations. Set up your evidence folder structure (see the exam binder section below) so documentation practices are embedded from day one.

Days 31 to 60: Operationalize and Formalize Contracts

Update vendor contract templates and prioritize negotiations with critical providers first. Implement a 72-hour vendor notification workflow, using a shared inbox and ticketing system to ensure nothing falls through the cracks. Build your 30-day client notification workflow, including draft notice templates and an internal approval chain.

Days 61 to 90: Test, Document, and Close Gaps

Run at least one tabletop exercise covering both an internal incident and a vendor-originated scenario. Capture all artifacts from the exercise: the agenda, participant list, outcomes, and any remediation items identified. Close gaps, update policies accordingly, and document the revision history with version control.

7. Your Reg S-P Exam Binder

When the SEC comes knocking, a well-organized evidence package goes a long way. The structure does not need to be elaborate, but it does need to be complete and current. Not every item below is mandated by the rule. The rule requires the written policies and procedures, the incident response program, service provider oversight, and the records documenting them; training, tabletop exercises, and periodic program reviews are not separately required, but they are the evidence examiners look for that the required program is reasonably designed and actually operating.

• Policies and Procedures: Your safeguards and privacy policy, your incident response program, and your data classification criteria mapping the rule's definition of "sensitive customer information" to the specific data elements your firm holds.
• Vendor Oversight: Your vendor inventory with risk tiering, a contract clause tracker showing which agreements include the 72-hour notification requirement (and what alternative assurance is on file where they do not), and SOC reports or security review documentation along with evidence of follow-up on any identified issues.
• Training: Annual training logs and materials, along with an incident escalation quick-reference guide for staff.
• Testing and Reviews: Tabletop exercise documentation with remediation items, and annual program review notes with explanations for any changes made.
• Incident Log: A running log of incidents including near-misses, the decisions made, and any notifications issued.

The theme across all of this is demonstrating that your program is real, implemented, and monitored. Not theoretical.

8. Frequently Asked Questions

Do I always have to notify clients within 30 days?

The rule requires notice as soon as practicable, but no later than 30 days after the firm becomes aware that customer information was, or is reasonably likely to have been, accessed or used without authorization. There is no separate investigation period: the firm may conduct a reasonable investigation to decide whether notice is required, but that investigation has to be completed within the 30 days. Notice can be skipped only if the firm determines that sensitive customer information has not been, and is not reasonably likely to be, used in a manner that would result in substantial harm or inconvenience, and it can be delayed only on a written determination by the U.S. Attorney General on national security or public safety grounds. The presumption under the rule tilts toward notification, particularly when there is uncertainty about which individuals were affected; in that case the firm must notify everyone whose sensitive customer information was on the affected system.

Can a vendor send client notifications on our behalf?

Yes. The amendments permit a written agreement under which a service provider notifies affected individuals on the RIA's behalf. However, the responsibility for ensuring that notice is provided, and that it meets the regulatory requirements, remains squarely with the RIA.

What is the biggest implementation pitfall for small RIAs?

Having policies that articulate the right principles but lack the operational infrastructure to back them up. The two most common failure points are vendor arrangements that do not address the 72-hour notification requirement and the absence of a tested workflow to meet the 30-day client notice window. Policies without execution are just paper.