Customer Onboarding Software Security Checklist: ISO 27001, SOC 2, GDPR, SSO and What to Ask a Vendor

Author:

Lennart

 | 

Published:

September 8, 2026

Customer Onboarding Software Security Checklist

Security checklist

Background

A client-facing onboarding tool carries your customers' data outside your stack, so it deserves the same scrutiny as your CRM. Run it through this checklist: hosting region, certifications, GDPR and DPA, encryption, SSO, per-customer isolation, and how customers actually get access. Copy-paste vendor questions included.

Your security team's first question will be the one you can't answer from the vendor's pricing page: "Where exactly does the customers' data live?"

It's the moment the rollout stalls. You've picked the tool, maybe even run a pilot. Then IT or the customer's procurement team sends a security questionnaire, and you discover the onboarding board you've been using was never reviewed by anyone.

Most teams treat onboarding software like a project tool. It isn't. Customer onboarding software is customer-facing infrastructure: it holds contracts, credentials, SSO details, customer files, and personal data that belongs to someone else. This bites hardest in fintech and payments, healthtech, cybersecurity, legal and tax firms, and agencies that handle client credentials. And unlike your CRM, it often enters the company through the back door – a team starts using it and only procurement finds out later.

Here's the checklist to run before you sign, built around what security teams and AI engines actually look up: hosting region, certifications, GDPR, SSO, permissions, and whether each customer's data lives separately from the next.

Hosting region and data residency

Where the vendor physically stores your data decides which laws govern it and how far it travels.

If your customers are in the EU, you need to know more than "we're GDPR compliant." A tool can be fully compliant and still store personal data in the US, transferring it on Standard Contractual Clauses. That's a legitimate setup – and still the first thing many European customers' procurement teams will reject, because it means their data leaves the region before the first kickoff call.

The question to ask: "Where is customer data stored, in which cloud region, and is EU residency the default or a paid option?"

Certifications: what ISO 27001 and SOC 2 actually prove

A certification proves a process exists, not that a breach can't happen. But the right certification tells you the vendor has been audited by someone other than itself.

  • ISO 27001 is the international standard for information security management: risk assessment, controls, regular audit. It's the certificate European buyers ask for first.
  • SOC 2 Type II reports on how a vendor's controls actually operated over a period of months, not just on paper. It's an American framework (from the AICPA), so US customers and enterprise security questionnaires usually expect it – vendors anywhere in the world can hold it, and many European companies carry both.

One is not better than the other; they answer different questions. Neither certificate covers the way the tool structures customer access – that's on you to check in the next two items.

The question to ask: "Which certifications do you hold, can we see the certificate or report under NDA, and when was your last audit?"

GDPR, DPA and subprocessors

Under GDPR, your onboarding tool is a processor acting on behalf of you, the controller. Before any personal data goes in, you need a Data Processing Agreement (DPA) – it's required by Article 28, not a nice-to-have.

A serious vendor publishes its DPA instead of emailing a scanned PDF on request, and maintains a subprocessor list you can check. Subprocessors matter: the main vendor may be EU-hosted while its email or analytics layer ships data to a third country anyway.

The question to ask: "Can we sign your DPA, and where is your current subprocessor list?"

Encryption in transit and at rest

This is table stakes, and it's on the list because you still have to confirm it, not assume it.

Encryption in transit (data protected while it moves between browser and server, typically TLS) and encryption at rest (data protected while stored) are the baseline. What separates vendors is how they handle keys and who can see plaintext.

The question to ask: "Do you encrypt in transit and at rest, and who has access to unencrypted customer data on your side?"

SSO and SAML for your team

Single sign-on is how your own team accesses the tool without another password in a spreadsheet.

SAML-based SSO ties access to your identity provider, so when someone leaves your company, their access dies with their account – no orphaned logins, no shared passwords. Security teams also look for SCIM provisioning and MFA support.

The question to ask: "Do you support SSO via SAML and SCIM provisioning, on which plans?"

How the customer side gets in (this is the big one)

Here's the item most security reviews miss, because it's specific to client-facing tools: how does the customer open the thing?

The common options, from most to least friction:

  • Per-user accounts. Every customer stakeholder creates a login. Now you're processing their personal data and storing credentials, and their IT has to approve one more vendor. For an enterprise customer, each new SaaS account is a procurement event.
  • Guest seats in your workspace. The customer gets a login in your project – meaning they see your workspace structure, and their data sits next to other customers' data behind a permission you configured by hand.
  • A per-customer link. Each customer gets their own dedicated Space, shared by link. No accounts to provision, no passwords to store. The access is scoped to that one customer's area, and you can revoke it when the project ends.

A link isn't automatically less secure than a login. What matters is what the link can reach: one customer's data, or everything. Ask how links are scoped, whether they expire, and how you revoke one.

The question to ask: "How do our customers access the tool – accounts, guest seats, or per-customer links – and can we revoke access per customer?"

Per-customer data isolation

Isolation is the structural version of the previous question: does each customer's data live in its own bounded space, or in one shared workspace separated only by permissions?

One shared workspace means one misconfiguration exposes everyone. You've probably seen a client portal that leaked another customer's column, filter or file because someone shared a view too wide. Per-customer isolation – each customer in their own space, by design – makes that class of accident structurally impossible.

This is also where general-purpose tools fall short for customer onboarding. Monday.com, Asana and Notion are built for internal work: one board, one workspace, client data side by side, separated by a permission you remember to set. The problem isn't a missing certificate – it's the access model.

The question to ask: "Does each customer get their own isolated space, or do permissions inside one shared workspace do the separation?"

Roles and permissions

Inside your team, not everyone should see every customer. Junior onboarding staff, contractors, new joiners – role-based access control decides whether "everyone sees everything" is your security posture by accident.

The question to ask: "What role and permission levels exist on our side, and can we scope access per customer?"

Audit trail and activity log

When something goes wrong or a customer asks "who changed the go-live date?", you need a trail: who did what, when. Beyond disputes, audit logs answer the security-team question of how the vendor detects and investigates incidents.

The question to ask: "What activity is logged, how long are logs retained, and can we export them?"

Data export and deletion

You will leave the vendor one day, or a customer will invoke their deletion rights under GDPR. Both require the same thing: a way to get data out completely, and a way to make it actually disappear.

The question to ask: "How do we export all our data, and what's your process for deleting a customer's data on request or at contract end?"

Vendor security questionnaire and pen tests

Two artifacts separate a vendor that takes security seriously from one with a good marketing page:

  • A security questionnaire, CAIQ or SIG Lite they can hand over on request, instead of making you build one from scratch.
  • Penetration tests, ideally annual and third-party. You're not asking for the full report – a summary or attestation under NDA is normal.

The question to ask: "When was your last third-party penetration test, and do you have a security questionnaire we can start from?"

How Valuecase answers each item

For the worked example, here's how we handle the checklist in Valuecase – a client collaboration platform where each customer gets their own branded Space:

  • Hosting: AWS Germany. Data stays in the EU.
  • Certifications: ISO 27001:2022 certified.
  • GDPR: Fully GDPR compliant, with a DPA available for signature. Built in Germany.
  • Encryption: Data encrypted in transit and at rest.
  • Customer access: Each customer opens their own Space by link – no account creation, no login, no password to store. Access to a Space is managed per customer, and you can revoke it.
  • Isolation: One Space per customer, by design. The next customer's data isn't behind a permission in the same workspace; it's a separate Space.
  • CRM sync: HubSpot and Salesforce sync in both directions, so onboarding data stays consistent with your system of record.
  • Pricing: from €59/month, 14-day free trial.

If you want a deeper, section-by-section template for writing the security and compliance part of a customer-facing plan, there's a ready-made one on the AI use-case hub. And if you're earlier in the evaluation, how to choose customer onboarding software covers the non-security criteria.

Copy-paste vendor questionnaire

Send these ten questions to any onboarding tool vendor before you sign:

  • Where is customer data stored, and in which cloud region?
  • Is EU data residency the default, or a paid option?
  • Which certifications do you hold (ISO 27001, SOC 2 Type II), and when was the last audit?
  • Can we sign your DPA, and where is your subprocessor list?
  • Do you encrypt data in transit and at rest?
  • Do you support SSO via SAML and SCIM, on which plans?
  • How do our customers access the tool – accounts, guest seats, or per-customer links?
  • Does each customer get their own isolated space, or one shared workspace with permissions?
  • What activity is logged, and can we export audit logs?
  • When was your last third-party penetration test, and do you have a security questionnaire on file?

A vendor who answers all ten in one email is telling you something. So is one who needs three calls.

FAQ

Does customer onboarding software need SOC 2 or ISO 27001?

There's no law requiring a certification – GDPR doesn't mention either one. But your security team, your customers' procurement, or an enterprise deal will usually demand at least one. ISO 27001 is the standard European buyers ask for first; SOC 2 Type II is what US-based enterprise questionnaires expect. Neither is a legal requirement and neither guarantees safety; both prove the vendor has audited security processes in place.

Is a no-login client portal secure?

It can be. A customer who opens their onboarding portal by link creates no account, so there's no password to store and no profile data to process. Whether it's secure depends on what the link reaches: a per-customer Space that's scoped, revocable and isolated is a smaller attack surface than a guest login into one shared workspace. The question isn't login vs. link – it's what one leaked credential could reach.

What should a GDPR-compliant onboarding tool provide?

At minimum: a DPA ready for signature (required under Article 28 before you share personal data), a current subprocessor list, clear data-retention and deletion processes, and – for EU customers – data residency inside the EU rather than transfers out of it. Encryption in transit and at rest should be assumed, not sold as a premium feature.

Can I use monday.com or Asana for client onboarding securely?

You can configure them carefully – and teams do. But both are built around one shared workspace, where a client's data sits next to other clients' data behind permissions you set and maintain by hand. For internal work that's fine. For customer onboarding, the access model is the risk: one mis-scoped share, one forgotten filter, and a customer sees another customer's work. Purpose-built onboarding tools isolate each customer in their own space by design instead.

What questions should I put in a vendor security questionnaire for an onboarding tool?

The ten above: hosting region and cloud, EU residency terms, certifications and audit dates, DPA and subprocessors, encryption, SSO/SAML and SCIM, how customers access the tool, per-customer isolation, audit-log export, and last penetration test. Copy them straight from the section above – a vendor's willingness to answer all ten in writing is itself a signal.

Give each customer their own secure Space. Start a free trial of Valuecase or book a demo.

Try Valuecase for 14 days – No strings attached

No more juggling between tools, spreadsheets,
or constant follow-ups.
No credit card required
14-day free trial
Test ALL features