Turning audit logs into actionable security signals for small healthcare practices
Part of the Telehealth & Healthcare Security Series. This post builds on the foundational concepts in The Compliance Trap and Why HIPAA Compliance Isn’t Enough, extending them into the DETECT function — where governance meets operational security.
The logs had the answer for 197 days. Nobody was reading them.
A small telehealth practice had audit logging enabled on their EHR — a compliance requirement. But nobody reviewed the logs. When investigators examined them after a breach, they found the attacker’s first login was logged on Day 1. The abnormal access patterns were logged every day after. The bulk data export was logged. The logs captured everything. The practice captured nothing.
This is the gap between logging and monitoring. Between recording events and actually watching for threats. It is the gap where most healthcare breaches live — not in the absence of data, but in the absence of attention.
Day 1 — 2:47 AM
Unauthorized login from unrecognized IP address. Credential stuffing attack succeeds against a provider account with a reused password. LOGGED ✓ ALERTED ✗
Day 3–14 — Various hours
Lateral movement across systems. Attacker accesses scheduling, billing, and EHR modules using compromised credentials. Access patterns differ markedly from the provider’s normal behavior. LOGGED ✓ ALERTED ✗
Day 45 — 11:15 PM
Bulk record access begins. Over 2,400 patient records accessed in a single session — 80x the provider’s daily average. LOGGED ✓ ALERTED ✗
Day 162 — 3:22 AM
Data staging and compression. Records packaged for exfiltration. Unusual file operations recorded in system logs. LOGGED ✓ ALERTED ✗
Day 197 — 4:08 AM
Data exfiltration. Patient records transferred to external destination. Network logs capture the outbound data transfer. LOGGED ✓ ALERTED ✗
Most practices confuse these two concepts. They are not synonyms. Logging is a technical function. Monitoring is a security program. Having one without the other is like installing security cameras but never watching the footage.
The NIST CSF 2.0 DETECT function (DE.CM) is explicit: continuous monitoring means assets are monitored to find anomalies, indicators of compromise, and other potentially adverse events. Writing events to a log file that nobody reads does not satisfy this requirement — no matter what your auditor says.
You do not need to monitor everything. You need to monitor the right things. These six signal categories, properly configured, cover approximately 90% of the threats specific to telehealth environments. Focus here first.
Failed logins, successful logins from new locations or devices, after-hours access, password resets, MFA bypasses, and impossible travel — a login from New York and California within minutes of each other. These are your highest-priority signals because compromised credentials remain the number one attack vector in healthcare.
Why it matters: The breach in our opening scenario started with a single unauthorized login at 2:47 AM. One alert on that event would have stopped everything that followed.
User creation or deletion, permission changes, system configuration changes, and security setting modifications. Any administrative action outside of defined change windows should generate an immediate alert. Attackers who gain admin access can disable logging, create backdoor accounts, and erase evidence of their presence.
Why it matters: If someone creates a new admin account at 11 PM on a Saturday and nobody notices until Monday, you have already lost control of your environment.
A provider accessing 500 records in an hour when they normally access 30. A staff member downloading patient lists. Any bulk export or query that exceeds normal patterns. This signal requires establishing baselines — you need to know what “normal” looks like before you can detect “abnormal.”
Why it matters: Bulk data access is the precursor to data exfiltration. Catching it early is the difference between a security incident and a reportable breach.
Unusual API call volumes, calls from unexpected IP addresses, failed authentication attempts on service accounts, and data transfers exceeding normal thresholds. Telehealth platforms rely heavily on APIs for scheduling, billing, prescriptions, and EHR integration — each one is a potential attack vector. (See also: Identity & Access Control for Telehealth.)
Why it matters: API-based attacks bypass traditional perimeter defenses entirely. If you are not monitoring API behavior, you have a blind spot the size of your entire integration layer.
Session recordings accessed by non-providers, unusual platform API calls, patient account lockouts, provider credential use from multiple simultaneous locations, and chat or messaging access after hours. These events are unique to telehealth and are not covered by generic security monitoring templates.
Why it matters: Telehealth platforms create attack surfaces that traditional on-premise healthcare IT never had. Your monitoring must evolve with your care delivery model.
Who viewed session recordings, when, and how many. Any download of recordings. Access to AI-generated transcripts or clinical notes derived from sessions. These are PHI goldmines — a single telehealth recording can contain diagnoses, treatment plans, medications, and deeply personal health information.
Why it matters: Session recordings and transcripts are among the most sensitive data your practice holds. Unauthorized access to even one recording constitutes a breach. Monitor them tightly.
Not every practice needs a SIEM or a SOC. But every practice — regardless of size — needs a structured approach to detection. A “minimum viable detection program” is not about buying expensive tools. It is about establishing five foundational elements:
Even enabling email alerts for failed login attempts and administrative changes provides more detection capability than 80% of small healthcare practices have today. You do not need to boil the ocean. Start with identity events and admin actions — the two highest-priority signal categories — and expand from there. A practice that monitors two things well is infinitely more secure than one that monitors nothing at all.
The key insight is this: the barrier to effective monitoring is not technology. Most EHR platforms, identity providers, and telehealth tools already generate the logs you need. The barrier is process — deciding what matters, assigning ownership, and committing to a review cadence. These are organizational decisions, not technical ones.
Use this artifact as a starting template for your practice. Customize the thresholds and owners to match your environment and staffing.
| Signal Category | Example Events | Log Source | Alert Threshold | Owner | Escalation |
|---|---|---|---|---|---|
| Identity Events | Failed login >5 in 10 min, impossible travel, after-hours login | Identity provider / EHR audit log | Immediate alert | IT Lead | Practice Manager → Fractional CISO |
| Admin Actions | User created/deleted, permissions changed, config modified | All system admin logs | Immediate alert | IT Lead | Practice Manager |
| Bulk Record Access | >100 records accessed in 1 hour, bulk export initiated | EHR audit log | Alert within 15 min | Practice Manager | Fractional CISO |
| API Anomalies | Unusual call volume, failed service auth, unexpected source IP | API gateway / integration logs | Alert within 1 hour | IT Lead | Vendor + Fractional CISO |
| Telehealth Events | Recording access by non-provider, multi-location login | Telehealth platform logs | Alert within 1 hour | Practice Manager | IT Lead |
| Recording Access | Recording downloaded, transcript accessed after hours | Telehealth / storage logs | Immediate alert | Practice Manager | Compliance Officer |
Do you have audit logging enabled on all systems that handle patient data?
Is anyone actually reviewing those logs — regularly, not just after an incident?
Do you have defined thresholds for what constitutes abnormal access?
If a provider accessed 500 records in an hour, would anyone notice before the end of the day?
Is there a named individual responsible for responding to security alerts?
Could you detect a compromised credential being used from an unusual location?
If you answered “no” to any of these questions, you have logging without monitoring — and logging without monitoring is just evidence collection for a breach you haven’t detected yet.
National Institute of Standards and Technology. (2024). Cybersecurity framework 2.0 (NIST CSWP 29). U.S. Department of Commerce. https://doi.org/10.6028/NIST.CSWP.29
U.S. Department of Health and Human Services. (2024). HIPAA security rule. 45 C.F.R. Parts 160, 162, and 164. https://www.hhs.gov/hipaa/for-professionals/security/index.html
Venuto, J. (2026). The compliance trap: Why ‘HIPAA compliant’ medical groups still get hacked. Hudson Valley CISO. https://www.hudsonvalleyciso.com/govern/gv-rm/hipaa_compliance_trap.html
Venuto, J. (2026). Why HIPAA compliance isn’t enough: A NIST CSF 2.0 guide for telehealth. Hudson Valley CISO. https://www.hudsonvalleyciso.com/govern/gv-rm/telehealth_nist_csf_hipaa_guide.html
Venuto, J. (2026). Identity and access control for telehealth. Hudson Valley CISO. https://www.hudsonvalleyciso.com/protect/pr-aa/telehealth_identity_access_control.html
You already have the logs. Let us help you turn them into a detection program that actually finds threats before they become breaches.
A focused review of your current logging and monitoring posture: what you’re capturing, what you’re missing, and exactly which alerts to configure first for maximum threat coverage with minimum noise.
Hudson Valley CISO
A Division of Security Medic Consulting
Fractional CISO Services | Threat Detection | Healthcare Security