Sensitive Data Access Trails

Why sensitive data access logging is different

Most application logging captures what the system did — errors, latency, request counts. Sensitive data access logging captures what people did — who read whose record, who ran a bulk export, who accessed PII they probably shouldn't have.

The difference matters at incident response time. When a data breach occurs or a compliance audit begins, you need to answer:

Who accessed this customer's data and when?
Was this access authorized, or anomalous?
Has the access log itself been altered since the event occurred?

Standard application logs can answer the first two questions. They cannot answer the third.

Compliance context

GDPR Article 30 requires records of processing activities. HIPAA requires access logs for PHI. SOC 2 CC6.1 requires "prior to issuing system credentials... authorization is obtained." But none of these standards specify that logs must be tamper-evident — they just require that you have them. unTamper goes further: it makes them provably unaltered.

What to instrument

The events that matter for sensitive data access trails:

data.read          — individual record access (user profile, health record, payment info)
data.export        — bulk data exports with record count and filter parameters
data.search        — queries against sensitive collections with search terms
data.share         — records shared externally or with third parties
pii.view           — explicit PII field access (SSN, DOB, financial data)
access.escalate    — break-glass or emergency access

The chain makes the difference

When a customer reports "someone accessed my data without authorization," your team needs to produce an access log. Without a tamper-evident chain, there's always a shadow of doubt: could the log have been modified to hide someone's access? Could records have been deleted?

With unTamper's hash chain, that question has a mathematical answer. The chain is either intact or it isn't. There's no ambiguity.

SDK example

// Track PII access
await client.logs.ingestLog({
  actor: { id: currentUser.id, type: 'support_agent' },
  action: 'pii.view',
  target: { id: customer.id, type: 'customer_record' },
  metadata: {
    fields: ['email', 'phone', 'address'],
    accessReason: ticket.id ? `support_ticket:${ticket.id}` : 'manual',
    ipAddress: request.ip,
  },
})

// Track bulk exports
await client.logs.ingestLog({
  actor: { id: currentUser.id, type: 'data_analyst' },
  action: 'data.export',
  target: { id: 'customers', type: 'dataset' },
  metadata: {
    format: 'csv',
    recordCount: exportResult.count,
    filters: JSON.stringify(query.filters),
    exportId: exportResult.id,
  },
})

Auditor-ready exports

When your compliance team or an external auditor needs the access log for a specific customer or time window, they get a file with cryptographic verification proofs attached. They can verify chain integrity on their own machine — no access to your infrastructure, no trust required.

# Export access logs for a customer with verification proof
curl "https://app.untamper.com/api/v1/logs/export?target=customer:${CUSTOMER_ID}&format=json" \
  -H "Authorization: Bearer $API_KEY" \
  > access_log_with_proof.json

The compliance answer

When an auditor asks "can you prove this access log hasn't been modified since these events occurred?" — the answer becomes yes, with verifiable cryptographic proof.

Who this is for

Healthcare applications handling PHI under HIPAA
Financial services handling transaction and account access data
Any product with enterprise customers who require verifiable access logs as a contractual condition
Teams preparing for SOC 2 or ISO 27001 audits where access controls and audit trails are reviewed