The St. Louis Financial Firm Technology Guide [2026 Edition]

What St. Louis RIAs, Wealth Managers, CPAs & Financial Services Firms Need to Know Before Their Next Technology Decision

IMPORTANT: The SEC’s amended Regulation S-P compliance deadline for smaller RIAs (under $1.5B AUM) is June 3, 2026. If your firm hasn’t built a documented incident response program and information security policy that meets the new standard, the deadline has arrived. This guide covers what that means for your IT environment. 

Need more information on the SEC’s Reg S-P Compliance Deadline? Visit our blog on the Final Countdown Before June 2026. Need immediate help with SEC compliance? Contact us at (314) 649-8888 or fill out the form.

Most financial firms don’t have an IT problem. They have an IT structure problem. Systems get added as the firm grows, software decisions get made in a hurry, and compliance gaps accumulate quietly until an audit, an insurer, or an incident forces the issue. By then, the cost of fixing what should have been right from the start is significantly higher than the cost of building it correctly.

This guide comes from a financial IT services firm that has spent 25+ years working with RIAs, wealth management firms, broker-dealers, and CPAs across St. Louis and the surrounding region. The issues covered here are not theoretical; they’re what we find every time we walk into a new client environment. The regulatory context is current as of May 2026, and the technical guidance reflects what regulators and cyber insurers are actually asking for right now.

Note: Nothing in this guide constitutes legal, compliance, or regulatory advice. For guidance specific to your firm’s obligations, consult your compliance consultant, securities counsel, or the relevant regulatory body.

What’s In This Guide

• Why Financial Services IT Is Categorically Different From General Business IT
• The Compliance Stack: FINRA, GLBA, SEC Regulation S-P, and What Each Requires From IT
• The Microsoft 365 Problem: Default Settings That Create Regulatory Exposure
• Network Design for Financial Firms: What’s Different and Why It Matters
• The 8 Non-Negotiable Security Controls for Regulated Financial Firms
• Ransomware: The First 60 Minutes of Response
• The Documentation an Audit Will Ask For
• What to Look for in an IT Partner for Your St. Louis Financial Firm

1. Why Financial Services IT Is Categorically Different From General Business IT

A general IT provider can keep your systems running. That’s not the same as keeping your firm compliant, audit-ready, and operationally resilient under the pressures that financial services creates. The fundamental difference is what failure costs. When a general business has an IT outage, productivity suffers. When a wealth management firm goes down during market hours, the consequences are different in kind:

• Client trades may not execute
• Portfolio monitoring goes dark
• Time-sensitive communications stop
• Advisors can’t access the data their clients are calling about.

For an RIA with a fiduciary obligation to act in the client’s best interest, a technology failure at the wrong moment is not just an operational problem. It’s a compliance and liability event. 

If you’re curious what downtime would cost your financial services firm, take a look at our Cost of IT Downtime Calculator. 

Financial firms operate under FINRA rules, SEC regulations, GLBA data protection requirements, state-level regulatory obligations, and in many cases, specific client due diligence requirements from institutional counterparties who conduct their own vendor assessments. An IT environment built for a general SMB will fail these requirements, not because it’s poorly designed, but because it was never designed for this.

Three infrastructure weaknesses appear consistently when we take over a new financial services client:

1. Flat network architecture: workstations, servers, compliance systems, VoIP, and guest WiFi all on the same logical network with no segmentation. A compromised workstation has direct access to everything else.
2. Microsoft 365 at default security settings: external sharing open, audit logging not enabled, no DLP policies, Conditional Access not configured. The single biggest attack surface in most firms – running wide open.
3. No tested incident response plan: a policy document that hasn’t been exercised, with no mapped regulatory notification requirements, no pre-established relationships with counsel or the cyber insurer, and no defined decision-making authority for the first hour of a breach.

The most dangerous assumption financial firm owners carry is that cybersecurity is an IT problem, something technical that lives in the server room. It isn’t. The primary attack vector for financial firms is email phishing. The primary consequence of a breach isn’t technical recovery; it’s regulatory notification, client communication, legal exposure, and reputational damage. These are leadership problems that happen to have a technical origin.

2. The Compliance Stack: FINRA, GLBA, SEC Regulation S-P, and What Each Requires From IT

Financial firms operate under multiple overlapping regulatory frameworks, each with specific IT implications. Understanding which rules apply to your firm and what they actually require from your technology environment is the first step toward a compliant infrastructure.

SEC Regulation S-P: The June 2026 Deadline

The SEC’s 2024 amendments to Regulation S-P represent the most significant change to financial firm data protection requirements in years. The amendments require covered institutions to adopt a written program reasonably designed to detect, respond to, and recover from unauthorized access to sensitive customer information, and to notify affected individuals when a breach occurs or is reasonably likely to have occurred. For larger institutions, compliance was required by December 3, 2025. For smaller RIAs under $1.5 billion in AUM, the compliance deadline is June 3, 2026. That deadline is now.

What Regulation S-P requires from your IT environment: a documented information security policy, a complete inventory of all systems and devices that could pose a risk (including personal phones used for work email), MFA on all systems, a written and tested incident response program, vendor contracts that include data protection and confidentiality requirements, and documented procedures for notifying clients when their information is compromised. SEC examiners are not checking boxes on a form. They are asking whether your written procedures are reflected in actual technical controls. A policy that says “we require MFA” while MFA is not enforced on all accounts is a deficiency.

FINRA’s 2026 Cybersecurity Priorities

FINRA’s 2026 Annual Regulatory Oversight Report identifies cybersecurity as a top examination priority, tying it directly to Regulation S-P, Regulation S-ID, FINRA Rule 3110 (supervision), Rule 4370 (business continuity), and Exchange Act books-and-records rules. FINRA’s examinations are now focused specifically on ransomware and extortion preparedness, business email compromise, new account fraud and account takeovers enabled by AI-generated identity documents and voice clones, and third-party vendor risk. FINRA has reinforced that outsourcing IT functions does not outsource compliance responsibility. The firm is accountable for what its vendors do with firm and client data.

GLBA: The Safeguards Rule for Financial Institutions

The Gramm-Leach-Bliley Act Safeguards Rule applies to financial institutions that collect nonpublic personal information about their customers, which includes most RIAs, broker-dealers, and wealth management firms. The FTC’s updated Safeguards Rule requires a written information security program with specific elements: a designated qualified individual responsible for the program, a risk assessment, implementation of safeguards including encryption and MFA, regular monitoring and testing, training, vendor oversight, and an incident response plan. For financial services firms in Missouri, GLBA obligations layer on top of state-level data protection requirements.

The AI Compliance Problem Financial Firms Aren’t Prepared For

FINRA’s 2026 Report includes a dedicated section on generative AI for the first time, and the SEC’s 2026 examination priorities integrate AI oversight into cybersecurity, emerging technology, and operational resiliency examinations simultaneously. The specific concern is that firms are adopting AI tools for client communication, document drafting, and research without conducting formal risk assessments of how those tools handle client data, or ensuring AI-generated communications are captured in books-and-records systems. An AI drafting tool that processes client portfolio information through an unvetted third-party model creates both a data security exposure and a regulatory one. Most firms haven’t mapped it.

3. The Microsoft 365 Problem: Default Settings That Create Regulatory Exposure

Microsoft 365 is the single largest attack surface in most financial firms, and it ships with default settings that are nowhere near sufficient for a regulated environment. Most advisory firms are running M365 in a configuration that is open, unmonitored, and non-compliant with Regulation S-P and GLBA requirements. This isn’t a generalization; it’s what we find in the first week of every new client onboarding.

Identity and Access: MFA Is Not Enough on Its Own

MFA is table stakes, but configuration matters. Conditional Access policies should restrict access by device compliance state, location (blocking foreign logins or logins from unexpected geographies), and risk signal. Global administrator accounts should be completely separate from the principals’ standard user accounts. An owner who uses the same login for email and for global admin access has created an environment where a single phishing email can hand a threat actor the keys to the entire M365 tenant. This configuration error is nearly universal in financial firms that haven’t had a dedicated security review.

Data Loss Prevention: Client PII Is Leaving Undetected

Financial firms should have DLP policies configured to detect and block transmission of Social Security numbers, account numbers, and other regulated data via email or SharePoint sharing. Without DLP, an advisor can email a spreadsheet of client account numbers to a personal Gmail account and M365 will deliver it without flagging it. That’s both a security event and a Regulation S-P event, and there will be no record of it unless audit logging is enabled and configured correctly.

External Sharing: Most Firms Are Sharing Client Documents With Anyone

By default, SharePoint and OneDrive allow users to create sharing links accessible to anyone with the link, no authentication required. Advisory firms are frequently shocked when we audit their SharePoint environments and show them client planning documents, account statements, and financial plans shared via anonymous links with no expiration date. Every one of those links is a Regulation S-P exposure. The fix is straightforward: restrict external sharing to specific approved domains only, disable anonymous links entirely, and audit existing shares for anything that needs to be revoked.

Email Forwarding Rules: The Silent Compromise Indicator

When an attacker compromises an M365 account, the first thing they typically do is create a silent forwarding rule that copies all incoming email to an external address. The attacker then monitors communications for weeks, learning payment schedules, client relationships, and transaction patterns, before taking any visible action. By default, M365 allows users to create external forwarding rules and does not alert administrators. Disabling auto-forwarding to external addresses and configuring alerts for new mail rules is a basic control that most financial firms don’t have in place.

Audit Logging and Retention: The Missing Compliance Evidence

The Unified Audit Log in Microsoft 365 must be explicitly enabled and retained for the period required by the firm’s compliance obligations. FINRA and SEC examiners ask for it; cyber insurers want to see it after an incident. Without it, there is no record of who accessed what, when a forwarding rule was created, when a document was shared externally, or when a login came from an unexpected location. In most financial firms we onboard, the audit log has never been configured, meaning there is no forensic baseline if an incident is later investigated. Business Premium is the minimum viable M365 license level for a financial firm. Standard or Basic licensing excludes most of the security controls that matter.

4. Network Design for Financial Firms in St. Louis: What’s Different and Why It Matters

A standard SMB typically runs a flat network: workstations, servers, printers, VoIP, and guest WiFi all sharing the same logical space. For a business without regulatory obligations, that’s a manageable risk. For a financial firm, it’s indefensible. A single compromised workstation on a flat network has direct access to compliance servers, client data systems, and custodian integrations. A threat actor who enters through a phishing email on one advisor’s workstation can move laterally to everything else without crossing a security boundary. If you’re working with a cybersecurity firm, it’s critical to ensure they’re familiar with the ins and outs of proper network security for financial services firms. 

Hard VLAN Segmentation

Financial firms should implement hard VLAN segmentation across network zones. Client-facing systems, advisor workstations, compliance and document servers, VoIP, and guest WiFi should all live on separate network segments, with firewall rules explicitly controlling inter-VLAN traffic. A wealth manager’s workstation should never be able to directly reach a file server without traversing a firewall policy that logs the connection. This isn’t an advanced configuration; it’s baseline architecture for a regulated environment. The absence of it is one of the most common findings when we take over a new client.

Dedicated Compliance Zones

Any system that stores or processes regulated data, including CRM records, financial planning files, and custodian integration endpoints, should sit in a defined network segment with logging enabled on all traffic flows. The ability to answer a regulator’s question about who accessed what and when depends entirely on having that logging in place before the question is asked. Retroactive reconstruction of access events from an unlogged network is not possible. If the logs don’t exist, the evidence doesn’t exist.

Zero-Trust Access for Remote Advisors and Multi-Office Environments

The traditional VPN model (trust anything that connects through the tunnel) is not sufficient for financial firms with remote advisors or hybrid work arrangements. Zero-trust access principles require every device to authenticate and prove compliance before gaining access to internal resources, regardless of where it’s connecting from. For firms where advisors access custodian portals and client data from multiple locations, VPN hairpinning creates performance problems as well as security gaps. Split tunneling or a SASE approach routes cloud traffic directly while keeping internal traffic secured, reducing latency during market hours and removing the VPN as a single point of failure.

What Actually Causes ‘Slow Systems’ in Financial Firms

Slow system complaints in financial offices almost always trace to a handful of specific causes:

• Aging workstations with insufficient RAM running financial planning software, browser-based custodian portals, M365, and a PDF viewer simultaneously.
• Workstations still running spinning hard drives instead of SSDs (the single highest-ROI hardware change available).
• Endpoint protection software not tuned to the environment, running full-disk scans at 10 AM on a loaded machine.
• DNS misconfiguration creating intermittent hangs that users within the organization describe as “everything is slow.”
• Insufficient internet bandwidth for cloud-dependent workflows; a 50Mb connection shared across 20 advisors during market open is a bottleneck.

The fix is almost never tuning. It’s a hardware refresh, proper security software configuration, and a bandwidth assessment. A proper managed IT services plan makes all the difference in terms of keeping your environment current and secure. 

5. The 8 Non-Negotiable Security Controls for Regulated Financial Firms in St. Louis

These are the controls where there is no acceptable version of ‘we’ll get to it later.’ Each one is a baseline requirement for a regulated financial firm. If a financial services firm is missing more than two of these, they have material risk exposure regardless of how everything else looks.

• MFA on everything: every user, every application, no exceptions. This includes email, practice management software, custodian portals, document management, and any remote access method. A single account without MFA is the attack surface.
• Endpoint detection and response (EDR/MDR): traditional antivirus detects known malware signatures. EDR detects behavioral anomalies; processes that behave like ransomware before they’re identified as ransomware. Financial firms need behavioral detection with a human response capability behind it. Passive software is not sufficient.
• Email security: phishing remains the primary entry point for breaches. Defender for Office 365 with Safe Links and Safe Attachments enabled, anti-phishing policies tuned for impersonation of executives and custodian brands (Schwab, Fidelity, and similar firms are routinely spoofed), and DMARC/DKIM/SPF fully configured. Most financial firm breaches begin with an email that shouldn’t have been delivered.
• Privileged access controls: admin accounts must be separate from standard user accounts, audited, and protected. Shared admin credentials or standing admin access for principals are indefensible in a regulated environment. Every privileged action should be logged.
• Encrypted, tested backups: backups that haven’t been restored are assumptions, not protections. Regulators and cyber insurers want documented evidence of restore tests; timestamps, what was restored, who verified it, and how long recovery took. An untested backup with no documentation is treated the same as no backup in a FINRA or SOC 2 context.
• Patch management: unpatched systems are the second most common entry point after phishing. Financial firms we onboard are frequently 6 to 18 months behind on endpoint patches. A defined patching cadence with documented evidence is required for FINRA and GLBA compliance and is a standard cyber insurance requirement.
• Cybersecurity awareness training: your people are part of the security stack. Simulated phishing campaigns and regular training are expected by regulators and insurers. Training records should document completion rates, dates, and phishing simulation results at the individual level. Regulators want this granularity, not just aggregate completion rates.
• Data backup and loss prevention: for firms handling client PII and financial data, knowing where that data lives and preventing it from leaving through uncontrolled channels is both a security and compliance requirement. DLP policies in M365 should be configured before an incident reveals that client data has been exfiltrating for months.

6. Ransomware: The First 60 Minutes of Response

Speed and decisiveness in the first hour of a ransomware event determine whether you’re dealing with a contained incident or a firm-ending catastrophe. Most firms have never thought through what those 60 minutes actually look like until they’re living them. Here is exactly what should happen. (And this is how our team handles it every single time):

Minutes 0-10: Detect and Isolate. Stop the Spread First.

The moment ransomware is suspected, whether from unusual file extensions, encrypted shares, or a ransom note appearing on screen, the immediate priority is stopping the spread, not investigating the cause.

• Physically disconnect or power off affected workstations. Don’t just log off; pull the network cable or disable the network adapter.
• Isolate affected network segments at the switch or firewall level immediately. If you can’t identify which segment is compromised, segment everything and work backward.
• Do not shut down servers without guidance. Some ransomware variants accelerate encryption on shutdown, and critical forensic evidence lives in RAM that disappears on power-off.

Minutes 10-25: Scope Assessment

Identify which systems are confirmed clean, which are confirmed infected, and which are unknown. Check firewall logs for outbound connections; most modern ransomware exfiltrates data before encrypting. If data left the building, you have a Regulation S-P notification obligation, not just an IT recovery problem. Determine when the infection likely began. Ransomware typically dwells in a network for days or weeks before triggering, so the visible encryption event is not the beginning of the incident. It’s the end of the dwell period. Your investigation will need to establish the actual entry point and timeline.

Minutes 25-40: Notifications Begin. The Clock Is Already Running.

Financial firms have legal notification obligations, and the regulatory clock may already be running. Notify firm principals and legal counsel immediately. This is not an IT decision. Engage your cyber insurance carrier; most policies require prompt notification and require use of their approved incident response vendors. Using non-approved IR firms can void coverage. If the firm is an RIA, Regulation S-P notification requirements may be triggered depending on what data was accessed. Counsel needs to make that determination, but they can’t make it if they’re not in the loop. Do not communicate via email systems that may be compromised. Use personal phones and out-of-band channels.

Minutes 40-60: Recovery Posture and Documentation

Confirm backup integrity and the last known clean backup point; this is your recovery baseline. Stand up out-of-band communication for the firm so business can continue while primary systems are down. Advisors should have mobile access to client contact data that doesn’t depend on the primary network. Hosted VoIP should have a cellular failover path so client calls still reach the right people. Document everything from this point forward with timestamps. Your cyber insurance claim, any regulatory response, and potential litigation will depend on a clear incident timeline. The most common failure in this window is indecision, waiting to be certain before acting. Act first, verify second.

7. The Documentation a St. Louis FINRA or SEC Examiner Will Expect

When FINRA or SEC examiners arrive, or when a cyber insurance claim is filed, the question isn’t whether you have security controls in place. It’s whether you can prove it. The documentation below is what regulators, insurers, and sophisticated institutional clients are asking for. Most financial services firms we onboard have two or three of these. A mature environment has all of them, kept current, and tied to an annual review cycle. 

• Asset inventory: all endpoints, servers, mobile devices, and licensed software, including personal devices used for work email, which fall within your Regulation S-P scope.
• User access matrix: who has access to what, including admin and privileged accounts, with dated records of access reviews and approvals.
• Off-boarding checklist: a repeatable, documented process for account termination, including review of file access, removal of forwarding rules, and revocation of all credentials and device access.
• Incident response plan: documented, tested, and current; covering ransomware, business email compromise, data exfiltration, and vendor breach scenarios, with regulatory notification requirements mapped and decision authority defined.
• Business continuity and disaster recovery plan: RTOs and RPOs defined and tested; not aspirational targets but verified recovery times from actual restore exercises.
• Backup and restore logs: completed backup jobs AND verified restore tests with timestamps, what was restored, who verified it, and how long recovery took. The absence of restore documentation is treated the same as no backup.
• Patch management reports: what was patched, when, and what remains outstanding with documented risk acceptance for anything deferred.
• Security awareness training records: completion rates, dates, and phishing simulation results at the individual user level. Regulators want this granularity, not just aggregate completion rates.
• Vendor risk assessments: documentation that third-party vendors with access to firm systems or client data have been evaluated for security posture, with annual review. FINRA’s 2026 Report specifically emphasizes vendor risk management as an examination focus.
• Incident log: a record of every security event, however minor, with how it was handled. The complete absence of any incidents on record is itself a red flag to experienced auditors.
• Compliance evidence folder: for FINRA, GLBA, Regulation S-P, or SOC 2 purposes; logs, attestations, training records, policy acknowledgments, and change management documentation organized and current.

8. What to Look for in an IT Partner for Your St. Louis Financial Firm

Not every financial firm needs the same IT setup. A 5-advisor RIA in Clayton has different requirements than a 40-person broker-dealer in Chesterfield. But there are consistent questions every principal should ask before selecting or evaluating an IT provider for a regulated financial services environment.

Do they assess security first, or do they start with performance and infrastructure?

An IT provider who walks into a new financial firm and starts optimizing network performance before assessing security exposure has their priorities wrong. A firm can operate with missing documentation or slow systems. It cannot operate after a ransomware event or a regulatory breach notification. Security assessment should come first, always. Ask specifically: what do you look at in the first week of a new financial services engagement?

Do they understand FINRA, GLBA, and Regulation S-P requirements specifically?

Your IT provider doesn’t need to be a compliance consultant, but they should know what Regulation S-P’s amended requirements mean for your M365 configuration, what GLBA’s Safeguards Rule requires in your specific environment, and how to structure documentation that will satisfy a FINRA examination. If they can’t explain how their service maps to these frameworks, they’re working from general IT knowledge rather than financial services IT experience.

What is their standardized security stack, and can they articulate it?

A mature financial IT provider deploys a consistent, documented security stack across all clients rather than a patchwork of tools chosen client by client. Ask for the specific toolset:

1. What EDR platform do they use?
2. What email security solution do they use?
3. What backup technology do they use?
4. What patch management system do they use?

Ask whether it includes managed detection and response (MDR), meaning a human team monitoring alerts, not just software. The tools matter, but the human response layer behind them matters more.

How do they handle clients who resist recommended security controls?

This question reveals how the provider operates in a regulated environment. The right answer: they explain the risk clearly, and if the client still declines, they document the declination in writing; a signed acknowledgment that the control was recommended, the risk was explained, and the client chose to defer. In a regulated environment, undocumented security decisions are liabilities for everyone involved. A provider who lets resistance go silently is a liability for your firm.

Can they pre-establish escalation contacts for your critical vendors?

Financial firms rely on custodians, CRM platforms, portfolio management systems, and practice management software that a general IT provider has never touched. Your IT partner should have pre-established escalation contacts for Redtail, Orion, Schwab, Fidelity, and whatever platforms your firm uses, before you need them. An IT team calling a custodian’s general support line during an incident is losing hours that a firm with pre-established relationships would spend on resolution.

About Alliance Tech: Your St. Louis Financial IT Services Firm

Alliance Tech has been serving financial services firms in St. Louis for over 24 years. We specialize in IT and cybersecurity for RIAs, wealth management firms, broker-dealers, CPAs, and insurance brokers; regulated environments where the standard for IT isn’t operational reliability alone, but compliance readiness, audit documentation, and the ability to respond when something goes wrong.

Our standardized Armada security stack, deployed across all financial services clients, includes endpoint detection and response, managed detection and response (MDR), email security, encrypted backup with documented restore testing, and patch management. We are an Inc. 5000 company, a Microsoft Silver Partner, a certified Sophos Gold Partner, and the #1 Invicti/Acunetix partner in the United States.

You can read more about our awards and certifications here: Our Leading IT Credentials, Awards & Certifications. We serve financial firms throughout the St. Louis metro, including Clayton, Chesterfield, Kirkwood, Ballwin, and St. Charles County, as well as Grand Rapids, Michigan, and clients nationwide.

If you’d like a complimentary security assessment of your firm’s IT environment mapped against Regulation S-P, FINRA, and GLBA requirements, we’re happy to take an honest look at where things stand.

Call (314) 649-8888 or fill out the form to book an assessment. We respond quickly and give you a straightforward read on your environment.