Security and data protection

In EnaResearch, organization, customer and deployment are the same boundary. A separate environment is set up for each organization: the API, background worker, web application, time-series database (ClickHouse), queue and file storage are part of that environment. The relational database server may be shared, but each organization has its own database and its own database user. Your data is never processed in the same application or database as another organization’s data.

Each environment runs with a single organization code and rejects requests for unexpected host names. The organization code is only used for routing; knowing an address or a code grants no access to any data.

The product is designed for organizations in Türkiye, Germany, the United Kingdom, the Netherlands and Switzerland. Because each organization is deployed separately, the region or country where data is hosted is agreed with the organization at setup and written into the contract.

The measurement database is backed up encrypted: a full backup once a week and incremental backups on the other days, kept for 35 days. If the organization chooses, backups are also copied to remote storage in the same region as the data; a lost local file is restored from the remote copy.

Restores are verified with a drill that loads a backup into a separate database and compares table counts with the live data. Backup details are settled with the organization during contracting.

Operational alerts cover ingestion delays and failed batches, failed or overdue backups, failed remote copies, disk usage and pending deletion or export jobs. The maintenance screen in the admin panel shows the latest backup, the remote copy, disk usage and pending jobs.

The meaning of each alert and the steps to take are defined in a written runbook; incident response follows the notification clause of the data processing agreement.

Organization users sign in through the Logto identity platform. A study is led by the principal investigator (PI) who creates it; co-investigators join the team. Participant and data operations require study team membership for everyone, owners included.

The organization owner is responsible for governance: approving studies or requesting changes, deciding change requests and, when needed, ending a study early with a stated reason. In studies whose team they are not on, owners see only the metadata, team, timeline and study-level counts; they cannot access participants, data or datasets.

Every protected request is authorized on the server; hiding a menu in the interface is not authorization. Resources of a study whose team you are not on answer “not found”. Attempts to reach another study’s resources by address (IDOR) and the role × action matrix are covered by automated tests.

The organization-wide person record holds only the minimum identity needed for matching. In research data a person appears under a study pseudonym (P001). Exports contain only the pseudonym, sex and age at start; names, identifiers and birth dates never enter them. Researchers see match candidates masked; full names are for the owner role.

The person identifier your organization chooses (its own record number, NHS number, BSN, AHV/AVS, KVNR, Turkish ID number and so on) is not stored in clear: an HMAC hash with a versioned, HKDF-derived key and the last 4 characters are kept. If the organization chooses, an AES-GCM encrypted copy is stored; only authorized members can reveal the clear code, and every reveal is audited. The identifier never enters exports, the mobile app or the audit trail.

Participants have no organization account. The 6-character participant code is generated with a secure random source, is non-sequential and unique across the organization, and never signs anyone in on its own. The activation key is single-use, valid for 14 days, stored only as a SHA-256 hash and carried in the # fragment of the link, which never reaches the server.

An activation key starts a session that covers all of the person’s studies. So if the person is also active in another study whose team the researcher is not on, only the organization owner can issue the key; the same rule applies to rotating and revoking the code.

Web sign-in takes the code and a 6-digit PIN hashed with scrypt. A wrong code and a wrong PIN get the same answer; 5 failures for a code from one IP address lock it for 15 minutes, 50 failures for a code from any address within 24 hours lock it for 24 hours, and each IP address is limited to 30 failed attempts per hour. Session tokens are stored only as hashes, the refresh token changes on every use and reuse ends the session. On the web, tokens live in httpOnly, SameSite=Strict cookies out of reach of page JavaScript.

Analyses, dashboards and event-course charts never show groups or days with fewer than 5 participants. Complementary suppression keeps a hidden group from being derived from totals: when needed, the counts of the second-smallest group are hidden too.

Small counts also appear as “<5” in the context sent to the AI assistant.

Hospital stays, clinical events and manual measurements are recorded per participation. A correction creates a new revision with a required reason; records are never deleted but marked “entered in error” with a reason. Exports read records as they were at the data cut-off, so the same dataset version gives the same result.

CSV or FHIR R4 Bundle imports run as a dry run first, list rows with errors and never read identity fields. Clinical records are not shown in the participant area or the mobile apps.

Study, participant, team and identifier operations, approval decisions, matching searches, clear-identifier reveals, participant sign-in attempts, clinical record corrections, dataset generation and file downloads, AI assistant requests and data deletions are written to the audit trail. Entries are chained with HMAC; a later change is detected when the chain is verified.

The audit trail shows who did what and when, without needlessly copying sensitive data: PINs, session tokens, participant sign-in codes and the person identifier never enter it in clear.

By default, data is kept for the term of the license. The organization can set a shorter retention period counted from the study’s final closure; the study team receives email warnings 30 and 7 days before deletion. When the period ends, measurement data, clinical records, export files, analysis results and the AI assistant history are physically deleted; the study record, definitions, pseudonyms, manifests and the audit trail remain.

When a participant withdraws, the researcher chooses whether to keep or delete the data. Deletion covers only that participation’s data window and never touches the person’s data in other studies. Every deletion is audited with counts, without content.

The AI assistant is off by default; the organization turns it on in system management, and a provider key is needed on the server. Only aggregated context goes to the provider: variable definitions, counts (small counts as “<5”) and test output. Participant rows, pseudonyms, names and birth dates are never sent.

The assistant never creates, approves or runs analyses and never computes. Every number in a reply is checked against the statistics output; replies that cannot be verified are rejected. Every request is written to the assistant history and the audit trail. The first provider is Claude by Anthropic. Before using it with real patient data, the organization needs its own legal review; the assistant is not for clinical decisions.

EnaResearch is designed to support your obligations under regulations such as GDPR, UK GDPR, the Swiss FADP and KVKK. The product does not make an organization compliant on its own and makes no compliance claim. Legal basis, consent, ethics approval, participant information and the controller and processor roles are the responsibility of the organization and the research protocol.

EnaResearch is not a medical device or a clinical decision-support system and makes no claim about the clinical accuracy of measurements. Statistics and the AI assistant are for research.

If you find a security issue, please write to support@enainnovation.com. We review the report, get back to you and share the fix process. Details are on the responsible disclosure page among the legal documents.