If you handle electronic protected health information (ePHI) in the United States, HIPAA isn't optional. The Security Rule requires you to implement administrative, physical, and technical safeguards to protect ePHI — and those safeguards explicitly include availability and integrity, not just confidentiality.
Most teams think of HIPAA as a privacy framework about access controls and BAAs (Business Associate Agreements). True, but HIPAA also requires ongoing monitoring of system activity, the ability to recover from incidents, and audit-ready records that prove your safeguards actually work. When the OCR (Office for Civil Rights) audits you, "we hope it's working" is not an answer.
This guide explains what HIPAA actually requires from a monitoring perspective, what auditors look for, and how to set up monitoring that produces the evidence you'll need.
Disclaimer: This guide is general technical guidance, not legal or compliance advice. For binding HIPAA interpretations specific to your covered entity or business associate status, consult your HIPAA compliance officer, privacy officer, or qualified legal counsel.
How HIPAA Touches Monitoring
The HIPAA Security Rule (45 CFR §§ 164.302 – 164.318) is where monitoring obligations live. Three sections matter most:
§ 164.308(a)(1)(ii)(D) — Information System Activity Review
The Security Rule requires implementing procedures to "regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports."
Translated: you need monitoring that produces logs, and a documented process for actually reviewing those logs. An audit log nobody reads is not a safeguard.
§ 164.308(a)(7) — Contingency Plan
Covered entities must establish "policies and procedures for responding to an emergency or other occurrence (for example, fire, vandalism, system failure, and natural disaster) that damages systems that contain electronic protected health information."
This includes:
- Data backup plan (required)
- Disaster recovery plan (required)
- Emergency mode operation plan (required)
- Testing and revision procedures (addressable but expected)
- Applications and data criticality analysis (addressable but expected)
Translated: your backup and recovery procedures must exist, must be tested, and must be documented. Monitoring is how you prove they work.
§ 164.312(b) — Audit Controls
A specific technical safeguard: implement "hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information."
Translated: log access to ePHI, and have the means to examine those logs. Monitoring tools that surface anomalies in those logs satisfy this requirement.
§ 164.310(a)(2)(ii) — Facility Security Plan
For physical safeguards on facilities housing ePHI; relevant for on-prem health systems but largely abstracted away if you use a HIPAA-compliant cloud provider under a BAA.
What "Availability" Means Under HIPAA
The Security Rule's definition of integrity (§ 164.304) and the contingency plan requirement together set an expectation: ePHI must be accessible to authorized users when needed, and recoverable after incidents.
HIPAA doesn't specify a numeric uptime target. It does require reasonable and appropriate safeguards, evaluated against:
- Size, complexity, and capabilities of the covered entity
- Technical infrastructure, hardware, and software security capabilities
- Costs of security measures
- Probability and criticality of potential risks
For a hospital EHR with 24/7 clinical use, "appropriate" is far more stringent than for a small dental practice's appointment portal. But for any system handling ePHI, OCR expects at least:
- Continuous availability monitoring of systems holding ePHI
- Alerting that reaches a person who can act
- Documented incident response with timestamps
- Tested backups and a tested recovery plan
- Records of monitoring activity available for audit
Monitoring for SOC 2 Compliance and Audit Requirements covers a related framework with significant evidence overlap. Monitoring for GDPR Compliance covers the EU equivalent.
What to Monitor for HIPAA Evidence
1) Systems Containing ePHI
Every system that creates, receives, maintains, or transmits ePHI is in scope:
- Patient portals and EHR access — Uptime monitoring with check intervals supporting your detection SLO (typically 1–5 minutes)
- APIs serving ePHI — Monitor authenticated endpoints used by integrations and partners
- Multi-region availability — If clinicians or patients access from anywhere, confirm reachability
- TLS / SSL monitoring — Encryption in transit is required (§ 164.312(e)); expired certs are an availability and a confidentiality issue
2) Access Control Systems
A failed authentication system can either lock out clinicians (availability incident) or silently allow unauthorized access (confidentiality incident):
- Authentication flow synthetics (see How to Monitor Your Login and Authentication Flow)
- MFA verification path — Required for many ePHI access scenarios; verify it actually works
- Session timeout enforcement — Monitor that idle sessions actually expire as configured
- Emergency access procedure ("break glass") — Test and document the path used in emergencies
3) Backup and Restore
§ 164.308(a)(7)(ii)(A) makes data backup mandatory. § 164.308(a)(7)(ii)(D) makes testing addressable but expected:
- Backup completion monitoring — Heartbeat from the backup job; alert when missed (see Cron Job Monitoring)
- Backup integrity — Alert if backup size deviates from expected ranges
- Restore drill schedule — Quarterly is a common cadence; document each drill with results
- Backup encryption status — Backups containing ePHI must remain encrypted at rest
4) Audit Logging Pipelines
If your audit logging system goes down, you've lost the ability to satisfy § 164.312(b). The pipeline itself is in scope:
- Audit log ingestion endpoint — Monitor that logs are arriving
- Log volume tracking — Alert on suspicious drops (broken collector) or spikes (incident in progress)
- Log integrity — Cryptographic log signing or write-once storage with monitoring of integrity violations
- Retention compliance — HIPAA requires 6-year retention for many records; monitor that storage isn't being prematurely cleared
5) Encryption Infrastructure
Encryption is technically addressable, but in practice expected:
- Database TLS — Connections to databases holding ePHI must use encryption
- KMS / key management service availability — A KMS outage can take systems offline if encryption is mandatory at the application layer
- Certificate validity for internal mTLS — Service-to-service auth in HIPAA-compliant architectures
6) Incident Detection and Response
§ 164.308(a)(6) requires identifying and responding to security incidents. Speed of detection matters:
- Mean Time To Detect (MTTD) — How long between incident start and alert?
- Mean Time To Acknowledge (MTTA) — How long until a human responds?
- Mean Time To Recover (MTTR) — How long to full restoration?
The OCR has fined organizations specifically for slow detection. How to Reduce MTTR and Recover from Incidents Faster covers the operational side.
7) Business Associates and Vendors
§ 164.308(b)(1) requires written contracts with business associates handling ePHI. You're responsible for monitoring that those vendors are operationally healthy:
- Monitor third-party APIs handling ePHI (see Third-Party Dependency Monitoring)
- Track vendor incidents in your incident log even when you didn't resolve them
- Maintain awareness of vendor status pages and breach notifications
8) Workstation and Endpoint Health
§ 164.310(c) and § 164.312(a)(2)(iii) cover workstation security:
- Endpoint detection and response (EDR) telemetry
- Device encryption status (FileVault, BitLocker)
- Patch level monitoring
- Inactivity timeouts on workstations accessing ePHI
Evidence Auditors Look For
When OCR investigates (or your annual risk assessment is being prepared), auditors typically request:
| Question | Evidence to Provide |
|---|---|
| How is system availability monitored? | Monitoring tool, check intervals, list of in-scope systems |
| Who responds when something breaks? | Escalation policy, on-call rotation, contact details |
| What was your average detection time last quarter? | Incident records with detect/ack/resolve timestamps |
| Show me your contingency plan testing | Quarterly restore drill records, tabletop exercises |
| When was your last backup restore drill? | Drill log, results, action items |
| How is ePHI access logged? | Audit logging architecture, sample logs, retention policy |
| Show me an example security incident response | Incident timeline, root cause, remediation, evidence |
| How do you handle business associate incidents? | BA inventory, BA incident log |
| What changed after your last incident? | Post-mortem actions, follow-up tickets |
| How do you ensure monitoring itself is working? | Heartbeat / synthetic checks on the monitoring system |
You don't need expensive software to produce this — you need consistency and durability of records. A simple, well-maintained incident log with timestamps, owners, and resolutions outperforms scattered Slack threads in any audit.
Common HIPAA Monitoring Gaps
| Gap | Risk | Fix |
|---|---|---|
| No uptime monitoring on patient portal | OCR finding on availability | Synthetic checks with multi-region |
| Backup completes but never tested | Cannot satisfy § 164.308(a)(7)(ii)(D) | Quarterly restore drill with logged evidence |
| Audit log pipeline silently failed | Missing § 164.312(b) coverage during outage | Log volume monitoring + heartbeat |
| Alert fatigue causes ignored real incidents | Late detection, late breach response | See Alert Fatigue |
| No record of incident detection time | Auditor cannot assess responsiveness | Standardized incident log with timestamps |
| Monitoring runs from one region | Outages in other regions invisible | Multi-region checks |
| Business associate outages not logged | Article 308(b)(1) oversight gaps | Incident log includes BA incidents |
| No certificate expiry monitoring | TLS lapse risks confidentiality + availability | SSL monitoring with multi-week notice |
| Monitoring tool itself is unmonitored | Silent monitoring failure | Heartbeat from monitoring to a second system |
| EDR telemetry gap on clinical workstations | Endpoint compromise undetectable | Workstation telemetry alerting |
Setting Up HIPAA-Aligned Monitoring
Minimum baseline
- Uptime monitoring of all systems handling ePHI with at least 5-minute checks
- TLS certificate monitoring with at least 14-day expiry warnings
- Multi-region monitoring matching your user geography
- Documented escalation policy so alerts reach someone authorized to act
- Incident log with timestamps for detection, acknowledgment, and resolution
- Heartbeat monitoring of backup jobs
- Audit log pipeline monitoring with volume baselines
Audit-ready setup
Add:
- Synthetic monitoring of authentication and emergency access flows
- MFA verification path synthetics
- Business associate health in your monitoring dashboard
- Quarterly restore drills with logged evidence
- Quarterly tabletop exercises simulating major incidents
- Annual monitoring effectiveness review with documented results
- Status page for transparent communication during incidents involving ePHI access
A public status page is valuable for HIPAA: it doubles as evidence of timely communication of availability incidents to affected parties, which OCR weighs favorably.
What to Do When Monitoring Detects a Potential ePHI Incident
HIPAA-aware incident response differs from purely operational response in three ways:
1) Triage with ePHI exposure in mind
For every detected incident, ask early: does this involve ePHI?
- If unauthorized access or disclosure is possible — your breach risk assessment process starts now
- If integrity might be compromised — note exact detection time
- If availability is impacted — document for the contingency plan record
2) Document the timeline rigorously
For HIPAA, minute-by-minute records matter:
- Time of first alert (from monitoring)
- Time of acknowledgment (from your alerting tool)
- Time of escalation
- Time of containment
- Time of resolution
- Time of risk assessment completion
- Time of notification decisions
Your monitoring system already produces most of these timestamps automatically. Capture them and preserve them in your incident record.
3) Loop in the privacy officer early
Whether or not the privacy officer is on the technical bridge, they need to know quickly. Notification timelines under § 164.404 (60 days) and the breach risk assessment under § 164.402 are not flexible. The privacy officer is the one who decides whether notification is required.
Incident Communication: Status Updates During Outages covers the customer-facing side; the privacy officer communication is internal but equally time-sensitive.
How Webalert Helps
Webalert provides the technical foundation for HIPAA-aligned monitoring:
- 24/7 uptime monitoring with check intervals as tight as 30 seconds
- Multi-region checks — confirm availability across every region your users access from
- SSL monitoring — catch certificate issues that affect availability and confidentiality
- DNS monitoring — detect resolution failures that block authorized access
- Heartbeat monitoring — confirm backups, audit log pipelines, and scheduled jobs are running
- Multi-channel alerts — Email, SMS, Slack, Discord, Microsoft Teams, webhooks
- Status pages — transparent customer communication during incidents
- Incident records — timestamped detection, acknowledgment, and resolution data for audits
- 5-minute setup — start producing audit-ready monitoring evidence today
Webalert itself does not store, process, or transmit ePHI. We monitor the availability of systems that may. Confirm with your privacy officer how external monitoring fits into your risk analysis and BAA inventory.
See features and pricing for details.
Summary
- HIPAA Security Rule explicitly requires availability and integrity safeguards, not just confidentiality.
- § 164.308(a)(1)(ii)(D), § 164.308(a)(7), and § 164.312(b) put monitoring squarely in scope.
- Auditors care about process and evidence: monitoring coverage, escalation, incident records, restore drills, audit log integrity.
- Monitor systems containing ePHI, authentication flows, backup pipelines, audit log pipelines, and business associates.
- Track detection time, acknowledgment time, and resolution time for every incident.
- Use a public status page as both communication and audit evidence.
- Treat your monitoring system itself as in-scope — heartbeats, redundancy, and effectiveness reviews matter.
HIPAA turns availability into a regulatory requirement. Monitoring is how you prove your safeguards actually work.