AES-256 encryption in clinical data: what it is and why it matters

AES-256 in one sentence

AES-256 is the NIST-published symmetric encryption standard (FIPS 197, 2001) with 256-bit keys. The key is so long that brute force would take billions of years with all Earth's compute. It's what the NSA uses for its Top Secret data.

Why it matters in clinical research

Clinical data are special category under GDPR and PHI under HIPAA. A leak directly impacts subject privacy and investigator liability. Not protecting at-rest data with AES-256 (or equivalent) is, in 2026, a failure neither ethics committees nor audits will overlook.

Where it applies in an EDC

A good EDC applies AES-256 at at least three layers:

• Database at rest: disk files are encrypted. An attacker who steals the disk gets nothing.
• Backups: snapshots inherit the same encryption.
• Backups of backups: even long-term archives keep encryption.

In Trialinx this is achieved via Neon Postgres (AES-256 at the storage layer) combined with TLS 1.2+ in transit.

What AES-256 does NOT solve

• Does not protect against configuration errors (misassigned permissions, logs with PHI).
• Does not protect against stolen credentials (hence 2FA).
• Does not protect against SQL injection (hence ORM with parameters).
• Does not protect against deficient auditing (hence audit trail).

Strong encryption + operational controls + audit trail = real compliance.

Questions to ask when evaluating an EDC

1. What at-rest encryption algorithm? (AES-256 is the minimum.)
2. Who manages the keys? (Cloud provider with SOC 2-certified KMS.)
3. Are keys rotated? How often?
4. Do backups inherit encryption?
5. Is encryption documented in their ethics-committee package?

If any of these lack a clear answer, change providers.

Conclusion

AES-256 is the floor, not the ceiling. Any serious EDC must meet it. See HIPAA compliance at Trialinx and GDPR in clinical trials for the concrete controls we apply.