How to Build a Reg S-P Incident Response Plan That Won't Fall Apart During an Exam

What the SEC requires

Under amended Rule 248.30(a)(4), your firm must adopt written policies and procedures for an incident response program that is "reasonably designed" to detect unauthorized access to customer information, respond to it, and recover from it.

That phrase "reasonably designed" is doing a lot of work. The SEC deliberately avoided prescribing specific technologies or formats. What they care about is whether your program makes sense for your firm and whether you can show it works. A solo RIA with 50 clients looks different than a firm with 5,000 clients and a dozen offices, but the core pieces are the same.

The four things your IRP must cover

1. Detection

How does your firm identify that something went wrong? This is about monitoring and alerting. It could mean:

• Email account compromise alerts from your provider
• Failed login monitoring
• Unusual file access patterns
• Employee reporting channels (someone notices something odd and knows who to tell)
• Alerts from your endpoint protection or managed detection service

You don't need a SOC (security operations center). You need a clear answer to the question: "How would we know?"

2. Assessment and containment

Once you know something happened, what do you do next? Your plan should cover:

• Who leads the response (name or role, not "TBD")
• How you assess the scope: what information was involved, how many people are affected, whether it's ongoing
• Containment steps: disabling compromised accounts, isolating affected systems, preserving evidence
• When to involve outside help (legal counsel, forensics firm, law enforcement)

3. Notification

If sensitive customer information was or is "reasonably likely" to have been accessed without authorization, you must notify affected individuals within 30 days of becoming aware. Your plan needs to spell out:

• Who makes the notification decision
• The "no substantial harm" exception: if you determine the information hasn't been and isn't reasonably likely to be misused, you can skip notification. But you have to document that determination.
• What goes in the notice: description of the incident, types of information involved, FTC contact info, whether you're offering credit monitoring
• How you send it: postal mail is the default. Email is acceptable if the individual has agreed to electronic communications.
• State law obligations that may run in parallel

4. Recovery

After the immediate response, what happens? Your plan should address:

• Remediation of the vulnerability that was exploited
• Review and update of policies and procedures based on lessons learned
• Communication with affected clients beyond the required notice
• Reporting to your cyber insurance carrier

How to test it

A plan that sits in a binder untested is worse than useless -- it gives you false confidence. The SEC checks whether your program is actually implemented, and testing is part of that.

The simplest form of testing is a tabletop exercise. Pick a scenario. Sit down with your team (or just yourself, if you're solo). Walk through it.

Good scenarios for RIAs:

• Email compromise: An employee's email account is accessed by an unauthorized party. Client names, account numbers, and SSNs are visible in email threads. What do you do?
• Vendor breach: Your CRM provider notifies you that their systems were breached and client data may have been exposed. Now what?
• Ransomware: You come in Monday morning and your files are encrypted. You have backups (you do have backups, right?). Walk through the response.
• Lost laptop: A team member's laptop with client data is stolen from their car. Full disk encryption was enabled. Or was it?

Run at least one tabletop per year. Document what happened, what you learned, and what you changed afterward. Examiners love seeing that paper trail.

Common mistakes

Using your IT vendor's plan as your own

Your managed IT provider probably has an incident response plan. Good for them. The SEC's requirements are on you, the RIA. You can incorporate your IT vendor's capabilities, but the assessment, notification decision, and documentation are your responsibility.

Setting the bar at "confirmed theft"

The notification trigger is "reasonably likely to have been accessed or used without authorization." Not confirmed data exfiltration. Not proof of misuse. If you wait for certainty, you've probably already blown your 30-day window.

Forgetting about the people part

An IRP is a communication plan as much as a technical one. Who calls clients? Who talks to the SEC? Who handles the press if it gets that far? Work this out before you're in the middle of it.

Writing it once and filing it away

Your IRP should be reviewed whenever your business changes: new technology, new vendors, new offices, staffing changes. At minimum, review it alongside your annual compliance review.

Fiduciary duty and incident response

This part gets overlooked. As an RIA, you owe a fiduciary duty to your clients. The SEC has framed failures to safeguard client information as breaches of that duty, which gives them enforcement hooks beyond Reg S-P. Your IRP is not a checkbox. It is part of how you meet your obligation to the people whose money you manage.

What examiners actually look for

Incident response has been in the SEC exam priorities since 2020. When they show up, they ask for:

• Your written IRP
• Evidence that staff know about it (training records)
• Evidence that you've tested it (tabletop exercise documentation)
• A list of incidents and how they were handled (even if the answer is "none")
• Your vendor contracts showing the 72-hour notification clause

If you can produce all five, you're in good shape. If you can't, expect a deficiency letter.

Where to start

You do not need a 40-page document. You need a plan that answers the right questions and that your people can actually follow when things go wrong. Start with the four components, assign roles, run a tabletop, and write down what happened.

Or let a platform handle the structure while you focus on the decisions. See how BlackSheep supports incident response planning.