Access Logging and Monitoring

Access logging and monitoring means you must record and routinely review all access events to systems that store or process PHI, including successful logins, failed attempts, and privilege escalations. To operationalize it quickly, define PHI system scope, standardize required log fields, centralize logs, set alerting for high-risk events, and keep evidence that reviews and follow-up happened. ¹

Key takeaways:

• You need complete access-event coverage for PHI systems: success, failure, and privilege change events. ¹
• “Logging” without review is a control gap; monitoring must detect and drive response to anomalous patterns. ¹
• Auditors will ask you to prove scope, log integrity, alert handling, and consistent review records—not just tool screenshots. ¹

For healthcare organizations and Health IT vendors, “access logging and monitoring” is one of those requirements that sounds straightforward until you try to prove it under audit: Which systems count as “PHI systems”? What events must be captured? How do you show monitoring is real and not aspirational?

HICP Practice 3.8 is clear on the minimum: log and monitor all access events to PHI systems, including successful logins, failed attempts, and privilege escalations, and monitor for anomalous patterns. ¹ In practice, that translates into a short list of operational outcomes: (1) you can reconstruct who accessed PHI systems, when, from where, and with what privilege; (2) you can detect abnormal access behavior; and (3) you can demonstrate that alerts and reviews lead to investigation and remediation.

This page is written for a Compliance Officer, CCO, or GRC lead who needs requirement-level implementation guidance you can hand to IT/security and then verify with artifacts. It focuses on scoping, control design, and audit-ready evidence.

Regulatory text

Requirement (excerpt): “Log and monitor all access events to PHI systems including successful logins, failed attempts, and privilege escalations.” ¹

Operator interpretation (what you must do):

• Log: Configure PHI systems and their identity layers to generate audit records for (at minimum) successful authentications, failed login attempts, and privilege escalations. ¹
• Monitor: Review and/or alert on those logs to identify anomalous patterns and take follow-up actions when something looks suspicious. ¹

Plain-English version: If someone tries to get into a PHI system (and whether they succeed or fail), or their access level changes, you need records of that activity and a monitoring process that can spot abnormal behavior and drive investigation. ¹

Who it applies to

Entity types

• Healthcare organizations that create, receive, maintain, or transmit PHI and run systems where PHI resides. ¹
• Health IT vendors operating products or services that store, process, or provide administrative access to PHI systems. ¹

Operational context (where the control must exist)

• PHI systems: EHR/EMR platforms, clinical apps, billing/revenue cycle systems, imaging systems, document management systems containing PHI, data warehouses with PHI, and any hosted environment where PHI is stored or processed. ¹
• Access paths that matter: SSO/IdP, VPN/remote access, privileged access tools, admin consoles, cloud control planes, break-glass accounts, service accounts with interactive login capability, and third-party support access when it can reach PHI systems. ¹

Boundary rule you can enforce internally: If compromise of an account or admin session could expose PHI, treat it as in-scope for access logging and monitoring.

What you actually need to do (step-by-step)

1) Define and freeze “PHI system” scope

Deliverable: an inventory list you can audit against.

• Identify systems that store or process PHI, plus supporting identity components (IdP, directory services) and administrative interfaces. ¹
• Include cloud services and managed platforms where you have admin access that could enable PHI access (for example, cloud console roles tied to PHI data stores). ¹
• Record system owner, environment, and primary log sources (OS, app, database, IdP, PAM).

2) Standardize minimum access-event coverage

Create a simple control standard that engineering can implement consistently:

• Successful logins (interactive and administrative). ¹
• Failed login attempts (bad password, MFA failure, locked account events where available). ¹
• Privilege escalations (role grants, group membership changes, admin rights added, sudo/RunAs events, cloud IAM role changes). ¹

Minimum fields to make logs usable in investigations:

• User/account identifier, timestamp, source IP/device, system/application name, authentication method, result (success/failure), and privilege level/role at time of access (or before/after for change events).

3) Centralize logs and protect their integrity

You need a defensible story for completeness and tamper resistance.

• Forward logs from PHI systems and identity layers to a central log platform (SIEM or log management).
• Restrict who can disable logging or alter log pipelines; treat this as privileged admin activity and monitor it as well.
• Document log source onboarding status and exceptions (with compensating controls).

4) Define “monitoring” in operational terms

Monitoring must be more than “logs exist.”

• Establish alerting use cases tied to the required events: repeated failed logins, unusual geo/ASN access patterns, impossible travel indicators where your tools support it, and privilege escalations outside normal workflows. ¹
• Set triage ownership: who receives alerts, who investigates, and who can disable accounts or roll back privileges.
• Write investigation playbooks for:
  • Credential stuffing / brute force (failed attempts trend)
  • Account takeover suspicion (success after multiple failures; new device/IP)
  • Unauthorized privilege elevation (unexpected role change)

5) Build a review cadence and make it auditable

You need a repeatable process with records:

• Assign log review responsibilities by system family (identity team reviews IdP logs; security reviews SIEM alerts; app owners validate expected admin access patterns).
• Require documentation of:
  • What was reviewed (systems, date range)
  • Findings (including “none”)
  • Tickets created and outcomes

6) Close the loop with access governance

Monitoring findings must connect to control improvements:

• Feed confirmed issues into access management: disable stale accounts, tighten role assignment workflows, and require approvals for privileged changes.
• If you rely on third parties for support, ensure their access events are captured (through your IdP, PAM, or application audit logs) and included in monitoring.

Where Daydream fits naturally: Daydream can help you turn this requirement into a tracked control with owners, defined evidence, and recurring review tasks, so access-log reviews and follow-up tickets don’t live in inboxes and tribal knowledge.

Required evidence and artifacts to retain

Auditors usually want proof across four categories: scope, configuration, operations, and response.

Scope and design

• PHI systems inventory with log source mapping
• Access logging and monitoring standard (what events are required)
• Monitoring use-case list (alert logic descriptions)

Configuration evidence

• Sample log outputs showing:
  • successful login event
  • failed login attempt
  • privilege escalation event ¹
• Screenshots or exported configurations showing audit logging enabled on representative PHI systems and identity services
• Log forwarding/collector configuration summaries

Operational monitoring evidence

• Alert queue snapshots with timestamps and dispositions
• Log review attestations (dated checklists, sign-offs, or tickets)

Response evidence

• Incident or case tickets for investigated anomalies
• Privilege rollback records / account disablement approvals
• Post-incident notes showing root cause and corrective actions

Common exam/audit questions and hangups

Questions you should be ready for

• “List all systems in scope for PHI and show which are logging access events.” ¹
• “Show me failed login attempts and how you detect anomalous patterns.” ¹
• “How do you detect and investigate privilege escalation?” ¹
• “Who reviews logs, how often, and where is it documented?”
• “Can administrators delete or change logs? How do you control that?”

Hangups that slow audits

• “PHI system” definition is fuzzy or outdated.
• Logging exists in tools, but you cannot prove anyone reviewed it.
• Privilege changes happen in multiple places (AD groups, application roles, cloud IAM) with incomplete coverage.

Frequent implementation mistakes (and how to avoid them)

1. Logging only at the application layer

• Fix: capture identity-provider, OS, and cloud IAM events for systems that gate access to PHI.

2. No reliable privilege escalation trail

• Fix: standardize “privilege escalation” to include group changes, role grants, and admin rights assignments across platforms; route those events to the same monitoring pipeline. ¹

3. Alert fatigue without a triage model

• Fix: define a small set of high-signal alerts (failed attempts bursts, admin role grants) and require disposition notes.

4. Third-party access is invisible

• Fix: force third-party support through your IdP/PAM so access is attributable and logged; avoid shared accounts.

5. Evidence is scattered

• Fix: store evidence in a control record (tool exports + review tickets + response tickets). Daydream can act as the system of record for evidence requests and recurring reviews.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions. Practically, weak access logging increases breach investigation time, limits your ability to confirm whether PHI was accessed, and makes it harder to show that privileged activity was controlled and reviewed. The operational risk is highest where administrators can reach PHI systems and where accounts are federated across many apps.

Practical 30/60/90-day execution plan

Because no time-to-implement metrics are provided in the source material, treat this as a sequencing plan, not a guaranteed timeline.

Days 0–30: Stabilize scope and minimum coverage

• Publish the PHI system inventory for logging scope and get owner sign-off.
• Define the required events (success, failure, privilege escalation) and minimum fields. ¹
• Pick the central log platform and onboard highest-risk identity sources first (IdP, directory, VPN/remote access).

Days 31–60: Turn on monitoring and prove operations

• Implement alerting for failed login bursts and privilege escalation events. ¹
• Stand up triage workflows (who investigates, how to document outcomes).
• Run tabletop tests using real log samples: simulate a failed login spray and a suspicious role grant; confirm alerts fire and tickets are created.

Days 61–90: Expand coverage and harden evidence

• Onboard remaining PHI systems and admin planes into centralized logging.
• Reduce exceptions: replace shared admin accounts with named accounts; route third-party access through controlled paths.
• Operationalize evidence: recurring log review tasks, evidence repository, and consistent ticketing. If you use Daydream, configure the control with required evidence types and automated reminders for reviews.

Frequently Asked Questions

Do we have to log both successful and failed logins?

Yes. HICP Practice 3.8 explicitly calls out logging and monitoring successful logins and failed attempts for PHI systems. ¹

What counts as a “privilege escalation” for this requirement?

Treat any event that increases effective access to PHI systems as a privilege escalation, including admin role grants, group membership changes, and cloud IAM policy/role changes. HICP Practice 3.8 requires logging and monitoring privilege escalations. ¹

If our SIEM stores logs, is that enough to meet “monitoring”?

Storage alone is not monitoring. You need a defined process that reviews logs and/or alerts on anomalous patterns, with records of investigation and follow-up actions. ¹

How do we handle third-party support access to PHI systems?

Require third-party access through controlled identity paths (your IdP, VPN with individual accounts, or PAM) so each session is attributable and logged. Then include those events in the same monitoring workflows.

What evidence should we show an auditor first?

Start with the PHI system scope list, then demonstrate representative log events (success, failure, privilege escalation) and provide recent review/alert tickets that show triage and resolution. ¹

Our EHR is hosted by a Health IT vendor. Are we still on the hook?

You still need assurance that access events are logged and monitored for the PHI system you rely on. Contractual requirements, shared responsibility documentation, and obtained audit evidence help close the gap for hosted systems. ¹

Footnotes

1. HICP 2023 - 405(d) Health Industry Cybersecurity Practices