SOC2-02: Audit Logging for Sensitive Data Read Access

Released in v0.1.131

Overview

SOC 2 requires that access to sensitive data is logged — not just mutations. Prior to v0.1.131, the platform's audit trail captured write operations (create, update, delete) but did not record when a user read sensitive PII such as date of birth, nationality, or full screening records.

This release closes that gap by adding writeAuditLog calls to all GET handlers that return sensitive personal data.

What Changed

Endpoints Now Audit-Logged

The following GET endpoints now emit audit log entries on every successful request:

GET /api/people/[id]

Returns an individual person record, including PII fields such as dateOfBirth and nationality. Each access now records:

• Action: person.accessed
• Resource ID: the ID of the person record accessed
• User ID: the authenticated user who made the request

GET /api/export/people

Exports the full people dataset. Each access now records:

• Action: export.accessed
• User ID: the authenticated user who triggered the export

GET /api/export/screening-history

Exports full screening history, including match results and risk scores. Each access now records:

• Action: export.accessed
• User ID: the authenticated user who triggered the export

GET /api/export/audit-trail

Exports the audit trail log. Each access now records:

• Action: export.accessed
• User ID: the authenticated user who triggered the export

Compliance Context

This change addresses SOC2-02 under the SOC 2 framework. The control requires that access to sensitive data — not solely data mutations — is captured in a tamper-evident audit trail. Screening platforms that handle PII (nationality, date of birth) and produce regulatory outputs (OFSI screening results) must demonstrate to auditors that they know who accessed what, and when.

With this release, the audit log now provides a complete picture of data access across both read and write operations.

Audit Log Entry Format

Audit entries generated by these endpoints follow the same structure as existing log entries:

{
  "action": "person.accessed",
  "resourceId": "<person-id>",
  "userId": "<user-id>",
  "timestamp": "<ISO-8601>"
}

Export events omit resourceId (as they cover the full dataset) and use export.accessed as the action:

{
  "action": "export.accessed",
  "userId": "<user-id>",
  "timestamp": "<ISO-8601>"
}

Viewing Audit Logs

Audit log entries are visible in the Audit Trail section of the compliance dashboard. You can filter by action type (person.accessed, export.accessed) to review all PII read events within a given time period.

Exported audit trail files (via GET /api/export/audit-trail) will include these new entry types from v0.1.131 onwards.

Notes for Integrators

If you consume the audit log programmatically (e.g. via the export endpoint or a downstream SIEM integration), your tooling should be updated to handle the two new action values:

• person.accessed
• export.accessed

These actions will not appear in audit logs generated prior to v0.1.131.