I'm building a consent audit trail for a regulated business

I can help with that. A consent audit trail for a regulated business usually needs to answer, for any given person and consent event:

• What was consented to
• When it was given, changed, renewed, or withdrawn
• How consent was captured
• Who/what captured it
• What information the person saw at the time
• What version of the terms/privacy notice/consent language applied
• Proof that the event wasn’t altered later

A good design usually includes:

1) Core audit event fields

For each consent-related event, store:

• event_id — unique immutable ID
• subject_id — the person/customer identifier
• event_type — grant / withdraw / update / re-consent / expire
• consent_purpose — marketing, data sharing, profiling, etc.
• status — granted / denied / withdrawn / expired
• timestamp_utc
• source_channel — web, mobile, call center, paper, API
• captured_by — user ID, service account, or agent ID
• jurisdiction — useful for region-specific rules
• policy_version_id — exact text/version shown
• consent_artifact_hash — hash of the rendered consent page/PDF/text
• ip_address and/or device_id — if appropriate and lawful
• locale / language
• correlation_id / session_id
• evidence_uri — pointer to stored proof artifact
• record_hash and previous_record_hash — for tamper-evident chaining

2) Make it append-only

For regulated audit trails, avoid updating historical consent records. Instead:

• write a new event for every change
• preserve all prior events
• derive current consent state from the event history
• prevent hard deletes except through a governed retention process

3) Store evidence separately but link it immutably

Evidence can include:

• exact text shown
• UI screenshot or PDF
• web form payload
• clickstream or transaction log
• call recording reference
• signed document image
• agent notes

Use a content-addressed hash for each artifact so you can prove it wasn’t changed.

4) Version everything

You’ll want version control for:

• consent wording
• privacy notice
• collection channel UI
• legal basis or policy rules
• product/service category taxonomy

Without versioning, it’s hard to prove what the person actually agreed to.

5) Add tamper evidence

Common approaches:

• hash chaining between events
• periodic signed snapshots
• WORM storage / immutable object storage
• KMS-backed signatures
• restricted write permissions and separate admin domains

6) Define retention and legal hold

Regulated businesses often need to keep records for a fixed period and sometimes longer due to disputes or investigations. Define:

• retention period by consent type/jurisdiction
• legal hold process
• deletion/anonymization rules after retention expires
• exception handling for ongoing claims

7) Build an audit query model

You’ll likely need queries like:

• show complete consent history for a person
• prove what was displayed on date X
• identify who changed a consent
• list all users who consented to purpose Y in jurisdiction Z
• show withdrawals and whether downstream systems were notified

8) Consider downstream propagation

If consent affects other systems, log:

• when consent change was published
• which systems received it
• delivery status / retries / failures
• reconciliation results

That helps prove enforcement, not just capture.

9) Security and privacy controls

Because consent logs are sensitive:

• encrypt at rest and in transit
• restrict access by role
• mask sensitive fields where possible
• audit access to the audit trail itself
• keep PII minimization in mind

If you want, I can help you with one of these next:

1. a database schema
2. an event model
3. a tamper-evident design
4. a regulatory requirements checklist
5. a sample API for recording consent