What Should a Tenant Audit Log Record for Protected Data

A tenant audit log should record who acted, when the action occurred, what action was attempted, which tenant and record reference were involved, and whether the action succeeded. It should normally avoid copying record content. This design gives reviewers useful evidence while limiting the audit store’s own sensitivity and retention burden.

The right fields depend on the operation and the risk analysis. A read, export, role change, restore, and deletion need different context. Keep the schema boring, documented, append-only where practical, and easy to query during an incident.

Isolation model and threat boundary

An audit log is evidence about an action, not a second application database. Its boundary is crossed when it stores names, contact details, treatment descriptions, free-text notes, or full request bodies. Those fields make incident response and retention harder, while often adding little proof about authorization.

The eCFR Technical Safeguards rule describes audit controls, access controls, integrity, authentication, and transmission security. Translate those requirements into a field-level design. Explain what each field proves and which actor may read it.

Use the audit event to prove that a request was received, authorized or denied, and completed or failed. Do not imply that a complete event record proves the underlying business action was correct. Application logs and audit logs serve different purposes and should not be conflated.

See six-year audit evidence without storing record content for retention planning. See tenant isolation negative tests for the actions the log should capture during denial tests.

Enforcement path and bypasses

Define a minimum event schema that every service can produce without copying the request payload.

Field	Purpose	Example shape
event ID	Unique evidence reference	Generated opaque UUID
actor ID	Identifies the authenticated principal	Internal user or service ID
tenant ID	States authorization scope	Opaque tenant key
timestamp	Supports sequence reconstruction	UTC timestamp from trusted service
action and target	Explains the attempted operation	read, export, role.update, record reference
result	Distinguishes success, denial, and error	allowed, denied, failed
correlation ID	Joins distributed steps	Request or job ID
reason code	Supports review without content	membership_missing, policy_denied

The NIST SP 800-53 Revision 5 Update 1 provides a catalog for control and evidence thinking. It is guidance, not a substitute for the applicable rule or contract. Use it to ask whether events are complete, protected, reviewable, and tied to a responsible owner.

Audit, restore, support, and offboarding

Log access denials as well as successes. A denial event should say which policy rejected the request, but it should not include the record that the actor tried to access. Log role grants, revocations, support sessions, exports, restores, queue retries, backup changes, and deletion decisions.

For restores, record backup reference, approved destination, operator, start and end time, result, and cleanup. For support, record ticket reference, approval, expiry, tenant, actor, and revealed field group. For offboarding, record export confirmation, access revocation, working-copy cleanup, and any retained backup reason.

Protect the audit store from routine mutation. Restrict who can read it, separate audit administration from ordinary application administration, and alert on retention or access-policy changes. Hash chains or write-once storage may strengthen tamper evidence, but document the threat they address and test recovery.

Minimum necessary means the event should be useful without becoming a content archive. If an investigation needs more context, retrieve it through a separately authorized workflow and record that reveal. Do not place full records into error messages or tracing attributes.

Runnable proof tests

Run a field-level test against representative operations. Inspect the event store after each action.

for each operation in [read, denied_read, export, role_change,
                       support_session, restore, deletion]:
  execute operation with synthetic tenant context
  assert event has actor, tenant, UTC time, action, target reference,
         result, and correlation ID
  assert event has no request body, name, contact detail,
         treatment detail, or free text

alter audit retention and access policy:
  assert change requires elevated approval
  assert change creates an audit event

attempt cross-tenant read:
  assert denial event contains policy reason
  assert target content is absent

Review events after schema changes, new queues, new integrations, and new support tools. A shared helper can reduce omissions, but each caller still needs a test because background workers and administrative paths often bypass request middleware.

Decision and approval gate

Approve the schema when a reviewer can reconstruct security-relevant actions without reading record content, identify the responsible actor, and verify that retention and access changes are themselves logged. Stop when an event lacks tenant scope, timestamps cannot be trusted, or the only way to investigate is to store full payloads by default.

Use support access controls across tenant boundaries to connect audit fields with break-glass review. Use immutable home-region controls to record where recovery and support actions occurred.

Field-by-field review questions

For actor ID, ask whether the identity is unique, current, and tied to the service or person that acted. For tenant ID, ask whether the value came from a server-owned membership decision. For time, ask which clock and timezone are used. For action and target, ask whether a reviewer can understand the operation without seeing record content.

For result, distinguish allowed, denied, failed, retried, and completed. For correlation ID, make sure a distributed worker, webhook, export, and support event can be followed without copying payloads. For reason code, use a controlled vocabulary that does not expose free-text content.

Audit integrity needs an owner. Restrict writes to the logging service, protect retention policy, alert on disabled delivery, and make access to older evidence visible. A tamper-evident event that no one can retrieve is not useful, while a searchable event containing excessive content creates its own risk.

Events that are easy to miss

• Denied reads and failed authorization before a database call.
• Changes to membership, roles, keys, secrets, and retention.
• Export creation, download, cancellation, and expiry.
• Queue retries, dead letters, replay, and manual release.
• Backup policy changes, restore requests, and cleanup.
• Support reveals, break-glass approval, expiry, and review.

Frequently asked questions

Should an audit log store a full record?

Usually no. Store an opaque target reference and event metadata. A separately approved reveal workflow can retrieve additional context when necessary, with its own audit record and retention decision.

Which audit events matter most?

Start with access success and denial, role changes, exports, restores, support sessions, queue actions, backup-policy changes, and deletion decisions. Extend the list after the risk analysis identifies other material paths.

Does logging prove compliance?

No. Logging provides evidence for selected controls. It does not replace risk analysis, authorization, contracts, training, incident response, or legal review. Assess whether the events are complete and protected for the actual system.

References

• Electronic Code of Federal Regulations, 45 CFR 164.312 Technical Safeguards, retrieved 2026-08-15: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312
• National Institute of Standards and Technology, SP 800-53 Revision 5 Update 1, retrieved 2026-08-15: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
• U.S. Department of Health and Human Services, Security Rule Laws and Regulations, retrieved 2026-08-15: https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html