Leadership and readiness
Data licensing policy: rules for when and how your company licenses records
By SourceX Editorial · Updated
Short answer
A data licensing policy sets the rules for when and how a company may license its records to outside parties such as AI developers. It should define scope, list records that are never licensed, name the approval chain, set a de-identification standard, require a licensing register and fix a review cadence, so each request is judged against agreed rules.
Key takeaways
- A data licensing policy decides in advance what every later request is measured against.
- The never-license list is the most useful section, because it answers the hardest requests before anyone asks.
- Every license should pass a named approval chain that ends with the authorized signer of the supplier entity.
- The de-identification standard should require human review, since automated detection tools do not catch everything.
- A licensing register shows auditors, acquirers and the board what left the company and on what terms.
What does a data licensing policy do?#
A data licensing policy sets out when the company may license records to outside parties and the process each license must follow. It turns case-by-case debates into a standing rule, so an inbound request from an AI developer is checked against agreed limits rather than argued from scratch.
The policy is different from your privacy notice, which tells individuals how their information is used, and from your acceptable use policy, which governs what employees do with company systems. It governs outbound licensing by the company itself, including samples, evaluation access and requests framed as free research.
The general counsel or the COO usually owns the policy, with the CFO involved on commercial terms. In a smaller company a short policy signed by the CEO is enough, provided it names who decides.
Policy outline: the sections to include#
A complete data licensing policy has ten short sections. Most companies can draft the outline in a single working session and fill in the detail as the first request moves through it.
- Purpose: why the company may license records and the principles it follows, such as licensing rather than selling and approving every release.
- Scope: the legal entities, systems and record families covered, including acquired companies.
- Definitions: metadata, sample, licensed dataset, permitted use, supplier entity and authorized signer.
- Roles: the data owner for each record family, the policy owner and the authorized signer.
- Never-license list: record categories excluded regardless of the offer.
- Approval chain: who reviews and approves at each stage, in order.
- De-identification standard: the minimum preparation before any record leaves the company.
- Contract minimums: terms every license must contain, such as permitted use, deletion and breach notice.
- Licensing register: the fields recorded for every release.
- Review and exceptions: when the policy is reviewed, and how exceptions are requested and documented.
What belongs on the never-license list?#
The never-license list names categories of records the company will not license, whatever the terms. Writing it in advance protects the company from deciding under commercial pressure, and it tells employees and customers where the hard lines are.
| Category | Example records | Reason |
|---|---|---|
| Client-owned work product | Deliverables, drawings, customer code, customer-specific procedures | Ownership or contract terms sit with the client |
| Contract-restricted records | Records under customer NDAs or data use prohibitions | Licensing would breach the agreement |
| Sensitive personal data | Health details, biometrics, government ID numbers, background checks | High harm if exposed; heavy legal obligations may apply |
| Personnel files | Performance reviews, disciplinary records, leave files | Employee trust and employment law exposure |
| Privileged communications | Exchanges with outside or in-house counsel | Licensing could waive privilege |
| Secrets and credentials | Passwords, API keys and access tokens in code or chat | Security risk with no licensing value |
| Records under legal hold | Anything subject to a litigation or investigation hold | Must be preserved unchanged and not used |
| Export-controlled technical data | Controlled designs and specifications | Transfer restrictions |
How should the approval chain work?#
The approval chain should move from the people who know the records to the people who carry the risk, ending with the authorized signer. Each approver signs off on one specific question, which keeps reviews short and makes it obvious where a request stalled.
| Stage | Approver | Signs off on |
|---|---|---|
| Request intake | Policy owner | The request is in scope and not on the never-license list |
| Record review | Data owner for the record family | What the records contain and what to exclude |
| Rights and privacy | General counsel or outside counsel | Contracts, notices and the laws that may apply |
| Security | CTO or IT lead | Buyer security answers and delivery method |
| Commercial | CFO | Fees, payment terms, tax and accounting treatment |
| Final release | CEO or authorized signer | The license and release of the specific dataset |
| Consent where required | Board, investors or lenders | Approvals required by governing or credit documents |
Setting the de-identification standard#
The de-identification standard defines the minimum preparation before any record leaves the company, samples included. A practical standard requires removal or masking of direct identifiers, review of free-text fields where names and contact details hide, scanning for secrets in code and chat, and human review of a sample of the output.
Human review is not optional. The documentation for Presidio, an open-source PII detection tool, states that automated detection carries no guarantee of finding all sensitive information and that additional protections should be used. Write that expectation into the policy so nobody treats a tool's output as final.
The standard should also say what gets recorded: the methods applied, who reviewed the result and what was excluded. That record becomes the privacy record for each release.
The licensing register and review cadence#
The licensing register is the company's single record of what left the building, for whom and on what terms. Published provenance standards are a useful guide to its fields: the Use group of the Data & Trust Alliance Data Provenance Standards includes confidentiality classification, consent documentation location, privacy-enhancing technologies applied, allowed geographies, license to use and intended use.
Review the policy on a fixed schedule set by the policy owner, and also whenever a trigger occurs: an acquisition, a new system of record, a change in privacy law that may apply to you, or an incident involving licensed data.
- Release identifier, date and the supplier entity that licensed the records.
- Record families, systems and date ranges included, and what was excluded.
- Buyer, permitted use, term, exclusivity and deletion obligations.
- De-identification methods applied and the person who reviewed the output.
- Approvals obtained at each stage, with names and dates.
- Location of the signed license and supporting documents.
Illustrative: a 3PL writes its policy after an inbound request#
Illustrative: a fictional third-party logistics provider receives a request from an AI developer for warehouse exception records. Its warehouse management system holds receiving discrepancies, pick errors, damage reports and resolution notes, and many customers' own operating procedures are documented in the same system.
Rather than answer ad hoc, the COO and outside counsel draft a data licensing policy first. Customer-specific procedures go on the never-license list because customer agreements cover them. Exception records are allowed, with customer names, consignee addresses and employee names removed under the de-identification standard.
The request then moves through the approval chain in order. Counsel finds that two large customer contracts restrict use of operational records, so those accounts are excluded, and the register captures the release, the exclusions and each approval.
How SourceX fits a company's licensing policy#
SourceX is designed to run inside a company's own policy rather than replace it. The SourceX five-step transaction, Supply, Rights, Preparation, Approval and Delivery, maps onto the approval chain, and the supplier approves every step.
For each release, the SourceX Evidence Packet documents provenance, licensing rights, permitted use, the privacy record and release authorization, which gives the licensing register a ready source for its entries.
Frequently asked questions
Who should own the data licensing policy?
Usually the general counsel or the COO, with the CFO consulted on commercial terms and the CTO on security and delivery. What matters most is that one named person owns the policy and that the authorized signer for each supplier entity is identified.
Does a mid-size company really need a written policy?
If the company has never been asked, a short written policy is still cheaper than deciding under pressure. It can fit on a few pages: scope, the never-license list, the approval chain and the register. Detail can grow as requests arrive.
How should the policy treat free research requests?
Treat them as licenses. Free access for research still releases records, so the request should pass the same never-license check, approval chain and de-identification standard, and the permitted use should be written down even when no fee is charged.
Should employees see the policy?
Employees should know a policy exists and that only the company, through its approval chain, can license company records. A short notice or FAQ explaining what may be licensed and how people are protected builds trust and discourages individuals from selling work files on their own.
How does the policy relate to our privacy notice?
They should be consistent. If the policy allows licensing of de-identified records, check with counsel whether your privacy notice, customer contracts and employee notices need updating so that what you do matches what you have told people.
Sources
- The Use group of the Data & Trust Alliance Data Provenance Standards includes elements for confidentiality classification, consent documentation location, privacy-enhancing technologies applied, allowed and excluded processing and storage geographies, license to use, intended data use, and copyright, patent and trademark status. Source
- Presidio's own documentation warns that because it uses automated detection mechanisms, there is no guarantee that Presidio will find all sensitive information, and additional systems and protections should be employed. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.