All Docs
FeaturesCalmony Sanctions MonitorUpdated March 12, 2026

HIPAA-04: Read Access Audit Trails for Sensitive Data

HIPAA-04: Read Access Audit Trails for Sensitive Data

Introduced in: v0.1.154

Overview

As of v0.1.154, every GET request that returns sensitive PII — including person records, screening results, and data exports — is now recorded in the platform audit log. This brings read operations to parity with the mutation audit logging that was already in place.

This change satisfies HIPAA Control HIPAA-04 and is consistent with the audit logging pattern used elsewhere in the platform (SOC2-02).

What Is Logged

The following audit log actions are emitted for read operations:

ActionTrigger
person.accessedA GET request is made to /api/people/[id] returning a person record, including fields such as dateOfBirth and nationality
match.viewedA screening result (OFSI match or near-match) associated with a person is viewed
export.accessedA data export containing PII is accessed

All entries are written via writeAuditLog at the start of each GET handler, before the response is returned, ensuring the log is written even if a downstream error occurs.

Audit Log Entry Format

Each read-access audit log entry follows the same structure as mutation log entries:

{
  "action": "person.accessed",
  "actorId": "<user or service account ID>",
  "resourceType": "person",
  "resourceId": "<person ID>",
  "timestamp": "<ISO 8601 UTC timestamp>",
  "metadata": {
    "ip": "<request IP address>",
    "userAgent": "<request user agent>"
  }
}

Why Read Access Logging Matters

For a sanctions screening platform that holds third-party PII:

  • Regulatory compliance — HIPAA requires covered entities and their business associates to record all access to protected information, not just changes to it.
  • Enterprise assurance — Customers and auditors expect a complete, tamper-evident trail showing who read what and when, not just who modified data.
  • Incident response — In the event of a suspected data breach or misuse, read logs allow you to identify exactly which records were accessed and by whom.

Viewing Audit Logs

Audit log entries can be reviewed in the Audit Trail section of the Compliance dashboard. Filter by action type to isolate read events:

  • Use person.accessed to see all person record reads
  • Use match.viewed to review screening result views
  • Use export.accessed to audit data export activity

Implementation Notes

  • The writeAuditLog call is placed at the beginning of each GET handler, before any data is fetched or returned.
  • This pattern is consistent with the implementation used for SOC2-02 mutation audit logging — the same utility function and log schema are reused.
  • No database schema changes are required; audit entries use the existing audit log table.