🔑 KEY TAKEAWAYS
- Any vendor breach triggers your IRP – Even a split-second unauthorized access to a service provider's system requires you to activate your Incident Response Plan within 72 hours
- You can't prove it? You notify everyone – If your vendor can't show exactly what data was accessed, you must assume ALL client data in that system was compromised
- Well-designed IRPs have off-ramps – A reasonable investigation that proves no sensitive data was accessed (or wasn't reasonably likely to be accessed) lets you avoid customer notifications
- Vendor logging is your lifeline – Without granular, timestamped logs from your service providers, you're flying blind and facing worst-case notification scenarios
- The trend is accelerating – Third-party breaches increased 15% in 2024, with major incidents at SitusAMC, Conduent, Snowflake, and Discord affecting millions
- Prevention is your only defense – Update vendor contracts NOW to require 72-hour notifications, detailed logging, and cooperation during investigations
If you're an SEC-registered RIA, you've probably heard about Regulation S-P's new Incident Response Plan (IRP) requirement by now. You might have even started drafting policies or attended a webinar about the December 2025 and June 2026 compliance deadlines.
But here's what most compliance consultants aren't emphasizing: your IRP is far easier to trigger than you think.
In fact, there's one specific provision in the rule that's going to catch a lot of RIAs off guard when it takes effect—and it has nothing to do with whether your systems were breached or whether any client data was actually compromised.
It's the service provider notification trigger.
Let me explain why this matters—and what you can do about it right now.
The Service Provider Notification Rule: A Hair Trigger for Your IRP
Under the amended Regulation S-P, your written policies and procedures must be "reasonably designed to ensure" that service providers notify you within 72 hours after becoming aware of a breach in security resulting in unauthorized access to a customer information system maintained by the service provider.
Here's the critical part that's easy to miss: any time a service provider sends you a breach notification, your IRP is automatically triggered—meaning you must activate your incident response plan.
On its face, this seems reasonable. If your vendor had a security incident, why shouldn't you conduct an investigation?
But here's what makes it so sensitive—and potentially overwhelming.
It Doesn't Matter What the Attacker Accessed—Or Whether They Accessed Anything At All
The rule doesn't require that client data was actually compromised for the service provider to notify you. It doesn't require that the attacker had meaningful access. It doesn't even require that the service provider knows what was accessed.
The trigger is simply: unauthorized access to a customer information system maintained by the service provider.
If an unauthorized person got onto a server—even for a fraction of a second—that's enough to trigger the 72-hour notification requirement to you. And the moment you receive that notification, your IRP is activated.
Now, here's the good news: if you have a well-designed IRP, you'll have clear off-ramps.
Your investigation doesn't have to be endless. If you can reasonably determine, after a reasonable investigation, that sensitive customer information was not accessed—or that there was not a reasonable likelihood that it was accessed—you can conclude your response without triggering customer notifications.
But that's a big "if." And it depends entirely on what your service provider can tell you about what happened.
You now have to:
- Assess the nature and scope of the incident
- Identify affected systems and types of customer information
- Contain and control the incident to prevent further unauthorized access
- Investigate whether sensitive customer information was accessed or is reasonably likely to have been accessed
- Determine whether customer notification is required within 30 days
All of this—even if the breach was minor, even if it's unclear what data was involved, and even if your vendor's investigation is still ongoing.
The "Assume Everything Was Breached" Problem
Here's where the real headache begins: if you can't show what information was accessed in the system, you have to assume that all of the information in that system was accessed.
Let me say that again, because it's critical:
If an attacker got into the company that hosts your CRM, and they can't say with certainty—or near certainty—what the extent of the breach was, then you have to assume that every record in that CRM was compromised.
That means:
- Every client name
- Every account number
- Every Social Security number
- Every date of birth
- Every piece of financial data stored in that system
Unless your vendor can provide detailed logs showing exactly what the attacker accessed (or didn't access), you're looking at a worst-case scenario: notifying every single client whose data resides in that system within 30 days.
This is why logging is so critical. Without granular, timestamped logs that show what systems were accessed, what files were opened, what queries were run, and what data was exfiltrated, your vendor can't give you the proof you need to narrow the scope of notifications.
And if they can't give you that proof, the SEC expects you to err on the side of notification.
You're on the Hook Unless You Can Prove Otherwise
According to the SEC's guidance in the final rule, unless you or the service provider can affirmatively show that data on that system was not accessed or was not reasonably likely to have been accessed, you're still on the hook for customer notifications.
The rule establishes what the SEC calls a "presumption of notification." That means:
- If the investigation is inconclusive, you must notify.
- If you can't determine what data was accessed, you must notify.
- If the vendor doesn't have detailed logs showing exactly what the attacker touched, you may have to notify.
The only way out is to affirmatively demonstrate—with evidence—that sensitive customer information was not accessed and is not reasonably likely to be used in a manner that would result in substantial harm or inconvenience.
That's a high bar. And it places enormous pressure on both you and your vendors to have the right systems, logging, and documentation in place before an incident occurs.
The Vendor Uncertainty Problem: Real Examples From 2024-2025
This isn't a hypothetical concern. We've already seen multiple high-profile service provider breaches in 2024 and 2025 where downstream customers faced exactly this dilemma.
SitusAMC breach (November 2024): JPMorgan Chase, Citi, and Morgan Stanley are among the major US banks assessing potential customer data exposure following a cyberattack on SitusAMC, a third-party vendor that processes residential mortgage data for hundreds of financial institutions. This incident demonstrates how a single service provider breach can cascade across multiple financial services firms simultaneously—exactly the scenario RIAs need to prepare for.
Conduent data breach (January 2025): Business services provider Conduent notified over 10.5 million individuals that their personal information—including names, addresses, dates of birth, Social Security numbers, health insurance details, and medical information—was stolen in a January 2025 breach. The SafePay ransomware gang claimed to have stolen 8.5TB of data. Organizations relying on Conduent's services had to notify millions of customers because they couldn't definitively determine which specific records were accessed.
Snowflake breach (April-June 2024): Attackers compromised hundreds of organizations using Snowflake's cloud data platform, exposing sensitive records belonging to over 500 million individuals. Affected organizations included Ticketmaster, Santander Bank, Advance Auto Parts, and Neiman Marcus. The breach occurred because attackers exploited stolen credentials and many Snowflake customers hadn't implemented multi-factor authentication. Organizations using Snowflake had to notify millions of customers because they couldn't prove which data the attackers accessed within their Snowflake environments.
Discord customer service breach (September 2024): Discord disclosed that approximately 70,000 users may have had their government ID photos exposed after hackers compromised a third-party customer service provider on September 20, 2024. The breach included partial payment information and personally identifiable data. This demonstrates how even customer service platforms—not just core data systems—can create notification obligations for the companies that rely on them.
Change Healthcare ransomware attack (February 2024): On February 21, 2024, Change Healthcare—one of the largest healthcare payment processing companies in the United States—fell victim to a devastating ransomware attack. The ALPHV/BlackCat ransomware group claimed to have stolen 6 terabytes of data, affecting one-third of Americans. The attack's total costs are expected to exceed $1 billion, making it one of the most costly data breaches ever. Healthcare providers and insurers who relied on Change Healthcare's systems faced months of uncertainty about whether their patients' data was accessed.
Harrods third-party breach (September 2024): The luxury London department store disclosed that customer data—including names and contact details—were stolen from the systems of a third-party provider. This is part of a broader trend: according to Venminder's State of Third-Party Risk Management 2025 survey, third parties accounted for 30% of data breaches in 2024, a 15% increase from 2023.
Each of these incidents demonstrates the same pattern: when a service provider can't tell you exactly what was accessed, you're forced to assume the worst.
For RIAs, this means that a breach at your custodian, your CRM provider, your cloud backup service, or your email host could instantly trigger notification obligations for your entire client base—unless that provider has the logging and forensic capabilities to prove otherwise.
What You Need From Your Service Providers—Right Now
The only real defense here is preventative. You need to work with your service providers now—before an incident occurs—to ensure two things:
1. They Understand Their Notification Responsibilities
Your vendors need to know that under Regulation S-P, they're required to notify you within 72 hours of becoming aware of a breach involving a customer information system they maintain on your behalf.
Many service providers—especially smaller ones—may not be familiar with this requirement. If they include generic "industry compliance" language in their contracts, they may not realize what they've actually committed to.
Action step: Reach out to your key vendors (custodians, CRM providers, cloud storage, email hosts, backup providers, IT service providers) and confirm they understand the 72-hour notification requirement. Document their responses.
2. They Have the Logging and Documentation You'll Need
When (not if) you receive a breach notification from a vendor, the quality of information they can provide will determine whether you're able to avoid customer notifications or whether you're forced to notify everyone whose data resides in the affected system.
What you need from them:
- Detailed, granular logging on any systems that store your clients' information—timestamped records showing exactly what data was accessed, by whom, and when
- Information about how attackers gained access (phishing, credential stuffing, vulnerability exploitation, etc.)
- Duration of access—how long were they in the system?
- Timeline of data exfiltration—if any data was taken, when did it happen? What specific files or records?
- Proof of what was not accessed—this is your "get out of jail free" card, but it requires robust logging and forensic capabilities
If your vendors don't have this level of logging and incident response capability in place, you're flying blind when a breach happens. And that means you're notifying everyone.
Your Two Best-Case Scenarios
When you receive that 72-hour notification from a service provider, there are really only two outcomes that avoid a massive customer notification process:
Best Case: Prove No Client Data Was Accessed
If your vendor can show you—with logs, forensic evidence, and a clear investigation report—that the attackers did not access your client information, you're in the clear.
This is the gold standard. But it requires that your vendor has robust logging, monitoring, and incident response capabilities.
Second Best: Prove Only a Subset Was Accessed
If you can determine that only some client data was accessed—and you can identify exactly which clients—your notification list will be short instead of long.
This still triggers notifications, but it's manageable. It also demonstrates to the SEC that you conducted a thorough, reasonable investigation.
What This Means for Your Vendor Contracts
If you haven't already, now is the time to review and update your service provider agreements. While Regulation S-P doesn't explicitly require written contracts (the SEC removed that language in the final rule), the practical reality is that you need documented commitments from your vendors.
Your contracts or vendor agreements should include:
- 72-hour breach notification requirement explicitly stated
- Commitment to provide detailed incident information, including logs, timelines, and scope of access
- Cooperation during investigations, including timely responses to your requests for information
- Security standards they commit to maintaining (encryption, MFA, access controls, logging, etc.)
- Regular security assessments or attestations (SOC 2 reports, penetration testing, vulnerability scans)
For large providers like AWS, Google, Microsoft, Fidelity, or Schwab, you may not be able to negotiate custom contract language. But you can document where their commitments exist—in Data Processing Addendums, security whitepapers, compliance certifications, or public breach notification policies.
The key is having a vendor oversight file that shows you've verified these commitments and that you're actively monitoring your service providers' security posture.
How to Prepare Your Firm Right Now
Even if your compliance deadline is months away, here's what you should do immediately:
1. Inventory Your Service Providers
List every vendor that handles, stores, processes, or has access to customer information:
- Custodians and clearing firms
- CRM and portfolio management systems
- Cloud storage (Dropbox, Google Drive, OneDrive, Box)
- Email providers (Google Workspace, Microsoft 365, etc.)
- Document management systems
- Marketing platforms
- IT service providers and MSPs
- Backup and disaster recovery providers
- Any consultants or contractors with system access
2. Assess Their Breach Notification Capabilities
For each vendor, determine:
- Do they have a formal breach notification policy?
- Can they notify you within 72 hours?
- What level of detail will they provide in a notification?
- Do they have the logging capabilities to determine what data was accessed?
3. Update Your Vendor Agreements
Where needed, request addendums or written confirmations that address the 72-hour notification requirement and the information you'll need during an investigation.
4. Document Everything
Create a vendor oversight file that includes:
- Copies of relevant contract sections or addendums
- Emails confirming breach notification commitments
- SOC 2 reports, security questionnaires, or certifications
- Notes from vendor security reviews
- Your assessment of each vendor's compliance with your requirements
5. Build This Into Your IRP
Your Incident Response Plan should include specific procedures for:
- Receiving and triaging vendor breach notifications
- Requesting detailed information from vendors
- Assessing whether customer notification is required
- Documenting your investigation and decision-making process
- Escalating to legal, compliance, or senior management as needed
6. Train Your Team
Make sure the people who will receive vendor notifications (IT staff, compliance officers, operations managers) know what to do when one arrives. Run tabletop exercises that simulate receiving a vendor breach notification with incomplete information.
The Bottom Line: This Will Happen More Than You Think
Vendor breaches are common—and they're increasing. The U.S. is on track for another record year of data breaches, with over 2,500 breaches and nearly 200 million victims reported in 2024 alone.
If you're an RIA, you rely on multiple service providers—and every single one of them is a potential IRP trigger.
The firms that will handle this well are the ones that prepare now:
- They know which vendors have access to client data
- They've documented vendor security commitments
- They've confirmed vendors can provide detailed breach information with granular logs
- They've built vendor breach scenarios into their IRPs with clear investigation procedures and off-ramps
- They've trained their teams on what to do when a notification arrives
The firms that will struggle are the ones that wait until they receive that first 72-hour notification—and then realize they have no idea what data was accessed, no vendor cooperation agreement, no logging requirements in their contracts, and a 30-day customer notification deadline bearing down on them.
Need Help Getting Your Vendor Oversight and IRP Ready?
At CyberSecureRIA, we specialize in helping RIAs navigate exactly these kinds of compliance challenges. We work with your firm to:
- Inventory and assess your service providers
- Review and update vendor agreements for Reg S-P compliance
- Build comprehensive, tested Incident Response Plans
- Prepare audit-ready documentation for SEC exams
- Provide ongoing support when vendor incidents occur
We don't just hand you templates—we help you implement real, defensible compliance programs that work under pressure.
Regulation S-P's service provider notification requirement is one of the most underestimated parts of the new rule. Don't let it catch you off guard.
Schedule a free consultation to discuss your vendor oversight strategy and IRP readiness.
Related Resources:
