Audit Logging and Access Controls for Clinical Video

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

Audit logging is the control your team will be asked about in every enterprise sales call, every payer security questionnaire, and every OCR investigation — usually in the same form: "show me who accessed this patient's session, and prove the log is complete." If you build a telemedicine platform, you must be able to answer for the video call itself, not just the chart: who joined, who watched the recording, who downloaded the transcript, and who changed the settings that govern all of it. This article is for the founder, product manager, or hospital IT lead who needs to translate four short rule citations into an event taxonomy, a role matrix, an immutable storage design, and a review cadence. You will leave with the exact regulatory text, the telemedicine-specific list of events to capture, the arithmetic showing retention costs almost nothing, and a one-page checklist to run against your build.

The visitor sign-in sheet, and the two halves of the problem

Picture a hospital ward with a locked door. Two separate mechanisms protect it. The badge reader on the wall decides who may enter — that is access control. The sign-in sheet at the nurses' station records who actually came in, when, and what they touched — that is the audit log. One is preventive; the other is evidentiary. Neither substitutes for the other: a badge reader without a sign-in sheet cannot reconstruct an incident, and a sign-in sheet without a badge reader merely documents the intrusion it failed to stop.

The Health Insurance Portability and Accountability Act (HIPAA) — the US law protecting health information that can be tied to a person, called protected health information (PHI) — writes both mechanisms into its Security Rule, the part of the regulation that governs electronic PHI (ePHI). For the architecture of the whole law, start with HIPAA in plain English for product teams; if you are entirely new to healthcare compliance, the short version is in our compliance guide for healthcare apps. Here we go deep on one pair of controls — the pair that decides whether you can answer the only question that matters after something goes wrong: who did what, and when?

In a telemedicine product the question has more surface area than in any other health system. A video consult is not one record in one database. It is a waiting-room admission, a call with two or more participants whose roles differ, an optional recording, an optional transcript, a chat thread, shared files, and a write-back to the electronic health record (EHR). Each of those is an access event someone may later need to reconstruct — for a patient complaint, a breach investigation, a malpractice case, or an OCR audit. Design the logging after launch and you will discover that the most important events were never captured.

What the rules actually say — four citations, four duties

The regulatory core of this topic fits in four citations. Everything else in this article is engineering built on top of them.

Duty 1 — control access (45 CFR §164.312(a)). The access-control standard requires "technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in §164.308(a)(4)." It carries four implementation specifications, and their labels matter. Unique user identification is required: "assign a unique name and/or number for identifying and tracking user identity" — no shared logins, ever, because a log entry that says clinic-cart-3 identifies a piece of furniture, not a person. Emergency access procedure is required: a documented way to reach ePHI when normal authorization fails — the "break-glass" path we design below. Automatic logoff is addressable: end idle sessions after a set time. Encryption and decryption is addressable and covered in depth in the encryption article. Addressable, as a reminder, does not mean optional — under §164.306(d) you implement it, or you document why an alternative achieves the same protection.

Duty 2 — authenticate identity (45 CFR §164.312(d)). The person-or-entity-authentication standard requires procedures to "verify that a person or entity seeking access to electronic protected health information is the one claimed." Access rights are meaningless if anyone can claim someone else's identity. Today the rule names no mechanism; the proposed 2026 Security Rule update would make multi-factor authentication (MFA) — proving identity with two independent factors, such as a password plus a phone — mandatory with limited exceptions, aligning HIPAA with NIST SP 800-63B's Authentication Assurance Level 2. We map identity flows for patients and clinicians in roles, identity, and consent.

Duty 3 — record activity (45 CFR §164.312(b)). The audit-control standard, in full: "Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." That is the entire text. It is required — there is no addressable flexibility here — and it is deliberately technology-neutral: no event list, no field schema, no log format, no retention clock. The one-sentence brevity is not a loophole; it is a delegation. The rule tells you that you must record and examine; your risk analysis under §164.308(a)(1)(ii)(A) determines what and how much. An auditor will not accept "the rule didn't specify" as a reason your recording-download events don't exist.

Duty 4 — review what you recorded (45 CFR §164.308(a)(1)(ii)(D)). The Security Rule's administrative safeguards close the loop with a required specification: "implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports." Logging without review is not compliance; it is evidence accumulating for the prosecution. The enforcement cases below all turn on this one specification.

Around these four sit two supporting requirements. The Privacy Rule's minimum-necessary standard (45 CFR §164.502(b)) requires you to limit each person's access to the minimum PHI needed for their job, and §164.514(d) makes that concrete: identify the classes of persons who need access and the categories of PHI each class needs — which is, in engineering terms, a requirement to design role-based access. And the workforce-security standards (§164.308(a)(3)–(4)) require procedures to authorize access, review it, and terminate it when someone leaves — the administrative process your technical controls enforce.

Figure 1. The compliance loop for clinical video. Access control and authentication decide who gets in; audit controls record what they did; the required activity review closes the loop — and feeds corrections back into access rights.

Where the specifics come from, since HIPAA names none

Three documents fill in what §164.312(b) leaves open, in descending order of authority.

NIST SP 800-66 Revision 2 (February 2024) is the National Institute of Standards and Technology's official implementation guide for the Security Rule, written with OCR. It frames audit logging as risk-driven: identify the systems that touch ePHI, decide which activities are security-relevant, log those, protect the logs, and review them on a documented schedule proportionate to your risk. It pointedly notes that a reasonable implementation for a small practice differs from a national platform's — which cuts both ways: a telemedicine platform serving thousands of patients does not get the small practice's discount.

ONC certification criteria give the closest thing US health IT has to a field-level logging standard. The certification program for EHR technology (45 CFR §170.315(d)(2), "auditable events and tamper-resistance") requires certified systems to record actions on health information using the content standard in §170.210(h), which incorporates ASTM E2147-18 — the standard specification for audit and disclosure logs in health information systems. The required minimum per event: the date and time, the patient identity, the user identity, and the type of action, with the audit log protected against being disabled or altered — and any change to the audit-log configuration itself recorded. Your telemedicine platform is probably not seeking ONC certification, but when a hospital customer's security team asks "what's in your audit events," ASTM E2147's field list is the vocabulary they expect.

Your own risk analysis is the third source, and legally the controlling one for scope. The required risk analysis (§164.308(a)(1)(ii)(A)) is where you document which systems hold ePHI — including the ones telemedicine teams forget: the selective forwarding unit (SFU) that routes call media, the recording pipeline, the transcription service, the support tooling that can impersonate users. If a system can see ePHI, its activity belongs in the audit trail.

The telemedicine audit-event taxonomy: what a clinical video platform must capture

Generic HIPAA articles tell you to log "access to ePHI." Useful logging for clinical video requires walking the consult lifecycle and naming the events at each stage. The taxonomy below is the list we wish every telemedicine codebase started with — it is also the spine of the downloadable checklist at the end.

Identity and account events. Login success and failure (with method — password, SSO, MFA), MFA enrollment and reset, password change, account creation, role assignment and change, permission grants, access-review decisions, deactivation, and — critically — every use of an impersonation or "view-as" feature by support staff. Failed logins matter as much as successes: §164.308(a)(5)(ii)(C) names log-in monitoring explicitly.

Scheduling and pre-visit events. Appointment created, rescheduled, canceled; intake form viewed or edited; insurance or ID document uploaded and viewed. The fact that a person has an appointment with a behavioral-health clinician is itself PHI — access to the schedule is access to PHI.

Waiting-room events. Patient joined the queue, was admitted by whom, was denied or timed out, was transferred. The waiting room is where identity verification meets the call — the admission decision is an access-control decision and must be logged as one.

Session events — the call itself. Session created; each participant's join and leave with timestamp, role, and device/IP; mid-call role changes (an interpreter added, a supervisor joining silently for QA, a caregiver invited); screen-share start and stop; in-call chat message sent (log the event and sender, not the message body — see the pitfall below); file shared; vitals device connected. For multi-party consults, the per-participant granularity is the difference between "there was a call" and "we can prove who was in the room."

Recording and artifact events. Recording started (by whom, under which consent), stopped, completed processing; recording viewed, downloaded, shared, exported, deleted; transcript generated, viewed, edited, exported; AI summary generated and viewed. Recordings are the highest-risk artifact a telemedicine platform produces — the recording article covers when to make them; this article's rule is simpler: every access to one is a loggable event, no exceptions, including access by your own engineers.

Clinical-data events. Chart opened during the consult, note created or amended, prescription initiated, lab order placed, EHR sync executed (what was written, where, by which integration identity).

Administrative and platform events. Configuration changes (recording defaults, retention settings, consent text), BAA-relevant vendor toggles, encryption settings, audit-log configuration changes (per ASTM E2147's tamper-resistance expectation), data exports, bulk reports, and use of the emergency-access procedure.

Here is what one well-formed audit event looks like in practice — note that it references PHI without containing it:

{
  "event_id": "evt_8f2c41d0",
  "timestamp": "2026-06-11T14:32:07.412Z",
  "event_type": "recording.downloaded",
  "actor": { "user_id": "u_5102", "role": "provider", "auth_method": "sso+mfa" },
  "patient_ref": "pt_88421",
  "resource": { "type": "recording", "id": "rec_3377", "session_id": "ses_9120" },
  "context": { "ip": "203.0.113.40", "user_agent": "Chrome/126", "reason": null },
  "outcome": "success",
  "prev_event_hash": "sha256:9b1f..."
}

The classic mistake: PHI in the logs. Engineers log what is in front of them — and in a telemedicine platform, what is in front of them is a diagnosis, a chat message, a signed URL to a recording. Log references, never payloads: patient and resource identifiers, not names; event types, not message bodies; resource IDs, not tokenized links that grant access to anyone holding the log. And accept the corollary: even reference-only logs tie identifiable people to clinical encounters, which makes the audit log itself ePHI. It must be encrypted, access-controlled, covered by a Business Associate Agreement (BAA) if a vendor hosts it — and access to the log must appear in the log.

Figure 2. The consult lifecycle as an audit surface. Every stage emits events; the recording and its derivatives generate access events for years after the call ends.

Access control in practice: roles, minimum necessary, and the break-glass path

The Privacy Rule's minimum-necessary standard turns into one engineering artifact: a role-permission matrix. Define the roles your product actually has, then grant each the narrowest slice of PHI its job requires. The matrix below is a starting point from our telemedicine builds — your verticals will adjust it.

Permission	Patient	Provider	Interpreter	Caregiver	Scheduler	Support	Billing	Platform admin
Join assigned session	Yes — own	Yes — assigned	Session-scoped	Invited, consented	No	No	No	No
View schedule / queue	Own only	Own panel	No	No	Yes — no clinical notes	Metadata only	No	No
Open chart during call	Own record	Treatment relationship	No	No	No	No	No	No
View / download recording	Own, if policy allows	Authoring clinician	No	No	No	Time-boxed, logged, with reason	No	No
View transcript / AI summary	Own, if released	Treatment relationship	No	No	No	No	No	No
Billing and claims data	Own statements	No	No	No	No	No	Amounts + codes, not notes	No
Change platform config	No	No	No	No	No	No	No	Yes — every change logged
Read audit logs	No	No	No	No	No	No	No	Security role only, logged

Three design rules make a matrix like this real rather than aspirational.

Scope access to the clinical relationship, not the role alone. Role-based access control (RBAC) — permissions attached to roles, roles attached to people — is the baseline, and it is what §164.514(d)'s "classes of persons" language anticipates. But "provider" must not mean "can open any patient's chart." The working rule is role plus relationship: a clinician sees the patients they treat. Pure RBAC cannot express that; you need an attribute on top (NIST SP 800-162 calls the general model attribute-based access control, ABAC) — the attribute being an active treatment relationship, an assigned session, an open episode of care. Interpreters are the cleanest example: their access should be session-scoped — granted when admitted to a consult, expiring when it ends, leaving nothing to revoke.

Give support staff time-boxed, reasoned access — never standing access. The support engineer who can open any session "to debug" is the single most common minimum-necessary violation in telemedicine builds. The pattern that survives audits: support access requires a ticket reference and a reason, elevates for a fixed window (30–60 minutes), is recorded as an impersonation event, and triggers a notification to the security role. Anthem's $16 million settlement — the largest in OCR history, after a breach of nearly 79 million records — cited, among other failures, insufficient procedures to regularly review information system activity and inadequate minimum-access controls; standing administrative access is exactly the condition that lets one phished credential become an enterprise-wide breach.

Design the break-glass path before you need it. The emergency-access procedure of §164.312(a)(2)(ii) is required, and clinical reality demands it: a covering physician needs the chart of a patient mid-crisis at 3 a.m. The wrong answer is a shared "emergency" account (it violates unique user identification). The right answer: any authenticated clinician may invoke emergency access to a specific record, the elevation requires a typed reason, the event pages the security role in real time, and every break-glass use is reviewed by a human within one business day. Break-glass that is silent is indistinguishable from a breach; break-glass that is loud is a safety feature.

Round out the access half with the mechanics the rule names: automatic logoff tuned to the surface (a shared nurses'-station workstation might lock at 2–5 minutes idle; a personal device at 15), MFA for every workforce account today (mandatory under the proposed 2026 update, and AAL2 per NIST SP 800-63B is the bar to design to), and termination procedures wired into your identity provider so that offboarding revokes access the day employment ends — the proposed update would add a 24-hour notification obligation between regulated entities when a workforce member's access changes or ends. Memorial Healthcare's $5.5 million settlement began with exactly this failure: a former employee of an affiliated physician's office whose credentials kept working — and being used — for a full year.

Immutability and retention: a log you can edit is not evidence

An audit trail earns its name only if nobody — including your own administrators, including an attacker holding admin credentials — can rewrite it. The Security Rule's integrity standard (§164.312(c)(1)) requires protecting ePHI from improper alteration or destruction, and the audit log is both ePHI and the evidence of everything else; it deserves the strongest integrity posture in the system.

The engineering pattern has four parts. Write-once storage: ship log batches to object storage with a write-once-read-many (WORM) lock — on AWS, S3 Object Lock in compliance mode, which nobody, including the root account, can lift before the retention date; GCP Bucket Lock and Azure immutable blob storage are the equivalents. Hash chaining: each event carries the hash of the previous one (the prev_event_hash field above), so deletion or edit of any record breaks the chain detectably — the same idea that makes a ledger tamper-evident. A separate security domain: the logging pipeline runs under credentials the production application cannot assume; the systems being watched must not be able to silence the watcher. Synchronized clocks: every service stamps events from NTP-disciplined time, because an investigation that cannot order events across the SFU, the API, and the EHR sync cannot establish what happened.

Now retention — and a discrepancy worth naming, because nearly every article on this topic gets it subtly wrong. The popular claim is "HIPAA requires you to keep audit logs for six years." What the rule actually says: §164.316(b)(1)(ii) requires a written record of any "action, activity or assessment" that the Security Rule requires to be documented, and §164.316(b)(2)(i) requires retaining that documentation for six years from creation or last effective date. The audit-control standard itself names no log-retention period at all. The six-year figure attaches to audit logs by a conservative — and near-universal, and auditor-expected — reading that treats system-activity records and the records of your required reviews as documentation of a required activity. We follow that reading and recommend you do too, but precision matters when your retention policy meets a lawyer: the six years is an interpretation of the documentation rule, not a sentence you can quote from §164.312(b). And the federal floor is not the ceiling: ASTM E2147-18 recommends retaining audit data for the life of the medical record and at least 10 years, several states set medical-record retention near 10 years, and substance-use-disorder records under 42 CFR Part 2 carry their own stricter regime — see state and specialty rules.

Whatever period you choose, the cost argument for keeping more is over before it starts. Walk the arithmetic once: a mid-size platform running 200 consults a day, each emitting roughly 40 audit events of about 1 KB each, produces 200 × 40 × 1 KB = 8 MB per day — call it 2.9 GB per year. Six years of fully searchable history is about 17.5 GB; at roughly $0.023 per GB-month for standard object storage that is about $0.40 per month, less than a coffee, for the dataset that decides whether an incident is reconstructable. There is no cost excuse for thin logs. The real cost lives in the next section.

Figure 3. The immutable-trail pattern: append-only collection, write-once storage, hash chaining, separate credentials, synchronized clocks — and log access that is itself logged.

The review loop: what "regularly review" means, and what it costs to skip

Four OCR enforcement actions define this section better than any prose.

Memorial Healthcare System — $5.5 million (February 2017). A former employee's login credentials were used to access ePHI for twelve months — April 2011 to April 2012 — before anyone noticed. 115,143 individuals affected. OCR's findings: failure to regularly review records of information system activity, and failure to review and modify users' access rights. The accompanying OCR statement is the thesis of this article in one line: "Organizations must implement audit controls and review audit logs regularly."

Anthem — $16 million (October 2018). The largest health data breach in US history at the time — nearly 79 million people — began with spear-phishing. Among OCR's cited failures: insufficient procedures to regularly review information system activity and inadequate minimum-access controls. The logs existed; the looking did not.

Premera Blue Cross — $6.85 million (September 2020). Attackers persisted undetected for roughly nine months; OCR cited systemic non-compliance including risk-analysis and audit-control failures across 10.4 million records.

CHSPSC — $2.3 million (September 2020). A business associate serving hospital systems was warned by the FBI that attackers were active, and the intrusion continued for months afterward; more than 6 million individuals affected. Failures included information-system activity review and security-incident response. A BAA does not transfer this duty — business associates carry §164.312(b) and §164.308(a)(1)(ii)(D) themselves.

The pattern across all four is identical: the breach was not the violation OCR led with — the silence was. "Regularly review" has no numeric definition in the rule, so define it yourself, in writing, at a cadence you can sustain, and generate evidence that the reviews happen. A telemedicine-appropriate baseline:

Cadence	Activity	Output you can show an auditor
Continuous	Automated alerts: failed-login bursts, impossible-travel logins, break-glass use, recording bulk downloads, audit-config changes, log-pipeline gaps	Alert rules + paging history
Weekly	Human triage of the alert queue and anomaly dashboard	Signed-off triage notes
Monthly	Review of all impersonation/support access and break-glass events; sample-based session-access review	Review record with findings
Quarterly	Access recertification: every workforce role re-confirmed by a manager; dormant accounts disabled	Recertification report
Annually	Full evaluation under §164.308(a)(8); review of the logging taxonomy against new features	Updated risk analysis + policy revisions

Figure 4. The review loop an auditor will accept: five cadences, each leaving an artifact. Beneath them, OCR's price list for silence.

The honest cost center is here, not in storage: a competent weekly triage plus monthly reviews consumes hours of skilled time, every week, forever. Budget for it as an operating expense of handling PHI — it is the part of compliance that compounds, because every review record is evidence of diligence, and a twelve-month silent gap is evidence of the opposite.

The 2026 Security Rule update: where this is heading

The proposed HIPAA Security Rule update (Notice of Proposed Rulemaking, 90 FR 898, January 6, 2025) would be the first major rewrite of these requirements since 2003 — and as of June 11, 2026 it remains a proposed rule: the comment period closed March 7, 2025, OCR's regulatory agenda pointed at spring 2026 for a final rule, and that window has passed without publication. Verify current status against RIN 0945-AA22 before relying on any provision. The full change set is mapped in the 2026 Security Rule article; the provisions that land directly on this article's territory:

• Every implementation specification becomes required — the addressable category, including automatic logoff, disappears.
• MFA becomes mandatory with limited exceptions, written into the technical safeguards.
• A proposed audit trail and system log controls standard strengthens §164.312(b), including monitoring activity in relevant systems — with the NPRM's real-time-monitoring language drawing heavy industry comment about feasibility; expect the final text to move, and design to the direction rather than the letter.
• Annual compliance audits and a maintained technology asset inventory and network map (refreshed at least every 12 months) become explicit duties — the asset inventory is where your SFU, TURN servers, recording pipeline, and transcription vendor get formally enumerated.
• 24-hour notification between regulated entities when a workforce member's access to ePHI changes or terminates.
• Vulnerability scanning at least every six months and annual penetration testing, which will exercise the logging pipeline as much as the perimeter.

The practical posture mirrors our encryption advice: build to the proposal now. Every provision above is already the expectation of enterprise customers' security questionnaires, and nothing in the NPRM contradicts the architecture in this article — it mandates it.

Choosing where the logs live: the BAA column decides

The log platform sees every event your system emits — and since the events reference patients, the platform handles ePHI and needs a signed BAA, the contract that makes a vendor your HIPAA business associate (the BAA article explains why "encrypted" does not substitute for "covered"). BAA coverage is binary per vendor and per contract; the table below reflects vendor-published status as of June 2026 — confirm your specific plan in writing before a single event flows.

Log / observability platform	BAA available?	Notes (verify at contract time)
AWS CloudWatch / CloudTrail / S3	Yes	Under the AWS BAA; check each service against the HIPAA-eligible services list
Google Cloud Logging	Yes	Covered under the GCP BAA for in-scope services
Azure Monitor / Log Analytics	Yes	Covered under Microsoft's BAA/DPA for in-scope services
Datadog	Yes	BAA offered for the Log Management service; HIPAA-enabled accounts carry feature restrictions
Splunk Cloud	Yes	BAA applies to the HIPAA Premium environment and Observability Cloud
Sumo Logic	Yes	HIPAA attestation; BAA on request
New Relic	Yes	Bespoke BAA via account team
Self-hosted OpenSearch / Loki / ELK	N/A	No vendor in the data path — runs inside your own cloud BAA boundary; you own hardening and immutability

A self-hosted stack avoids one BAA but inherits every duty the SaaS vendors carry for you: WORM configuration, access control on the log indices, patching, and the uptime of the thing that must never be down. Either answer can be right; the unforgivable answer is shipping patient-referencing events to a free-tier log SaaS that has never heard of HIPAA.

Common mistakes, collected. Shared logins on clinic carts and front desks (kills unique user ID). Chat bodies, diagnoses, and signed URLs in log lines (PHI in the logs). Log pipeline writable by the production app (the watched silencing the watcher). Recording downloads unlogged because "only staff can reach them." Support staff with standing view-any-session rights. Logs shipped to an analytics or error-tracking SaaS with no BAA. Retention "whatever the default was" — 30 days, discovered during an investigation. Break-glass that nobody reviews. Reviews that happen but produce no record — if it isn't documented, for HIPAA purposes it didn't happen. The full catalogue lives in common HIPAA mistakes in telemedicine builds.

Where Fora Soft fits in

Fora Soft has built video software since 2005 — telemedicine, video conferencing, streaming, surveillance, e-learning — and audit logging is one of the controls we insist on designing before the first sprint, because retrofitting an event taxonomy onto a shipped product means the most important history was never written. In our telemedicine builds the patterns in this article are defaults: role-plus-relationship access models, session-scoped roles for interpreters and observers, time-boxed reasoned support access, append-only event pipelines with WORM storage, and review dashboards that turn §164.308(a)(1)(ii)(D) from a policy sentence into a weekly habit. If you are scoping a platform — or answering a hospital security questionnaire with gaps you can see — talk to our telemedicine team.

What to read next

• The 2026 HIPAA Security Rule update — what changed and what it means for video
• Who is in the room: roles, identity, and consent
• Recording clinical sessions: when, how, and the compliance tension

Call to action

• Talk to a telemedicine engineer — book a 30-minute scoping call to talk through your hipaa audit logging requirements plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Telemedicine Audit-Log Checklist — One page: the clinical-video audit-event taxonomy, access-control checks, immutability and retention rules, and the review cadence, with HIPAA citations.

References

1. 45 CFR §164.312 — Security Rule technical safeguards: access control (a)(1)–(a)(2)(iv), audit controls (b), integrity (c), person or entity authentication (d). eCFR, read 2026-06-11. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312 Tier 1.
2. 45 CFR §164.308 — Administrative safeguards: information system activity review (a)(1)(ii)(D), workforce security (a)(3), information access management (a)(4), log-in monitoring (a)(5)(ii)(C), evaluation (a)(8). eCFR, read 2026-06-11. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308 Tier 1.
3. 45 CFR §164.316 — Policies and procedures and documentation: written records of required actions/activities/assessments (b)(1)(ii); six-year retention (b)(2)(i). eCFR, read 2026-06-11. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.316 Tier 1.
4. 45 CFR §164.502(b) and §164.514(d) — Privacy Rule minimum-necessary standard and role-based implementation; HHS OCR minimum-necessary guidance. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.502 · https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/understanding/coveredentities/minimumnecessary.pdf Tier 1.
5. HHS OCR — HIPAA Security Rule NPRM, "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information," 90 FR 898, January 6, 2025 (RIN 0945-AA22; status: proposed as of 2026-06-11; comment period closed 2025-03-07). https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information Tier 1.
6. HHS OCR — HIPAA Security Rule NPRM Fact Sheet (mandatory specifications, MFA, asset inventory and network map, annual compliance audits, 24-hour access-change notification, vulnerability scanning and penetration testing). Read 2026-06-11. https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html Tier 1.
7. NIST SP 800-66 Rev. 2 — Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide (February 2024); risk-based audit logging and activity review. https://csrc.nist.gov/pubs/sp/800/66/r2/final Tier 1.
8. NIST SP 800-63B — Digital Identity Guidelines: Authentication and Lifecycle Management (AAL2 multi-factor baseline). https://pages.nist.gov/800-63-3/sp800-63b.html Tier 1.
9. NIST SP 800-162 — Guide to Attribute Based Access Control (ABAC) Definition and Considerations. https://csrc.nist.gov/pubs/sp/800/162/upd2/final Tier 1.
10. ONC Health IT Certification — 45 CFR §170.315(d)(2) Auditable events and tamper-resistance; §170.210(h) audit log content standard incorporating ASTM E2147-18 (date/time, patient ID, user ID, action; tamper-resistance; audit-status change recording). https://healthit.gov/test-method/auditable-events-and-tamper-resistance/ · https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170/subpart-C/section-170.315 Tier 1.
11. ASTM E2147-18 — Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems (field specification; retention recommendation: life of record, ≥10 years). https://store.astm.org/e2147-18.html Tier 1 (standard).
12. HHS OCR — "$5.5 million HIPAA settlement shines light on the importance of audit controls" (Memorial Healthcare System resolution agreement, February 2017; 115,143 individuals; credentials of a former affiliated-office employee used April 2011–April 2012; failures of information-system activity review and access-rights management). https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/memorial/index.html Tier 2.
13. HHS OCR — "Anthem Pays OCR $16 Million in Record HIPAA Settlement Following Largest U.S. Health Data Breach in History" (October 2018; ~79 million individuals; insufficient information-system activity review and minimum-access controls). https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/anthem/index.html Tier 2.
14. HHS OCR — Premera Blue Cross resolution agreement, $6.85M (September 2020; 10.4M individuals; risk-analysis and audit-control failures) and CHSPSC LLC resolution agreement, $2.3M (September 2020; >6M individuals; activity-review and incident-response failures after FBI warning). https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/index.html Tier 2.
15. Healthcare Trust Institute — comment letter on the Security Rule NPRM (industry feasibility concerns with the proposed real-time monitoring language in audit trail and system log controls). https://healthcaretrustinstitute.com/wp-content/uploads/2025/04/HTI-Security-Rule-NPRM-Comms-final.pdf Tier 5 (industry comment, cited as evidence of NPRM contention, not as rule interpretation).
16. Datadog — HIPAA-eligible services and BAA for Log Management. https://www.datadoghq.com/legal/hipaa-eligible-services/ · https://docs.datadoghq.com/data_security/hipaa_compliance/ Tier 4.
17. Splunk — Business Associate Agreement scope (Splunk Cloud HIPAA Premium environment, Observability Cloud); New Relic — HIPAA BAA FAQ; Sumo Logic — compliance attestations including HIPAA. https://www.splunk.com/en_us/legal/splunk-baa.html · https://newrelic.com/termsandconditions/hipaabaafaq · https://www.sumologic.com/vs Tier 4.
18. The HIPAA Journal / Compliancy Group / Aptible — audit-log explainers (competitor reference; commonly assert "HIPAA requires six-year log retention" as rule text — overridden per §164.316(b): the six-year clock attaches to required documentation, and its application to audit logs is a conservative interpretation, which this article recommends but labels as such). https://www.hipaajournal.com/hipaa-explained/ · https://compliancy-group.com/hipaa-audit-log-requirements/ · https://www.aptible.com/hipaa/audit-log-retention Tier 7 (competitor reference only).

Where lower-tier sources disagreed with rule text, the rule text won: the "six-year audit-log retention requirement" is an interpretation of §164.316(b)(2)(i), not audit-control rule text (flagged in-line); claims that HIPAA prescribes specific log fields are contradicted by §164.312(b)'s technology-neutral text — field specificity enters via ONC/ASTM E2147 and risk analysis; "real-time monitoring is required" is NPRM-proposed language, not current law, and is contested in public comments.