Example rotation checklist for a committed access key, with what the account holder does

This checklist is synthetic

The service, the key name and every detail below are invented, and no real credential format is used. The checklist shows the order of steps and who does each one. The account holder does every step that touches the credential. We never hold or receive the replacement key, and a real checklist is written for your own services and where you actually use the key. In the paid job you complete step 1 before we receive the repository, and our scan of the repository supplies what a generic list cannot: the files, workflows and deployment settings where the credential was found, for steps 3 and 4 and the repository part of step 7.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

SYNTHETIC EXAMPLE: service "Example Storage" and key "deploy-bot" are invented.
Owner of every step: the account holder. Status is marked by the account holder.

1  Revoke      Revoke the exposed key in the provider's console.
               Evidence: the console shows the key as revoked or deleted.   [ ] done  by ____ on ____
2  Replace     Create a new key with the narrowest permissions the application needs.
               Evidence: the new key's identifier is noted (never its value).  [ ] done
3  Store       Put the new value in the secret store or the environment, not in the repository.
               Evidence: the application reads it from configuration.         [ ] done
4  Configure   Set it everywhere the application reads it: staging, production, CI.
               Evidence: each place listed with the date it was changed.      [ ] done
5  Verify      Run the application and its checks against the new key in staging first.
               Evidence: a passing run that used the new key.                 [ ] done
6  Review logs Read the provider's access and billing logs from the date of the commit.
               Evidence: reviewed by ____; anything unexpected? yes / no
               If yes: stop and use your incident process.                    [ ] done
7  Find copies List other places the old value may sit: CI variables, teammates' files,
               chat, tickets, backups, forks.                                 [ ] done
8  Clean       Only after steps 1 to 5: remove the value from the current files and, if
               you choose, from history. Keep a backup before any history rewrite. [ ] done
9  Prevent     Add the scan configuration; check whether push-time scanning is available
               on your plan and turn it on.                                   [ ] done

Why the order matters

The first two steps change what the leaked value is worth. Once the key is revoked, anyone who copied it holds nothing useful, and the repository cleanup becomes housekeeping. If the cleanup came first, the key would stay valid while the team worked on the repository. GitHub's guidance makes the same point: revoke or rotate first, and remember that the data can remain reachable in other people's clones, forks and cached views even after a rewrite. Step 6 is separate and yours: only the account holder can read the provider's logs and decide whether something unexpected happened.

• Steps 1 to 5 protect the account. Steps 8 and 9 tidy the repository.
• A suspected misuse changes the plan: stop and follow your incident process.

What the repository work adds

The repository job covers the part of this list that sits in code: finding each occurrence in current files and history with values redacted, changing the code to read configuration, preparing the rewritten history copy and the publishing steps, adding the scan configuration and checking that no real value appears in any deliverable. Ignoring a file does not remove one that Git already tracks, so the cleanup also removes it from the index. The job is accepted by re-scanning the final branch and the rewritten copy, running the application with placeholder values and your own marking of each item on the checklist.

Limits

This is a checklist, not a record of any client's incident. It does not investigate misuse, give legal advice or promise that a repository or account is secure. If personal or customer data was committed, that may be a reportable incident and needs your own legal or privacy advice before any cleanup.