After a Breach: What a Small Merchant Actually Has to Do

The call usually comes from the acquirer rather than from your own systems: cards used at your business have shown up in a fraud pattern. The instinct at that moment is to find the problem and fix it immediately — and doing that can destroy the evidence that determines what the whole thing costs you. Scope is what drives the obligations and the assessments, logs are what establish scope, and a merchant who rebuilt the affected system before anyone imaged it is generally treated as though the compromise was as broad as it could have been. The first forty-eight hours matter more than anything that follows.

The first forty-eight hours

1. Contain without destroying. Disconnect affected systems from the network. Do not wipe, rebuild, patch, or reinstall — those actions eliminate exactly what an investigation needs.
2. Don't turn things off if you can avoid it, since some evidence exists only in running memory. Isolate rather than power down where possible.
3. Notify your acquirer. Your merchant agreement almost certainly requires prompt notification, and the obligation runs regardless of how certain you are.
4. Engage counsel — before an investigator, because counsel shapes how the investigation is conducted and how findings are handled.
5. Preserve logs. System, network, application, access. Many systems rotate logs on a short cycle, so the window to preserve them is measured in days.
6. Write down the timeline — what was noticed, when, by whom, what was done.
7. Limit who knows internally to those who need to.
8. Say nothing publicly until scope is understood.
9. Notify your insurer, since policies typically require prompt notice and may direct which vendors you use.

Steps one and five are where the money is. A merchant who preserved evidence can potentially demonstrate a narrow compromise; one who didn't cannot demonstrate anything, and the difference between those two positions is frequently the largest single variable in the total cost.

Why scope decides everything

The mechanism that makes evidence preservation financial rather than procedural.

Every consequential number depends on scope:

• How many cards were exposed drives reissuance and fraud assessments.
• How many individuals drives notification cost.
• Which jurisdictions they're in drives which laws apply.
• What data types were involved drives the content of notifications.
• How long the compromise ran drives all of the above.

And the default when scope can't be established: the assumption runs against you. An investigation unable to determine what was accessed generally concludes that everything reachable may have been — which converts an incident affecting a fortnight of transactions into one affecting everything the system ever held.

Which produces the practical framing worth holding onto: logs are not an IT artifact, they're the document that establishes how much you owe. A merchant with thirty days of retained logs and a compromise that ran forty days has a problem the logs can't solve, and log retention settings are therefore worth reviewing before anything happens rather than after.

Who you owe obligations to

Party	Obligation	Timing
Acquirer or processor	Prompt notification, cooperation	Immediate, per your agreement
Card networks	Investigation, possible forensic requirements	Via your acquirer
Affected individuals	Notification under state law	Varies — some are tight
State regulators	Notification in many states, thresholds vary	Varies
Your insurer	Notice under the policy	Prompt, or coverage may be affected
Law enforcement	Optional, sometimes advisable	On advice

The acquirer relationship is where the practical consequences concentrate. Beyond investigation requirements, an acquirer may hold funds, adjust reserve requirements, or terminate the relationship — and a merchant terminated after a breach can find replacement processing difficult and expensive, which is a business continuity issue as much as a compliance one.

Depending on the compromise's scale, a forensic investigation by a qualified investigator may be required rather than optional, and the scope of that engagement is not the merchant's to set.

Notification requirements

The area most often underestimated by small merchants, for a specific structural reason.

Which law applies depends on where the affected individuals live, not where you are. A single-location business serving customers from several states may face several sets of requirements at once, with different definitions of what triggers notification, different content requirements, different deadlines, and different regulator notification thresholds.

What varies:

• What data types trigger an obligation.
• Whether encryption creates a safe harbour — many states provide one for properly encrypted data, which is a direct argument for encryption independent of preventing the breach.
• Deadlines, some measured in a specific number of days.
• Required content of the notice.
• Regulator notification and its thresholds.
• Whether credit monitoring must be offered.

The encryption safe harbour deserves emphasis because it's actionable in advance. Data that was encrypted and whose keys weren't compromised frequently doesn't trigger notification at all in many jurisdictions — which means the same incident can be a notifiable event or a non-event depending on a decision made months earlier.

This is jurisdiction-specific, changing, and genuinely complex. It requires counsel, and it's the part a merchant should not attempt to work out themselves.

What it costs

Components, in rough order of how often they're underestimated:

• Forensic investigation — the single largest direct cost for most small merchants, and it scales with scope rather than with business size.
• Legal fees, across incident response and notification analysis.
• Notification — production and delivery, per individual.
• Credit monitoring, where offered or required.
• Card network assessments passed through by the acquirer, relating to reissuance and fraud.
• Remediation — the fix, and any required validation afterward.
• Operational disruption.
• Lost business and reputational effect.
• Higher processing costs or difficulty obtaining processing.

The two that surprise people: the forensic investigation, because it's scoped by requirement rather than by budget, and the assessments, because they arrive later and through the acquirer rather than as a bill you can query directly.

The general shape is the fixed-cost problem from our institutional cost analysis: an investigation costs roughly what it costs regardless of the merchant's size, so the same incident is an inconvenience for a large retailer and potentially existential for a small one.

Talking to customers

Where a badly handled communication creates a second problem.

What to do:

• Wait for scope before saying anything specific. An early statement that turns out to be wrong is worse than a later accurate one.
• Follow the required content, which is prescribed rather than discretionary.
• Be plain. What happened, what data, what you're doing, what they can do.
• Don't minimize. Customers who later learn it was worse than described react to the description more than to the breach.
• Give people something actionable — the credit-freeze and monitoring steps in our identity theft guide are the practical response and worth pointing to.
• Prepare staff for questions, with a script.

What not to do: speculate about cause, blame a vendor publicly, or say the investigation is complete before it is.

And a note on the customer side: a card compromise generally doesn't cost the cardholder money directly, since fraudulent charges are typically the issuer's or merchant's loss per our channel liability guide. The customer cost is disruption and the identity theft risk where more than card data was involved — and being accurate about which of those applies matters for how the notification reads.

Where insurance helps

Cyber coverage is the mechanism that makes this survivable for a small business, and the details matter more than the existence of a policy.

What to check before anything happens:

• Does the policy cover payment card assessments, specifically? Many general policies don't, and it's a large component.
• Does it cover forensic investigation and legal fees?
• Notification and monitoring costs?
• Business interruption?
• What are the notice requirements, and how quickly?
• Are you required to use panel vendors? Engaging your own investigator first can affect coverage.
• What conditions apply — some policies require specified controls, and a failure to maintain them can affect a claim.

The panel vendor point is worth acting on now: a merchant who engages a forensic firm before notifying their insurer may find that cost uncovered. Notify the insurer as part of the first forty-eight hours, not afterward.

Reducing exposure in advance

One change dominates all the others.

Don't hold card data. With point-to-point encryption and tokenization, card numbers never exist in usable form on your systems — the terminal encrypts at the point of capture and your records hold tokens rather than numbers. A compromise of a system that never held card data is a fundamentally smaller event, both in likelihood of material exposure and in the scope of any investigation.

The rest, in rough order of effect:

• Segment the network so payment devices aren't on the same network as general-purpose computers.
• Keep payment terminals off multi-purpose systems — a terminal on a machine also used for email and browsing is the most common small-merchant exposure.
• Patch promptly, including the point-of-sale software from our POS guide.
• Extend log retention beyond the default, since scope determination depends on it.
• Control remote access, which is a frequent entry point where vendors have standing access.
• Maintain PCI compliance genuinely, per our compliance guide — a completed questionnaire that doesn't reflect reality is worse than useless, since it's a document about you that turns out to be wrong.
• Know your vendors' responsibilities, since a compromise at a service provider is still your incident with your customers.
• Carry appropriate coverage, checked against the list above.

The comparison worth making: the cost of moving to encryption and tokenization is small and recurring; the cost of a breach in a system holding card data is large and one-time. For most small merchants that's a straightforward decision made unstraightforward only by never having been calculated.

Frequently asked questions

---

This guide is educational and does not constitute legal, security, or insurance advice. Breach notification requirements, deadlines, safe harbours, and regulator obligations vary substantially by state and continue to change, and card network requirements are set by the networks and your acquirer. Engage qualified counsel immediately upon discovering or being notified of a suspected compromise.