HIPAA does not designate an uptime-monitoring product as compliant or prescribe one universal check interval. The Security Rule requires regulated entities to protect the confidentiality, integrity, and availability of ePHI through reasonable and appropriate safeguards selected from their risk analysis.
Monitoring can support specific duties: regular information-system activity review, audit controls, security-incident procedures, and contingency planning. It is only one part of compliance, alongside access control, workforce, physical, vendor, documentation, and risk-management requirements. Start with HHS's official Security Rule summary and OCR audit protocol.
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)
- Applications and data criticality analysis (addressable)
The required contingency specifications must be implemented. For an addressable specification, the entity must assess whether it is reasonable and appropriate and then implement it or document why an equivalent alternative is used. Monitoring can provide evidence for parts of the contingency process; it does not prove restore capability without an actual exercise.
§ 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: implement mechanisms appropriate to the environment that record and let authorized personnel examine system activity. Alerting and anomaly detection may support the control, but do not replace the underlying records, examination process, or risk-based design.
§ 164.310(a)(2)(ii) — Facility Security Plan
This physical safeguard applies to facilities housing systems that access ePHI. Cloud hosting can shift implementation responsibilities, but a BAA does not remove the regulated entity's responsibility to understand and document the shared-control model.
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 does not specify a numeric uptime target. Safeguards are evaluated through the regulated entity's risk analysis and factors such as:
- 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, reasonable and appropriate safeguards may differ from those for a small appointment portal. Depending on the risk analysis, an availability program may include:
- Availability monitoring of critical systems holding or using 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 — detects certificate failures affecting access and can support implemented transmission-security safeguards; § 164.312(e) must be applied according to its required and addressable specifications
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 — where MFA is part of the entity's implemented access-control design, verify the path and recovery process
- 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 the data-backup plan required. Testing and revision procedures under § 164.308(a)(7)(ii)(D) are addressable and must be handled through the Security Rule's addressable-specification process:
- 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 — choose and document a risk-based cadence, responsibilities, results, and corrective actions
- Backup protection status — monitor the encryption or equivalent safeguards selected through risk analysis and documented for backup media
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 controls — apply the period required for each record category. The Security Rule's six-year rule applies to required policies, procedures, and documentation; it is not a blanket six-year audit-log retention rule.
5) Encryption Infrastructure
Encryption specifications are addressable, which means the entity must assess reasonableness and appropriateness and document its implementation or equivalent alternative:
- Database transport protection — verify the encryption or equivalent safeguard selected for connections carrying ePHI
- 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?
Detection and response records help the entity investigate incidents and demonstrate that its procedures operated. How to Reduce MTTR and Recover from Incidents Faster covers the operational side.
7) Business Associates and Vendors
§ 164.308(b)(1) addresses business-associate arrangements. Operational monitoring is not a substitute for the required agreement, risk analysis, and vendor-management process, but it can expose availability impact from a material service provider:
- 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 |
Build Monitoring From the HIPAA Risk Analysis
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 status page can support an operational communication plan, but HIPAA does not require a public status page. Never publish ePHI or details that create additional security or privacy risk.
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
Escalate a potential breach through the organization's privacy and legal process promptly. The Breach Notification Rule requires notice without unreasonable delay and no later than the applicable outer deadline when notification is required; the designated decision-makers should document the risk assessment and timing.
Incident Communication: Status Updates During Outages covers the customer-facing side; the privacy officer communication is internal but equally time-sensitive.
Where External Monitoring Can Contribute
External monitoring can contribute availability, certificate, DNS, heartbeat, and incident-timeline evidence. It does not implement the full set of HIPAA safeguards:
- 24/7 uptime monitoring with a cadence chosen from the risk analysis and recovery objectives; Webalert's published plans currently offer one-minute checks on paid tiers and ten-minute checks on Free
- Multi-region checks — Webalert probes from US, EU, and APAC regions; verify that those locations represent the populations and dependencies in scope
- 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 — Webalert lists Email and Slack on all plans; SMS, webhooks, Discord, and Microsoft Teams are paid-plan channels
- Status pages — transparent customer communication during incidents
- Incident records — timestamped detection, acknowledgment, and resolution data for audits
- Timestamped history — retain selected availability evidence under the organization's documentation and retention policy
Do not place ePHI in monitor URLs, request bodies, screenshots, response captures, alert messages, or status pages. Determine with your security and privacy officers whether a monitoring provider creates, receives, maintains, or transmits ePHI and whether a BAA or other safeguards are required.
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 status page only when it fits the communication plan and can avoid ePHI or sensitive incident disclosure.
- Treat your monitoring system itself as in-scope — heartbeats, redundancy, and effectiveness reviews matter.
Monitoring can support selected safeguards and their evidence. Compliance depends on the entity's complete, risk-based Security Rule program.