Back to Blog
Data Protection
10 min read

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

September 24, 2026

Securing the electronic health record

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.

Broad by design
Clinical roles need wide read access so care is not delayed in an emergency
Insider-weighted
A large share of healthcare privacy incidents involve authorised users, not intruders
HHS OCR breach portal
6 years
HIPAA documentation retention requirement — audit capability has to outlast staff turnover
45 CFR 164.316(b)(2)

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.

Layered EHR access modelAccess widens from a role baseline through department and treatment-relationship scoping, with break-glass override at the top generating a reviewed alert.Break-glass overrideAny chart, any time — every use alerts and is reviewed within 24hTreatment relationshipAssigned patients, scheduled encounters, care-team membershipDepartment scopeUnit or service line, appropriate to the roleRole baselineWhat the job function needs on an ordinary day
Each layer above the baseline should be harder to reach and more heavily logged.

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
TriggerReview windowTypical volume
Break-glass override24 hoursLow — every one reviewed
VIP / employee record access24 hoursLow
Surname or address matchWeeklyModerate
Peer-group volume anomalyWeeklyModerate
Post-termination activityReal-time alertShould be zero
The finding that ends careers
Post-termination access is the one to automate first. It is unambiguous, it is entirely preventable, and it appears in enforcement actions repeatedly. The fix is an HR-to-identity feed that disables accounts on the leave date without a ticket.

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

EHR security: first 90 daysEHR security: first 90 days1Inventory accessDays 1-30Who can see what, including service accounts and integrations. Compare against role definitions.2Close the leavers gapDays 15-45Automated HR-to-identity disablement, plus a one-off sweep of existing orphaned accounts.3Turn on targeted auditingDays 30-60Break-glass, VIP, surname and post-termination alerts routed to a named owner.4Scope the forgotten surfacesDays 60-90Interface engine encryption, FHIR app inventory and revocation, non-production PHI.

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.