Which HIPAA Security Rule requirements can your data platform's logs give evidence for?

Step 1. Fetch the rule text at a pinned date and list every item

The rule is 45 CFR Part 164, Subpart C, in the eCFR (eCFR: Subpart C (read 2026-10-18)). The script fetches the XML of the subpart from the eCFR versioner API with the date fixed in the URL, 2026-10-01, so a later amendment cannot change the answer. It sends an Accept-Encoding: gzip header and prints the byte size and the date of the subpart’s latest amendment. The US federal rule text is public.

It reads sections 164.308 (administrative safeguards), 164.310 (physical), 164.312 (technical), 164.314 (organizational requirements) and 164.316 (policies and documentation). In the XML, a standard is a paragraph with an italic “Standard:” label, and an implementation specification is an italic name followed by “(Required)” or “(Addressable)”. The script keeps the paragraph numbering, so each item gets its citation, for example 164.308(a)(3)(ii)(C). These are the two patterns, copied from the script:

std = re.search(r"<I>Standard: ([^<]+?)\.</I>", p)
spec = re.search(r"<I>(?:Implementation specifications?: )?([^<]+?) \((Required|Addressable)\)\.?</I>", p)

One standard, 164.308(b)(1), has no “Standard:” label in the eCFR text, so the script matches its heading by name. Two specifications, in 164.314(a)(2) and 164.314(b)(2), are labeled only “Implementation specifications (Required)”, and the script names them after their standard.

Step 2. Check the list against the rule’s own matrix

Appendix A to Subpart C is a table of the standards and specifications in 164.308, 164.310 and 164.312. The script parses that table separately and compares it with the list from the paragraphs: the same standards, the same number of specifications under each, and the same Required or Addressable letter wherever the matrix gives one. The matrix does not cover 164.314 and 164.316, so those two sections are not cross-checked.

The check found one oddity in the rule text itself: in Appendix A the row for Workforce Clearance Procedure has no (R) or (A) marker, while the paragraph text marks it Addressable. The script prints it and goes on, since the paragraph text is the rule.

Step 3. Write the rating table

This is the judgment, and it is a table, not a model. Each item gets a rating, what a log shows and what it cannot show. The key is the citation and the rule’s own name for the item, so the script can tell if the table and the rule disagree. Three of the 63 rows:

"164.308(a)(3)(ii)(C)": ("Termination procedures", "Partial", "grant history shows when each access ended", "the termination date comes from HR, so on-time needs that record"),
"164.312(b)": ("Audit controls", "Direct", "the platform's access and query history is a mechanism that records activity", "it covers only what the platform records, for as long as it keeps it"),
"164.310(d)(2)(i)": ("Disposal", "None", "", "disposal of hardware or media is physical"),

The full table is in the script and in the CSV. Disagree with a rating and change it: nothing else in the script moves except the counts.

Step 4. Count in DuckDB

The script loads the parsed items, the rating table and the section names into DuckDB tables, joins them, and counts by rating, by safeguard and by the rule’s Required or Addressable label (DuckDB documentation (read 2026-10-18)). Then it runs its own checks and writes the CSV only if all pass.

Run 2: plant three faults and see whether the script notices

We ran the same script with three faults planted in the parsed list before the checks: the Termination procedures item listed twice, the name of Audit controls changed to “Audit control”, and the Person or entity authentication standard dropped. Each fault trips a named check:

• The duplicate trips the check that no citation appears twice and the check that the number of specifications under a standard equals the matrix (4 against 3).
• The rename trips the check that each key in the rating table meets an item with the same name.
• The dropped item trips the comparison with Appendix A (a standard the matrix lists and the parsed rule lacks) and the check that every key in the rating table matches an item.

The script reports all five failures, exits with code 1 and writes no CSV. The tables above it are printed from the faulty list, so they are wrong on purpose: they show 63 items, but 21 standards and 42 specifications.

Command: run 2

python3 guides/hipaa-security-rule-evidence-from-data-platform-logs/hipaa_log_evidence.py --out loop-out/planted.csv --plant duplicate-row,renamed-item,drop-item

Output from our run 2

duckdb 1.5.6, python 3.12.15
source  https://www.ecfr.gov/api/versioner/v1/full/2026-10-01/title-45.xml?part=164&subpart=C
        bytes=37860 sha256=9041a339ad1eaec5... latest amendment of the subpart=2020-11-24
Appendix A rows with no (R) or (A) marker, where the rule text gives one: ['164.308(a)(3) Workforce Clearance Procedure']
PLANTED: 'Termination procedures' listed twice
PLANTED: 164.312(b) 'Audit controls' renamed 'Audit control'
PLANTED: 164.312(d) 'Person or entity authentication' dropped from the parsed list

items rated: 63 (21 standards, 42 implementation specifications)

by what                         items  Direct  Partial  None  % with some log evidence
  all items                          63        1       21       41      34.9

by safeguard
  Administrative (164.308)           31        0       15       16      48.4
  Physical (164.310)                 12        0        0       12       0.0
  Technical (164.312)                11        1        4        6      45.5
  Organizational (164.314)            4        0        0        4       0.0
  Documentation (164.316)             5        0        2        3      40.0

by designation in the rule
  Addressable                        23        0        7       16      30.4
  Required                           19        0        7       12      36.8
  Standard                           21        1        7       13      38.1

Direct and Partial items:
  Partial 164.308(a)(1)           Security management process
  Partial 164.308(a)(1)(ii)(D)    Information system activity review
  Partial 164.308(a)(3)           Workforce security
  Partial 164.308(a)(3)(ii)(A)    Authorization and/or supervision
  Partial 164.308(a)(3)(ii)(C)    Termination procedures
  Partial 164.308(a)(4)           Information access management
  Partial 164.308(a)(4)(ii)(A)    Isolating health care clearinghouse functions
  Partial 164.308(a)(4)(ii)(B)    Access authorization
  Partial 164.308(a)(4)(ii)(C)    Access establishment and modification
  Partial 164.308(a)(5)(ii)(C)    Log-in monitoring
  Partial 164.308(a)(5)(ii)(D)    Password management
  Partial 164.308(a)(6)           Security incident procedures
  Partial 164.308(a)(6)(ii)       Response and reporting
  Partial 164.308(a)(7)(ii)(A)    Data backup plan
  Partial 164.312(a)(1)           Access control
  Partial 164.312(a)(2)(i)        Unique user identification
  Partial 164.312(a)(2)(ii)       Emergency access procedure
  Direct  164.312(b)              Audit control
  Partial 164.312(c)(1)           Integrity
  Partial 164.316(b)(1)           Documentation
  Partial 164.316(b)(2)(i)        Time limit
  Partial 164.308(a)(3)(ii)(C)    Termination procedures

SELF-CHECK FAILED: no CSV written
  - 164.308(a)(3)(ii)(C) appears 2 times in the parsed rule
  - 164.308(a)(3): parsed rule has 4 specifications, Appendix A has 3
  - Appendix A lists 164.312(d) (Person or Entity Authentication) but the parsed rule has no such standard
  - RATINGS key 164.312(b) expects 'Audit controls' but the rule says 'Audit control'
  - RATINGS key 164.312(d) ('Person or entity authentication') matches no item in the parsed rule

Method

• Source: 45 CFR Part 164 Subpart C from the eCFR versioner API, https://www.ecfr.gov/api/versioner/v1/full/2026-10-01/title-45.xml?part=164&subpart=C, 37,860 bytes after decompression in our run; the subpart’s latest amendment is dated 2020-11-24 (from https://www.ecfr.gov/api/versioner/v1/versions/title-45.json?part=164&subpart=C). It is a US federal regulation, public.
• Unit: one row per standard and one per implementation specification, 63 in all. A standard that has specifications is rated on its own text too, so a rated standard and its rated specifications are separate rows.
• The rating table is written out in the script and in the CSV, with a reason for each item. The three ratings are defined above.
• No sampling and no random seed. Every share is a count over the 63 rows.
• Self-checks, each with the fault that trips it: no citation twice (a duplicated row); the list equals Appendix A for 164.308 to 164.312 (a duplicated or dropped item); every item has a rating (an item the rating table lacks); every key in the rating table matches an item with the same name (a renamed or dropped item); every rating is Direct, Partial or None and the shares add up to 100% (a typo in the table); 63 items against 63 table rows (a duplicate or a drop). The CSV is written only if all pass.

Limits

• This is not a client result. It rates a public regulation, not any organization’s logs. It does not say what your platform records or for how long.
• The ratings are our judgment, made by us from the rule text. A reasonable reader could rate some items differently, for example whether a setting counts as evidence (automatic logoff, encryption), whether the login history is enough for person or entity authentication (164.312(d)) or whether a log can be “the record” the rule asks to be documented (164.316(b)(1)). That is why the table is written out.
• A log is evidence, not proof of compliance. Direct means a log alone is the record of the thing. It does not mean the organization meets the standard, and we do not say what any auditor or regulator will accept.
• The rule is technology-neutral. It says covered entities may use any security measures that allow them to reasonably and appropriately implement the standards (164.306(b)), so an item rated None here may still be met by a measure that leaves a different record.
• One item applies only to some organizations. Isolating health care clearinghouse functions (164.308(a)(4)(ii)(A)) applies only to a clearinghouse that is part of a larger organization. We counted it because a log can show part of it.
• Only Subpart C. We did not rate the Privacy Rule (Subpart E) or the Breach Notification Rule (Subpart D), which also call for records.
• The source can change. Our numbers are for the version dated 2026-10-01. A later amendment would change the list, and the script would need a new date.

Tested on

When this is not enough

• Your platform is not an example here. Find which of your own views hold grants, logins and access, how long they keep them and how late they appear, before you rely on any Direct or Partial rating.
• A rating is a starting point for a question. It tells you which item needs which second record. It cannot tell you whether the log was on, complete or kept long enough for the period your auditor asks about.
• The None items are most of the rule. Risk analysis, policies, contracts, training and physical safeguards need their own evidence, from outside the data platform.
• Legal advice is not here. Whether a safeguard is reasonable and appropriate for your organization is for your compliance and legal team.