Database rights audit: documents to prepare
A database rights audit establishes who currently holds rights to a database used in the business — the compilation as a structure, and the data extracted from it — and whether that holder can licence, sell or restrict access. The audit does not test data accuracy. It tests ownership and the paper trail behind it.
What the audit actually checks
Rights over a database sit on two separate layers. One layer protects the selection and arrangement of contents as a creative structure. The other protects the investment made in obtaining, verifying or presenting the contents, independent of any creativity. Each layer can have a different owner, a different starting date and a different duration. An audit checks both layers on their own terms, because a business can hold one without the other, and licensing decisions depend on knowing which layer is actually in play.
Why timing matters
A gap in the ownership chain rarely causes damage on its own. It causes damage the moment the database is licensed to a customer, pledged as an asset, or merged into a product built by someone else. Past that point, correcting a defect means unwinding a live commercial relationship rather than fixing a file. That is the point of no return this audit exists to find before it passes.
Documents to prepare
Preparation determines how long the audit takes. Four categories cover most databases in practice.
| Document | What it proves | Who usually holds it |
|---|---|---|
| Source and supply agreements | Where each dataset element came from and under what terms | Procurement or the data team |
| Employment and contractor agreements covering data work | Who built or maintained the database, and under what relationship | HR or the engineering lead |
| Assignment and licence records | Whether rights actually moved to the business, or only a right to use was granted | Legal, or the contracting party |
| Extraction and reuse logs | Whether a third party has taken data out under permitted terms | Whoever manages the licensing relationship |
Where the database absorbs a feed processed by an outside vendor, the audit also needs the vendor's own approval record for that processing role — the same record checked in a Subprocessor approval process.
Ownership defaults differ by relationship. Work built by an employee within their duties typically sits with the employer from the outset. Work built by an independent contractor does not transfer automatically — it needs a written assignment, and the audit checks whether one exists and what it actually covers.
Who decides ownership questions
There is no dedicated registry that confirms who owns a database. Ownership rests on the documents described above, not on a filing. Where the parties agree, the audit closes with an internal memo and a corrected chain of title. Where they disagree, the question moves to the competent civil court in the jurisdiction where the database is exploited, and the court decides on the same documentary record the audit assembled.
Common scenarios
- If the database was built entirely in-house by employees, the audit is short: confirm the employment scope and close the file.
- If a contractor built part of it, the audit centres on the assignment clause. A missing or narrow assignment is the single most common defect found.
- If a third-party feed sits inside the database, the audit checks the licence's field of use. Use beyond that field is the second most common defect.
- If the database backs a tokenised offering that later has to pause, the same ownership record decides who can act — How suspension of an offer token issuance runs in practice follows the same logic.
What this audit does not cover
This audit confirms who owns the database and whether the paper trail supports that claim. It does not confirm that the counterpart to a deal can actually pay, or that a foreign holding structure survives scrutiny. Where the database sits inside a structure based in the United Arab Emirates, ownership findings should be read together with the Asset report united arab emirates.
Where the other side is showing signs of financial distress, ownership on paper means little if there is nothing left to enforce it against. That risk is covered separately in the Debtor report when insolvency signals appear: what it costs to be wrong.
Verified
Verified: 10 March 2025. This page describes procedural practice only. Specific statutory references are omitted deliberately: implementing legislation differs between jurisdictions, and a citation that is not checked against the current national text creates more risk than no citation at all.
FAQ
How long does database rights audit take in practice?
Most audits close within two to four weeks once the documents above are assembled. That timeline extends when a contractor assignment is missing and needs to be reconstructed from correspondence, or when a third-party feed's licence terms need clarifying with the vendor.
Which documents are needed to start?
Start with the source and supply agreements, the employment or contractor agreements covering the people who built the database, and any assignment or licence records already on file. Extraction logs can follow once the first three categories are in.
What happens if the other side does not respond?
Silence does not resolve the question; it simply removes the fastest route to an answer. The audit continues on the documents already held. It flags the gap explicitly, and the business then decides whether to proceed on that basis or escalate the request formally before further use.
Related reading
A database audit run for provenance reasons usually starts one step earlier, with the training data itself: Provenance review of a training data set: documents to prepare covers that starting point in detail.
Ownership questions on a database rarely stay isolated. The same evidence trail that settles who owns a dataset often resurfaces later, for instance when A competitor files a patent application next to your product and priority of rights becomes the whole dispute.