How to Keep a Password Reset Log: A Practical Guide
A password reset log is a simple record of every time someone’s password was reset: who asked, when, how their identity was checked, and who did the reset. It sounds like admin overhead. In practice, it’s one of the cheapest security controls a small-to-mid business can run, social engineers target the help desk, not the firewall. This guide explains how to use the IT Password Reset Log properly.
When to Use This
Log every password reset you perform, no exceptions: employee requests, new-starter initial passwords, resets after a suspected compromise, and resets for shared or service accounts. The only entries that don’t go in the log are self-service resets through an automated portal, and only because the portal keeps its own log, which IT should be able to access.
The log matters most in three situations. First, when someone reports suspicious account activity, the log shows whether a reset happened and who authorised it. Second, during a security audit, where “show me your reset records for the last six months” is a standard request. Third, when a dispute arises: an employee claims they never received a new password, or a manager questions whether proper verification was done.
If your organisation has no log today, start one now and backfill what you can from memory and email. A partial history beats none, but don’t present backfilled entries as certain if you’re not sure.
How to Fill It Out
Section 1: Request details. Date and time of the request, the account holder’s name and username, and how the request arrived, in person, phone, email, or ticket. The channel matters: a phone request carries different verification risk than someone standing at the service desk with an ID badge.
Section 2: Identity verification. Record exactly how you confirmed the requester was the account holder. Accepted methods depend on your organisation’s policy, but typical ones include: recognised in person by IT staff, verified against a callback to the number on file, confirmed by their line manager, or answered a pre-registered security question. Write the method, not just “verified.” “Called back on the extension listed in the directory” is a record; “verified” is a claim.
Never reset a password for someone who hasn’t been verified. If the usual method isn’t available, the person is travelling and their usual number doesn’t work, escalate to a manager rather than improvising.
Section 3: Reset performed. Date and time the reset was completed, who performed it, and how the new password or reset link was delivered: verbally in person, via the corporate email (never personal email), or through a secure password-sharing tool. Temporary passwords must require a change on first login wherever the system supports it.
Section 4: Reason. Forgotten password, suspected compromise, new starter, scheduled rotation, or account lockout. The reason is what turns the log from a list into a diagnostic tool, a cluster of “suspected compromise” entries in one department is a pattern worth investigating.
Section 5: Follow-up actions. If the reset was due to suspected compromise, note what else was done: sessions revoked, a scan run, the user briefed. If the same person keeps forgetting their password, note whether password-manager training was suggested.
Common Mistakes
1. Resetting without verifying identity. The classic attack: a caller claims to be a senior manager, sounds urgent, and the help desk resets the password and reads it out. Every reset without verification is a potential account takeover. No exceptions, even for executives, especially for executives, since they’re the most impersonated.
2. Sending passwords over insecure channels. Reset links and temporary passwords sent to personal email addresses, or read out over the phone to an unverified caller, defeat the point. Deliver through the corporate account or a secure channel, and force a change at next login.
3. Incomplete entries. “John, reset, done” tells you nothing later. Every entry needs the full set: who, when, how verified, who performed it, how delivered. The log is only useful if each row stands alone.
4. Treating repeats as routine. The fifth reset for the same person in a month isn’t a routine ticket, it’s a signal. It may mean they’re writing passwords on sticky notes, sharing them with a colleague, or that someone else is requesting resets in their name. Flag patterns, don’t just process them.
Who Needs to Sign Off
The log itself doesn’t need per-entry sign-off, it’s a working record kept by IT support staff. But the verification policy behind it should be approved by IT management (or the business owner in a small company without a dedicated IT manager), so help desk staff can point to it when someone pressures them to skip a step. Review the log monthly: IT management or the designated security contact checks for gaps, unverified entries, and unusual patterns.
How Often to Review and Update
Review the log itself monthly for completeness and anomalies. Retain entries for at least 12 months, or longer if your industry regulations require it, check your local requirements. Review the template and the underlying verification policy annually: the accepted verification methods should keep pace with how your team actually works (remote staff, new joiners in other offices), and delivery channels should reflect current tools.
Download the free IT Password Reset Log template.
Disclaimer: identity verification and credential handling may be subject to data protection and information security regulations that vary by jurisdiction. This guide is general information, not legal advice. Check your local regulations before setting your reset policy.