Security schedules in data licenses: controls to require from buyers

What a security schedule does in a data license#

A security schedule is the exhibit to a data license that lists the specific controls the buyer must operate over licensed records for as long as it holds them. The license grant says what the buyer may do with the data; the security schedule says how the data must be protected while it does.

The schedule carries more weight in data licensing than in a typical software purchase, because the records physically leave your environment. Once support tickets, CRM histories or maintenance logs sit in a buyer's training pipeline, your only levers are the contract and the evidence the buyer agrees to provide.

Security terms also protect your legal position. Under the Defend Trade Secrets Act, information is a trade secret only if its owner takes reasonable measures to keep it secret, and DOJ guidance lists need-to-know access and confidentiality agreements among reasonable measures. Enforceable controls in the schedule are part of showing those measures.

The twelve controls to require from buyers#

The twelve controls below cover access, encryption, segregation, logging, deletion and incident notice. Each row pairs the requirement with evidence you can actually request, so the schedule can be checked rather than just signed.

Keep requirements outcome-based. Naming a specific product invites exceptions, while a requirement such as encryption at rest with separately managed keys can be met many ways and is still testable. Location terms can also travel with the dataset's documentation: the Data and Trust Alliance's Data Provenance Standards include allowed and excluded processing and storage geographies as dataset metadata.

Where licensed training data is harder to protect#

Licensed training data is harder to protect than ordinary vendor data because AI pipelines multiply copies. A raw export lands in a staging bucket, gets cleaned and deduplicated, is split into training and evaluation sets and is converted into tokenized shards. Every one of those is a copy of your records under the license.

Ask the buyer for a copy map that names each environment where licensed records, or files built directly from them, will live, who controls it and how it is deleted. Then make every control in the schedule apply to all of them, not only to primary storage.

Be precise about trained models. Many licenses treat learned model weights differently from stored records, so decide with counsel whether deletion covers datasets only or also creates obligations for models trained on them.

• 1Landing or staging storage for raw deliveries.
• 2Cleaning, deduplication and labeling workspaces, including any annotation vendor.
• 3Training, validation and evaluation splits.
• 4Tokenized or embedded versions of the records.
• 5Backups and disaster recovery copies.
• 6Analyst extracts, notebooks and sample files.

How to word incident notice and deletion terms#

Incident notice terms should define the trigger, the clock, the content and the cooperation. A useful trigger is suspected or confirmed unauthorized access to licensed records, not only a confirmed breach, because confirmation can take a long time.

Set the notice window with counsel as a fixed number of hours or days, and require the notice to state which records were involved, what the buyer has done and who the contact is. Add duties to preserve logs, to support your own notification obligations and to bear the costs the incident causes. State breach laws may require notice to individuals when personal information is involved, so the buyer's notice must reach you in time.

Deletion terms should name the triggers (end of term, termination, a schedule expiring, a written request after an incident), the scope (records, backups, working copies), a deadline and a certificate signed by an officer. Where backups cannot be purged at once, require that they stay encrypted, are never restored for use and expire on their normal cycle.

What evidence should a buyer provide?#

A buyer should provide independent evidence that its controls exist and work, not only a completed questionnaire. The most common evidence is a SOC 2 report. SOC 2 examinations use the AICPA Trust Services Criteria, which cover security, availability, processing integrity, confidentiality and privacy, and a Type 2 report also tests whether controls operated effectively over a period.

Check scope before relying on any report. A SOC 2 report for a buyer's commercial product may not cover the research cluster where training data actually lives, so ask which systems the auditor examined.

Illustrative: a software company rewrites the buyer's addendum#

Illustrative: a fictional vertical software company serving property managers plans to license support conversations from Zendesk, linked to the Jira issues and fixes they produced. The buyer's first draft attaches its standard supplier security addendum, written for vendors that connect to the buyer's own systems.

The CTO sees that the addendum protects the buyer's network, not the licensed records. It asks the software company for background checks and its own controls, but says nothing about where the tickets will be stored, who can read them or how they will be deleted.

The CTO replaces it with a licensed-data schedule: a named cloud region, named roles, no laptop copies, a copy map, a notice window set with counsel and a deletion certificate that covers tokenized shards. The buyer accepts most terms and supplies a SOC 2 Type 2 report after confirming its training environment sits inside the report's scope.

Common mistakes in security schedules#

Most security schedule problems come from templates written for a different relationship, such as a SaaS vendor addendum or a buyer's supplier terms. Read every draft from the position of a licensor whose records are leaving the building.

• 1Signing the buyer's supplier addendum, which runs in the wrong direction.
• 2Accepting phrases like industry standard security with no named controls behind them.
• 3Covering primary storage but not staging areas, annotation vendors or backups.
• 4Taking audit rights with no remedy, such as suspended deliveries, if a control fails.
• 5Leaving deletion undefined for working files and derived copies.
• 6Letting the schedule lapse at termination instead of surviving until deletion is certified.

How SourceX approaches security terms#

SourceX reduces what needs protecting before a security schedule is negotiated. In the Preparation step of the SourceX five-step transaction (Supply, Rights, Preparation, Approval, Delivery), personal and confidential details are removed, so the licensed package carries less exposure if a control ever fails.

At Delivery, large datasets stay in the supplier's own storage or ship on encrypted drives, and SourceX never hosts multi-TB datasets. The SourceX Evidence Packet records permitted use and release authorization alongside provenance and the privacy record, so supplier and buyer work from one record of what was approved.