A change-control policy requires every network modification to be logged. What information does a useful change-log entry need to include beyond just the date?
Select an answer to reveal the explanation.
Short Explanation
A change log is only useful if it answers the questions someone will ask later: what changed, why, who did it, and did it actually work? Leave any of those out and the log becomes a timestamp with no story attached. A complete entry means the next person — maybe during an audit, maybe during an outage — isn't left guessing.
Full Explanation
A change-log entry earns its purpose when it captures enough context for someone else to understand a modification without having to track down the original technician: what was changed (the specific configuration or firmware action taken), why it was needed (the business or operational reason), who performed it (accountability), and the outcome of post-change verification (whether it worked as intended). That combination is what makes the log useful during an audit, a root-cause investigation, or a rollback decision later. A badge number alone identifies who acted but leaves out everything about what was done or why, which is most of what makes a log entry actionable months later. The brand of laptop used has no bearing on the network change itself and carries no diagnostic or audit value. Campus weather is similarly irrelevant to a network configuration change and doesn't belong in a change record — including such details would just clutter records that need to stay concise and relevant. A caveat: change logs work best when entries are made close to the time of the change, since details reconstructed later from memory tend to be less accurate. As an operational check, periodically review a sample of recent log entries against actual device configurations to confirm the log reflects what was really done.