Log schema versioned for regulatory changes
Why it matters
When a regulator examines records from 5 years ago, they need to understand what the log schema meant at that time — whether status meant HTTP status or business status, whether amount was in cents or dollars, whether a column that now exists was absent in earlier records. Without schema versioning, there is no authoritative answer to those questions. NIST 800-53 AU-3 requires audit records to contain sufficient information to establish what happened, which extends to the schema definitions that give field values their meaning. SOX §404 internal control assessments assume that the design of a control is stable and documented — an undocumented schema change is a gap in that documentation. FINRA Rule 4511 requires that books and records be available in a form that permits examination; records whose column semantics have shifted without documentation cannot be reliably examined.
Severity rationale
Info because schema versioning is a documentation and interpretability control — its absence creates ambiguity about historical records but does not directly expose data or enable unauthorized access.
Remediation
Create an audit_schema_versions table and insert a record for every migration that modifies transaction_logs, in db/migrations/ or supabase/migrations/:
CREATE TABLE audit_schema_versions (
version INTEGER PRIMARY KEY,
applied_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
changelog TEXT NOT NULL,
regulatory_reason TEXT
);
INSERT INTO audit_schema_versions (version, changelog, regulatory_reason) VALUES
(1, 'Initial: id, timestamp, user_id, operation_type, amount, currency',
'SOX §404 baseline — AU-3 required fields'),
(2, 'Added balance_before, balance_after',
'FINRA 4511 — reconciliation support'),
(3, 'Added entry_hash, previous_hash',
'PCI-DSS 4.0 Req-10.3.3 — tamper evidence');
ALTER TABLE transaction_logs ADD COLUMN schema_version INTEGER NOT NULL DEFAULT 3;
When applying future migrations, always include an INSERT INTO audit_schema_versions as part of the same migration file so version tracking stays in sync with schema state. Add schema_version as a column in the exported audit log (see finserv-audit-trail.retention-compliance.export-completeness) so regulators can identify which schema applies to each record.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Financial Audit Trail Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- nist:rev5 · AU-3 — Content of Audit Records — schema must support required fields across regulatory changes
- sox · Section 404 — Management Assessment of Internal Controls — schema change governance
- external · FINRA-Rule-4511 — FINRA Rule 4511 — records must remain accurate as requirements evolve
Taxons
History
- 2026-04-18·v1.0.0·Initial import from finserv-audit-trail·automated