Tuesday, 08:40. A bank text about a $1,340 charge at an electronics retailer arrives, and nobody in the team bought so much as a cable. The card is a shared one — it has paid the software stack, the ads, and the flights for two years, and nobody can name every service riding on it.
That combination — one card, many services, no list — is how a one-hour fraud becomes a two-week outage of the whole company's payments. Cancelling the card kills every autopay at once: the domain registrar, the hosting, the ads account, the tool the team actually uses. The fraud costs $1,340; the clumsy response costs a week.
The full runbook lives on ops-notes. Here is the spine of it.
1. Freeze in the first hour — lock, don't cancel
Every major network lets you lock a card from the app in seconds. New charges decline; existing authorizations still settle. Locking is reversible, which makes it the right move before the ten-minute argument about whether the weird charge "might be legitimate."
Two more first-hour moves:
- One person owns the freeze. Two people calling the bank produce two contradictory stories. The freeze owner screenshots the lock and posts the timestamp in the team channel.
- Pull the last 30 days of statements before you call. Fraudsters test with $1.02 and $4.99 authorizations first. That small-change pattern is the map of when the card leaked — and downloading the statement now beats fighting the dispute portal's history limits later.
Write down the freeze time. "When did you report this?" is a question on every dispute form, insurance questionnaire, and audit follow-up.
2. Build the autopay table before the declines arrive
The frozen card just turned your SaaS sprawl audit from "someday" into "in the next two hours." Three months of statements, every recurring merchant in a table: service, owner, monthly amount, account email.
Most five-person teams find 15–30 autopays. Half are services nobody remembered paying for — which is its own finding.
Then rank by blast radius, not alphabet. Domain registrar and hosting are P1 (a decline there kills the company, not just the mood). The design tool can ride a grace period. The severity matrix habit transfers directly: P1s get the new number first.
3. Migrate the new number on your schedule
"The bank is shipping a new card" is not a plan. A table with a migrated-on column is. New number to the P1 tier first, verified by a screenshot or a one-dollar charge, then down the list. Nothing is done until its row says so.
Two traps:
- Assume nothing about reissued numbers. Banks differ on whether recurring authorizations follow the new card. The row that declines during migration is normal; the failure mode is discovering the domain renewal was still on the dead card when the account auto-cancels.
- The dead card stays dead. The "legacy" service that keeps charging the old number for convenience is how the next compromise inherits the same house of cards.
While you're touching every service anyway: this is the cheapest week you'll ever have to move to per-merchant virtual cards. The ads account gets a number, the SaaS stack gets a number, and the next compromise is a one-row incident instead of a company-wide one.
4. Reconcile the fraud window line by line
Define the window (first unauthorized authorization → freeze timestamp). Every charge inside it gets a verdict: recognized, unrecognized, or unrecognized-but-actually-yours (the intern's test subscription).
File disputes per charge, not one blanket claim. Banks process line items; a dispute with date, amount, merchant, and the freeze timestamp is the claim that clears.
One thing small teams learn the hard way: business cards are not consumer cards. Zero-liability rules that cover your personal plastic may not cover the company card, and some agreements have short reporting windows. Read the card agreement's fraud terms in daylight — or add it to the cyber-insurance review — not mid-incident.
And watch for the second wave: stolen card data resurfaces weeks later. Check the closed card's final statement weekly for a month.
5. Report in writing, close the loop same day
Bank fraud form, yes — and a police report number, even when nobody asks for one. Ten minutes online, and it gets requested later by insurers, bank escalations, and client auditors more often than you'd expect.
Then the one-page incident record: what happened, when the card was frozen, what it was feeding, what migrated when, the fraud total, dispute status. That page becomes the postmortem input and the exhibit that answers "describe an incident and your response" on the next security questionnaire with something real.
Finally: find where the number lived. Browser autofill on every workstation? A spreadsheet? A screenshot in Slack? A credential shared with five people and stored in four places has a leak probability, not a question of one. The secrets rotation rule applies to card numbers exactly like API keys.
The sentence to keep
Freeze within the hour, enumerate before the declines, migrate by rank, reconcile the window, report in writing — and end the single shared card forever.
A compromised card handled this way costs one afternoon and one ledger table. Handled the usual way, it costs the domain, the hosting, the ads, and a week of everyone's attention — for the same thirty dollars of fraud.
The complete checklist — including the quarterly ten-minute card-table review that keeps it from ever being this bad again — is at ops-notes.
Running a small business or ops team? The Ops Starter Kit ($14) packs the checklists, templates, and runbooks from this article into ready-to-use form. Free First 30 Minutes incident response kit also available.
Top comments (0)