Software companies
Selling a cybersecurity software company: telemetry rights buyers check
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
In cybersecurity company acquisition due diligence, buyers check whether customer terms grant rights to use telemetry for detection and model training, where that telemetry is stored, and which models were trained on which customers' data. A seller who can show each right in writing, by contract cohort, avoids holdbacks and late renegotiation.
Key takeaways
- Buyers treat telemetry rights as part of the product's value, not a legal footnote.
- Training rights must be traced to customer terms by contract cohort, including negotiated enterprise redlines.
- Data residency promises reach training copies and analyst exports, not only production storage.
- A model lineage register shows which data trained each detection model and whether a cohort can be removed.
- Third-party threat feeds and channel partner contracts carry their own restrictions.
Why telemetry rights carry so much weight in security deals#
Telemetry rights carry weight in security deals because a security vendor's detection quality is built on the events, samples and verdicts its customers' environments produce. If the rights to use that telemetry are thin, the buyer is paying for a capability it may not be allowed to keep improving.
Telemetry here means more than logs. It includes endpoint process events, network flows, DNS queries, email headers and URLs, file hashes and samples, cloud configuration findings, alerts and the verdicts analysts attach to them. Some of it describes the customer's environment; some of it is the customer's own content.
Buyers also know that security customers negotiate hard. Large enterprises and regulated customers often redline data clauses, so the standard terms on your website may not describe the rights you actually hold.
The telemetry rights checklist buyers work through#
The telemetry rights checklist below reflects what buyer counsel and technical diligence teams typically request from a security vendor. Use it to build the data room section before a process starts, not after the first request list arrives.
| Item | What buyers ask for | Red flag |
|---|---|---|
| Training rights in customer terms | Clause text by contract version allowing telemetry use to improve detection or train models | Silent terms, or enterprise redlines that struck the clause |
| Aggregated and derived data | Definitions of aggregated, de-identified or threat data the vendor may keep | Definitions that still capture customer content |
| Data residency | Regional storage commitments and where training copies sit | Training pipelines that move data out of a committed region |
| Retention and deletion | What happens to telemetry and derived features at contract end | Training sets holding data customers were promised would be deleted |
| Model lineage | Which datasets and cohorts trained each production model | No record of what trained the models now in production |
| Sub-processors and AI tools | Third parties that receive telemetry, including AI vendors | Undisclosed vendors with rights to retain or train on inputs |
| Threat intelligence inputs | Licenses for third-party feeds and shared intelligence | Feed terms that bar derivative works, training or transfer |
| Channel and MSSP contracts | Whose terms govern end-customer telemetry sold through partners | No direct terms with end customers |
| Sensitive customer segments | Special terms for government, defense, healthcare and financial customers | Restricted data mixed into general training sets |
Reading training rights clause by clause#
Training rights are read clause by clause because the same product can sit on several contract versions at once. Buyers want a cohort map: which customers are on which paper, and what each version permits.
Search master agreements, DPAs, order forms and enterprise amendments for the clauses that grant or limit use. The word training rarely appears, so look for the concepts below.
Channel sales complicate the map. When an MSSP or reseller signs with the end customer, your rights may arrive only through the partner agreement, which may not pass improvement or training rights through. Ask partners which end-customer terms they used, or confirm that your own end-user terms apply.
Record the result per cohort in a single table. A buyer accepts a known, sized gap far more readily than an unknown one.
- Definitions of service data, security data, threat data or telemetry.
- Rights to use data to improve, develop or enhance the services.
- Aggregated, anonymized or de-identified data carve-outs, and who owns the output.
- Machine learning, artificial intelligence or model clauses, including promises not to train.
- Confidentiality clauses that treat all environment data as confidential information.
- Deletion and return obligations at termination.
Data residency: where telemetry actually sits#
Data residency diligence asks where telemetry actually sits, not only where production runs. Commitments to keep data in a region usually extend to copies, and training pipelines are where copies multiply.
Map the data lake, feature store, training buckets, analyst sandboxes and research exports. Note which regions each one uses and whether telemetry from a committed region ever crossed into another for model training. If it did, record when, why and what was done about it.
Where European customers are involved, GDPR transfer rules may apply to those movements. Treat any finding as a matter for counsel rather than a technical footnote.
Model lineage: which data trained which detection#
Model lineage is the record of which data trained which detection model, and a buyer will expect a security vendor to produce it on request. Without it, every rights gap becomes a question about the whole product.
A useful lineage register is not elaborate. It lets a buyer answer one question quickly: if a customer cohort's rights turn out to be weak, which models are affected, and can they be retrained without that cohort?
Keep the register with the code and the training pipeline, not in a slide deck. Update it at every retraining so it always describes the production models a buyer will inherit.
- Model name, version and the product feature it powers.
- Training datasets with source, date range and customer cohorts included.
- Labels and who produced them: customer feedback, analyst verdicts or automated rules.
- Evaluation sets and whether they overlap with training data.
- Retraining history and whether a cohort can be excluded in the next run.
Illustrative: an email security vendor prepares for a sale#
Illustrative: a fictional email security vendor sells phishing detection to mid-market companies and a handful of large enterprises. Its telemetry includes message headers, URLs, attachment hashes, user-reported phish and the verdicts its analysts record in an internal case tool.
Preparing for a sale, the team found that several enterprise customers had struck the improvement clause from their agreements, yet their messages had flowed into the training set for the current classifier. The team built a lineage register, retrained the classifier without that cohort, kept both versions' evaluation results and documented the change.
Diligence then focused on a defined, remediated issue rather than an open question. The team also identified analyst case notes, with message content and recipient details removed, as company records the business could consider licensing later.
Which security vendor records are usually licensable#
Security vendor records the company created itself are usually licensable, while customer content is not. Detection rule changes and their code reviews, analyst triage reasoning, postmortems of incidents in the vendor's own systems, support tickets and product decision records belong in the first group.
Customer emails, files, logs, samples containing customer content and environment details stay out by default, as do records involving defense or export-controlled customers. Keeping that line clear also makes the diligence story simpler.
How SourceX handles security vendor records#
SourceX works through the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. For a security vendor, the Rights step separates vendor-created records from customer telemetry, and anything tied to defense or export-controlled work is excluded.
A future buyer's diligence team can read the resulting SourceX Evidence Packet as a closed, documented contract: provenance, licensing rights, permitted use, the privacy record and release authorization. Large datasets stay in the vendor's own storage or ship on encrypted drives.
Frequently asked questions
Do existing data licenses survive a change of control?
That depends on the license's assignment and change-of-control clauses and on the deal structure. In a stock sale the contracting entity usually stays the same, while an asset sale may need consent. Disclose every outbound data license early so the buyer can review it on its own terms.
Can we use telemetry from free trials and proof-of-concept deployments?
Only under the terms those users accepted. Trial and evaluation agreements are often shorter and less specific than the master agreement, and some proof-of-concept deployments run on the prospect's own paper. Treat each as a separate cohort in the rights map.
Should we delete telemetry we lack rights to before a sale?
Not without counsel. Deletion can conflict with retention duties, litigation holds or customer obligations, and unexplained deletion looks worse in diligence than a documented gap. Stop using the data for training, record the decision and let counsel advise on retention or disposal.
Do buyers look at the threat intelligence feeds we license in?
Yes. Third-party feeds and sharing communities often restrict redistribution, derivative works or use in commercial models. If a feed contributed labels or features to a model, the buyer will want the feed license and confirmation that the use fits within it.
What if models were trained before our terms covered training?
Treat the older contracts as their own cohort and assess what they did allow. Options include retraining without that data, seeking amendments from affected customers or disclosing the gap with a defined remedy. A lineage register makes each option easier to cost and explain.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.