Observability that is itself audit evidence
Practice · Observability & Audit Evidence
An observability layer built as audit evidence, a hash-chained, append-only audit trail retained for 365 days under a policy you set and control, meets the HIPAA Security Rule's audit-control requirement at §164.312(b) for PHI systems and supports incident response under §164.308(a)(6), which bolted-on logging under a third-party APM vendor's retention policy cannot prove.
How can observability serve as audit evidence for regulated SaaS?
An observability layer built as a hash-chained, append-only audit trail, retained under a policy you control, meets the HIPAA audit-control requirement at §164.312(b). Bolted-on logging under a third-party vendor's retention policy cannot prove that nothing was altered.
Bolted-on logging tells you what happened. An observability layer built as audit evidence tells you what happened, proves nothing was altered after the fact, and stays under your own sovereign control instead of a third-party APM vendor's retention policy. The difference is a hash-chained, append-only event table — direct protocol, no SDK black box — not a bigger logging budget.
Logging and audit evidence are not the same deliverable
Logging answers "what happened, approximately, for debugging." Audit evidence answers a stricter question: "prove this record hasn't been altered since it was written, and prove I'm not missing a record I should have." For PHI systems under the HIPAA Security Rule, a third-party APM or log-aggregation SaaS is usually built for the first question, not the second — its audit trail's retention window, export format, and tamper-resistance guarantees are the vendor's choice, not yours.
Direct protocol boundaries over a vendor logging SDK
A vendor logging SDK typically batches, buffers, and transmits to a
third-party endpoint you don't control — which means your audit trail's
durability depends on a vendor's uptime and retention policy, not your own.
The Bare Metal alternative: write structured events directly to a
first-party store your own process owns, over a protocol you can inspect
(a local SQL insert, not an opaque SDK call). This repository does exactly
that — every observed event (`discovery.redirect_hit`,
`crm.opportunity_state_changed`, PLG telemetry) is a direct
INSERT into a first-party SQLite table, not a call into a
third-party SDK.
A hash-chained, append-only schema
The pattern that makes an event table into audit evidence, not just a log:
CREATE TABLE audit_events (
event_id TEXT PRIMARY KEY, -- UUIDv7: time-ordered, globally unique
event_type TEXT NOT NULL,
occurred_utc TEXT NOT NULL,
actor_ref TEXT, -- NULL for anonymous/system events
payload_json TEXT NOT NULL,
prev_hash TEXT, -- previous row's row_hash -- the chain
row_hash TEXT NOT NULL -- hash(payload + prev_hash) -- tamper-evident
) STRICT;
-- No UPDATE or DELETE statement against this table exists anywhere in the
-- codebase. Verifying the chain (recompute row_hash for every row, compare
-- to the stored value and to the next row's prev_hash) proves nothing was
-- altered after the fact -- the check is mechanical, not a policy promise.Sovereign control means you set the retention policy
With a first-party, self-hosted store, the retention window is a configuration your own team decides and can prove — not a line item in a vendor's terms of service that can change without your approval.
Engineering reference only. Not formal regulatory counsel. Adapt the schema to your own quality system's audit-log requirements.
Provenance & review state
- Last reviewed
- Sources
-
- HIPAA Security Rule, 45 CFR §164.312(b) — U.S. Department of Health and Human Services
- ISO 27001:2022 — International Organization for Standardization
- Ingested from
-