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.

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.