Most RIA firms, when asked whether they have an Incident Response Plan, say yes. Then an SEC examiner asks to see it, and one of three things happens: the firm produces a document that was downloaded from the internet with the firm’s name in the header and never actually customized; the firm produces a cybersecurity policy that mentions “incident response” but contains no operational procedures; or the firm produces nothing at all because the document that was supposed to exist doesn’t.
Under Reg S-P’s 2024 amendments (SEC Release No. 34-100155), having a Written Incident Response Plan is not optional. Having one that passes examiner scrutiny requires understanding what an IRP actually is, what it must contain, and what the difference is between a compliant program and a document that merely uses the right vocabulary.
What an Incident Response Plan Actually Is
An Incident Response Plan is a written operational document that tells your firm exactly what to do — step by step, person by person — when a security event involving customer data occurs. It is not a cybersecurity philosophy statement. It is not a list of best practices. It is a procedure manual for a specific type of emergency, and it should be specific enough that a person who has never thought about data security before could follow it in a crisis.
The IRP exists because data breaches are not theoretical. They happen to small RIA firms. They happen through phishing emails, through compromised vendor systems, through employees clicking the wrong link, through ransomware that encrypts your client files. When a breach occurs, the last thing you want is a team that has no idea what to do next and a regulatory clock that started ticking the moment you became aware of the incident.
A compliant IRP under Reg S-P defines your firm’s response across the full incident lifecycle: detection, assessment, containment, eradication, recovery, customer notification, and post-incident review. Every phase requires documented procedures with assigned responsibility — and the entire program requires evidence of periodic testing to demonstrate that it actually functions.
What a Compliant Reg S-P IRP Must Include
The SEC’s 2024 amendments to Reg S-P specify that covered institutions must maintain written policies and procedures for responding to incidents that involve unauthorized access to or use of customer information. Regulatory guidance and examiner practice have clarified what that means in operational terms. A compliant IRP must address all of the following:
Scope and Trigger Definitions
Your IRP must define what constitutes a security incident requiring activation of the plan. Not every IT issue is an incident. Your firm needs clear definitions of event types that trigger the IRP — unauthorized access, data exfiltration, ransomware infection, phishing compromise of a credential with customer data access, vendor notification of a breach affecting your data — versus IT issues that require routine remediation but do not rise to the level of an incident under the plan.
Roles and Responsibilities
Every phase of your incident response requires a named role and a named person. For a small RIA, this typically means the principal adviser, a designated IT contact (which may be an outsourced MSP), a compliance officer (which may be the same person or an outsourced CCO), and outside legal counsel for incidents with significant regulatory notification implications.
Generic IRPs list job titles. Compliant IRPs list actual people — or at minimum actual roles with contact information — so that when an incident occurs at 11pm on a Friday, there is no ambiguity about who gets called first.
Detection and Initial Assessment Procedures
How does your firm detect a potential incident? What monitoring is in place? Who receives alerts? What happens in the first hour after detection — who is notified, what initial containment steps are taken, how is the scope of the incident assessed? The IRP must walk through this phase with specificity.
Containment and Eradication Procedures
Once an incident is confirmed, what does your firm do to stop the bleeding? Containment means different things for different incident types — isolating a compromised device, revoking compromised credentials, suspending a vendor’s access while an investigation proceeds. Your IRP should address the incident types most relevant to your specific technology environment.
Customer Notification Decision Protocol
Reg S-P requires notification to affected customers within 30 days of discovering a breach. Your IRP must include a decision protocol for determining when the notification requirement is triggered, who makes that determination, and what the notification process looks like. This section of the IRP feeds directly into your 30-Day Customer Notification Procedure, and the two documents must be consistent.
Regulatory Notification Requirements
In addition to customer notification, certain incident types require notification to regulators. Your IRP must address when and how regulatory notifications are made and who is responsible for drafting and submitting them.
Recovery Procedures
What does returning to normal operations look like? How does your firm verify that the threat has been eliminated before restoring full system access? Who authorizes the return to normal operations? Recovery without verification is how firms get re-compromised within weeks of an initial incident.
Post-Incident Review
After every incident, your firm should conduct a documented review: what happened, what the firm did well, what needs to change, and what the IRP update requirements are. This review documentation is part of your six-year recordkeeping requirement under Reg S-P and is evidence that your compliance program is living and operational, not a shelf document.
Testing Protocol
An IRP that has never been tested is not a compliant IRP. The SEC expects covered firms to periodically test their incident response capabilities. For small RIAs, this typically means tabletop exercises — walking through a simulated incident scenario with the people responsible for executing the plan — at least annually. The testing must be documented, and deficiencies identified during testing must be addressed and recorded.
Common Mistakes RIA Firms Make
The Generic Template Problem
This is the most common failure mode. A firm purchases a $300 compliance template package, sees a document titled “Incident Response Plan,” inserts the firm name into the header fields, and considers the box checked. The document contains generic language about “the organization” and “the CISO” and “the IT department” — none of which exists at a four-person RIA advisory firm.
An SEC examiner reviewing that document knows within 90 seconds that it was not built for the firm. The language doesn’t match the firm’s size, the roles don’t match the firm’s structure, and the technology references don’t match the firm’s actual systems. Generic templates do not pass examination. They generate deficiency findings.
Outdated Contact Information
An IRP that lists the right roles but contains outdated phone numbers, departed personnel, or vendors that were replaced two years ago is operationally useless in an actual incident — and is evidence of a compliance program that nobody is actually maintaining. Reg S-P requires that your program be kept current. Annual review of contact information is a minimum maintenance standard.
No Testing History
A firm that produces an IRP in response to an examiner request but has no documentation of ever having tested it has a document, not a program. The SEC’s 2024 amendments reflect a clear intent to require operational programs, not paper compliance. If you cannot demonstrate that personnel know what to do under the plan, the plan does not meet the standard.
Misalignment with Actual Technology Environment
Your IRP must address the systems you actually use. If your firm uses Orion for portfolio management, Redtail as your CRM, Schwab as your primary custodian, and Microsoft 365 for email and document storage, those systems need to be reflected in your incident response procedures. An IRP written for a firm with on-premises servers and a dedicated IT department is not a compliant IRP for a cloud-native, fully outsourced technology environment.
Confusing IT Policy with Incident Response
Many firms have acceptable use policies, password policies, and cybersecurity awareness training documentation, and they assume this constitutes an IRP. It does not. IT policies are preventive controls. An IRP is a reactive procedure. They address different regulatory requirements and cannot substitute for each other.
What SEC Examiners Are Looking For
When an examiner reviews your IRP, they are not reading it as a compliance professional hoping you pass. They are reading it as someone trained to identify gaps. They look for three things: specificity (does this document name actual people and actual systems?), operationality (could someone execute this under pressure?), and currency (has anyone touched this document in the last 12 months?). A document that fails on any of these three dimensions generates a finding.
- Is the plan written and current (reviewed within the past 12 months)?
- Does it address your firm’s specific technology environment, not a generic environment?
- Are roles and responsibilities assigned to specific personnel with current contact information?
- Does it include the 30-day customer notification trigger and procedure?
- Is there evidence of periodic testing — tabletop exercises, drill documentation, or after-action reports?
- Does it address your firm’s specific service providers and the 72-hour notification requirement for vendor-side incidents?
- Are post-incident reviews documented?
- Is the IRP integrated into the firm’s broader Reg S-P compliance program, or does it exist in isolation?
The last point matters more than people realize. A standalone IRP that contradicts your Vendor Oversight Policy, references a privacy notice that hasn’t been updated in five years, or has no connection to your recordkeeping framework is a compliance program with structural gaps. Examiners review the documents together, not in isolation.
If your firm’s IRP is a downloaded template or hasn’t been reviewed in over a year, it will not pass this test. See what a firm-specific, exam-ready IRP looks like.
The Real Risk: Examination vs. Actual Incident
There are two risk scenarios that a non-compliant or deficient IRP creates:
The first is examination risk: an examiner arrives, your IRP fails review, you get a deficiency letter, you spend six months in remediation mode while also running your advisory practice, and you pay your attorney to correspond with the SEC on your behalf.
The second is actual breach risk, and it is far worse. If a breach occurs and your firm does not have a functioning IRP, the consequences cascade. You do not notify customers within 30 days because you have no procedure for making that determination. You cannot demonstrate reasonable care to regulators because your program was inadequate. You cannot demonstrate reasonable care to plaintiffs’ attorneys because your documentation shows you had no plan. The financial exposure from an actual breach at a firm with no IRP is categorically different from the cost of getting compliant before anything happens.
The Difference Between a Real IRP and a Document That Just Says “IRP”
A real IRP passes the operational test: take a person responsible for executing it, put them in a simulated incident scenario, and see whether they can follow the plan. A real IRP results in the right people being notified, the right containment steps being taken, and the 30-day notification clock being properly tracked.
A document that just says “IRP” fails the operational test. It cannot be followed because it is not specific enough to follow. It does not help in a crisis. It does not satisfy an examiner. It exists to check a box, and it does not even successfully check the box.
Building a real IRP requires knowing your firm’s systems, vendors, personnel, and data environment. It requires regulatory expertise to ensure all required elements are addressed. It requires integration with your other Reg S-P compliance documents. It cannot be downloaded from the internet.
Getting Your IRP Right Before June 3, 2026
The deadline is June 3, 2026. The SEC has told you this is an examination priority. Enforcement is already occurring. The question is not whether you need a compliant IRP — it is whether you will have one before the examiner comes or after.
Getting the IRP done correctly means getting it done in a way that reflects your actual firm: your vendors, your technology, your personnel, your data environment. It means building it as part of a complete Reg S-P compliance program — not as an isolated document — so that when the examiner reviews all five required deliverables together, they are consistent and coherent.
Get your firm’s complete Reg S-P compliance package — including a firm-specific Written Incident Response Plan, all four other required deliverables, attorney-reviewed and delivered in 3 business days — at mrfixitgeeks.com/reg-sp-compliance.