What Should a Vendor Due Diligence Questionnaire Cover for RIA Compliance?

TL;DR: A vendor due diligence questionnaire (DDQ) for an RIA should cover five categories: data security and Reg S-P safeguards, subcontractor and sub-processor use, financial stability and business continuity, regulatory history and registration, and — the part most firms skip — a written commitment to ongoing monitoring and notification, not just a one-time snapshot. A questionnaire that only gets sent once, at onboarding, isn't a due diligence program. It's a compliance artifact that ages badly.

I've built and re-built this questionnaire more than once, and the version that actually holds up in an exam isn't the longest one. It's the one that asks a small number of specific questions and then has a plan for what happens to the answers after day one.

What Categories Should a DDQ Actually Cover?

Five categories do most of the work. Everything else is either padding or specific to your firm's vendor mix.

1. Data security and access controls. Does the vendor encrypt customer data at rest and in transit? What's their incident notification timeline? Do they have a SOC 2 Type II report, and how recent is it? This is the section examiners look at first, and it's also the section vendors are best-rehearsed at answering — which is exactly why you need the next category too.
2. Subcontractor and sub-processor disclosure. Who does the vendor share data with downstream? This is the question most DDQs handle worst. A vendor's own security posture can be excellent while a sub-processor three layers down has none of the same controls — and the vendor's public terms of service, not the signed contract, is usually where a new sub-processor addition first shows up.
3. Financial stability and continuity. Can the vendor demonstrate they'll still exist in two years? What's their disaster recovery plan, and have they tested it? This matters less for headline-grabbing breaches and more for the mundane failure mode: a vendor quietly winding down support while your firm still depends on them.
4. Regulatory history. Has the vendor been fined, sanctioned, or subject to enforcement action? Are they registered where registration is required for their function? This is a background-check question, not a technical one, and it's easy to skip because it feels adversarial to ask a vendor you're trying to onboard.
5. Ongoing monitoring commitment. This is the category most DDQs leave out entirely, and it's the one that actually determines whether the questionnaire does anything after the day you send it.

What Does Reg S-P Specifically Require You to Ask?

The amended Regulation S-P puts the compliance burden for vendor-handled client data on the RIA, not the vendor — a breach at a service provider is still your firm's problem to answer for. That reframes what belongs in the DDQ: it's not just "does this vendor have good security," it's "can this vendor meet the specific obligations my firm is on the hook for."

Two questions follow directly from that. First, what's the vendor's breach notification timeline, and does it give your firm enough runway to meet your own client notification deadline? Second, does the vendor's contract language actually commit them to notify you of a breach — or does it only commit them to "reasonable efforts," which is not the same thing in an exam.

Neither of these is answered by a generic security questionnaire template pulled from a vendor's website. They have to be asked in your specific language, tied to your specific obligations.

How Detailed Should Follow-Up Documentation Be?

Answers on a form aren't evidence. Documentation is. For any vendor handling client data or performing a function core to your advisory business, the file behind the DDQ should include the underlying SOC report (not just a mention that one exists), the actual contract language on breach notification and data use, and a record of who at your firm reviewed the responses and when.

This is where firms lose the most ground in an exam — not because the DDQ questions were wrong, but because the file only contains the questionnaire itself, with no evidence anyone verified the answers against source documents. A signed attestation from the vendor that they encrypt data is not the same thing as a SOC 2 report confirming it.

What's the Difference Between an Initial DDQ and Ongoing Monitoring?

They answer different questions, and a defensible program needs both, structured differently. The DDQ is a point-in-time document: a fixed set of questions, sent once at onboarding (or at the annual re-send), producing a signed record of what the vendor represented as of that date. Ongoing monitoring is a process, not a document: a standing mechanism that checks whether the vendor's actual current terms still match what the DDQ file says they agreed to.

The practical gap between the two is scope. A DDQ file typically only gets reopened when someone remembers to reopen it — at the next scheduled review, or after a breach headline prompts a spot check. Ongoing monitoring is designed to surface a change without anyone having to remember to go looking, because vendor terms of service, DPAs, and privacy policies are usually incorporated by reference into the master agreement, meaning the vendor can revise them unilaterally, on their own website, without triggering any contract renegotiation on your end.

Treat the DDQ as the input to a file, not the whole file. Pair it with a documented answer to a second question the questionnaire itself doesn't ask: how does this specific vendor's terms get re-checked in the gaps between formal reviews.

How Often Should You Re-Send the Full Questionnaire?

Annually, at minimum, tied to the firm's overall compliance review cycle under Rule 206(4)-7 — and immediately after any material change you become aware of, such as a vendor breach disclosure, a merger or acquisition involving the vendor, or a significant new sub-processor. For vendors classified as higher-risk (anyone with broad access to client PII or a core role in advisory operations), a semi-annual check-in is more defensible than a purely annual cadence, even if the full questionnaire isn't re-sent each time.

The honest answer, though, is that the re-send cadence matters less than most firms think, because the questionnaire is a snapshot regardless of frequency. The vendor's actual published terms can change between any two re-send dates, and a firm relying solely on the resend schedule to catch that has a gap the schedule itself can't close.

How Legal Sentinel Helps

The DDQ answers what a vendor says about themselves at one point in time. Legal Sentinel handles the part a questionnaire can't: it monitors the vendor's actual published legal documents — privacy policies, terms of service, DPAs, sub-processor lists — on a continuous basis, and flags a material change the same day it happens, rather than waiting for the next re-send cycle to surface it. Its Vendor Intelligence module also extracts and tracks the specific clauses a DDQ asks about — data sharing, sub-processor use, liability caps — across every vendor's document set, so the file behind your questionnaire has something to check answers against beyond a vendor's own attestation. RFG Advisory used this to catch four separate instances of a vendor changing AI training clauses in three months, each flagged the same day the change was published — the kind of gap a DDQ, re-sent even annually, would have missed entirely.

Disclosure: Emily Mora, author of this post, is Cofounder & US Commercial Lead, Legal Sentinel and holds profit-sharing in the company.