Contentious offboardings are where credential rotation checklists usually fail, since the pressure is to move fast and something always gets missed. This one is built to surface the access nobody remembers granting a year ago, not just the obvious login.
Security
Plan a credential rotation checklist after an employee offboarding
A marketing coordinator with WordPress admin, SFTP, hosting-panel, and shared-vault access let go on bad terms, turned into a same-day rotation checklist that doesn't miss the integrations nobody remembers exist.
Works with Claude / GPT329 uses★ 4.1
The prompt
security-credential-rotation-after-offboarding
OFFBOARDING CONTEXT: [marketing coordinator terminated today, not on good terms, had personal access to: WordPress Administrator account, SFTP/SSH access to the production server, the hosting control panel login (shared single account, not per-user), a seat in the team's shared password vault, and admin access to Google Analytics and the ad platform. They also set up an email marketing integration and a webhook to a Slack channel roughly a year ago that nobody else has touched since.] Build the rotation checklist the way it needs to happen for a contentious exit, not a routine one: 1. Split this into same-day items versus follow-up items, and justify the split: anything this person could use right now to access systems or data (WordPress login, SFTP/SSH, hosting panel, vault seat) gets rotated today, before end of business, regardless of how busy the team is. 2. For the shared single hosting-panel login specifically, flag this as a structural problem beyond just this offboarding: a shared account means you can't selectively revoke one person's access, only reset the password for everyone, and recommend moving to per-user access as a follow-up so the next offboarding isn't this disruptive. 3. For WordPress specifically, don't stop at the account password: revoke any application passwords issued to that account, terminate active sessions, and check whether they had any REST API keys or plugin-level credentials tied to their identity rather than a shared service account. 4. Handle the forgotten integrations as their own line item: audit the year-old email marketing integration and Slack webhook to determine whether they were set up under this person's personal API key or a company-owned one, since a personal key silently stops working (or worse, still works) long after the person is gone if nobody checks. 5. Close with a short list of what to verify 24 to 48 hours later: confirm no login attempts using the old credentials, confirm the rotated integrations are still functioning correctly, and confirm the vault access is fully removed rather than just deactivated.