Data Asset vs Database vs Data Rights

Introduction

Three data-related intangibles sit close together in modern SaaS and data-led businesses, and they are routinely conflated: the data asset (the underlying data), the database (the structured container holding the data), and the database right (the UK/EU sui generis legal protection). They are not the same. The taxonomy matters because the accounting recognition, the valuation method, and the legal protection differ across all three.

A data asset is the dataset itself — customer records, transactional logs, behavioural data, sensor data, telemetry, or any other body of information held by the business. A data asset has economic value when it supports revenue generation, decision-making, model training, or competitive advantage. A database is the structured container — the schema, indexes, query infrastructure, and software that organises the data for use. A database right is the UK/EU sui generis intellectual property right under the Copyright and Rights in Databases Regulations 1997 (transposing EU Database Directive 96/9/EC into UK law) — a 15-year protection over the substantial investment in the database itself.

For a UK SaaS founder, all three matter at fundraising, M&A, and IP-backed lending. The inventory is asymmetric: most SaaS businesses have substantial data assets, modest database infrastructure value, and partial database-right protection — but conflate the three when describing the business to investors.

TL;DR: A data asset is the dataset itself — the substance. A database is the structured container — the engineering. A database right is the UK/EU sui generis legal protection over a database showing substantial investment, lasting 15 years from creation or substantial change. All three are intangible assets but they answer different questions: the data asset's value lies in its information content, the database's value lies in its organisational architecture, and the database right's value lies in legal exclusion. A SaaS founder inventorying intangibles needs to identify each separately.

Data Asset

A data asset is the dataset itself — the substance of the information held by the business. It is broader than any specific table, schema, or storage container; it is the underlying information that creates economic value when collected, structured, and applied. The data asset's value is in its informational content, not in the infrastructure that holds it.

Common data assets in a SaaS context:

• Customer relationship and behavioural data
• Transactional and operational logs
• Sensor, telemetry, or IoT data
• Model training datasets
• Aggregated cohort or benchmark data
• Third-party data feeds (where the entity has lawful processing rights)

How a data asset gets recognised

Under IAS 38 paragraph 8 (UK and global IFRS), a data asset can be an intangible asset where it meets the identifiability test — separable (can be sold, transferred, licensed) or arising from contractual or legal rights. The internal-generation prohibition under IAS 38 paragraphs 63-67 catches most internally accumulated data assets — they are typically not recognised on the holder's balance sheet, although they may be the most valuable intangible the business owns.

Acquired data assets, in a business combination, are recognised at fair value under IFRS 3 (UK and global) or ASC 805 (US). The PPA team identifies the dataset, evidences the lawful basis for processing, and applies an appropriate valuation method.

Typical data-asset valuation methods

• Cost approach — reproduction cost of building the dataset from scratch, less obsolescence. Common for early-stage datasets where no licensing comparables exist.
• MPEEM — where the data is the primary driver of cash flows (rare; more common for customer relationships incorporating data).
• RFR — where the data could be (or is being) licensed to third parties under observable royalty terms.
• Market approach — comparable data-asset sales or licensing transactions where evidence exists.

What auditors look for in data-asset recognition

• Lawful processing basis under UK GDPR / EU GDPR / US privacy regimes
• Evidence of value generation — revenue attribution, decision support, model performance uplift
• Useful-life assessment — obsolescence rate, refresh frequency, retention policy
• Defensibility of the chosen valuation method

Database

A database is the structured container that organises the data for use — the schema design, indexing, query architecture, integration interfaces, and the supporting software infrastructure. The database is engineering; the data asset is content.

A database has economic value because well-designed structure makes data faster to query, easier to integrate, and more resilient to scale. Two SaaS businesses with the same underlying data can have very different platform value depending on the database architecture. Common database value drivers:

• Schema design optimised for the access patterns of the application
• Query performance — indexing, materialised views, caching layers
• Integration interfaces — APIs, webhooks, ETL pipelines
• Resilience — replication, sharding, backup architecture
• Governance — access controls, audit logging, lineage tracking

How a database gets recognised

A database — as software-and-architecture engineering — is typically recognised under the internally generated software framework. Application-development-stage costs are capitalisable under IAS 38 / SIC-32 (UK and global) where technical and commercial feasibility is established. Acquired databases are recognised at fair value under IFRS 3 / ASC 805.

The distinction between the database (engineering) and the data asset (content) matters because they are valued differently. The cost approach is the dominant method for database valuation; income-based methods rarely apply because the database alone — without the underlying data — does not produce revenue.

Typical database valuation methods

• Cost approach — reproduction or replacement cost of building the schema, indexes, query infrastructure, and integration layer
• MPEEM — only where the database itself is the primary revenue driver (uncommon)
• Market approach — rarely available; databases are bespoke

What auditors look for in database recognition

• Documentation of the database architecture in transferable form
• Capitalisation policy applied consistently to internal database development
• Useful-life assessment reflecting the rate of technology obsolescence
• Distinguishability from the underlying data asset

Database Right

A database right is the UK and EU sui generis intellectual property right over databases that show "substantial investment in obtaining, verifying, or presenting the contents". It is conferred by the Copyright and Rights in Databases Regulations 1997 (UK SI 1997/3032), which transposed the EU Database Directive 96/9/EC into UK law and has been retained as UK law post-Brexit.

The database right is distinct from copyright in the database (which protects the original creative expression of the structure) and from any IP in the underlying data. The database right is a regional regime — UK and EU only; the US does not have an equivalent sui generis database right (US database protection relies on copyright, contract, and trade-secret law).

What a database right protects

• The whole or a substantial part of the contents of the database from unauthorised extraction or re-utilisation
• The database from systematic extraction or re-utilisation of insubstantial parts where this conflicts with normal exploitation
• The investment in obtaining, verifying, or presenting the database contents

How a database right gets recognised

Database rights arise automatically under SI 1997/3032 where the substantial-investment test is met — no registration is required. The right lasts 15 years from creation or from the date of substantial change. Substantial change restarts the 15-year clock, which means actively maintained databases can have continuous protection extending indefinitely in 15-year increments.

In intangible-asset accounting terms, the database right is a contractual or legal right (the second arm of the identifiability test under IAS 38 paragraph 12). It can be recognised at fair value when acquired in a business combination, but typically only where the right is itself the source of material value beyond the underlying data and database.

Typical database-right valuation methods

• RFR — comparable database-right licensing rates where evidence exists (rare; the market is thin)
• Cost approach — the cost of establishing the substantial investment (often the same cost basis as the underlying database)
• Income approach via competitive differential — the margin differential attributable to the legal exclusion

What auditors look for in database-right recognition

• Evidence of substantial investment in obtaining, verifying, or presenting contents
• Documentation of the database creation date and any substantial-change resets
• Lawful basis for the underlying data and any processing
• Distinguishability from the underlying database and data asset