Cybersecurity Policy Template for SEC-Registered RIAs: What to Include (And What Templates Get Wrong)

Why templates are a starting point, not the answer

SEC examiners have seen every template on the internet. The OCIE and Division of Examinations staff review hundreds of Written Information Security Programs every year. They know the difference between a generic document with your firm name swapped in and a tailored program that reflects how your firm actually operates.

A template gives you structure. It tells you what sections to include and what topics to cover. That is genuinely useful if you are starting from nothing. But the value of a cybersecurity policy is not in having the right headings — it is in having accurate, specific content under those headings that someone at your firm can actually follow.

The firms that get flagged in examinations are not the ones without a policy. They are the ones with a policy that does not match their reality.

What a compliant cybersecurity policy must include

Under Reg S-P and SEC examination guidance, your Written Information Security Program needs to address these areas. This is the skeleton that any decent template should give you:

• Data classification and inventory.What client data do you hold, where does it live, and how is it categorized by sensitivity? This includes PII, financial records, account numbers, and anything covered under Reg S-P's definition of nonpublic personal information.
• Access controls and authentication. Who can access what systems, how are permissions granted and revoked, and what authentication methods are required? Multi-factor authentication is no longer optional — the SEC has made this clear in recent examinations.
• Encryption standards. How is data protected at rest and in transit? This covers client data in your CRM, portfolio management system, email communications, and file transfers.
• Email security. Policies for phishing prevention, email authentication (SPF, DKIM, DMARC), and handling of sensitive information via email. Email is the primary attack vector for financial services firms.
• Incident response procedures. What happens when something goes wrong. The amended Reg S-P rule requires notification to your service providers within 72 hours and to affected clients within 30 days of discovering unauthorized access to client information.
• Vendor and third-party oversight. How you evaluate, monitor, and manage the security posture of your custodians, cloud providers, IT vendors, and any other third party with access to client data.
• Employee security awareness training. What training is required, how often, and how you verify that employees completed it. Annual training is the floor, not the ceiling.
• Physical security. Office access controls, clean desk policies, visitor procedures, and secure disposal of physical records containing client information.
• Business continuity and disaster recovery. How your firm continues to operate and protect client data during a disruption. This includes backup procedures, recovery time objectives, and communication plans.
• Annual review procedures. How and when the policy gets reviewed, who is responsible for the review, and how changes are documented and communicated to staff.
• Board and principal oversight.Who at the firm is responsible for cybersecurity, how they stay informed about the firm's security posture, and how decisions about cybersecurity resources and priorities are made and documented.

What most templates get wrong

Having the right sections is necessary but not sufficient. Here is where the gap between a template and a compliant program shows up:

1. Too generic to be useful

Most templates are written to apply to any firm. That means they reference "the organization's systems" instead of naming your actual CRM, custodian portal, portfolio management platform, and cloud storage provider. SEC examiners want to see that you know what your systems are and have written procedures specific to them. A policy that says "access to systems is restricted to authorized personnel" without defining which systems and which personnel is a template, not a program.

2. Includes controls you do not implement

This is the most dangerous template mistake. The template includes a section on network segmentation, intrusion detection, or data loss prevention. It sounds thorough. But your firm does not actually have those controls in place. Now your policy makes claims your infrastructure cannot support — and an SEC examiner who tests those claims will find a gap between what you said and what you do. That gap is worse than not having the section at all.

3. Missing Reg S-P specific requirements

The amended Reg S-P rule introduced specific notification timelines that many generic templates do not include: 72 hours to notify service providers who may have been affected, and 30 days to notify clients whose information was compromised. If your incident response section does not reference these specific timelines, it was written before the rule change or was not written for RIAs.

4. No evidence trail

The policy exists as a PDF in a shared folder. Nobody signed it. There are no training records showing employees reviewed it. There is no log of the annual review. There are no incident response drill records. The SEC does not just ask whether you have a policy — they ask for evidence that it is followed. A template does not generate evidence. A program does.

5. Never updated

The policy was written in 2023. The Reg S-P amendments took effect in 2025. Your firm switched custodians in 2024 and added a new portfolio management system. None of that is reflected in the document. A cybersecurity policy with a two-year-old date and no revision history tells the examiner everything they need to know about how seriously your firm takes the program.

The template problem in one stat

We scanned 8,802 RIA websites. 83% had cybersecurity policies requiring email authentication — SPF, DKIM, DMARC. Standard template language. But when we checked their actual DNS records, no DMARC was configured. The template said the right thing. Nobody verified it was true.

That is the template problem in one number. The document claims a control exists. The infrastructure says otherwise. And when the SEC examines your firm, they do not just read the document — they test whether what the document claims is actually happening.

How to make a template actually useful

If you are starting with a template, here is how to turn it into something that will hold up under examination:

1. Customize every section to your firm's actual systems. Replace generic references with the names of your CRM, custodian, portfolio management platform, email provider, and cloud storage. If the policy mentions a system, that system should exist in your environment.
2. Remove controls you do not implement. Honest is better than comprehensive. If you do not have a data loss prevention tool, take that section out. If you do not segment your network, do not claim that you do. You can note it as a planned improvement with a timeline — that is acceptable. Claiming it exists when it does not is a finding.
3. Add your actual procedures. Not hypothetical ones. How does your firm actually handle a phishing email? Who does the employee contact? What is the phone number? Where do they report it? If the procedure section reads like a textbook instead of an internal manual, rewrite it.
4. Document who is responsible for what.Name the person or role responsible for each area. "The IT department" is not sufficient if your firm has three people and no IT department. Be specific about who owns each responsibility.
5. Schedule your annual review.Put a date on the calendar. Assign an owner. Define what "review" means — reading the document, testing controls, updating procedures, obtaining sign-off from principals.
6. Verify that technical controls match what the policy claims. If the policy says you require MFA, verify MFA is enabled on every system. If it says you encrypt data in transit, verify TLS is configured. If it says you authenticate email, check your DMARC records. The policy is only as good as the controls behind it.

How BlackSheep generates policies

BlackSheep does not hand you a template. When you run a scan, we assess your firm's actual technical environment — email authentication, encryption, exposed services, DNS configuration. We combine that with your state registration, AUM tier, and the specific regulatory framework that applies to your firm type.

The result is a policy that reflects your real controls, not aspirational ones. Sections that reference systems you actually use. Incident response timelines that match current Reg S-P requirements. Controls that are verified against your infrastructure, not assumed to exist because a template said they should.

When your environment changes — new vendor, new system, updated regulation — the policy updates. Not because someone remembered to open a Word document, but because the underlying data changed and the policy regenerates to match.