What should an RIA request before a first prospect call?

An RIA should request only the information needed to decide whether a first prospect call is useful, then ask for detailed records through an approved channel when a defined planning task requires them. Separate scheduling, fit and document review. A first-call form should not become an unplanned store of tax returns, account statements and family information.

This is an educational workflow for US advisory firms, not a legal opinion or cybersecurity assessment. Have the relevant compliance and security professionals review your firm's actual process. The SEC rules discussed below concern the institutions within their scope; do not apply them indiscriminately to every person using the RIA label.

What decision should the first form support?

The first form should support the next decision, not every decision the firm may eventually make. Start by writing what the person receiving it needs to learn.

For scheduling, that may be a suitable contact method and meeting availability. For an initial fit conversation, it may be a plain description of the question, the services sought and the jurisdiction relevant to the engagement. For actual planning, the information may be more detailed. These are different stages. Combining them can make it hard to explain why a sensitive field appears before the firm has agreed to any work.

Ask your team to finish this sentence for each field: "We need this now because it changes this decision." If the answer is that it might be useful someday, consider deferring it. This is an editorial and operational test, not a claim that every deferred field is legally prohibited.

Avoid promising that the first form determines suitability for an investment or establishes an advisory relationship. If it only sorts questions for a call, say that. Readers should understand what will happen next and what has not happened yet.

How can requests be staged without making the prospect repeat everything?

Keep the initial summary and add detail when a named task requires it. Staging should reduce unnecessary collection without forcing the prospect to start over.

A staff member can carry the summary into the meeting agenda, then confirm it with the prospect. If the call identifies a planning question, the professional responsible for that work can explain which records are needed, why they matter and how to provide them. Do not ask for an entire financial archive when a narrower record would answer the question.

A staged workflow also needs an exception path. A prospect may paste sensitive details into a free-text field even if nobody requested them. Decide beforehand who receives that submission and how the firm handles it under its policies. Do not rely on "please do not send sensitive information" as the whole control.

If your system offers an upload button, inspect what it actually does. Identify storage, notifications, forwarding and access. A form that sends documents into a shared inbox has a different operational footprint from one that places them in a controlled document workflow. The label on the button does not prove the underlying process.

What belongs in a prospect information-request worksheet?

Record purpose, channel, access and follow-up for every field or document request. This makes the request inspectable before it is placed on a live form.

Add the responsible person, review date and applicable policy reference in your internal record. Those fields do not need to become marketing copy. The prospect needs a clear request and explanation; the firm needs a record of the process behind them.

Use the worksheet to review existing forms too. Old optional fields can remain in a template long after their purpose disappears. A field being optional does not answer what happens if someone fills it in.

How does Regulation S-P affect this review?

Check the firm's actual regulatory status and the rule's definitions before deciding which legal duties apply. Do not treat a general intake checklist as a substitute for that analysis.

The SEC's guide to the Regulation S-P amendments describes safeguards and incident-response requirements for covered institutions, including investment advisers registered with the Commission. It addresses customer information, sensitive customer information and oversight of service providers. Those terms have specific meanings in the rule.

The adopting release provides the definitions and requirements that the firm's compliance team should inspect. The practical question is not simply whether a person is called a prospect or client in the CRM. Ask which information and relationship are involved, which rules apply to the firm, and what the firm's procedures require.

This article does not supply a legal retention period, a notice schedule or a classification decision for your firm. It also does not say that state-registered advisers have the same SEC rule obligations. Ask qualified counsel or compliance staff about applicable federal, state and other requirements instead of copying a notice from another firm.

The point of the worksheet is to make that review easier: the reviewer can see what is collected, why, where it goes and who can reach it. A vague description such as "our CRM handles it" is not the same information.

What should the prospect-facing explanation say?

Describe the actual purpose and next step in plain language. Do not advertise security or confidentiality that the workflow has not been reviewed to support.

For example, a fictional scheduling form might say: "Describe the question you want to discuss. Please do not include account numbers, tax returns or passwords in this field. If records are needed for an agreed planning task, we will explain how to provide them." This is example wording, not approved privacy language for every firm.

Have the compliance reviewer reconcile the wording with the firm's privacy notices and actual practices. The SEC's 2019 staff risk alert reported issues involving privacy notices and safeguard policies, including notices that did not accurately reflect practices and policies that did not address actual personal-device use. It is historical staff examination guidance, not a new rule or a current incident claim about your firm.

That source illustrates the danger of reviewing language separately from operations. A policy can sound careful while a notification email still carries unnecessary personal details. Inspect the actual notification, not only the form screenshot.

What should be checked when a vendor touches the request?

Map the vendor's role in the real workflow and have the appropriate reviewer assess it. A familiar brand or a paid subscription does not complete that check.

Identify what the vendor receives, where the firm retrieves it and which employees or other service providers have access. Inspect integrations, automated forwarding and export paths. Review who can change the form and who receives an alert when something changes.

The SEC amendment guide describes service-provider oversight within the covered institution's incident-response procedures. It does not mean this article can certify a scheduling product or approve a vendor contract. Your firm's security and compliance review should evaluate the product, configuration and agreement actually used.

For a small firm, write down the handoff when an administrator leaves or a contractor finishes a project. Otherwise the person who understands the intake system may be gone while access remains. This is a proposed operational practice, not a claim about how often that happens.

How can you test the request before it goes live?

Run a synthetic submission through the whole path and inspect every place it appears. Do not use real prospect records to test a form.

Test normal input, an empty optional field, a long question and a harmless fake document if uploads are in scope. Check confirmation text, staff notifications, vendor storage, the assigned recipient and the follow-up process. Confirm that the public wording describes those observed results.

Ask what happens when the prospect abandons the form or requests a correction. Do not invent a deletion promise without checking the firm's obligations and the systems involved. Keep the test evidence and version with the internal worksheet so a later form change can be reviewed against it.

This complements the solo-RIA automation guide: an automation should carry a defined process, not create a new information flow nobody owns.

What does a completed worksheet not prove?

It does not prove legal compliance or system security. It shows that the request and its handling assumptions are visible for review.

An unverified vendor configuration, unresolved policy question or missing recipient check should remain an open item. Review again when the form, vendor, staff access or planned use changes. A clean first-call page is useful only if the handling process behind it stays consistent with the explanation.

The bottom line

Start with the next decision and request the information it needs. Define the purpose, handling path and responsible person before collecting more. A smaller request is not enough on its own, but it makes the actual process easier to explain and review.