8 Things Your MSP Should Be Doing for SEC Compliance (But Probably Isn't)

Why this matters now

The SEC amended Regulation S-P in 2023 with a compliance deadline of June 2025. The updated rule requires written incident response plans, 30-day breach notification to affected individuals, and expanded safeguards for customer information. Examiners are now checking technical controls — not just policies. If your MSP is still running your IT the same way they run it for a dentist's office, you have a problem.

1. Configure DMARC on your domain

83% of RIA domains do not have a DMARC record. That means anyone on earth can send an email that appears to come from your firm's domain, and the recipient's email server has no way to flag it. Spoofed emails impersonating advisers are one of the most common vectors for client-targeted fraud.

Why it matters:DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receiving mail servers what to do with messages that fail authentication. Without it, a phishing email from "adviser@yourfirm.com" looks legitimate. With DMARC set to quarantine or reject, that email gets flagged or blocked.

How to check: Run nslookup -type=txt _dmarc.yourdomain.com in a terminal, or type your domain into MXToolbox. You should see a TXT record starting with v=DMARC1 with a policy of p=quarantine or p=reject. If you see p=none or no record at all, you are unprotected.

If your MSP hasn't done it:This is a 15-minute DNS change. Your MSP should have done this the day they onboarded you. The fact that they didn't tells you they are not thinking about email security through a regulatory lens. Run a free BlackSheep scan to see exactly where your domain stands.

2. Configure SPF and DKIM

SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) are the other two legs of the email authentication trifecta. DMARC depends on them. Without all three configured and aligned, spoofed emails can still get through to your clients.

Why it matters: SPF specifies which mail servers are authorized to send email on behalf of your domain. DKIM adds a cryptographic signature to outgoing messages so the receiving server can verify they were not tampered with in transit. Together with DMARC, they form a complete chain of trust for email. The SEC expects firms to protect the integrity of client communications — unauthenticated email is a direct threat to that integrity.

How to check: Look up your SPF record with nslookup -type=txt yourdomain.com and check for a record starting with v=spf1. For DKIM, you need to know your selector (your email provider can tell you), then query selector._domainkey.yourdomain.com. If either is missing, your email authentication is incomplete.

If your MSP hasn't done it:Ask them directly: "Are SPF, DKIM, and DMARC all configured and aligned on our domain?" If they hesitate or say "I think so," you have your answer.

3. Enable HSTS on your website

HSTS (HTTP Strict Transport Security) is a single response header that tells browsers to only connect to your site over HTTPS. Without it, a user who types yourfirm.com into their browser may briefly connect over unencrypted HTTP before being redirected — creating a window for man-in-the-middle attacks on client portals.

Why it matters: If your firm has a client portal, account access page, or any login page, HSTS prevents downgrade attacks where an attacker intercepts the initial unencrypted connection. It is one header. There is no reason not to have it.

How to check:Open your browser's developer tools, navigate to your website, and look at the response headers. You should see Strict-Transport-Security: max-age=31536000; includeSubDomains. If it is not there, HSTS is not enabled.

If your MSP hasn't done it: This is a one-line configuration change in your web server or CDN. If your MSP manages your website hosting and has not set this, they are not paying attention to security headers at all — which means items 4 and 5 on this list are probably missing too.

4. Set security headers (CSP, X-Frame-Options, X-Content-Type)

Security headers are instructions your web server sends to the browser, telling it how to behave. Three in particular matter for client-facing pages:

• Content-Security-Policy (CSP): Restricts what scripts, styles, and resources can load on your pages. Prevents cross-site scripting (XSS) attacks where an attacker injects malicious JavaScript into your client portal.
• X-Frame-Options: Prevents your site from being embedded in an iframe on a malicious site. This blocks clickjacking attacks where a user thinks they are clicking a button on your portal but are actually interacting with a hidden attacker-controlled page.
• X-Content-Type-Options: Prevents the browser from MIME-type sniffing, which can be exploited to execute malicious files disguised as harmless content types.

How to check: Same method as HSTS — open developer tools, check response headers. You should see all three. Most RIA websites have none of them.

If your MSP hasn't done it: These are standard web security hardening measures. Any MSP that manages your web hosting should have configured these during initial setup. If they did not, ask them why.

5. Remove server version headers

When someone connects to your web server, the server often responds with a header like Server: Apache/2.4.41 (Ubuntu) or Server: nginx/1.18.0. This is advertising your exact server software and version to anyone who asks — including attackers who maintain databases of known vulnerabilities indexed by version number.

Why it matters: An attacker who knows you are running Apache 2.4.41 can look up every CVE that applies to that version and target their exploit accordingly. Removing version headers does not fix vulnerabilities, but it eliminates free reconnaissance. Defense in depth starts with not handing attackers a blueprint.

How to check: Use curl -I yourfirm.com in a terminal and look at the Server header. If you see a version number, it needs to go. Also check for X-Powered-By headers that expose your backend framework (e.g., X-Powered-By: Express or X-Powered-By: PHP/8.1).

If your MSP hasn't done it: This is a basic hardening step taught in every security certification. It takes one configuration directive. If your MSP left version headers exposed, they are not performing even baseline server hardening.

6. Implement MFA on all systems touching client data

Most MSPs will enable MFA on email because Microsoft and Google have made it hard to avoid. But MFA on email alone is not enough. Every system that stores, processes, or transmits client data needs multi-factor authentication. That includes:

• Your CRM (Redtail, Wealthbox, Salesforce)
• Client portals (Schwab Advisor Center, Fidelity WealthCentral)
• Cloud storage (Dropbox, Google Drive, SharePoint, Box)
• Financial planning software (eMoney, MoneyGuidePro, RightCapital)
• Remote access tools (VPN, RDP, TeamViewer, AnyDesk)
• Password managers
• Your MSP's own remote management tools on your systems

Why it matters:Reg S-P requires safeguards "reasonably designed" to protect customer information. In 2026, single-factor authentication on a system containing client PII is not reasonable. The SEC has cited inadequate access controls in multiple enforcement actions. Compromised credentials remain the leading cause of data breaches in financial services.

How to check: Ask your MSP for a list of every application and system they manage for your firm. Then ask which ones have MFA enabled. If they cannot produce this list, that is a problem on its own.

If your MSP hasn't done it:Do not accept "the vendor doesn't support it" without verification. Most modern SaaS products support MFA. If your MSP has not enabled it, the usual reason is that it creates help desk tickets when users get locked out, and the MSP does not want the workload. That is not an acceptable reason for a regulated firm.

7. Document what they're doing

The SEC does not examine your technology. They examine your documentation. If your MSP is doing good work but cannot produce a report of what controls they manage, what configurations they have set, and what monitoring they perform, then as far as the SEC is concerned, it is not happening.

Why it matters:During an SEC examination, you will be asked to demonstrate your cybersecurity program. The examiner will want to see written policies, evidence of implementation, and proof of ongoing monitoring. "Our MSP handles that" is not evidence. A report from your MSP detailing specific controls, configurations, and monitoring results is evidence.

How to check: Ask your MSP for a monthly or quarterly security report. It should include at minimum: patch status, MFA enrollment, endpoint protection status, backup verification, and any incidents or alerts. If they do not produce one, or if the report is a generic template with no data specific to your firm, you have a documentation gap.

If your MSP hasn't done it: Tell them you need documented evidence of controls for SEC examination purposes. If they do not know what that means or cannot produce it, they are not equipped to support a regulated firm.

8. Read Reg S-P

This is the simplest test. Ask your MSP: "Have you read Regulation S-P?" The answer tells you everything you need to know.

Why it matters: Reg S-P is the regulation your firm is required to comply with. It governs how you protect customer records and information. If your MSP is implementing technical controls for your firm without understanding the regulatory framework those controls are supposed to satisfy, they are guessing. They may be guessing well in some areas and badly in others, but they are guessing.

How to check: Ask them. Not in an email — on a call or in person. You will know immediately whether they have read it based on whether they can discuss the safeguards rule, the disposal rule, and the 2023 amendments with any specificity.

If your MSP hasn't read it: It is a 20-page document. The amended rule is publicly available on the SEC's website. An MSP that supports investment advisers and has not read the primary regulation governing data protection for investment advisers is not a compliance partner. They are a utility.

The real issue

None of these 8 items are exotic. DMARC takes 15 minutes. Security headers take an hour. MFA enrollment takes an afternoon. Documentation takes discipline but not specialized knowledge. The reason most MSPs have not done these things is not that they are hard. It is that MSPs are generalists. They support dental offices, law firms, real estate agencies, and investment advisers using the same playbook. That playbook does not include SEC requirements because most of their clients are not SEC-registered.

That is not a criticism of your MSP. It is a structural mismatch. You are a regulated financial institution being supported by a vendor that does not specialize in regulated financial institutions.

What to do with this list

Print this list. Send it to your MSP. Ask them to check each item and report back with evidence — not just "yes, we do that," but screenshots, configuration records, and documentation.

If they can check all 8, you have a great IT partner. If they can't, you have a gap that BlackSheep fills.

BlackSheep monitors your domain, your email authentication, your security headers, and your web server configuration continuously. When something drifts or breaks, you know about it before an SEC examiner does. Run a free scan and see where your firm stands right now.