Rotate or revoke the credential first. Then find every place the value was copied, check for misuse during the exposure window, fix the code that logged it, and add a test. Deleting the log line alone does not make the secret safe.
Why rotation comes first
A secret in a log has been copied at least once and probably several times: local files, a shipper buffer, a central store, a backup, a search index. You cannot be sure who read it. Removing the line does not undo that. Making the value useless does.
The OWASP Logging Cheat Sheet says secrets such as access tokens, passwords, connection strings and encryption keys should not be recorded directly. Once one has been, treat it as exposed to everyone who could read that log.
Response steps
- Confirm it is live. Check whether the value works. A test token or an expired key needs a fix to the code but not an incident. See triage secret alerts: live, revoked or test.
- Rotate or revoke. Issue a new credential and disable the old one. For session tokens, invalidate the sessions. For user passwords, force a reset and tell the user.
- Record the exposure window. From the first log line containing the value to the time of rotation.
- Find every copy. Search the destinations: local files, central store, trace backend, error reports, backups, exports and any ticket or chat where the line was pasted.
- Check for misuse. Review access logs for the credential during the window: new locations, unusual calls, bulk reads. See detect API key misuse from logs.
- Purge where you can. Delete or redact copies that your retention rules allow. Note any that cannot be changed, such as write once archives, in the incident record.
- Fix the source. Find the line that logged it, usually a request object or exception. Change it to record selected fields only.
- Add a test. Reproduce with a canary. See test log redaction with canary values.
- Write it up. One page: what, when, who had access, what you did, what changed.
Who to tell
Tell the owner of the credential first, as the one who can rotate it. Tell security, since you may need to review wider access. If the secret was a customer's, or if personal data was involved, involve privacy or legal staff early so that any notification duty is assessed, not guessed.
What not to do
Do not wait for a convenient maintenance window. Do not paste the secret into a ticket or chat to discuss it. Do not assume that a short retention period means nobody saw it.
Reduce the odds next time
Short retention for raw logs, access reviews for log systems, and a pipeline filter for known patterns. See redact at the source or in the pipeline.
Quick check
Is deleting the log line enough?
No. The value may already be in buffers, backups and other systems, and someone may have read it. Rotate first.
What if the logged value is a test credential?
Fix the code and rotate if there is any doubt that it is real. A confirmed fake needs no incident.
Safeguard's compliance and evidence automation can help keep the record of such events. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
