Reg S-P Compliance for RIAs Using AI:
The 2024 Amendments and What They Mean

What Changed in May 2024

Regulation S-P was originally adopted in 2000 under the Gramm-Leach-Bliley Act (GLBA). For 24 years, its core obligation was straightforward: broker-dealers and investment advisers must adopt written policies to safeguard customer nonpublic information (NPI) and properly dispose of consumer report information. The rule was written in an era of paper records and early digital systems. It did not contemplate AI, cloud infrastructure, or third-party data processors with continuous API access to client data.

Published in the Federal Register on June 3, 2024 (89 FR 47688), the final amendments are substantive. The six principal changes:

1. Mandatory written incident response program. Under 17 C.F.R. § 248.30(a)(3), covered institutions — which include all SEC-registered investment advisers — must develop, implement, and maintain a written incident response program "reasonably designed to detect, respond to, and recover from unauthorized access to or use of customer information." The program must include procedures for assessment, containment and control, and notification. This is not a BYOD-style recommendation — it's a written, maintained, testable requirement.
2. 30-day client breach notification. If sensitive customer information is accessed or used without authorization, RIAs must provide notice to each affected individual no later than 30 days after becoming aware of the incident. The threshold is "reasonably likely to have occurred" — not confirmed. See Section 2 below for the exact mechanics.
3. 72-hour service provider notification requirement. Service providers — including AI vendors — must notify the RIA within 72 hours of becoming aware of a breach involving customer information. FINRA's cybersecurity advisory (Exchange Act Release No. 35193) confirms this applies broadly: any vendor with access to customer data is in scope.
4. Expanded scope of protected information. The amendments broaden what counts as "customer information" to include data received from third-party sources: placement agents, feeder funds, fund administrators, and — critically for AI deployments — any data injected into an AI system's context from external sources.
5. 5-year recordkeeping. RIAs must maintain written records of all compliance activities — breach investigations, notification determinations, service provider agreements, policies and procedures — for 5 years, with the first 2 years in an easily accessible location.
6. Compliance deadlines. Large RIAs (AUM ≥ $1.5 billion) must comply by December 3, 2025. Smaller RIAs (AUM < $1.5 billion) must comply by June 3, 2026. The SEC named amended Reg S-P in its 2026 Examination Priorities as an active enforcement focus.

The 30-Day Breach Notification Rule

The notification requirement is the most operationally demanding element of the amendments. 17 C.F.R. § 248.30(a)(4) sets out three mechanics that compliance officers need to understand precisely:

The triggering standard: "reasonably likely to have occurred"

You do not need a confirmed breach to trigger the 30-day clock. The clock starts when your firm becomes aware that unauthorized access has occurred or is reasonably likely to have occurred. This matters for AI systems that log client-specific context: if your AI vendor's logs are exposed in a misconfiguration event, even without confirmed exfiltration, the 30-day window may already be running.

The notification exception: reasonable investigation

Notification is not required if, after a reasonable investigation, the RIA 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." Two obligations follow from this: (1) the investigation must be reasonable — undocumented conclusions don't qualify; and (2) if the investigation is inconclusive, the presumption is notification, not silence. The SEC's final adopting release states this explicitly: "a covered institution must provide a notice unless it determines notification is not required following a reasonable investigation."

If you can't identify affected individuals

If a breach occurred but the RIA cannot identify which specific individuals were affected, the rule requires notifying all individuals whose sensitive customer information resided in the affected system. For an AI deployment where all client data is pooled in a shared retrieval index, this means a single incident potentially requires firm-wide notification. Tenant isolation — by architecture, not policy — is the only structural defense here.

The vendor chain

Your AI vendor's 72-hour notification obligation to you is a contractual and regulatory requirement you must establish and enforce. The final rule states that RIAs must "establish, maintain, and enforce written policies and procedures reasonably designed to require oversight, including through due diligence and monitoring of service providers." If your AI vendor contract does not include a 72-hour breach notification clause, you are already non-compliant with the oversight requirements of the amended rule.

Where AI Workflows Expose RIAs to Reg S-P Violations

Most RIA compliance programs were not written with AI in scope. The exposure points are structural — not addressable by updating your privacy notice.

1. Vendor data leakage through shared AI infrastructure

When an RIA uses a general-purpose AI assistant — commercial or internal — that is not tenant-isolated, client NPI can cross data boundaries. A retrieval query that searches across all clients' documents, or a context window that includes multiple clients' account data, creates cross-tenant exposure. If that system is ever breached, the firm cannot isolate which clients were affected — triggering the firm-wide notification scenario described in the final rule. The amended Reg S-P expanded scope to include data received from third-party sources, which means client data injected from external sources (custodians, fund admins) into an AI context is protected information regardless of how it arrived.

2. Hallucinated client-specific responses

An AI system that fabricates client account details, invents regulatory filings, or generates invented portfolio positions can cause a different kind of Reg S-P violation: distributing materially false information under your fiduciary duty. Under Advisers Act § 206, RIAs have a duty of care in client communications. An AI-generated client email that contains fabricated specifics about the client's account — even if the fabrication is "confident" — is a compliance event. It is not sufficient that the AI was confident. The output must be grounded. NIST AI RMF 1.0 identifies confabulation (hallucination) as a primary risk category for AI systems deployed in consequential contexts, and its Manage function requires controls to detect and mitigate ungrounded outputs before they reach end users.

3. Unencrypted prompt logs and inference traces

Every query submitted to an AI system — including the client-specific context injected with it — is a log entry. If your AI vendor retains prompt logs, those logs contain client NPI. If those logs are not encrypted, not WORM-protected, and not subject to your 5-year retention and accessibility requirements, you have a recordkeeping gap under the amended rule. Many standard AI API contracts do not provide the log access, immutability guarantees, or deletion rights required for SEC examination compliance.

4. AI systems as unscreened service providers

The amended rule's service provider oversight requirements apply to any vendor that accesses customer information. An AI provider that ingests client data through an API is a service provider under 17 C.F.R. § 248.30(a)(3). That means: (a) you must conduct due diligence before onboarding them; (b) you must monitor their security practices continuously; (c) their contract must require 72-hour breach notification to you; and (d) you remain responsible for ensuring affected clients are notified even if the breach originated at the vendor's infrastructure. Most standard AI vendor terms of service do not include any of these provisions.

The 5 Controls Sturna Enforces

Sturna's architecture addresses each of the Reg S-P exposure vectors above through five layered controls. These are not policy documents — they are enforced at the infrastructure level, independently of operator configuration, and produce verifiable artifacts for SEC examination.

For independent verification evidence, security documentation, and SOC 2 observation reports, see the Sturna Trust & Security Center →

For benchmark data on RIA compliance accuracy vs. unguarded AI: see Sturna vs. LangChain / AutoGen / CrewAI →

How to Audit Your Current AI Stack

Five questions to run against every AI vendor currently in your advisory workflow:

1. Is your contract with this vendor Reg S-P compliant? Does it include a 72-hour breach notification clause? Does it grant you audit rights over their security practices? If not, the vendor oversight requirements of 17 C.F.R. § 248.30(a)(3) are not met.
2. Is client data tenant-isolated? Can a retrieval query from Client A's session access data from Client B's files? If the system uses a shared embedding index across clients, you have a cross-tenant NPI risk that produces firm-wide notification exposure on any breach.
3. Are prompt logs retained, encrypted, and WORM-protected? Every query that includes client NPI is a customer information record under the amended rule. If the vendor retains those logs, they are subject to your retention, accessibility, and disposal requirements — and you need contractual access to them for examination purposes.
4. Can you produce a grounding artifact for any AI-generated client communication? In an SEC examination, "the model said so" is not an acceptable basis for a factual claim in a client communication. You need to be able to show the source, the retrieval context, and the verification applied. If your current AI stack doesn't produce this, you have a fiduciary documentation gap.
5. Does your incident response program include AI-specific scenarios? A pre-2024 incident response plan that covers network breaches but not AI vendor breaches, prompt injection attacks, or hallucination-induced disclosure events does not satisfy the amended rule. Update it before your compliance deadline.

Common Questions from CCOs