Audit Log

Overview

Audit Log is a chronological record of security-relevant and operational events that shows who or what performed an action, when it occurred, and what changed. Its operational purpose is to support accountability, incident investigation, control monitoring, troubleshooting, and regulatory or contractual evidence. It should be considered alongside Auditability. The relevant distinction is general application logging, which may include diagnostic messages that are useful for engineering but are not necessarily complete, protected, or suitable for audit evidence.

A typical workflow is as follows: Applications and infrastructure emit structured events for authentication, authorization, configuration, data access, transaction changes, approvals, exports, and administrative actions. Events are normalized, time-synchronized, retained, searched, and correlated across systems.

Core controls include tamper resistance, restricted access, clock synchronization, unique actor and request identifiers, retention rules, privacy filtering, alerting, integrity checks, and tested retrieval.

In payment and crypto operations, A payment audit log should capture state changes, amount or destination edits, refund and payout approvals, credential changes, rule overrides, webhook processing, and reconciliation corrections without storing secrets or unnecessary sensitive data.

Evidence should include event timestamp, actor, role, source, action, target, previous and new values where appropriate, request or trace ID, outcome, reason, and integrity metadata. Missing, mutable, or excessive logs can respectively prevent investigation, undermine trust, or expose confidential information.

It is used to support accountability, incident investigation, control monitoring, troubleshooting, and regulatory or contractual evidence. It differs from general application logging, which may include diagnostic messages that are useful for engineering but are not necessarily complete, protected, or suitable for audit evidence.

Implementation of Audit Log should map a chronological record of security-relevant and operational events that shows who or what performed an action, when it occurred, and what changed to the applicable entity, product, customer, transaction, and jurisdictional scope. Evidence for what performed an action, when it occurred, and and what changed should preserve the governing requirement, policy version, control execution, exception decision, owner, and review date. Material changes affecting the Audit Log context and what performed an action, when it occurred, and and what changed should trigger reassessment instead of silent reuse of an outdated conclusion.