Top 10 Cybersecurity Mistakes RIAs Make (From Scanning 8,802 Firms)

Most of these are not hard to fix. They persist because nobody checks until an examiner does. The updated Reg S-P rule changes that calculus — the compliance deadline is June 3, 2026, and the SEC has made clear that cybersecurity is a priority in their current exam cycle.

If you want the full dataset, we published it in our State of RIA Cybersecurity 2026 report. What follows is the practical version: what is broken, why it matters, and what to do about it.

1. No DMARC record (83% of firms)

Of 8,802 RIA firms scanned, 83% had no DMARC record on their primary domain. That means anyone can send email that appears to come from your firm, and most recipient mail servers will deliver it without question.

This is not theoretical. Business email compromise targeting financial advisors is a well-documented attack pattern. A client receives an email from what looks like your domain asking them to wire funds to a new account. Without DMARC, there is no mechanism for the client's email provider to reject or flag that message.

What examiners look for:SEC examiners have begun requesting email authentication records during cybersecurity-focused exams. They want to see DMARC, SPF, and DKIM configured and enforced — not just published with a policy of "none."

The fix: Publish a DMARC record on your domain. Start with a monitoring policy (p=none) to identify legitimate sending sources, then move to quarantine and eventually reject. SPF and DKIM must be configured first. Most DNS providers make this a 15-minute task once you know your sending sources. Run a free scan to check your current status.

2. Assuming your MSP handles compliance

This showed up in conversations with hundreds of firms during our research. The assumption is that because a managed service provider handles IT — patching, antivirus, network monitoring — they also handle SEC compliance. They do not.

Your MSP manages technology. SEC compliance requires documented policies, risk assessments, incident response plans, vendor management programs, and evidence that these are reviewed and updated regularly. Your MSP is not writing your Written Information Security Program. They are not conducting your annual risk assessment. They are not documenting your incident response procedures.

What examiners look for:Examiners ask who is responsible for the firm's cybersecurity program. If the answer is "our IT guy" or "our MSP," the follow-up questions get harder. They want to see a named individual at the firm who owns the program, with documented oversight of any third-party providers.

The fix:Designate a Chief Information Security Officer or equivalent at the firm level — even if the role is part of someone's broader responsibilities. Document what your MSP is responsible for and what the firm retains. Review your MSP contract for gaps between what they deliver and what the SEC expects.

3. Using a WISP template instead of a tailored program

We reviewed dozens of Written Information Security Programs during our research. The majority were clearly templates — identical structure, boilerplate language, references to controls the firm does not actually have. Some still contained the placeholder name of the template vendor's sample firm.

SEC examiners have seen every template on the market. They know what generic looks like. More importantly, a template that references controls you have not implemented is worse than having no document at all — it is evidence that you represented a security posture you do not actually maintain.

What examiners look for: They compare what the WISP says to what the firm actually does. If the WISP says you conduct quarterly access reviews but you cannot produce evidence of a single one, that is a finding. If the WISP references an intrusion detection system and you do not have one, that is a finding.

The fix:Start from your actual environment, not a template. Inventory the systems you use, the data you hold, the people who access it. Build your WISP around what is real, then identify gaps between what you do and what you should do. A shorter, accurate document is better than a 40-page template that describes someone else's firm.

4. No documented incident response plan

The updated Reg S-P rule requires RIAs to have written incident response plans by June 3, 2026. But beyond the regulatory mandate, this is a practical necessity. When a breach happens — and at the current rate of attacks on financial services, the question is when, not if — you need to know who does what.

Having a plan is necessary but not sufficient. An untested plan is almost as bad as no plan. If the first time your team reads the incident response procedures is during an actual incident, the plan has failed.

What examiners look for: A written plan that covers detection, containment, notification, and recovery. Evidence that the plan has been reviewed and tested — tabletop exercises, scenario walkthroughs, or at minimum an annual review with documented updates. Under the new Reg S-P requirements, they will also check for 30-day breach notification procedures.

The fix: Write an incident response plan that names specific people and specific actions. Include contact information for your legal counsel, your insurance carrier, your MSP, and relevant regulators. Then run a tabletop exercise — pick a scenario (ransomware, compromised email account, lost laptop) and walk through the plan step by step. Document the exercise and any changes you make afterward. The Reg S-P deadline makes this non-negotiable.

5. Treating cybersecurity as an annual project

Many firms treat cybersecurity like an annual audit: bring in a consultant in Q4, get a report, file it, forget about it until next year. The SEC has made clear this is not what they expect. Cybersecurity is a continuous obligation. The threat landscape changes monthly. Your controls need to keep up.

From our scan data, we can see this pattern clearly. Firms whose configurations had not changed in over 12 months — same DNS records, same security headers (or lack thereof), same certificate configurations — were overwhelmingly the firms with the most issues.

What examiners look for: Evidence of ongoing activity. Meeting minutes from quarterly security reviews. Updated risk assessments. Training records with dates. Patch management logs. Anything that shows the firm is paying attention between annual reviews.

The fix: Build cybersecurity into your regular operations. Quarterly reviews at minimum. Monthly patching verification. Ongoing training throughout the year rather than a single annual session. If you use a compliance platform, set it to surface action items on a regular cadence rather than letting it sit idle between annual assessments.

6. No vendor risk management program

RIAs rely on dozens of third-party vendors: custodians, portfolio management software, CRM systems, client portals, cloud storage, email providers. Each one has access to client data. Each one is a potential point of failure.

Most firms we reviewed had no formal process for evaluating vendor security. No questionnaires. No contract requirements. And critically, no 72-hour breach notification clauses requiring vendors to notify the firm promptly when something goes wrong. Without that clause, your vendor could be breached for weeks before you find out — and the clock on your own notification obligations is already running.

What examiners look for: A written vendor risk management policy. Evidence of due diligence on critical vendors. Contract provisions addressing data security, breach notification, and right to audit. Periodic reassessment of vendor risk.

The fix: Inventory your vendors. Categorize them by the sensitivity of data they access. For critical vendors (custodians, portfolio management, CRM, client portals), conduct security due diligence and ensure your contracts include breach notification requirements — 72 hours is the standard the industry is moving toward. Review annually.

7. Missing security headers on client portals

Of the RIA firms in our scan that operated client-facing web portals or websites, the vast majority were missing basic security headers. HSTS (HTTP Strict Transport Security), Content-Security-Policy, and X-Frame-Options were the most commonly absent.

These headers are not cosmetic. HSTS prevents downgrade attacks that could intercept client sessions. Content-Security-Policy blocks cross-site scripting attacks. X-Frame-Options prevents clickjacking. Without them, your client portal is vulnerable to attacks that have been well-understood for over a decade.

What examiners look for: While examiners may not run technical scans themselves, they do ask about web application security controls. If you cannot explain what security headers you have in place or what protections your client portal implements, that is a gap. More sophisticated exam teams have begun requesting technical documentation of web security configurations.

The fix: Add security headers to your web server configuration or CDN settings. HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy are the baseline. If you use a managed client portal from a vendor, ask them what headers they implement and request changes if they fall short. Scan your domain to see what is missing.

8. No MFA on systems with client data

Multi-factor authentication remains the single most effective control against account compromise. It stops the vast majority of credential-based attacks. And yet, firms continue to operate email accounts, CRM systems, and client portals with passwords alone.

The SEC has cited MFA specifically in multiple risk alerts. It is no longer a best practice — it is an expected baseline. If a firm suffers a breach that could have been prevented by MFA, the regulatory response will be significantly harsher than if MFA was in place and the attacker found another way in.

What examiners look for: MFA enabled on email, remote access, client-facing portals, and any system containing personally identifiable information or client financial data. They also check whether MFA is enforced (required for all users) versus merely available (optional).

The fix: Enable MFA on everything that holds or accesses client data. Start with email — that is where most attacks begin. Then remote access, CRM, portfolio management, and client portals. Use app-based authentication (Microsoft Authenticator, Google Authenticator) or hardware keys rather than SMS, which is vulnerable to SIM swapping.

9. Relying on a compliance consultant who does not verify technical controls

This is a pattern we see constantly. A firm hires a compliance consultant who produces a beautiful set of policies. The policies reference encryption, access controls, monitoring, and incident response. But nobody ever checks whether those controls are actually implemented.

Policy without implementation is theater. A policy that says "all data at rest shall be encrypted" means nothing if your laptops use unencrypted drives. A policy that requires annual penetration testing means nothing if no test has ever been conducted. The gap between policy and reality is where SEC findings live.

What examiners look for: Alignment between written policies and actual practices. They will ask for evidence: encryption status reports, penetration test results, training attendance records, access review logs. If your policies promise something you cannot prove, that is worse than not having the policy at all.

The fix: Audit your own policies against reality. For every control your WISP describes, ask: can I produce evidence that this is happening? If not, either implement the control or revise the policy to reflect what you actually do while you work toward the fuller standard. Pair your compliance consultant with someone who can verify technical controls — or use a platform that bridges both sides.

10. Waiting for the Reg S-P deadline to force action

The updated Reg S-P rule has a compliance deadline of June 3, 2026. Many firms are treating that date as the starting gun. It is not. It is the finish line.

The firms that are building their programs now — documenting policies, implementing controls, running tabletop exercises, training staff — will be ready when June arrives. They will pass exams. The firms that wait until May to start will scramble, produce rushed documentation, miss critical gaps, and face an exam cycle knowing their program is held together with tape.

What examiners look for: Maturity. A program that was clearly built over months shows iteration, updates, and refinement. A program thrown together in two weeks before a deadline shows boilerplate policies, no evidence of testing, and no training records. Examiners can tell the difference.

The fix: Start now. Not after the next board meeting. Not after you hire that compliance person. Now. Pick the highest-priority items — DMARC, incident response plan, MFA enforcement, vendor inventory — and start closing gaps. Use the SEC cybersecurity exam checklist to prioritize.

Score yourself

Go through the list above. Be honest about which ones apply to your firm.

• 0-2 mistakes: You are ahead of 97% of the industry. Keep going — close the remaining gaps and document everything.
• 3-5 mistakes:You have work to do, but it's manageable. Close the gaps before June 3. Start with DMARC and your incident response plan — those are the fastest wins.
• 6+ mistakes: Start today. Not next week. Every one of these gaps is something an SEC examiner could flag, and the exam cycle is active now. Pick the three highest-impact items and work through them in order.

If you want to know exactly where your firm stands, run a free scan and get a report in under two minutes. No sales call required.