Every view of a patient record, on the record.
164.312(b) (audit controls) is a mandatory HIPAA Security Rule standard: put mechanisms in place that capture activity in systems containing or using electronic protected health information (ePHI) and let you review it. Unlike 164.312(a)(2)(iv)'s addressable encryption specification, the standard itself cannot be skipped, though HIPAA leaves you to decide which activity to capture and what an entry needs to contain based on your own risk and systems. In practice, that means the paths that read or write ePHI need to produce a record someone can actually go examine, not just a log line nobody designed to be reviewed.
The shapes the same control failure takes.
Audit controls weaken when a change stops recording activity on ePHI, or a new way to reach it skips the recording entirely. The recurring shapes:
A new access path bypasses the audit trail
A new endpoint, query, or job reads or writes ePHI directly, without going through the shared audited access layer the rest of the system uses.
An audit call is removed
The call that recorded an access to ePHI is deleted in a cleanup or refactor, so the action still happens but nothing records it.
The actor or record identifier is dropped
An audit entry still fires but stops including who performed the action or which record it touched, so the entry cannot be examined afterward.
Audit logging is disabled outside a narrow scope
A flag or config meant to quiet audit logging in a test or staging path leaks into how production is configured.
The audit trail becomes writable or gets truncated
Write access to the audit store is opened up, or its retention is shortened, so entries can be altered or age out before anyone examines them.
A patient-preview endpoint that never calls the audit trail.
A dashboard widget needs a lightweight preview of a patient record (name, MRN), so a new route is added next to the existing full-record endpoint. The existing endpoint calls the shared audit wrapper before returning data; the new one queries the repository directly and skips it, because it only returns a couple of fields.
router.get('/patients/:id', async (req, res) => { const record = await patients.findById(req.params.id) await auditLog.record({ actor: req.user.id, patientId: record.id, action: 'view' }) res.json(record)})+router.get('/patients/:id/preview', async (req, res) => {+ const record = await patients.findById(req.params.id)+ res.json({ name: record.name, mrn: record.mrn })+})The new /preview endpoint reads a patient record, still ePHI, without calling auditLog.record, so it is a new access path with no audit trail. 164.312(b) requires activity on systems holding ePHI to be captured and reviewable, and the standard itself is not optional the way an addressable specification is. Route new reads of ePHI through the audited access layer, even a partial-field preview.
Audit controls are checked as a trail, not a policy.
A HIPAA review looks for whether activity on systems holding ePHI is actually captured and whether that record can be examined, the kind of question that means being able to reconstruct who touched which patient's data and when. The standard itself is mandatory, so there is no version of 'we assessed the risk and decided not to record it,' even though HIPAA leaves the exact scope and fields up to you. A new endpoint or query that reads or writes ePHI outside the audited access layer is the concrete gap, and it shows up in the diff as a route that never calls the audit function.
A review, not your audit trail.
heygrc flags changes that touch 164.312(b) and cites the CFR reference so the fix happens in the pull request. It does not run your audit logging pipeline or examine the trail for you. It catches the moment a new or changed access path to ePHI ships without an audit record, at the diff.