Introduction — The Vendor You Trust Is Now Part of Your Compliance Program
During a routine SEC exam, the CCO at a mid-size advisory firm was asked to produce communications between a particular advisor and a particular client for a two-week window in late 2024. The firm’s archiving vendor responded promptly. The records were missing.
Not because the vendor failed in any obvious way. During that window, the vendor had transitioned a portion of their capture infrastructure to a new sub-processor, and a misconfigured retention policy at that sub-processor caused a small subset of inbound messages to be dropped. The CCO had been notified of the migration months earlier in a routine release note. No one at the firm had read it that way.
The vendor took responsibility. The examiner moved on for the moment. But the question that lingered for weeks afterward wasn’t about the vendor. It was about the firm: how could a recordkeeping gap of that size have existed within the firm’s environment without anyone there knowing about it?
That is the vendor oversight question regulators are now asking, increasingly often, in increasingly direct ways.
For most of the past decade, vendor management lived inside procurement — annual questionnaires, contract renewals, SOC 2 reports filed away in a shared drive. That posture made sense when vendors handled discrete, well-defined services. It does not match the reality firms operate in now.
Today, third-party platforms are not just supporting compliance. In many firms, they are the compliance program. Communication capture, archiving, supervision, surveillance, CRM, cloud infrastructure, AI-enabled workflows — most of the operational surface a regulator examines runs through vendor systems. When a vendor’s posture changes, the firm’s compliance posture shifts accordingly. Often without anyone noticing until an exam.
That is why vendor oversight is no longer a procurement exercise. It is an operational compliance one.
Why Vendor Risk Has Expanded So Quickly
Compliance is now infrastructure-dependent
A typical broker-dealer or registered investment adviser today runs through a stack of third parties: an email and messaging archiver, a separate capture platform for collaboration tools and mobile channels, a cloud storage provider, a supervision platform, a CRM, identity and access management, endpoint security, and increasingly an AI vendor or two layered on top of the workflow.
Each of those vendors typically has its own sub-processors. Each has its own retention defaults, incident response posture, and escalation conventions. None of them know what the others are doing.
The result is a compliance program whose actual control environment is distributed across companies the firm does not run, on infrastructure the firm cannot see directly, and governed by contractual language negotiated before the systems behaved as they do today.
Operational complexity outpaced governance
Most firms’ vendor governance was designed when “the vendor” was a single email archiving company. The questionnaires, the diligence templates, the renewal cycles all assume a periodic point-in-time review.
Operational risk does not move on that cycle. A vendor can change a default, swap a sub-processor, deprecate a connector, or update its data residency posture between annual reviews. Each of those changes can quietly alter the firm’s compliance posture without triggering a contractual notification.
The static-assessment model assumes vendors are stable. The reality is that they are continuously changing — and the firm’s exposure changes with them.
The Shared-Responsibility Gap
Almost every modern compliance failure involving a vendor turns out, on close inspection, to be a shared-responsibility gap.
The firm believes the vendor is responsible for retention configuration. The vendor’s documentation states that the customer is responsible for retention configuration. Both parties are operating in good faith. Neither party is actually configuring it.
The vendor believes the firm has someone monitoring escalation alerts. The firm believes the vendor will route critical alerts directly to the named compliance contact. Neither side has tested the path end-to-end. When an actual incident occurs, the alert lands in a shared mailbox no one reads.
The firm believes the vendor’s WORM storage is set to comply with SEC Rule 17a-4. The vendor’s WORM storage can be configured that way, but the default is something else, and the firm never confirmed the change.
These are not exotic failure modes. They are the most common ones. And they are difficult to detect in advance, because the diligence artifacts the firm relies on — SOC 2 reports, security questionnaires, contractual commitments — describe what the vendor’s systems are capable of, not how they are configured for this customer.
The shared-responsibility gap is where most enforcement matters involving vendors start.
Where Regulators Are Focusing
Regulators have responded to the shift by tightening expectations specifically around third-party operational risk.
SEC Regulation S-P, as amended in May 2024, now requires broker-dealers, registered advisers, and investment companies to maintain written incident response programs that address third-party service providers explicitly — including procedures to ensure that providers themselves take appropriate measures to protect customer information. Larger firms had a December 2025 compliance deadline; smaller firms followed in June 2026. The rule also imposes a 30-day customer notification requirement for incidents involving sensitive customer information, with no carve-out for incidents that originated at a vendor.
FINRA’s Annual Regulatory Oversight Report has flagged third-party vendor dependencies and cybersecurity supply chain risk in each of its last two editions. Recent risk alerts have specifically highlighted advisers’ handling of vendor relationships involving electronic recordkeeping and communications capture.
Books-and-records enforcement — the pressure point firms know best — increasingly turns on vendor posture. A retention gap is a retention gap regardless of where it originated. An incomplete communications capture is a 17a-4 issue whether the missed channel was the firm’s responsibility or a sub-processor’s.
The cybersecurity-and-supervision overlap has also tightened. An incident that begins as a vendor breach can become a recordkeeping issue (if records were lost or altered), a supervision issue (if escalation procedures failed), and a customer notification issue all at once. The 2023 ION Markets ransomware event that froze derivatives processing across multiple firms and the MOVEit breach that affected financial-services vendors throughout 2023 and 2024 both made clear how quickly a single third-party event can ripple through a firm’s regulatory obligations.
The common thread across all of these is that regulators no longer accept “the vendor handled it” as a defense. They expect the firm to demonstrate operational oversight of its vendors, not just contractual coverage.
Why Traditional Vendor Management Doesn’t Catch These Issues
Most vendor management programs were designed to answer one question: did we do appropriate diligence at the start of the relationship? Annual questionnaires, SOC 2 reviews, and contract renewal cycles all operate at that level.
The questions regulators are now asking are different:
- Do you know how the vendor’s system is currently configured for your firm?
- Do you know who at the vendor receives an alert when something breaks, and how that alert is routed to your compliance team?
- Can you produce, today, a complete record of every communication for a given advisor over a given window — across every vendor in the capture chain?
- If the vendor experienced an incident this morning, would your compliance team learn about it in time to meet your own notification obligations?
Few firms can answer those questions cleanly without operational, not procurement, oversight. The diligence file does not contain the answers.
The deeper issue is that compliance teams often lack the technical visibility to evaluate these questions even when they want to. Configuration drift, sub-processor changes, integration handoffs. These are infrastructure-level realities that sit outside the typical compliance officer’s day-to-day field of view. That is not a failing of the compliance team. It is a structural feature of how vendor ecosystems now work.
What Mature Vendor Oversight Actually Looks Like
Firms that have moved past the procurement-only model tend to share three operational traits.
- Dependencies are mapped, not assumed. The firm can show, in a single view, which vendor supports which regulatory obligation — capture, retention, supervision, escalation, notification and which sub-processors sit underneath each. When a vendor announces a change, the firm can immediately see which obligations are touched.
- Oversight is continuous, not annual. Configuration is verified periodically rather than assumed permanent. Escalation paths are tested rather than documented and forgotten. Incident response playbooks are exercised with vendors, not just written about them. The diligence file becomes a baseline, not a finish line.
- Operational interlock is preserved. The firm and the vendor have a shared, live understanding of who is responsible for what — and that understanding is reflected in how systems behave, not just in how contracts read. When an incident occurs, both sides know within minutes who is doing what.
The common thread across all three: less reliance on documents that describe vendor systems, more reliance on direct visibility into how they actually operate.
Where Patrina Fits
There is an obvious irony in writing about vendor oversight as a vendor. The irony is also the point: the same operational traits that make vendor oversight work for a firm are the traits a firm should expect from the vendors it depends on.
Patrina has operated as an SEC-designated third-party recordkeeper since 1993, and the platform is built around the obligations that a firm cannot delegate. The Integrated Compliance Suite brings communication capture, supervision, and recordkeeping into a single environment with a single configuration surface, rather than a chain of sub-processors that a CCO has to track separately. The Message Archiving Platform ships with regulator-grade WORM storage configured to SEC Rule 17a-4 and 17 CFR 1.31 defaults out of the box, not as a customer-side toggle. Singular CRM keeps client-interaction logging within the same compliance perimeter, rather than as a separate vendor with its own escalation path.
The practical effect, for a smaller RIA or independent broker-dealer that does not have an in-house vendor risk function: one fewer set of integration handoffs to map, one fewer escalation chain to test, one fewer shared-responsibility gap to discover during an exam.
That is the version of vendor oversight that works at firms without large governance teams. Not more diligence files. Fewer dependencies that need them.
A Vendor-Tier Self-Assessment for Compliance Leaders
Vendor oversight does not need to be uniform across every relationship. A practical starting point is to sort vendors into three tiers and evaluate the depth of oversight against the tier.
Tier 1 — Compliance-critical vendors. Systems that support a regulatory obligation directly: capture, archiving, supervision, recordkeeping, customer notification. A Tier 1 failure can become a firm failure within days.
- Do you have a current, mapped view of how each Tier 1 vendor supports each regulatory obligation?
- When was the escalation path from this vendor to your compliance team last tested end-to-end?
- Can you reconstruct a full retention timeline for any advisor over any window without depending on the vendor’s goodwill?
Tier 2 — Operationally significant vendors. Systems that support compliance indirectly — CRM, identity, productivity, collaboration. A failure here does not immediately become a regulatory issue, but it can degrade the quality or visibility of evidence.
- Do you know which Tier 2 vendors touch data that ultimately flows into Tier 1 systems?
- When a Tier 2 vendor changes a default or adds a sub-processor, does anyone at the firm see it?
Tier 3 — Support vendors. Everything else: standard SaaS, peripheral tools. Annual diligence is appropriate here.
If you cannot answer the Tier 1 questions confidently, that is where to focus first.
Conclusion — Oversight Is the Job, Not the Contract
Firms can outsource the infrastructure. They cannot outsource the accountability.
Regulators have made that explicit in the rule text and in enforcement guidance. The firms that will absorb this shift well are not the ones with the thickest diligence files. They will be the ones with the clearest operational visibility into the vendors their compliance program actually runs on.
That visibility is what turns vendor oversight from a procurement artifact into a compliance discipline. And that discipline is, increasingly, the difference between a clean exam and a hard one.
FAQs
Why is vendor oversight becoming a compliance issue rather than a procurement one?
Because third-party systems now carry direct regulatory obligations — capture, retention, supervision, and notification — and regulators evaluate firms based on operational outcomes rather than on whether diligence was performed at the start of the relationship.
What does SEC Regulation S-P require in the context of vendor risk?
The amended rule (adopted May 2024, with compliance dates in December 2025 and June 2026 depending on firm size) requires written incident response programs that specifically address service providers and imposes a 30-day customer notification requirement for incidents involving sensitive customer information, with no carve-out for vendor-originated events.
What is the “shared-responsibility gap” in vendor oversight?
It is a recurring failure pattern in which both the firm and the vendor believe the other party is handling a critical configuration, escalation, or monitoring task. The diligence artifacts both sides rely on describe capability, not actual configuration, so the gap is rarely visible until an incident or exam reveals it.
How is mature vendor oversight different from traditional vendor management?
Traditional management is procurement-led, document-based, and annual. Mature oversight is operational, continuous, and tested. It maps live dependencies, verifies actual configurations, and exercises escalation paths rather than assuming them.
What’s the most useful first step for smaller firms with limited vendor governance resources?
Identify the small number of Tier 1 vendors that directly support regulatory obligations, map exactly how each one supports which obligation, and test the escalation path from each vendor to your compliance team end-to-end. Oversight on a handful of critical vendors matters more than thin oversight across all of them.
