The Four Data Tiers: A Practical Governance Model for Life-Science R&D

Why Data Tiers Are Independent of Platform Tiers

Most organisations that operate research infrastructure conflate two distinct concerns: the platform tier that defines compute capacity, networking, and service availability, and the data tier that defines what kind of information flows through that infrastructure and under what regulatory and organisational controls. This conflation leads to architectural decisions that are difficult to audit, expensive to change, and prone to compliance drift.

The four-tier data governance model we use at Biotech AI AG addresses this by treating data classification as a separate axis from infrastructure classification. A single platform tier, say a GPU compute cluster running containerised workloads, may simultaneously handle D-01 research-grade synthetic data and D-02 controlled health data. The infrastructure is the same. The controls around the data are not.

This separation has a practical consequence that matters enormously for procurement and audit: when a new dataset arrives, the question is not "which server does it go on?" but rather "which data tier does it belong to, and are the controls for that tier active on the target infrastructure?" The answer to the second question is deterministic and auditable. The answer to the first often is not.

D-01: Research-Grade Non-GDPR Data

Tier D-01 covers data that carries no personal-data obligations under GDPR or equivalent regulations. This includes publicly available datasets such as UniProt or PDB, simulation outputs generated entirely in silico, synthetic data produced by generative models trained on non-personal sources, and published reference genomes that have been stripped of donor-identifying metadata.

The governance posture for D-01 is deliberately lightweight. Access control exists primarily to manage licensing obligations and to prevent accidental mixing with higher-tier data. There is no requirement for pseudonymisation, no mandatory audit trail beyond standard infrastructure logging, and no data-protection impact assessment. Researchers can provision D-01 datasets through self-service pipelines without approval gates.

This tier is not unimportant. It represents the vast majority of data volume in most life-science R&D environments. Making it easy to access without bureaucratic overhead is what frees compliance resources to focus on the tiers that genuinely require them.

D-02: Controlled Health Data

Tier D-02 encompasses de-identified and pseudonymised health data that falls within GDPR scope but does not involve raw genomic sequences or other data categories that require specialised handling under national genomics legislation. Examples include pseudonymised clinical-trial outcome data, de-identified electronic health records used for secondary research purposes, and aggregated patient cohort statistics where the aggregation method has been validated against re-identification risk.

The control set for D-02 is substantially more rigorous. Role-based access control is mandatory, with access grants tied to specific project justifications and subject to periodic review. Every data access event is logged to an immutable audit trail. Data-protection impact assessments must be completed before a new D-02 dataset is onboarded. Pseudonymisation keys, where applicable, are stored in a separate security domain from the data they protect.

"Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information, should be considered to be information on an identifiable natural person."

GDPR Recital 26

This recital is the reason D-02 cannot be treated as a relaxed tier. Pseudonymised data remains personal data. The controls must reflect that legal reality regardless of how unlikely re-identification may seem in practice.

D-03: Federated Genomic Access

Tier D-03 addresses a pattern that is increasingly common in genomics research: the data cannot move. It resides in an external biobank, a national genomics programme, or a hospital information system that is legally or contractually prohibited from exporting raw sequences. The research organisation needs to analyse it, but cannot host it.

In the D-03 model, compute moves to the data rather than the reverse. Analysis pipelines are submitted to the external data custodian through controlled interfaces, typically conforming to GA4GH standards such as the Data Repository Service for retrieval abstraction and Passports for permission conveyance. The results, not the raw data, flow back to the research platform.

The governance challenge for D-03 is that the research organisation must still control what pipelines are submitted, what results are returned, and who has authority to initiate federated queries. The data may sit externally, but the accountability for appropriate use does not.

D-04: In-Platform Genomic Analysis

Tier D-04 is the most heavily controlled tier. It covers scenarios where pseudonymised genomic data is ingested into the research platform for direct analysis. This includes variant-calling workflows on whole-genome sequences, training machine-learning models on genomic features linked to phenotypic outcomes, and multi-omics integration where genomic data is combined with proteomic or metabolomic datasets.

D-04 inherits all D-02 controls and adds further requirements. Encryption at rest and in transit is mandatory with platform-managed keys that are rotated on a defined schedule. Processing environments are isolated at the namespace level with network policies that prevent lateral data movement. GxP-relevant workflows must be validated and version-controlled. Data retention policies are enforced automatically, with deletion certificates generated upon expiry.

The Data-Tier Controls Table

Risks Avoided by Tiering

Scope Creep

Without explicit tiers, research teams tend to store new data alongside whatever data already exists in their project workspace. A directory that started with D-01 synthetic data gradually accumulates pseudonymised clinical records, and eventually someone uploads a genomic dataset. At that point, the entire workspace should be governed at D-04 level, but nobody notices because there is no classification mechanism to trigger the escalation. Tiering makes the boundary explicit: when data arrives, it is classified, and the classification determines the control environment.

Compliance Drift

Compliance drift occurs when controls that were appropriate at the time of initial deployment become insufficient as the data landscape evolves. A project that was correctly governed under D-02 controls may begin accessing federated genomic sources without updating its governance posture to account for D-03 obligations. Tiering creates a forcing function: each tier has a defined control set, and any change in the data tier of a project triggers a review of whether the active controls match the new requirements.

Audit Ambiguity

When a regulator or an internal audit function asks "what controls apply to this dataset?", the answer must be unambiguous. If data classification is implicit or ad hoc, the audit team must reconstruct the governance posture from access logs, infrastructure configuration, and project documentation. If data classification is explicit and tier-based, the answer is the tier label plus the tier's control specification. The audit surface is reduced to two questions: is the tier assignment correct, and are the tier's controls implemented?

Practical Implementation

Implementing a four-tier model does not require four separate infrastructure environments. It requires four separate control configurations that can be activated on shared infrastructure. In Kubernetes-based platforms, this translates to namespace-level policies, admission controllers that enforce tier-specific constraints, and metadata labels that propagate tier classifications through the data lifecycle.

The critical architectural decision is where tier classification happens. In our model, classification occurs at the point of data ingestion, before the data enters any processing pipeline. An ingestion gateway evaluates the data source, the declared data category, and the associated metadata, then assigns a tier label that travels with the data through every subsequent processing step. Downstream services consult this label to determine which controls to enforce.

This approach makes tier governance observable. At any point, a platform operator can query the system to determine how many datasets exist at each tier, which projects are accessing D-04 data, and whether any datasets have been reclassified since their initial ingestion. These queries form the basis of compliance reporting and continuous monitoring.