What this page is
Three regimes, one set of technical controls. This page says what personal data Trialion holds and where it goes, what the software does about it once, and then what each regime additionally asks of the organization that runs it. Nothing here is legal advice, and no regime's compliance is a property of software.
What Trialion holds
About a participant. A participant record carries: a screening number, a participant number, an optional randomization number and the name of the randomization system, sex, birth year (not a full date of birth), the site, the consent date and the ICF version, the screening date, the eligibility determination and note, the arm, the status and, for an exit, its reason and date. The participant's name, address and contact details are not collected.
What can identify a person is whatever people type: the free text of a form field, a query or its answer, a deviation description, an eligibility or exit note, and the summary of a contact with a participant (a call, a letter; up to 2,000 characters). So the largest privacy decision on any study is made in the form builder and in the instructions given to site staff, not in a setting.
About staff. A user has a name, an e-mail address and optionally a phone number, a status and the time of their last sign-in. Each session keeps the address and the browser's description of where it started, and is not deleted; sign-in codes keep the same and are deleted after a time. The audit trail records who did what from which address.
What the operator's control plane holds. The organization's name and state, its platform administrators' names and e-mail addresses, its feature switches and its own ledger. It holds no clinical data (The database).
Where personal data goes
| To | What | Notes |
|---|---|---|
| The database | Everything above | Isolated per organization by row-level security (Data and tenancy) |
| Object storage (S3) | Documents, export files and audit anchors | Encrypted at rest with provider-managed or customer-managed keys (required when the driver is S3); documents move between the browser and storage over short-lived single-purpose links and never pass through the application |
| A mail relay | Invitations, notices, sign-in and signature codes, operator alerts | The relay sees the recipient's address and the message. Codes are single-use and short-lived |
| Google Vertex AI (optional, off by default) | The text a designer typed into the form generator, with the study's phase and therapeutic area; or a role's name, scope and description | Never participant data. The region is a setting (AI) |
| The web application's cookie | An encrypted, httpOnly session cookie holding the tokens | Unreadable by script on the page |
The technical controls, once
| Control | Implementation |
|---|---|
| Access control | Role-based and fail-closed: 15 standard roles and 68 permissions, custom roles with guardrails, one role per person per study, site staff confined to their site (Roles and permissions) |
| Tenant isolation | Every organization's data is separated in the database: a query with no tenant context returns nothing, never everything (Data and tenancy) |
| Encryption in transit | HTTPS with strict transport security; production refuses a database connection that is not encrypted |
| Encryption at rest | Files in S3 are encrypted by the storage. The database's encryption at rest depends on how it is provisioned |
| Audit trail | Every change, sign-in, signature and refusal is recorded with the person, the time and the origin. A read is not recorded (Audit trail and evidence) |
| Authentication | Passwordless one-time codes stored only as hashes: five minutes, three attempts, a cooldown and a per-account limit (Signing in) |
| Session control | 15 minutes idle, 12 hours absolute, and a view of a person's own sessions with the means to end any (Manage your settings and sessions) |
| Log hygiene | Application logs redact the authorization and cookie headers and fields named password, token or secret |
| Minimization | Birth year rather than date of birth; no participant names or contact details; an export can be limited to chosen sites or chosen participants |
HIPAA (United States)
Relevant when a covered entity or business associate processes protected health information.
| Requirement | Position |
|---|---|
| Unique user identification, automatic logoff, person authentication | Built: every action is by a named person; sessions end after 15 minutes idle; a code to the person's mailbox |
| Audit controls, integrity | Built: the tamper-evident trail and hash-bound signatures. No read log |
| Transmission security | Built in the application (HTTPS, headers); the certificate and network are the hosting's |
| Minimum necessary | Supported by role scoping and site confinement; the decision is the organization's |
| Emergency access procedure | Not built. There is no break-glass access |
| De-identification | Not automated. Participant records are pseudonymous by default; whether a dataset meets Safe Harbor or Expert Determination depends on the forms |
| Business Associate Agreement | The organization executes one with whoever hosts and operates the system |
| Breach notification, administrative and physical safeguards | Procedural and hosting |
GDPR (European Union and EEA)
| Requirement | Position |
|---|---|
| Lawful basis | The organization's. In trials normally public interest or legitimate interest, with consent for the trial itself under the Clinical Trials Regulation |
| Data minimization (Art. 5) | Supported by design; the form builder is where it is decided |
| Integrity and confidentiality (Art. 5(1)(f), 32) | Access control, encryption, isolation, the audit trail |
| Records of processing (Art. 30) | The organization's to maintain |
| Right of access (Art. 15) | The data exists and can be exported and printed by the study team; there is no participant portal |
| Right to erasure (Art. 17) | No erasure function exists, and governed records are deliberately never deleted. Trial records must be retained by regulation, and a request is assessed against that obligation, not the software |
| Data protection by design (Art. 25) | Pseudonymous participants, least-privilege access, tenant isolation |
| Breach notification (Art. 33, 34) | Procedural; the software gives alerts and the audit trail, not a reader log |
| International transfers (Ch. V) | The hosting's. Trialion does not pin a region; the storage region, the database region and the AI location are each a setting |
| DPIA | The organization's |
| Processors (Art. 28) | An agreement with the operator, the mail relay and, if used, the AI provider is the organization's |
DPDP Act 2023 (India)
| Requirement | Position |
|---|---|
| Consent and notice | The consent to the trial is recorded with its date and version. A DPDP-specific notice and consent management are the organization's |
| Purpose limitation, Data Fiduciary duties | Procedural |
| Security safeguards | Access control, encryption, isolation, the audit trail |
| Breach notification to the Board | Procedural |
| Data Principal rights: access, correction, erasure | Access and correction go through the study team (a correction is a query and a reason). Erasure conflicts with the retention obligation, as under GDPR |
| Cross-border transfer | A deployment decision |
Compliance Q&A
In part. A participant record holds no name, address or contact details and only a birth year, and sign-in codes are removed after a time.
Limits: what a form collects, and what people type into free text, is decided by the study. There is no retention schedule, no scheduled anonymization and no erasure function for clinical or staff records: they are kept until the operator removes them outside the application.
Evidence: study_subjects columns (birth year, no name or address)platform_usersotp_challenges retentionno retention schedule for clinical records
In part. The study team can print a participant's casebook and status report, export the data of chosen participants, and follow the participant's history in the audit trail.
Limits: a participant has no account or portal, so the request is handled by the investigator's team, who must also decide what is released.
Evidence: casebook and participant status report screensexportsno participant account
No. There is no erasure function, and governed records, staff identities and the audit trail are kept by design so that the trial stays attributable and inspectable. A request is assessed against the retention duties that apply to the trial; the software does not decide it.
Evidence: no-hard-delete governance testthe runtime role holds DELETE on two tables only, neither a record
No. The record of processing is the controller's and is kept outside the system. This page and Where personal data goes list what is processed and where, to help it.
In part. The operator is alerted when the audit ledger no longer verifies or events are not being recorded, the trail shows who changed what and who was refused, and a break in the chain is recorded.
Limits: a successful read is not recorded, so the application cannot show which participant records a person looked at; that has to come from the hosting's access logs. The assessment and the notification to the authority within the legal time are the controller's procedure.
Evidence: worker alerts (audit.chain_integrity, audit.anchor, audit.outbox, mail.delivery, backup.stale)audit trail of changes and refusalsno read log
Related
Security and hosting · Audit trail and evidence · AI · Not built yet