4 Change Logs and Audit Trails

Purpose of logs and trails

A Change log is the organized record of change requests and their progress. An Audit trail preserves the sequence of events for each request, including who acted, when they acted, and what decision or update they made. Together, they help a team track proposed changes through resolution and later verify how decisions were reached.

Recording the status of proposed and approved changes is a formal configuration-management activity. The exact fields and status names should match the organization’s process, while still making it possible to establish what was requested, what was decided, and what happened afterward.

Information to capture

Give every Change request a unique identifier and maintain one authoritative record for it. Include enough information to connect the request, its assessment, decisions, progress, and outcome.

• Request details: identifier, title, description, requester, submission date, and affected project, service, product, or configuration item.

• Assessment references: impact analysis, risk assessment, estimates, and links to supporting documents or related requests.

• Decision: outcome, decision date, decision-maker or approver, rationale, and any conditions or follow-up actions.

• Status and timeline: current status and dated status changes. Possible statuses include submitted, under review, awaiting information, approved, rejected, deferred, implementing, verified, or closed.

• Implementation and closure: responsible owner, actual implementation date, verification result, any deviation from the approved plan, and closure date.

Change-control records should document proposed changes, approval, implementation, and review. Linking a request to impact information and supporting material helps maintain that record.

Record decisions and progress

A status label alone does not provide a complete history. Record each important Status transition with a timestamp and the person or workflow responsible. For example, an approval entry should identify the approver and decision date; a deferral should include the reason and, if known, the condition or date for reconsideration. A rejection should state its rationale so the requester and later reviewers can understand the outcome.

Keep the Decision distinct from the request’s current state. A request may be approved but not yet implemented, or implemented but still awaiting verification. When multiple approvals are required, retain each approval or rejection, its actor, comments, and time rather than recording only the final result.

A useful event-history pattern ties dated, attributable entries to one request identifier. For example, request CR-042 was submitted on 2026-03-02, with an impact assessment requested; moved under review on 2026-03-03 for technical and operations review of dependencies and test effort; approved with conditions on 2026-03-06, requiring testing before release; and verified and closed on 2026-03-12 after testing passed and the record was updated, with evidence linked to the request. These entries illustrate a pattern, not a required status vocabulary.

Preserve an auditable history

An Audit trail should let a reviewer reconstruct the request’s path without relying on anyone’s memory. Preserve the original request, relevant impact-analysis material, approvals and comments, status transitions, implementation evidence, and closure record. Link documents and related records to the request with stable identifiers, and note when a record is superseded or corrected.

Use a controlled system or documented procedure that identifies who may create, approve, or change records. Avoid silently overwriting earlier decisions. If information must be corrected, preserve the prior entry or system history and record the correction’s author, date, and reason.

Restrict access appropriately, back up records, and retain them according to the organization’s record-retention rules. These practices support review of whether changes were authorized and how they were implemented.

Maintain reliable records

A log is useful only when it is kept current. Assign responsibility for updating it and periodically reconcile open requests against their actual status. Do not close a completed change until the required implementation and verification records are attached.

Change-request logs can communicate progress and establish a history that can be examined later. Reliable records give every request a unique identity, capture decisions with the responsible actor, date, and rationale, and preserve supporting evidence from submission through approval, implementation, verification, and closure. Keep records consistent, attributable, linked, and protected from untracked alteration.