Information system activity review: the logs exist so someone reads them

Audit controls gets attention because it sounds technical: logs, mechanisms, systems. This standard gets skipped because it sounds like a chore: someone has to actually sit down and look at what the logs say. That asymmetry, technical work gets built, human work gets postponed, is exactly why this is one of the more quietly common gaps in an otherwise reasonable program.

What the rule actually requires

Information system activity review is a Required implementation specification: regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports (45 CFR 164.308(a)(1)(ii)(D)).

This standard is the human half of audit controls (164.312(b)). Audit controls requires mechanisms that record and examine activity. The recording is the technical half, logs get generated. The examining is this standard, someone actually has to look at them. A system that logs everything and reviews nothing has technically satisfied audit controls’ recording requirement and failed this standard outright. They are two separate obligations, and a clinic can meet one while completely missing the other.

What “regularly” actually means

The rule does not define a cadence. “Regularly” is left to you, under the same flexibility that runs through the whole Security Rule, to define and defend given your own size, complexity, and risk.

“The logs exist so that someone reads them.”

That flexibility is not an excuse to skip the definition. A clinic that has never written down what “regularly” means for its own program has not exercised the flexibility, it has simply not done the review. The difference between a real practice and a good intention is almost always a calendar entry with a named owner. Someone specific, checking something specific, on a schedule that exists somewhere other than memory.

What this looks like in an ABA clinic

With BCBAs supervising across cases and RBTs rotating between clients, unexplained access is exactly the pattern this review exists to catch. A BCBA who has not worked with a family in six months, still opening that family’s record. An RBT account accessing charts outside their assigned caseload. None of these trigger an alert on their own in most small-clinic software. They only surface if someone is actually looking at the access reports on a schedule, asking whether the pattern makes sense.

What a real review looks like, next to what most clinics have

	What the rule requires	What most clinics actually have
Cadence	Defined and documented, even if the specific interval is your own choice	Undefined, “we’ll look if something seems wrong”
Ownership	A named person responsible for the review	Nobody specifically, so effectively nobody actually
Evidence	A record that the review happened, and what it found	No record either way
What it catches	Access patterns that don’t match the caseload	Only discovered after an incident forces a look back

The honest reason this gets skipped is not that it is difficult. It is that nothing announces the failure. Audit logs sitting unread do not trigger anything. The gap is invisible until an incident forces someone to go looking, and the first question in that moment is always whether anyone was already looking before.