Customer confidentiality clauses and your data

Most B2B companies signed confidentiality terms with at least some of their customers. Before licensing operational data, it is worth knowing which customers those are and what the clauses actually say. The answer will not stop most licences, but it often shapes the scope, and it is much easier to deal with on day one than after an evaluation.

This post explains where these clauses show up, why they matter for a data licence, and the practical options companies use to handle them. It is general information, not legal advice; how a particular clause applies is a question for your counsel.

Confidentiality obligations rarely sit in one place. A single customer relationship might involve a master services agreement, a separate non-disclosure agreement signed during the sales process, a data processing agreement, order forms and a statement of work. Each can carry its own definition of confidential information and its own limits on use.

For companies that sold to larger enterprises, the customer's paper often governed. Those terms can be broader than a startup's own template, and they sometimes include specific restrictions on using customer data to develop products or train systems.

A smaller number of customers may never have signed anything beyond standard online terms. Those relationships are usually simpler, but they are still worth noting so nobody assumes later that every customer was checked.

Operational data is full of customer material. A support ticket quotes a customer's message. A Slack channel discusses a customer's rollout. A shared folder holds a customer's spreadsheet. The CRM records who said what on each call.

Anonymization changes what that material looks like. Every person, company, email, phone number and account becomes a consistent token, so the customer's name and its people disappear from the dataset. Credentials, card numbers and government IDs are removed outright, and logos and signatures are blacked out in documents.

But a confidentiality clause may cover more than names. Some clauses protect the substance of what the customer shared, such as its pricing, its internal processes or its product plans, regardless of whether the customer is identified. Whether anonymization is enough for a given clause depends on its wording, which is why the clause needs to be read rather than assumed.

In practice, companies usually land on one of three approaches for each customer whose terms raise a question.

• Exclude the customer. The simplest option is to leave that customer out of scope across every tool: its channels, folders, projects, repositories and email threads. Exclusions are annexed to the contract before any data moves, so the boundary is fixed from the start.
• Exclude only the sensitive material. Sometimes the concern is narrower, such as a shared folder containing the customer's own documents or a repository holding its code. Excluding those and keeping the tokenized day-to-day work can protect the relationship while preserving more of the dataset.
• Keep the customer in scope after review. Where counsel concludes that a customer's terms do not restrict this kind of use of anonymized data, the customer can stay in, subject to the same tokenization as everything else.

Our post on exclusions explains how to describe an exclusion precisely enough that it can be applied and checked.

Excluding customers has a cost. What makes company data valuable is connection depth, the same piece of work traceable across chat, tickets, code and email, and customer projects are often where that depth lives. Imagine a 50-person implementation consultancy whose three largest clients all used enterprise paper with strict terms. Excluding all three might remove the best-connected projects in the archive.

That is not a reason to keep a customer in scope against advice. It is a reason to do the review early and to look for the narrowest exclusion that addresses the concern. Excluding a customer's own documents may be enough, while the internal discussion about the work, already tokenized, can stay. Counsel can tell you which approach fits each clause.

The read-only evaluation, which takes under an hour of the seller's time, measures only what is in scope. If you decide on exclusions before it runs, the estimate reflects the dataset you will actually license.

You do not need to read every contract the company ever signed. A focused review usually starts with:

• A list of the customers that account for most of the activity in Slack, Jira and email over the period in scope
• The governing agreements for those customers, including any separate NDA or data processing terms
• A note of which clauses restrict use of customer information, and how they define it
• A decision for each customer: exclude, partially exclude or keep in scope after counsel's review

For a company that is winding down, this review may fall to a director, liquidator or assignee who did not negotiate the contracts. A former account manager or operations lead can often find the right documents quickly.

Whatever you decide about individual customers, the licence itself limits what the buyer can do. Use is restricted to training and evaluation. The buyer may never market to, profile, contact or re-identify anyone in the data, and the data is never resold for marketing or people search. No third party touches raw data, and the raw archive is deleted within 30 days of sign-off, with a deletion certificate. More detail on those terms is in what a training-only licence should include.

You also review an anonymized sample before delivery. That is the moment to confirm an excluded customer is genuinely absent and that nothing identifying slipped through.

If you already know which customers might be sensitive, bring that list to the first conversation and we will build the scope around it. Book a 15-minute call to talk through your customers, your exclusions and what remains.