Representations and warranties in data licences, explained simply

Every data licence contains a section of promises, usually titled representations and warranties. It tends to be the part of the contract that founders skim and lawyers read slowly. It is worth understanding, because it is where each side states what it is standing behind, and where most of the real risk in the deal is allocated.

This post explains the concepts in plain English. It is general information, not legal advice, and you should involve your own counsel before signing any licence.

A representation is a statement of fact made at the time the contract is signed. "The company owns the workspace being licensed" is a representation. It describes how things are today.

A warranty is a promise that something is, or will remain, true, and it usually comes with a remedy if it turns out not to be. In practice, contracts often run the two together as a single phrase, and the difference matters more to lawyers than to anyone else. For a seller, the useful way to read the section is simple: each line is something you are telling the other side they can rely on.

That is why these promises deserve care. If one turns out to be wrong, the other party may have a claim, depending on what the rest of the contract says about remedies and limits.

In a data licence, the seller is the company granting a lab the right to use an anonymized copy of its operational data. The seller's promises tend to cover a few areas:

• Authority. The person signing has the power to bind the company. For a company that is winding down or closed, this may be a director, officer, liquidator or assignee with authority over company assets, which is why we ask for the authority document up front.
• Right to license. The company controls the data in scope and is entitled to grant the licence. This is where customer contracts and confidentiality clauses come in, a topic covered in customer confidentiality clauses and your data.
• Accuracy of scope. The systems and time periods described in the contract are the ones the company actually means to license.
• Known restrictions. The company is not aware of agreements or obligations that would prevent the licence, or it has disclosed them.

Notice the phrase "not aware of" in that last line. Many promises are qualified by knowledge, meaning the seller stands behind what it actually knows, not everything that might theoretically be true. Whether a promise is absolute or knowledge-qualified is one of the most important things to look at in this section.

A licence is not one-sided. The buyer and the party handling the data make promises too, and for a seller these are often the most reassuring part of the contract.

The buyer's promises in our licences are about use. The data is for training and evaluation only. The buyer may never market to, profile, contact or re-identify anyone in the data, and it may never be resold for marketing or people search. These are the terms that protect the employees, customers and partners who appear in the archive.

On the processing side, the commitments cover how the data is handled. No third party touches raw data. Every person, company, address, email, phone and account is replaced with a consistent token, and credentials, API keys, card numbers and government IDs are removed outright. The raw archive is deleted within 30 days of sign-off, as a contract obligation, and the seller receives a deletion certificate. Making deletion a contract term rather than a policy is the point. We go deeper on that in what raw data deleted should mean in a contract.

The easiest way to stand behind a promise is to make sure it only covers what you are comfortable with. That is the role of scope and exclusions.

Before any data moves, the seller sets the scope and lists any exclusions, such as a particular client, a sensitive channel or a folder, and those are annexed to the contract. HR, payroll, medical and legally privileged folders are excluded by default. Direct messages are excluded unless the company includes them and has the right to.

Imagine a 45-person consulting firm with one client whose agreement contains a strict confidentiality clause. Rather than promising that nothing in the archive conflicts with any client contract, the firm can exclude that client's channels, folders and email domain entirely. The promise in the contract then covers a narrower set of data the firm is confident about. Exclusions narrow what you are promising, which is often a better answer than arguing over the wording of the promise itself. Our post on exclusions shows how this works in practice.

The seller's review of an anonymized sample before delivery adds another layer. It gives the company a chance to confirm that what will be delivered matches what it agreed to license.

You do not need to become an expert in contract drafting to sign a licence well. You do need to ask the right questions. A few worth raising:

• Which of our promises are absolute, and which are limited to what we know?
• Is there a cap on how much we could owe if a promise turns out to be wrong?
• How long do our promises survive after the licence is signed?
• Does our scope and exclusion list match what we are actually promising?
• Do any customer, vendor or employment agreements limit what we can license?

These are standard questions, and a good counterparty will expect them. Answering them early tends to make the rest of the process faster, not slower.

If you are considering a data licence and want to see how the scope, exclusions and promises would fit your company, book a 15-minute call.