Why Our Security Is Native, Not Bolt-On — And Why That Difference Matters
Most EDC platforms add security after the fact. PharmaTrialsCortex built security into the architecture from line one. Here is what that means in practice and why it matters for your clinical trials.
The Bolt-On Problem
Most clinical trial software was not built for security. It was built for functionality — data entry, query management, visit scheduling — and security was added later, often in response to a customer requirement or a regulatory audit finding.
You can tell when security is bolted on. The signs are unmistakable:
- Audit trails that miss events. The system logs some changes but not others because the logging was added to individual features rather than enforced at the data layer.
- Access controls that work in the UI but not the API. A user cannot click a button they should not see, but they can call the same endpoint directly and bypass the restriction.
- Encryption that covers some fields but not others. PII encryption was retrofitted into specific forms rather than applied systematically across the data model.
- Compliance tests that run quarterly, not continuously. Security controls are verified during audit preparation, not on every deployment.
Bolt-on security is a patch over a structural weakness. It can pass a checkbox audit. It cannot survive a determined attacker, a sophisticated regulator, or the passage of time.
What Native Security Looks Like
Native security means security decisions were made at the architecture level — before the first line of application code was written. Here is how that manifests in a clinical trial platform.
The Data Layer Enforces Integrity
┌─────────────────────────────────────────────────────────┐
│ Bolt-On vs Native: Audit Trails │
├─────────────────────────────────────────────────────────┤
│ │
│ BOLT-ON APPROACH │
│ ───────────────── │
│ Application code → Sometimes creates audit log │
│ ↓ │
│ If developer remembers to add logging to this feature │
│ ↓ │
│ If the log call does not throw an exception │
│ ↓ │
│ Audit record created (maybe) │
│ │
│ ═══════════════════════════════════════════════════════ │
│ │
│ NATIVE APPROACH │
│ ──────────────── │
│ ANY data change → Database layer ALWAYS creates audit │
│ ↓ │
│ No developer action required │
│ ↓ │
│ No permission to skip, update, or delete audit records │
│ ↓ │
│ Audit record created (always) │
│ │
└─────────────────────────────────────────────────────────┘In a native security architecture, the audit trail is not a feature — it is a property of the data layer. Every model that stores clinical data inherits automatic change tracking. The audit model has no update or delete permissions at the database level. A developer cannot accidentally skip audit logging because they do not need to implement it — it happens automatically.
Access Controls Live at the API Layer
┌─────────────────────────────────────────────────────────┐
│ Bolt-On vs Native: Access Control │
├─────────────────────────────────────────────────────────┤
│ │
│ BOLT-ON: │
│ ┌──────┐ ┌──────┐ ┌──────────┐ │
│ │ UI │───→│ API │───→│ Database │ │
│ │ hides │ │ open │ │ returns │ │
│ │button │ │ │ │ all data │ │
│ └──────┘ └──────┘ └──────────┘ │
│ ↑ Security here only │
│ │
│ ═══════════════════════════════════════════════════════ │
│ │
│ NATIVE: │
│ ┌──────┐ ┌──────┐ ┌──────────┐ │
│ │ UI │───→│ API │───→│ Database │ │
│ │checks │ │checks│ │ scoped │ │
│ │ role │ │ role │ │ by site │ │
│ └──────┘ └──────┘ └──────────┘ │
│ ↑ Security ──↑ here ────↑ everywhere │
│ │
└─────────────────────────────────────────────────────────┘In a native security architecture, access control is enforced at every layer:
- The UI shows only what the user’s role permits
- The API checks permissions on every request, regardless of how it was made
- The database queries are scoped by study and site — a user at Site A literally cannot receive Site B data, even with a direct API call
This is defence in depth. Bypassing one layer does not grant access because the next layer independently enforces the same rules.
Encryption Is Structural, Not Selective
┌─────────────────────────────────────────────────────────┐
│ Bolt-On vs Native: Encryption │
├─────────────────────────────────────────────────────────┤
│ │
│ BOLT-ON: │
│ Some PII fields encrypted ─── some missed │
│ Volume encryption only ────── protects against theft │
│ but not app-layer breach │
│ │
│ ═══════════════════════════════════════════════════════ │
│ │
│ NATIVE: │
│ ALL PII fields ─── Field-level AES-256 encryption │
│ ALL volumes ────── Volume-level encryption │
│ ALL passwords ──── Argon2id memory-hard hashing │
│ ALL transit ────── TLS 1.3, no exceptions │
│ ALL backups ────── Encrypted with tested restore │
│ │
│ Encryption is a base model property, │
│ not a per-feature decision. │
│ │
└─────────────────────────────────────────────────────────┘When encryption is a property of the base data model, every field that stores PII is encrypted automatically. A developer adding a new form field inherits encryption without writing a single line of security code. There is no risk of “forgetting” to encrypt a new PII field because the architecture handles it.
Why the Difference Matters for Clinical Trials
Clinical trial data is not like other data. It has three properties that make native security essential:
1. Regulatory permanence. Clinical trial records must be retained for 15-25 years. Bolt-on security that works today may not survive 25 years of software updates, team turnover, and platform migrations. Native security — embedded in the data model — persists regardless of application changes.
2. Multi-layer accountability. Regulators inspect not just the data, but the controls. An FDA auditor examining your audit trail will ask: “Can anyone bypass this?” In a bolt-on system, the answer is “it depends on the implementation.” In a native system, the answer is “no — the database does not permit update or delete operations on audit records.”
3. Patient safety. Clinical trial data drives drug approval decisions. Compromised data integrity — whether from a cyberattack, an insider threat, or a software bug — can lead to incorrect conclusions about drug safety. The security architecture is not just protecting data; it is protecting patients.
How to Tell If Your EDC Has Native vs Bolt-On Security
Ask these five questions:
| Question | Native Answer | Bolt-On Answer |
|---|---|---|
| Can a system admin delete audit trail entries? | No — database permissions prohibit it | ”They shouldn’t” / “There’s a policy against it” |
| Are API endpoints protected independently of the UI? | Yes — every endpoint checks permissions | ”The UI prevents unauthorised actions” |
| How is PII encryption implemented? | At the base model level — all PII fields inherit encryption | ”We encrypt specific fields as needed” |
| How often do compliance tests run? | On every deployment, in the CI/CD pipeline | ”We run them before audits” |
| Can a user at Site A access Site B data via the API? | No — all queries are scoped by site at the database level | ”The UI only shows their site’s data” |
If the answers sound like policies rather than architecture, the security is bolted on.
We Did Not Add Security to Our Platform. We Built Our Platform on Security.
Every decision in PharmaTrialsCortex SmartEDC traces back to a security-first principle:
- Base data model: UUID primary keys (no enumeration attacks), timestamps, soft delete (no hard deletes), automatic change tracking — inherited by every clinical data model
- Audit trail: Append-only by database design. No update permission. No delete permission. Not for admins. Not for anyone.
- Access control: Role-based with 8 predefined clinical trial roles. Every API endpoint. Every database query scoped by study and site.
- PII encryption: Field-level AES-256 on the base model. PII_VIEW role required to decrypt. Clinical staff see clinical data; only designated staff see identifiers.
- Password security: Argon2id hashing, 12-character minimum, account lockout after 5 attempts, 15-minute session timeout
- Continuous validation: Compliance tests run on every deployment. If a security control breaks, the build fails.
This is not a feature list. This is the architecture. You cannot turn it off. You cannot bypass it. You cannot accidentally break it by adding a new feature.
That is the difference between native and bolt-on.
See it for yourself — request a technical deep-dive with your security team. We will show you the architecture, the test suite, and the evidence. Or start your 14-day trial and inspect the controls from the inside.
Your clinical trial data deserves a platform that was built to protect it. Not one that learned to protect it after the fact.
For technical security questions or to schedule an architecture review, contact security@pharmatrialscortex.com.