How to Build a Reg S-P Incident Response Plan: A Step-by-Step Guide for RIAs

Your Firm Got Breached. Now What?

In September 2015, the SEC fined R.T. Jones Capital Equities Management $75,000 after a data breach exposed the personal information of roughly 100,000 clients. The firm, a registered investment adviser in St. Louis, had no written cybersecurity policies. No incident response procedures. No encryption on the server that was compromised.

The fine itself was small. The reputational damage, the client attrition, and the cost of remediation dwarfed it.

Since then, the SEC has made cybersecurity a top examination priority. The amended Regulation S-P, adopted in July 2023 and effective June 3, 2025, now requires every RIA to maintain a written incident response program. Small entities (firms with under $1.5 billion in AUM or fewer than 10 employees) have an extended compliance deadline of approximately December 2026.

That deadline is closer than it feels. And "we'll figure it out if something happens" is not a plan the SEC will accept.

This guide walks you through building a Reg S-P incident response plan that satisfies the SEC's requirements, fits a small firm's reality, and costs you nothing but a few hours of focused work.

What the SEC Requires (and What It Doesn't)

The amended Reg S-P adds a new requirement under Rule 248.30: every covered institution must develop, implement, and maintain written policies and procedures for an incident response program.

Your program must be "reasonably designed" to detect, respond to, and recover from unauthorized access to or use of customer information. Specifically, the rule requires procedures for:

• Detection of unauthorized access to or use of customer information
• Response to contain and control the incident
• Recovery of affected systems and data
• Documentation of the incident and your firm's response
• Notification to affected individuals within 30 days of detection

The SEC is not prescribing a specific format. There is no mandatory template, no required page count, no certification process. Your plan needs to be appropriate for the size and complexity of your firm.

For a solo adviser with 50 clients and a laptop, the plan looks different than it does for a 200-person wirehouse. The SEC knows this. Your plan should reflect your actual operations, not a Fortune 500 playbook copied from the internet.

Step 1: Define What Counts as an "Incident"

Before you can respond to an incident, you need to know what qualifies as one. This sounds obvious. In practice, most small firms skip this step and pay for it later.

Your plan should define a cybersecurity incident as any event that results in unauthorized access to, use of, or disruption of customer information or the systems that store it.

Examples to include in your definition:

• An employee clicks a phishing link that installs malware on a firm device
• A laptop or phone containing client data is lost or stolen
• You discover an unauthorized login to your CRM, custodian portal, or email account
• A vendor that handles client data on your behalf reports a breach
• Ransomware encrypts files on your network

Also define what does not count as an incident. A failed login attempt from an unknown IP address is suspicious activity worth logging, but it is not a breach. Drawing this line in advance prevents you from either overreacting to routine events or ignoring early warning signs.

Step 2: Assign Roles and Responsibilities

The SEC wants to know who does what when something goes wrong. For a small firm, this does not require a 15-person incident response team.

At minimum, designate:

Primary Incident Responder: This is you, the firm owner or CCO. You make the call on whether an event qualifies as an incident. You coordinate the response. You approve client notifications.

IT Support Contact: Your managed service provider, IT consultant, or the tech-savvy person you call when something breaks. This person handles containment and forensics. Get their after-hours phone number in the plan, not just their email.

Legal/Compliance Contact: An attorney or compliance consultant you can reach on short notice. You may not need one for every incident, but when a breach triggers notification obligations, you want legal guidance before sending letters to clients.

Vendor Contact List: For each third-party vendor that touches client data, document who to contact and how. Your custodian, your CRM provider, your portfolio management software, your cloud storage. If a vendor is breached, you need to reach their security team the same day, not spend three hours looking for a phone number.

Write these names and contact details directly into the plan. Update them whenever a contact changes.

Step 3: Build Your Detection Procedures

You cannot respond to an incident you do not know about. Detection procedures describe how your firm identifies potential breaches.

For most small RIAs, detection comes from a handful of sources:

Automated alerts. Enable login notifications on every system that holds client data: your email provider, CRM, custodian portals, cloud storage. If someone logs in from a new device or location, you should get an alert. Most platforms offer this for free in their security settings.

Employee reporting. If you have staff, train them to report suspicious emails, unexpected system behavior, or anything that seems off. A five-minute conversation during your next team meeting covers this. Document that the training happened.

Vendor notifications. Your service providers are required to notify you if they experience a breach affecting your data. The amended Reg S-P vendor management requirements make this your responsibility to track.

Routine monitoring. Check your system logs weekly. For a small firm, this can be as simple as reviewing login history on your email account and CRM every Monday morning. Note anything unusual.

Write these detection methods into your plan. Be specific. "We monitor our systems" is not a procedure. "The CCO reviews login activity for all firm email accounts and the Redtail CRM portal every Monday morning" is a procedure.

Step 4: Document Your Response and Containment Steps

When you detect an incident, you need a clear sequence of actions. Write them in order.

Immediate response (first 60 minutes):

1. Confirm the incident is real. Check logs, talk to your IT support, verify the alert is not a false positive.
2. Document the time of detection and everything you know so far. Use a simple incident log. A spreadsheet works. A Word document works. The format does not matter. The record does.
3. Contact your IT support. Get them working on containment.

Containment (first 24 hours):

1. Isolate affected systems. If a workstation is compromised, disconnect it from the network. If an email account is compromised, change the password and revoke all active sessions.
2. Preserve evidence. Do not wipe or rebuild systems until your IT provider has captured forensic data. If you destroy the evidence, you cannot determine what was accessed.
3. Assess the scope. Which systems were affected? What client information was stored on those systems? How many clients are potentially impacted?

Recovery (1-7 days):

1. Restore systems from clean backups. If you do not have backups, this is the painful moment where that oversight becomes expensive.
2. Patch the vulnerability that allowed the breach. If it was a phishing attack, reset all credentials and enable multi-factor authentication.
3. Verify that the attacker no longer has access. Your IT provider should confirm this in writing.

Each of these steps should name the person responsible. "The Primary Incident Responder confirms the incident" is better than "the incident is confirmed."

Step 5: Set Up Your Notification Process

The amended Reg S-P requires you to notify affected individuals "as soon as practicable" but no later than 30 days after you become aware that unauthorized access to customer information has occurred or is reasonably likely to have occurred.

Your notification must include:

• A description of the incident in general terms
• The type of information that was or may have been accessed
• Contact information for your firm so clients can ask questions
• Information about steps clients can take to protect themselves (credit monitoring, password changes, fraud alerts)

Draft a template notification letter now, while nothing is on fire. Trying to compose a breach notification under stress with a compliance deadline counting down is a recipe for mistakes.

Here is sample language to start with:

Dear [Client Name],

We are writing to inform you of a security incident that may have involved your personal information. On [date], [firm name] discovered [brief description of what happened]. We took immediate steps to contain the incident and engaged [IT security firm/forensic investigator] to assess the impact.

Based on our investigation, the following types of information may have been accessed: [list specific data types].

We recommend that you [specific protective steps: place a fraud alert, review account statements, enroll in credit monitoring]. We have arranged complimentary credit monitoring through [provider] for [time period]. To enroll, visit [URL] or call [number].

If you have questions, please contact [name] at [phone] or [email].

State-level breach notification laws may impose additional requirements on top of the SEC's 30-day rule. Most states have their own notification timelines and rules about what triggers a notification obligation. Check the laws in your state and any state where your clients reside.

Your plan should include a checklist: SEC notification requirements, state notification requirements, and any contractual notification obligations (some custodians require you to notify them within a specific timeframe).

Step 6: Create Your Documentation Protocol

The SEC will not ask whether you had a breach. They will ask what you did about it and whether you documented it.

For every incident, maintain an incident file that includes:

• Date and time of detection
• Who reported or discovered the incident
• Description of the incident and affected systems
• Client information potentially accessed
• Containment and recovery actions taken, with timestamps
• Communications sent to clients, regulators, or law enforcement
• Root cause analysis
• Changes made to prevent recurrence

Keep these records for at least five years. The SEC's books and records requirements under Rule 204-2 apply. A dedicated folder in your compliance files, labeled by incident date, is sufficient.

If you go through a year with zero incidents, document that too. A brief annual note stating "No incidents detected during [year]" shows examiners that you were paying attention, not that nothing was in place.

Step 7: Conduct a Post-Incident Review

After every incident, hold a review within 30 days of resolution. For a solo practitioner, this means sitting down with your IT contact and walking through what happened.

Answer three questions:

1. Did our detection methods work? Did we catch this through our monitoring, or did we learn about it from someone else? If detection failed, what do we add?
2. Did our response plan work? Were the steps clear? Did we follow them? Where did we improvise, and should those improvisations become part of the plan?
3. What do we change? Update the incident response plan based on what you learned. New procedures, additional training, different vendor controls, stronger authentication.

Document the review and the resulting changes. This creates a record of continuous improvement that examiners look for.

How to Run a Tabletop Exercise

A plan that has never been tested is a plan that will fail under pressure. The SEC expects your incident response program to be "reasonably designed," and a plan you have never practiced does not meet that bar.

A tabletop exercise is a low-cost, low-stress way to test your plan. You do not need to simulate a real attack. You need to walk through a scenario and see if your response makes sense.

Set up (15 minutes): Pick a scenario. A stolen laptop with client data. A phishing email that compromised your email account. A ransomware attack on your network. Write 3-4 sentences describing what happened.

Walk through (30-45 minutes): Sit down with everyone named in your incident response plan. Read the scenario. Then go step by step through your response procedures.

Ask at each step:

• Do we know who is responsible for this action?
• Can we reach our contacts right now? (Try calling. See if the numbers work.)
• Do we have the access and tools we need?
• How long would this step take in reality?

Debrief (15 minutes): What went well? What was confusing? What was missing from the plan? Write down the findings.

Update the plan based on what the exercise revealed. Document that the exercise happened, who participated, and what changed.

Run a tabletop exercise at least once a year. If you hire new staff or change a major vendor, run one after that transition too.

Common Mistakes Small RIAs Make

Writing a plan and never reading it again. The SEC's requirement is not to have a document. It is to have a program. That means your plan should be a living document you review and update at least annually.

Copying a large firm's plan. A 50-page incident response plan written for a broker-dealer with 500 employees will not help you. It will confuse you, and the SEC examiner will see immediately that it does not reflect your operations. Your plan should match your firm.

Forgetting about vendors. If your CRM provider gets breached and client data is exposed, that is your problem. Your incident response plan needs to address vendor incidents, not just breaches at your own firm.

No documentation of "non-events." If you investigate a suspicious email and determine it was not a breach, write that down. A log of investigated alerts shows examiners that your detection procedures are working. An empty file with no entries looks like nobody was watching.

Waiting until after a breach to draft notification letters. You do not want to write your first breach notification letter during an active incident. Draft templates now. Customize them later if you need to send one.

Skipping the tabletop exercise. It takes less than two hours once a year. It is the single best way to prove your plan is more than paper.

Build Your Plan Today

The December 2026 compliance deadline is not a soft suggestion. The SEC has made cybersecurity a priority in its examination program, and small firms without required documentation face deficiency letters, fines, and the kind of regulatory attention that consumes months of your time.

Building a Reg S-P incident response plan is not a weekend project if you start from scratch. It requires understanding the rule, translating it into procedures that fit your firm, and documenting everything in a format the SEC expects.

RegShield generates a complete, customized incident response plan for your firm in minutes. It covers every requirement outlined in this guide, including detection procedures, containment steps, notification templates, documentation protocols, and post-incident review frameworks. All for $299, a fraction of what a compliance consultant charges for a single document.

Check your readiness or get started with RegShield and cross incident response off your compliance list today.