Data Use Agreements: How tiCrypt's Architecture Satisfies Common DUA Requirements
A Data Use Agreement is a contract your institution signs on behalf of every researcher who will ever touch the dataset. Most research computing environments cannot make the guarantees a DUA requires. They can only promise to try.
Compliance officers who review DUAs for a living know the pattern. A data provider, often a federal agency, a pharmaceutical sponsor, or a consortium of universities, hands over a restricted dataset under a contract with specific, auditable obligations: named-user access only, no commingling with other data, destruction on a fixed timeline, no downloading. The institution signs. Then IT is asked to prove, months or years later, that every term was honored continuously.
This is where most environments fail, not through negligence, but through architecture. A shared file server, a general-purpose VM, or a cloud storage bucket can be configured to approximate DUA terms. Configuration can also be changed, misapplied, or quietly drift. A DUA does not ask for a best effort. It asks for a guarantee, and a guarantee requires a mechanism, not a policy.
Common DUA Clauses at a Glance
Before mapping architecture to requirements, it helps to see what a typical DUA actually demands. The clauses below appear, in some form, in nearly every data use agreement covering sensitive research data, whether the source is NIH, a state health department, a corporate sponsor, or a data repository like dbGaP.
| Clause Type | Typical Language | What It Actually Requires |
|---|---|---|
| Authorized users | "Access limited to the Principal Investigator and named study personnel." | A way to enforce, not just document, who can open the data |
| No redistribution | "Data shall not be shared, copied, or transferred to any third party." | Technical prevention of copying and export, not a signed pledge |
| No commingling | "Data shall be maintained separately from other datasets." | Structural isolation between projects, not shared drives with folder permissions |
| Encryption | "Data shall be encrypted at rest and in transit." | Encryption that cannot be disabled or bypassed by an administrator |
| Audit trail | "Recipient shall maintain records of all persons with access." | A verifiable log of every access event, not a spreadsheet updated by hand |
| Destruction | "Data shall be destroyed upon completion of the study or expiration of this agreement." | Certifiable, irreversible destruction on a defined schedule |
| Data residency | "Data shall not leave the recipient institution's secure environment." | Physical control over where the data lives, not a vendor's data center |
| Incident notification | "Recipient shall notify the Provider within [X] days of any breach." | Detection capability fast enough to make the notification window meaningful |
| Minimum necessary | "Access shall be limited to the minimum necessary to conduct the approved research." | Granular, revocable permissions, not all-or-nothing accounts |
| IRB/oversight | "Use is contingent on continued IRB approval and shall stop if approval lapses." | A way to suspend access on demand, tied to project status |
A DUA is a legal instrument, but its terms are only as credible as the technical environment enforcing them. When a compliance officer signs a DUA, they are making a representation about the institution's infrastructure, whether or not they realize it.
The Core Problem: Policy Versus Mechanism
Most research IT environments satisfy DUA terms through policy. Access lists are maintained in a spreadsheet. Encryption is turned on in a settings panel, where it can also be turned off. A shared drive hosts multiple projects, separated by folder permissions that any administrator with sufficient privilege can alter. None of this is dishonest. It is simply fragile, because every one of these controls depends on a person continuing to do the right thing, indefinitely, without exception.
tiCrypt takes the opposite approach. Mechanism over policy means that DUA obligations are satisfied as structural properties of the platform rather than as configuration choices an administrator makes and could later unmake. A researcher's private key either exists or it does not. A dataset either sits inside an encrypted, isolated project or it does not. There is no setting to misconfigure because there is no setting.
The distinction matters during an audit. A feature can be disabled. A structural property cannot, because it is not a switch, it is the architecture itself.
Requirement-to-Architecture Mapping
The table below maps the ten DUA requirements most commonly found in data provider contracts to the specific tiCrypt mechanism that satisfies each one.
| DUA Requirement | tiCrypt Mechanism | Why It Holds Under Audit |
|---|---|---|
| 1. Access control (authorized personnel only) | Role-based access control with per-project permission profiles; authentication via RSA key pair, never password alone | Access requires possession of a private key, not just a login credential an administrator can hand out informally |
| 2. Data isolation (no commingling) | Project-level cryptographic isolation; each project's data is encrypted under keys scoped to that project | Two datasets cannot share a decryption boundary even if they sit on the same physical storage |
| 3. Encryption at rest and in transit | AES-256 encrypted vault storage; TLS tunnel for every remote session (RDP, SSH, SFTP) | Encryption is mandatory and continuous, not a configurable checkbox |
| 4. Audit trails | 150+ logged event types, tamper-evident and SHA-256 hash-chained | Logs cannot be silently edited after the fact, satisfying "maintain records" clauses with cryptographic proof |
| 5. Data destruction at term end | Cryptographic erase: keys are destroyed, rendering ciphertext permanently unrecoverable | Destruction is provable and instantaneous, not a best-effort deletion request |
| 6. No copying or exfiltration | One-way SFTP (upload only); no export path without explicit administrative approval | The absence of a download path is architectural, not policy-enforced |
| 7. Physical security / data residency | On-premises deployment; data never leaves the institution's physical infrastructure | Data residency is a fact about deployment topology, not a vendor's contractual promise |
| 8. Incident reporting | Real-time, severity-tiered alerting across the full audit stream | Detection happens fast enough to meet contractual notification windows |
| 9. Minimum necessary access | Granular permission profiles scoped to specific actions and resources, not all-or-nothing accounts | Access can be scoped tightly enough to match the study's actual personnel roster |
| 10. IRB/ethics oversight | Project-level access that administrators can suspend or revoke instantly, tied to project or team status | Access can be cut the moment IRB approval lapses, with no residual path back in |
Many of these mechanisms overlap directly with controls assessed under NIST SP 800-171 and CMMC Level 2. Encryption at rest and in transit maps to SC.L2-3.13.16 and SC.L2-3.13.8. Audit trail requirements map to AU.L2-3.3.1 and AU.L2-3.3.8. Access control maps to AC.L2-3.1.1 and AC.L2-3.1.5 (least privilege). tiCrypt has been assessed at 110 of 110 controls by independent C3PAOs, so a DUA reviewer evaluating these same properties is not asking tiCrypt to prove something new.
Access Control: The First Line of a DUA
Nearly every DUA opens with a restriction on who may access the data. The language is usually specific: named PI, named study staff, no delegation without prior written approval. Enforcing this in a conventional environment means trusting that account provisioning stays synchronized with the study roster, a synchronization that tends to lag reality by weeks.
tiCrypt's VM Controller provisions users at boot and manages mounts according to the current permission state, not a cached snapshot. When a researcher is removed from a project, the removal takes effect at the next session, not at the next manual audit. Authentication itself relies on a zero-trust proof-provider model for MFA, meaning no single credential, including an administrator's, can substitute for the researcher's own key.
No private key, no session. Full stop.
Isolation: Preventing Commingling by Construction
"Data shall be maintained separately" is one of the more frequently violated clauses in practice, usually unintentionally. A shared NFS mount, a common analysis server, or a departmental storage array often ends up hosting multiple studies under different DUAs, separated only by folder-level permissions that any misconfiguration can breach.
tiCrypt enforces isolation at the project level. Each project runs on its own VLAN with no internet access, and its encrypted vault storage is scoped to that project's keys. A researcher working on two different DUA-governed projects does not carry data between them through a shared clipboard, a shared drive, or a shared VM image. The isolation is not a firewall rule sitting on top of shared infrastructure. It is the infrastructure.
When two datasets governed by different DUAs mix, even briefly and even without malicious intent, the institution has typically breached both agreements simultaneously. This is a common and underappreciated failure mode in shared research computing.
Destruction: Proving a Negative
Every DUA with a term limit requires destruction at the end. This is the clause institutions struggle to prove most, because conventional deletion is not really destruction. Deleted files remain recoverable on disk until overwritten. Deleted rows remain in database backups. A compliance officer asked to certify destruction is often certifying something they cannot actually verify.
tiCrypt performs cryptographic erase. Destroying the encryption keys associated with a project renders the ciphertext permanently unrecoverable, immediately. There is no residual plaintext to recover from a decommissioned drive, because the drive never held plaintext. This satisfies destruction clauses in a way that survives scrutiny: the institution is not asserting that data was deleted, it is demonstrating that the data cannot be reconstructed by anyone, including tiCrypt's own operators.
The process follows a defined sequence:
- Project reaches its DUA-defined end date or the PI initiates closure
- Administrator confirms closure through the management console
- Per-project encryption keys are destroyed
- Vault ciphertext becomes permanently unrecoverable
- The destruction event is logged in the tamper-evident audit trail, itself serving as the certification record
No Exfiltration Path
Redistribution clauses assume the recipient institution can prevent copying. Most environments cannot, not fully. A researcher with legitimate access to a dataset can, in a conventional setup, attach it to an email, upload it to personal cloud storage, or copy it to a USB drive.
tiCrypt closes this path structurally rather than through policy reminders. SFTP within the platform is one-way, upload only, so there is no download channel through that protocol at all. No data leaves the enclave without an explicit, logged export approval. No exceptions. This is the same absolutist design philosophy that underlies tiCrypt's audit and key architecture: a rule that can be bypassed under pressure is not a control, it is a suggestion.
Data Residency and Physical Control
Data provider agreements, particularly from federal sources, increasingly specify where data may physically reside. A cloud deployment complicates this. Even when a cloud provider offers a region lock, the institution is trusting a third party's attestation about physical infrastructure it cannot inspect.
tiCrypt deploys on-premises. The data never leaves the institution's physical control, which means the residency clause in a DUA is answered with a fact about the deployment, not a vendor's service-level agreement. The provider secures the rack. The institution must still secure the research, and an on-premises deployment keeps that responsibility, and the corresponding evidence trail, entirely within the institution's own walls.
Audit Trails That Hold Up to Scrutiny
A DUA's requirement to "maintain records of all persons with access" is frequently satisfied with a manually updated spreadsheet, which is itself frequently out of date and rarely verifiable. When a data provider's compliance office requests an access history for the last three years, the recipient institution needs more than a memory of who had an account.
tiCrypt logs over 150 distinct event types, from session starts to file transfers to permission changes, each entry chained via SHA-256 hash to the one before it. Any attempt to alter a historical record breaks the chain and is immediately detectable. This turns the audit trail from a document the institution asserts is accurate into an artifact whose accuracy can be independently verified.
No system is immune to a sufficiently privileged attacker. What hash-chaining provides is detection: any modification to the historical record is mathematically evident, even if it cannot be physically prevented. For a DUA audit, evident is what matters, because it means the record can be trusted or its tampering can be proven.
Incident Reporting Under a Ticking Clock
Nearly every DUA includes a notification window, often 24 to 72 hours from discovery of a suspected breach. That window is meaningless if the institution's environment cannot detect the breach in the first place. In practice, many research computing environments learn about unauthorized access weeks after the fact, if at all, because logging is sparse, informal, or scattered across systems that no one correlates.
tiCrypt's audit stream is real-time, not batch-processed. Access anomalies, failed authentication attempts, and unusual data movement generate alerts as they happen, not during a periodic review cycle. This does not replace the institution's obligation to investigate and notify, but it closes the gap between "something happened" and "someone noticed," which is the gap that turns a 72-hour contractual window into a promise the institution cannot keep.
Signing a DUA with a 24-hour notification requirement while running an environment that reviews logs monthly is not a compliance gap. It is a commitment the institution has already broken, it just has not been tested yet.
Minimum Necessary and IRB-Linked Access
DUAs frequently tie authorized access to a specific approved protocol, meaning access should track IRB status, not just employment status. A researcher whose IRB approval lapses should lose access immediately, not at the next quarterly review.
Because tiCrypt's role-based access control operates at the project level, an administrator can suspend a project's access the moment oversight status changes, and every user tied to that project loses their working session at that instant. Minimum necessary access is not achieved by trusting broad accounts to go unused. It is achieved by never granting more than the permission profile allows in the first place.
Why DUA Terms Keep Getting Stricter
Data providers have grown more exacting over the past several years, and for identifiable reasons. High-profile breaches involving genomic and health data, growing federal scrutiny under NIST SP 800-171 and CMMC for anything touching sponsored research, and an expanding list of foreign influence and export control requirements have all pushed data providers toward contract language that assumes the recipient institution's technical environment will be tested, not just trusted.
This shows up as more specific clauses: not just "encrypt the data" but naming the algorithm and key length; not just "control access" but requiring named-user rosters submitted for approval; not just "destroy the data" but requiring a signed certificate of destruction. The trend line points toward provable compliance, not asserted compliance, and an environment built on policy rather than mechanism will fall further behind each renewal cycle.
Institutions that negotiate DUAs regularly, particularly those working with NIH data repositories, state health agencies, or industry sponsors under CMMC flow-down requirements, are increasingly finding that the technical questionnaire attached to the DUA is longer and more specific than the legal terms themselves. An environment that cannot answer those questions with architectural fact, rather than policy intent, slows down every negotiation that follows.
What This Means for Your Next DUA Negotiation
The platform, not the hardware, determines compliance. A data provider's legal team does not care whether the recipient institution owns its own servers or rents them from a cloud vendor. They care whether the stated obligations, access control, isolation, encryption, audit, destruction, are guaranteed by something more durable than an administrator's good judgment.
When compliance officers evaluate whether their research computing environment can support the next DUA, the operative question is not "do we have a policy for this." It is whether the policy is backed by a cryptographic isolation boundary that holds regardless of who is watching. tiCrypt has been assessed against this standard directly: CMMC Level 2 at 110 of 110 controls, NIST SP 800-171 alignment, FIPS 140-2 validated cryptography, across 7+ independent C3PAO assessments at 8+ R1 research institutions serving more than 1,200 researchers.
A DUA is, in the end, a promise about how data will be treated when no one from the provider's side is looking. The strength of that promise is only as strong as the mechanism behind it.
Further Reading
- Shared Responsibility in Secure Compute
- The Shared Responsibility Gap in Cloud Research Enclaves
- Cryptographic Isolation for CUI on Shared Storage
- Satisfying CMMC Level 2 Audit and Accountability Controls with tiCrypt
The next time your institution reviews a Data Use Agreement, ask which clauses your current environment enforces structurally, and which ones it merely promises to honor.