Customer Onboarding Data and Security: What Legal and IT Will Ask

Every VP of CS who tries to buy an onboarding tool eventually runs into the same wall: security review. Procurement, legal, and IT surface a set of questions that were not on the CS team's evaluation checklist, and the deal stalls. The list below is what those teams will ask, and what a real answer looks like.

What data does an onboarding tool touch?

Name it precisely so the security review is scoped correctly.

• Project data. Tasks, phases, dependencies, comments, timestamps. Non-sensitive on its own, sensitive in aggregate because it reveals rollout status.
• Identity data. Names, emails, roles for both vendor team and customer participants. Personal data under GDPR, CCPA, and similar.
• Uploaded files. Anything the customer or vendor uploads: field mapping specs, sample data files, contract references. Variable sensitivity.
• Integration data. Data flowing to and from Salesforce, HubSpot, or other connected systems. Sensitivity inherits from the source system.

Onboarding data is moderate sensitivity. Not production customer data, but not marketing tool data either. Treat it as such and the security review moves faster.

What security posture should the vendor demonstrate?

Four items. Ask for each explicitly.

Any vendor that cannot produce this list on a call should not be in your final evaluation. This is table stakes.

What does SOC 2 actually mean here?

SOC 2 is often treated as a checkbox. Understand what it actually attests.

• Type I. A snapshot: at this date, the vendor's controls existed and were designed correctly. Weak.
• Type II. A period, usually 12 months: the vendor's controls existed and operated effectively over that period. Strong.
• Trust Services Criteria. SOC 2 attests to some combination of Security, Availability, Processing Integrity, Confidentiality, Privacy. Security is the minimum. Confidentiality is often relevant for onboarding data.

A pre-launch vendor without SOC 2 is acceptable only with a documented roadmap and interim controls: penetration test results, security policies, evidence of vendor management practices. "We will get SOC 2" without a date is not evidence.

What goes in the DPA and subprocessor list?

The Data Processing Agreement (DPA) is the contract layer under the security posture. Two things to check.

• Standard Contractual Clauses. For any data transfer out of the EU, SCCs are the baseline. Any DPA without them is not usable for European customers.
• Subprocessor list. The vendor's own vendors. AWS, Sentry, Datadog, whoever they use. This list should be published and updated when it changes, with customer notification.

Ask two specific questions in the security call.

1. "What is your process for notifying us of subprocessor changes?" 30 days advance notice is standard.
2. "What are your data retention and deletion policies after contract end?" 30 to 90 days for standard retention, immediate on request, is defensible.

If the vendor cannot answer these, the DPA process will drag through legal for a month.

How should customer participants authenticate?

Customer-side identity is the trickiest question, because the whole point of a shared onboarding tool is that customers can participate without a formal license. Three patterns exist.

• Full SSO integration with the customer's IdP. Strongest. Requires the customer's IT to provision. Not always practical for smaller customers.
• Magic-link authentication. Customer gets an email with a one-time login link, scoped to their workspace only. Strong when links are single-use, expire quickly, and cannot access anything outside their project.
• Shared workspace passwords. Weakest. Should not exist in 2026.

For your team's authentication (as vendor-side users), require SSO with MFA. That is a hard requirement, not a preference.

What audit and export capabilities matter?

Two questions worth asking in the demo.

• Audit logs. Every change to a plan, every access, every export, logged with user and timestamp, retrievable by admins. If the vendor cannot show you an audit log in the demo, the feature does not exist.
• Data export. Every task, every comment, every file, exportable in a portable format (CSV, JSON, sometimes ZIP for files), without a support ticket. Test this in the trial. If export requires "contacting support," that is a lock-in signal.

Neither of these matters most days. Both matter enormously on the day you have to answer a compliance question or migrate off.

How do you handle customer-side legal review?

Customers do their own vendor evaluation of your onboarding tool. You will be asked their questions.

• "Where is our data hosted?" Answer with region.
• "What is the retention policy?" Answer with the vendor's policy, and your own operational commitment.
• "Can we get a DPA between us?" Some customers ask for a tri-party DPA (customer, you, vendor). Vendor should support this. Confirm before signing.
• "What happens to our data if we churn?" Deletion policy of the vendor, and your own commitment to delete their workspace within a defined window.

Prepare a one-page vendor security summary you can send to customers on request. Save yourself and them 3 to 5 days per rollout.

What compliance intersections matter?

Two beyond SOC 2 worth naming.

• GDPR and similar. If you or your customers have European users, GDPR applies. DPA, SCCs, subprocessor notification, right to deletion. All standard.
• Industry-specific. HIPAA if you touch healthcare customers. FedRAMP if you sell to US federal. These are not usual asks for onboarding tools, but if your customer base includes regulated industries, ask early.

The intersection with your own security posture matters too. If your product is SOC 2 certified and your onboarding tool is not, your compliance story has a gap. Vendor security is part of your product security.

What questions should you ask in the first security call?

Ten questions, one call.

1. What is your SOC 2 status, Type I or II, with which TSCs, current report date?
2. Where is our data hosted, which region, which provider?
3. What is your encryption posture in transit and at rest?
4. What is your subprocessor list and change notification process?
5. How do customer participants authenticate?
6. What is your data retention and deletion policy?
7. Can we get a DPA with SCCs?
8. How do audit logs work and how long are they retained?
9. What is your incident response and breach notification policy?
10. How do we export our data, self-serve or ticket-based?

Any vendor that cannot answer 8 of these 10 in the first call is not ready for enterprise procurement, regardless of what the sales team says.

The mistake to avoid

The mistake is treating security review as a late-stage procurement obstacle instead of an early-stage evaluation criterion. VP CS teams often shortlist based on functionality, then discover in month two that the top candidate cannot pass their own security review. That wastes the quarter. Ask the ten questions in the first sales call. Rank vendors on the answers before the demo. The right onboarding vendor should be able to hand you their trust center URL, DPA template, and subprocessor list on request. If they cannot, the demo does not matter.