How to Handle Customer Data Securely During Onboarding

To handle customer data securely during onboarding, collect only the fields you need, move them through one approved channel, keep credentials and personal data out of chat and email, limit who can see them, and delete or return everything when the engagement ends. Most onboarding data incidents are not sophisticated attacks. They are a spreadsheet in an inbox, a password pasted into a channel, or an export that nobody remembered to delete. This guide gives implementation teams a practical set of rules, the legal basics behind them, and a checklist to run on every engagement.

What counts as customer data during onboarding?

Customer data in onboarding is anything the customer gives you that identifies a person, a business or a system. That includes far more than the files in your import template.

In practice it falls into four groups:

• Personal data: names, emails, phone numbers, job titles and employee or end-customer records inside migration files.
• Business-confidential data: pricing, contracts, org charts, roadmaps and process documents shared during discovery.
• Access material: admin logins, API keys, SSO metadata, test-account passwords and VPN details.
• Conversation data: call recordings, transcripts, screenshots and chat threads where all of the above get mentioned casually.

The fourth group is the one teams forget. A kickoff recording can contain more sensitive detail than the file it discusses, which is why it needs the same handling rules.

Why is onboarding a high-risk moment for customer data?

Because it is the point where the most data moves between the most people with the least structure. Files are exchanged in bulk, access is granted quickly, and several tools hold copies at once.

The numbers explain why customers worry. IBM's 2026 Cost of a Data Breach study, covering 602 organizations, put the global average breach cost at $4.99 million, and found that only 37% of breached organizations encrypted sensitive data both at rest and in transit. Coverage of the same report notes that customer personal data appeared in 52% of breaches, that supply chain compromise ranked second among attack vectors, and that breaches took an average of 247 days to identify and contain.

Vendors are a growing part of that picture. Verizon's 2025 Data Breach Investigations Report, which analyzed 12,195 confirmed breaches, found third-party involvement had doubled to 30%. SecurityScorecard's analysis of 1,000 breaches put the third-party share at 35.5% for 2024, and called that figure likely conservative.

When your customer's security team reviews you, they are not being difficult. They are reacting to a pattern in which a vendor like you is the weak link in roughly one breach in three. If you also need to pass their review before access is granted, see our guide to customer IT access and security reviews during onboarding.

What does the law expect from you as the vendor?

If you process a customer's personal data on their behalf, you are usually a processor under GDPR, and the customer is the controller. That means a written contract, documented instructions, appropriate security and a return-or-delete obligation at the end. This is general information, not legal advice, and US state privacy laws and sector rules such as HIPAA add their own requirements, so involve counsel for regulated customers.

The provisions that matter most to an implementation team are short:

• Article 28: the processor relationship must be governed by a written contract that requires processing only on documented instructions, confidentiality for staff, Article 32 security measures, prior authorization for sub-processors, and, at the controller's choice, deletion or return of all personal data after the services end.
• Article 5: data must be "adequate, relevant and limited to what is necessary", kept identifiable "for no longer than is necessary", and processed with "appropriate security".
• Article 32: examples of appropriate measures include pseudonymisation and encryption and a process for regularly testing their effectiveness.
• Article 33: a controller must notify the regulator "not later than 72 hours after having become aware" of a breach, and a processor must notify the controller "without undue delay".
• Article 83: infringements of the basic processing principles can bring fines of up to 20 million euros or 4% of worldwide annual turnover, whichever is higher.

The practical consequence is the 72-hour clock. If a customer file is sitting in an unknown number of inboxes, you cannot tell them quickly what was exposed. Tight handling is what makes a fast, accurate notification possible.

How do you decide which customer data you actually need?

Ask for the minimum that lets you configure, migrate and test, and say why for each item. Data minimization is both a legal principle and the cheapest control you have, because data you never receive cannot leak.

Run every request through the same three questions: which task needs this field, can masked or sample data do the job, and who on our side needs to see it. Most onboarding work can start from a small, representative sample rather than a full production export.

For the migration step itself, our guide to customer data migration in SaaS onboarding covers the cutover plan, and data mapping in SaaS implementation explains how to work from a sample.

How should customers send you files and credentials?

Through one channel you have agreed in advance, never through whichever method is quickest on the day. The rule is simple: decide the channel before kickoff, tell the customer in writing, and refuse the exceptions politely.

Whatever mechanism your company approves, such as your product's own import tool, an encrypted file-transfer service or a storage location with expiring links, it should meet five tests:

1. The customer can send files without creating a personal account on your side.
2. Access is limited to named people on your team, not a shared mailbox.
3. Links expire, and files are deleted on a schedule you set.
4. Files are encrypted in transit and at rest.
5. You can see who opened what and when.

Credentials need stricter rules still. Ask for scoped service accounts instead of an administrator's personal login, send secrets through a password manager or a one-time secret link, and never accept a password in an email thread or a channel message. The Cloud Security Alliance, republishing DoControl's list of SaaS data risks, flags exactly this family of problems: sharing permissions that stay active indefinitely, "anyone with a link" settings, and personal email accounts used for company data. The list dates from 2022, but the failure modes have not changed.

For a ready-made set of written rules to hand customers, adapt the data section of your customer onboarding SOP.

How do you keep customer data safe in Slack channels?

Treat the shared channel as a place for decisions and questions, not for data. Put the rule in the channel description on day one: no passwords, no personal records, no full exports, and a link to the approved transfer method instead.

It also helps to know who controls what once a channel is shared. According to Slack's documentation on data management in Slack Connect:

• Your retention settings apply only to messages and files your own members send. Content from external people is kept or deleted under their organization's settings.
• Messages can only be edited or deleted by someone from the organization that sent them.
• Paid-plan admins can export data from public channels shared with other companies, and eligible Business+ and Enterprise owners can apply to export private channels and DMs with external people.
• On Enterprise plans, org owners can use eDiscovery and DLP tools to review content in Slack Connect channels.

Two controls are worth setting before the first customer message. Members can upload files to Slack Connect channels by default, but admins can turn uploads off workspace-wide, organization-wide, or per external organization. And because retention is set per workspace, deleted messages and files cannot be recovered, so agree retention with legal before you rely on it for evidence of what was promised.

Our posts on using Slack Connect with customers and on Slack Connect security reviews go deeper on setup and what customer IT teams ask.

What about call recordings, transcripts and AI tools?

Recordings and transcripts are customer data, so they inherit every rule above: consent, minimum access, a retention period and deletion. The extra risk is sprawl, because one call can end up in a recorder, a transcript tool, a summary document and a chat thread.

Before you use any notetaker or AI assistant on customer calls, confirm four things: whether the customer has agreed to recording, where the transcript is stored, whether the vendor may use it to train models, and how it is deleted. Our guide to AI notetakers and customer call consent walks through the consent questions.

The same logic applies to how you keep track of what was agreed. Tools that read customer Slack channels, Stipulate among them, build their record from conversations the customer already had with you, so commitments stay linked to the source message instead of being copied into yet another spreadsheet. Whatever tool you choose, ask where data is stored and who can query it.

How do you close out customer data when onboarding ends?

Run an explicit offboarding step before you declare go-live finished. Article 28 requires the processor to delete or return personal data at the controller's choice once the services end, and the habit is worth building even where no regulation forces it.

Use this closing routine for every engagement:

1. List every location that holds customer data: transfer area, local downloads, sandboxes, recordings, transcripts, and shared drives.
2. Delete migration source files after the customer confirms the load is reconciled.
3. Remove temporary accounts, API keys and shared links, and rotate any credential that was shared.
4. Confirm retention for recordings and transcripts, and delete what is past its period.
5. Send the customer a short written confirmation of what was deleted and what was retained, and why.
6. Note the date in your project record so the next audit does not start from scratch.

Do this at the end of the hypercare window rather than at go-live, because customers often ask for a re-run of a load in the first weeks. Our guide to hypercare after go-live covers that period.

What is a one-page data handling checklist for every engagement?

Use this as the standard block in your kickoff plan and review it at each milestone.

What are the next steps?

1. Pick one approved transfer method for customer files and one for credentials, and write them into your kickoff template.
2. Add a "data requested and why" column to your onboarding questionnaire so every field has a stated purpose.
3. Switch sandboxes and UAT to masked or synthetic data by default.
4. Paste the no-credentials, no-records rule into your customer channel description, and decide on Slack Connect upload settings.
5. Build the offboarding routine into the hypercare exit criteria, and send your next customer a deletion confirmation.

None of this adds much work per engagement. It adds a few written decisions up front, and it turns a customer's security questions from a stall into a quick yes.