Company card compromised: kill the card, save the autopays, prove the damage

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 turns into a two-week outage of the whole company's payments, because cancelling the card kills every autopay at once. This runbook is the sequence that keeps the fraud small and the damage boring: freeze first, enumerate before the declines start, replace deliberately, reconcile line by line, report in writing, and make the next card harder to abuse. The invoice fraud checklist covers the fake-invoice cousin of this incident; this page is the plastic itself. The one rule that runs the whole page: the card is dead in the first hour, but the list of what it was feeding exists before you call the bank.

1. The first hour: freeze the card, don't debate it

• Freeze, don't cancel — yet. Every major card network lets you lock the card from the app in seconds: new charges decline, existing authorizations still settle. Locking is reversible, which makes it the right first move before anyone has finished arguing about whether that weird charge "might be legitimate." The debate happens after the card is already inert; a ten-minute discussion with a live card is ten minutes of open door.
• One person owns the freeze; everyone else owns enumeration. Two people calling the bank at once produce two contradictory statements and a slower investigation. The owner of the freeze confirms the lock on screen, screenshots it, and posts the timestamp in the team channel. The incident communication templates principle applies at company scale: one voice on the outside, parallel work on the inside.
• Pull the last 30 days of statements before you call. The disputed charge is rarely the only one. Fraudsters test a card with small amounts first — a $1.02 subscription, a $4.99 verification — and those authorizations are the map of when the card leaked and what else to expect. Download the statement now, because the bank's own dispute portal may limit how far back you can see without effort later.
• Write down the freeze time. It sounds like ceremony until you are answering "when did you report this?" in a dispute form, a cyber-insurance questionnaire, or the incident timeline. The minute is the difference between "unauthorized" and "you let it ride for a week."

2. Enumerate every autopay before the declines arrive

• The statement is the list; build it while the card is frozen. Three months of statements, every recurring merchant extracted to a table: service, owner, monthly amount, account email, alternate card on file. Most five-person teams find 15–30 autopays, half of which nobody remembered — the SaaS sprawl audit exists because this list is always longer than anyone thinks. The frozen card just turned that audit from "someday" into "in the next two hours, or the services that matter go dark."
• Rank the table by blast radius, not by alphabet. Domain registrar, cloud hosting, and the payroll-adjacent tools are the tier that kills the business if they decline; the design tool and the newsletter can ride a grace period. The tiering mirrors the severity matrix: what stops customer-facing work is P1, what merely annoys the team is P3, and the P1s get the new card number first.
• Check for charges not on the statement. Annual subscriptions bill on anniversaries, and usage-based services bill in arrears — the statement shows history, not everything. Ask the owners of the critical tier one question: "what does this service bill the company card for?" The answer usually surfaces two forgotten charges and one expired-card time bomb per page of the list.
• The enumeration table outlives the incident. Save it next to the software license register — same idea, different columns. The next card compromise (and there will be one) starts with a table instead of a scramble, and the annual review finally has a payments section to check off.

3. Replace the card on your schedule, not the bank's

• Get the replacement, then migrate in the ranked order. The new number goes first to the P1 tier — domain, hosting, anything the customers touch — verified by a screenshot of the saved card or a successful one-dollar charge, then down the list. "The bank is shipping a new card" is not a plan; a table with a migrated-on column is. Nothing on the list is done until its row says so.
• Keep the old card's status in the ledger. Banks vary on whether a reissued number kills recurring authorizations; assume nothing. The rows that decline during the migration window are normal — the failure mode to avoid is discovering the domain renewal was still on the dead card when it auto-cancels the account. The expiry checklist rule applies: things that expire silently need an owner, not a hope.
• Decide what the old card never gets again: everything. There is a temptation to keep one "legacy" charge on the frozen card for a service nobody wants to log into. The dead card stays dead; that one service gets the new number and an owner's name, or it gets cancelled. Half-alive cards are how the next compromise inherits the same house of cards.
• Virtual and single-merchant cards end this incident class. Most modern business cards issue per-merchant virtual numbers: the ads account gets a card, the SaaS stack gets a card, and a compromise of any one number is a one-row incident instead of a company-wide one. Migrating this week is the cheapest moment to adopt it — every service is already being touched for the new number.

4. Reconcile the fraud window line by line

• Define the window, then audit it completely. From the first unauthorized authorization to the freeze timestamp, every charge on the card gets a verdict: recognized, unrecognized, or unrecognized-but-actually-yours (the intern's test subscription). The 30-day statement pull from step 1 is the source of truth. The outcome is a number — total fraudulent charges — that everything downstream depends on.
• File the dispute for each charge, not one blanket claim. Banks process line items; a dispute per fraudulent charge with date, amount, and merchant is the claim that clears. Attach or reference the freeze timestamp, the statement pages, and the fact that the card was locked within the hour. The stolen laptop runbook and this page share the same spine: evidence produced at the time beats evidence reconstructed later.
• Business cards are not consumer cards — know your liability window. Consumer cards carry strong zero-liability protections; some small-business cards do not, and the clock matters. This is exactly what the cyber-insurance requirements review should have surfaced: the card agreement's fraud liability terms, read in daylight, not mid-incident. If the terms are bad, the fix is a different card product, not a wish.
• Watch for the second wave for 90 days. Card data sold in bulk resurfaces weeks later — a $0.99 test, then a real charge. Calendar a recurring check of the closed card's final statement weekly for a month and monthly after. The new-card question on the access review gets one more line: are the compromised number's charges still appearing anywhere?

5. Report, document, and close the loop

• Report to the bank in writing, and the police report exists whether they want it or not. The bank's fraud form is the primary channel, but a police report number (most jurisdictions take these online) costs ten minutes and is repeatedly requested later — by insurers, by the bank's own escalation, by clients' auditors. The breach first-24-hours principle holds: generate the paper trail while the facts are fresh.
• Write the one-page incident record the same day. What happened, when the card was frozen, what was on it, what migrated when, what the fraud total was, what the dispute status is. This page becomes the postmortem's raw material using the postmortem template, and the exhibit that answers the security questionnaire's "describe an incident and your response" question with something real. The timeline template gives it a spine.
• Find the leak point — or at least shrink the blast radius for next time. Where did the number live? A browser profile with autofill on every workstation, a spreadsheet of card details, a screenshot in Slack, a contractor's copy. The secrets rotation rule applies to card numbers the same as API keys: a credential shared with five people and stored in four places has a leak probability, not a question of one. Whatever the entry point was, it gets fixed in the same week, not "when things calm down."

6. Make the next card boring before it's urgent

• The shared card gets retired by architecture, not by policy. A policy that says "don't save the card anywhere" loses to human convenience every time. The structure that wins: per-merchant or per-owner virtual cards for subscriptions, a physical card for two named humans, and per-card spending limits so any single compromise has a ceiling. The delegation of authority table gets a payments column — who can issue a virtual card, who can raise a limit, who freezes.
• Card alerts on, thresholds low. Transaction alerts above a small threshold (and declined-charge alerts always) turn the next compromise from a Tuesday-morning surprise into a same-minute response. The alert that fired this incident is the control; make it permanent and make it louder, the same way the alert fatigue page tunes noise out of the way of signal.
• Quarterly, ten minutes: the card table. Statement review against the autopay table — every recurring charge matches a row with an owner, anything unmatched gets investigated, dead rows get cancelled. This is the weekly review habit applied to money, and it is the difference between the next incident being one row and the next incident being this page again from step one.

The whole discipline fits one sentence a five-person team can keep: freeze within the hour, enumerate before the declines, migrate by rank, reconcile the window, report in writing, and end the single 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 every owner's attention — for the same thirty dollars of fraud.