EHR Security: Protecting the Electronic Health Record
Clinicians need broad access, which makes least privilege hard rather than merely inconvenient. Access models that match clinical reality, audit alerting that gets read, and the integration surfaces that get forgotten.
GuardsArm Team
Security Experts
The electronic health record is the densest concentration of regulated data most organisations will ever operate. Every clinician needs broad access to do their job safely, which makes least privilege genuinely difficult rather than merely inconvenient. Get it wrong in one direction and you have delayed care. Get it wrong in the other and a curious employee reads a neighbour's chart.
This is about the controls that work inside that constraint: access models that match clinical reality, audit logging that someone actually reads, and the integration surfaces that get forgotten.
Access control that survives contact with a hospital
Role-based access is the starting point, not the answer. A "Nurse" role is too coarse — a nurse on the paediatric ward has no clinical reason to open an oncology chart in another facility. Three refinements matter:
Relationship-based filtering. Access is scoped to patients the clinician has a treatment relationship with: assigned to their unit, on their panel, or with a scheduled encounter. This is the single highest-value control and most EHRs support some form of it.
Break-glass, with consequences. Emergencies are real, so there must be a path to override. The override must be one click, always available, and it must generate a reviewed alert — not a log entry nobody opens. Break-glass that is never reviewed is just access.
Time-bound elevation. Locum staff, students, visiting specialists and vendors get access that expires by default. The most common audit finding in this area is not excessive permissions granted deliberately; it is permissions that were appropriate in March and never removed.
Audit logging people actually read
Every major EHR logs access. Very few organisations review those logs in a way that would catch misuse, because the volume is enormous and unfiltered review is hopeless. Effective programmes alert on patterns rather than reading everything:
- VIP and employee records — any access to a flagged record, reviewed every time
- Same-surname access — a strong proxy for family-member snooping
- Same-address access — catches what surname matching misses
- Post-termination access — any activity by an account after the HR leave date
- Volume anomaly — a user opening far more charts than their peer group
- Deceased or high-profile patients — historically the most-snooped records
| Trigger | Review window | Typical volume |
|---|---|---|
| Break-glass override | 24 hours | Low — every one reviewed |
| VIP / employee record access | 24 hours | Low |
| Surname or address match | Weekly | Moderate |
| Peer-group volume anomaly | Weekly | Moderate |
| Post-termination activity | Real-time alert | Should be zero |
The surfaces people forget
The EHR application is usually the best-secured part of the estate. The gaps sit around it.
Interface engines and HL7 feeds. Messages moving between systems frequently travel unencrypted on the internal network, on the assumption that internal means safe. An attacker with a foothold reads clinical data off the wire without touching the EHR at all.
FHIR APIs. Modern patient-access and third-party app integration runs over FHIR. The controls that matter are OAuth scope granularity, per-app rate limiting, and — most often missed — revocation when a patient disconnects an app or an app is decommissioned.
Reporting databases and data warehouses. Analytics copies of clinical data routinely have weaker access control than the source. The data is identical; the protection often is not.
Non-production environments. Test and training systems built from a production refresh contain real PHI. Either de-identify on refresh or apply production-grade controls. Choosing neither is the common answer.
Exports and reports. The clinician who runs a legitimate report and saves it to a laptop has moved PHI outside every control you built. This is where data loss prevention earns its cost.
Encryption, honestly
Encryption at rest on a database that the application queries with full privileges protects you against one scenario: physical theft of the storage media. That is worth having, and it is what the HIPAA addressable specification contemplates. It does nothing about a compromised application account, which is the realistic threat.
Encryption in transit is the one with everyday value — including on internal network segments, which is exactly where healthcare estates tend to leave it off.
Do both. Just do not let "the database is encrypted" stand in for access control in a risk assessment. It answers a different question.
A 90-day improvement plan
GuardsArm assesses EHR access models and audit programmes across Epic, Cerner and MEDITECH environments, including the integration surfaces that sit outside the EHR vendor's responsibility. Book a scoping call.
Written by GuardsArm Team
Our team of cybersecurity experts brings decades of combined experience in penetration testing, compliance auditing, and incident response. We're dedicated to helping organizations strengthen their security posture.
Take the next step on “EHR Security: Protecting the Electronic Health Record”
Talk to the GuardsArm team about how these services apply to your environment.


