Clinical data is only as trustworthy as the controls around it. This page describes the security and integrity guarantees TrialPilot makes at the platform level: how accounts and sessions are protected, how access is decided on every request, what is audited, and how trial-of-record data is kept complete, attributable, and safe from silent change.
It pairs with Privacy and de-identification, which covers the boundary between participant identity and study data. Here the subject is everything else: authentication, authorization, auditability, and integrity.
Accounts and sessions#
Researcher accounts sign in with email and password, with a one-time email sign-in link or Google sign-in available when those methods are enabled. Passwords must be at least 8 characters at registration, and email verification gates access to the researcher workspace when enforcement is enabled — an unverified account can manage its own settings but cannot operate studies.
Sessions are token-based: signing in issues a short-lived access credential that is refreshed automatically from a longer-lived, revocable session. Signing out revokes the session, and a revoked session cannot mint new credentials — the next use requires signing in again.
From Account Settings, every researcher can:
- Add or change their password.
- Review linked external sign-in providers, and unlink one as long as another sign-in method remains available — an account can never be left with no way in.
- Review active sessions, including the current one, and select Log Out Everywhere to revoke sessions across all devices and browsers at once.
If you suspect account compromise
Access control on every action#
Access in TrialPilot is role-based and organization-scoped: roles such as organization admin, study admin, investigator, coordinator, and viewer determine what each team member can do, per study. The enforcement model has one non-negotiable property: every researcher action is authorized on the server, on every request.
- Each action declares the permission it requires, and the platform checks that permission against current records — not against anything the browser claims — before the action runs.
- What the dashboard shows or hides is a convenience only. Hiding a button is never the control; the server-side check is.
- Automated tests verify that no researcher-facing action ships without an explicit authorization rule, so an unguarded endpoint is a build failure, not a runtime discovery.
Publishing a study is itself a gated decision: when publication approval is enforced, a study cannot begin enrolling real participants until a platform administrator reviews and approves the request, the approval is bound to the exact protocol and consent versions reviewed, and a later change to either invalidates it. Approvals are also monitored continuously — if a study's authorization lapses, enrollment is paused automatically until a fresh valid approval exists. Sensitive administrative decisions, such as acting on a publication request, additionally require the administrator to re-confirm their password.
The blinding firewall#
In a blinded study, knowing which participant received which treatment is itself sensitive information — accidental unblinding can compromise an entire trial. TrialPilot treats blinding as a security property, not a display preference:
- Blinded roles cannot see the code-to-arm mapping. The restriction is enforced by the same server-side authorization model as everything else, so it holds regardless of what any screen renders.
- Emergency unblinding exists for genuine clinical need. It requires a stated reason, and every use is recorded in the audit trail.
- Randomization activity is captured in an immutable audit that study teams can review.
See Randomization and blinding for the workflow, and Adaptive platform studies for how the firewall extends to governed multi-arm decisions.
Auditability#
Actions that matter leave a record, and the record is append-only — entries are added, never edited or removed. Audit coverage spans the workflows where accountability is required:
| Area | What is audited |
|---|---|
| Administrative actions | Every state-changing platform administration action is recorded, so administrative changes remain traceable to a person and a time. |
| Randomization | Allocation activity and emergency unblinding, with the stated reason, in an immutable audit. |
| Data management | Data queries, coding, lock activity, and other trial-of-record work, reviewable from the Audit tab. |
| Platform-study decisions | Governed arm decisions in adaptive platform studies are snapshotted and their rollout is auditable. |
| Publication compliance | System-driven warnings, suspensions, and reinstatements of enrollment authorization use an append-only compliance audit. |
Trial-of-record data integrity#
The data-management workspace is designed around Part 11 / ALCOA+ style expectations — the regulatory shorthand for records that are attributable, legible, contemporaneous, original, and accurate. In practice, TrialPilot backs that orientation with specific behaviors:
Values are versioned#
Trial-of-record values are versioned and auditable. A correction adds a new version rather than destroying the old one, so the history of a data point is always reconstructable.
Locking is controlled and deliberate#
Database lock — the point at which a study's dataset is frozen for analysis — is a controlled, audited transition, not a switch anyone can flip. Once a study is locked, ordinary changes are refused across the platform, and unlocking is itself an audited decision. See Locking and closeout.
Late data is quarantined, never silently merged#
Data that arrives after a study locks — for example, from a device that was offline — is neither dropped nor quietly folded into the locked dataset. It is held in quarantine for explicit review, so the locked dataset stays exactly what it was at lock, and late arrivals remain visible and accounted for.
Conflicting edits cannot silently overwrite#
When two people edit the same record at the same time, the platform detects the conflict and rejects the later write instead of letting it silently overwrite the earlier one. In clinical data paths, TrialPilot never resolves a conflict by discarding someone's change without anyone knowing.
Supporting documents follow the same care: uploaded ethics evidence is stored server-side, covered by encryption at rest, and retrievable only through the administrator review path — never exposed through participant-facing surfaces or shareable links.
Scope and current status#
This page describes the guarantees engineered into the platform, and we have tried to state them precisely rather than generously. TrialPilot is in active development: capabilities and controls evolve, and some enforcement described here is configurable per deployment or per study. This page is not a certification claim. For TrialPilot's current compliance posture, or to discuss requirements specific to your study or organization, contact the team.