Data Breach Response for Small Business: The Owner's Playbook

The hardest first 60 minutes

Something feels off. A staff member got a wire-transfer email from the bookkeeper that doesn't sound right. A login alert pinged on the CFO's account from an IP in another country. A vendor mentioned an invoice from you that you didn't send. Now what?

The first decision isn't technical. It's restraint. The instinct is to start fixing things: delete the suspicious email, remove the inbox rule that's forwarding mail to a stranger, reset the affected user's password, restore from yesterday's backup. Every one of those instincts is wrong in the first hour, and three of them will cost you money in court six months from now.

Here is what to do instead. Document, don't destroy.

• Don't delete the suspicious email. It's evidence. Take screenshots, note the headers, and leave it where it is.
• Don't delete inbox forwarding rules. They tell forensics where the attacker was sending stolen mail. A single rule, captured intact, often unlocks the whole timeline.
• Don't notify customers, vendors, or staff yet. You don't know enough to be accurate, and inaccurate breach notices create their own legal exposure.
• Don't restore from backup. If the attacker is still in your tenant, restoring overwrites the evidence and changes nothing about their access.
• Don't pay anything. Not a "release fee" on a ransomware screen, not a wire to a vendor whose email you can't verify, nothing.

Now, before anything else, do these three things:

1. Write down what you know and when you knew it. A timestamp on a notepad is fine. "9:14am: Sarah forwarded me an invoice from a vendor we don't use. 9:22am: I noticed an inbox rule on her account forwarding mail to an external Gmail." This document becomes your forensic timeline.
2. Disconnect the affected user from the network. Sign them out of Microsoft 365 in the admin center. Don't change the password yet (we'll get to that). Just kill the active sessions.
3. Take a deep breath and stop touching things. The next 30 minutes are about phone calls, not console clicks.

"Weird email" versus "actual breach"

Not every alarm is a breach. A user clicking a phishing link and immediately reporting it usually isn't a breach yet. A failed login from a new country usually isn't a breach. A spam message that looks like it came from your CEO usually isn't.

The threshold flips when any of these are true:

• A successful sign-in from an unfamiliar location (not just an attempt).
• Inbox rules, forwarding rules, or sign-in app consents on a mailbox that the user didn't create.
• An email sent from one of your accounts that the account owner didn't send.
• A vendor or customer received a message from you with payment instructions that didn't come from you.
• A ransomware note, a defaced site, or a "we have your data" message.

Any one of those, treat it as a breach. The cost of overreacting is a few hours of work. The cost of underreacting is your insurance carrier denying the claim because you missed the notification window.

Who to call, in what order

The order matters more than most owners realize. Make these calls in this sequence, even if it feels backwards:

1. Your cyber insurance carrier (yes, before your IT)

This surprises every owner the first time. You're sitting on a probable breach, your impulse is to call your IT person, and the playbook says call insurance first. The reason is contractual. Your policy almost certainly has a notification clause that gives you 24, 48, or 72 hours to report a "security incident" or "suspected breach." Miss the window and the carrier can deny coverage for the whole event. We've watched it happen.

The other reason is leverage. Your carrier has a panel of forensics firms, breach coaches (specialized attorneys), and PR vendors on retainer. When you call them, they engage those resources at policy rates, often pre-paid, and you avoid the mistake of hiring a $750-an-hour forensics firm yourself only to learn your policy required you to use a different one.

Find your policy now, before you need it. The breach hotline is usually a single phone number on the cover page. Save it in your phone.

2. Your IT provider or MSP

After insurance, call your IT person. They have the M365 admin access, the firewall logs, and the context on your environment. Be specific with them: "I think we have a breach. Insurance has been notified. Don't delete anything yet. I need you to (a) confirm what you can see in the sign-in logs for the last 30 days, (b) export those logs, and (c) wait for forensics before making changes." That sentence saves a lot of pain.

3. Your attorney

State data breach notification laws apply if personally identifiable information was exposed. The trigger varies (in most states it's name plus Social Security number, name plus driver's license, name plus financial account number, sometimes name plus email and password). Your lawyer reads the law for the states where your customers and employees live, not just where you're incorporated. Do this in days, not weeks.

If you don't have a tech-comfortable attorney, your insurance carrier's breach coach fills this role and is usually included in the policy.

4. A remediation partner (optional)

Once forensics has the timeline and the access scope, you'll need someone to actually rebuild the M365 baseline (revoke tokens, reset MFA, audit forwarding rules, lock down legacy auth, harden Conditional Access). Your MSP can do it if they have the bench. M365Shield handles this work as a flat-fee remediation when the MSP doesn't. The full step-by-step technical recovery is in the M365 tenant compromised recovery checklist.

The conversation with your insurance carrier

The first call to the carrier is short. The intake person isn't a forensics expert. They're triaging. They will ask:

• What happened, in one or two sentences?
• When did you first notice it?
• Has any data been confirmed exfiltrated?
• Have you notified anyone yet (customers, regulators, media)?
• Have you restored from backup, deleted anything, or paid anything?

Answer the first two questions specifically. Answer the third with "we don't know yet." Answer the fourth and fifth with "no, we have not" if that's true. Those last two answers are doing a lot of work for you. They preserve evidence and they preserve coverage.

What not to say on that first call:

• Don't speculate on cause. "I think it was Russia" or "the attacker definitely got the customer database" can both end up in the claim file and contradict the forensics report later.
• Don't admit fault. "We knew our MFA was misconfigured" is a sentence to never say to the intake person. Save it for forensics, who are working under privilege through the breach coach.
• Don't promise a notification timeline. The carrier will help you build one once forensics is engaged.

The carrier will then assign a breach coach (an attorney) and, usually within hours, a forensics vendor. Both work under the breach coach so their findings are protected by attorney-client privilege. That privilege matters if the breach later becomes a lawsuit.

What a breach actually looks like at SMB scale

Forget the movie version. At a 30-person company, a breach almost always falls into one of three patterns. Understanding which one you're in tells you what to do next.

Pattern 1: Business Email Compromise plus wire fraud

The most common breach we see, by a wide margin. An attacker phishes one user (often through a fake Microsoft sign-in page or an OAuth consent prompt). They steal the session token, log in as that user, and read mail for two to six weeks. They learn your vendors, your invoice cadence, your CEO's writing style. Then they impersonate someone (usually you, the owner) and send a wire instruction to the bookkeeper. The wire goes out, lands in a mule account, and is gone within hours.

Tell from this signature: a sent email from your account that you didn't send, an inbox rule forwarding to an external address, a successful login from a new IP weeks ago, and a wire that the recipient never received.

Pattern 2: Ransomware via a single endpoint

A user opens an attachment, malware encrypts the laptop, and the ransomware tries to spread to file shares and OneDrive. At SMB scale, this usually stops at one or two machines (because most small businesses don't have the kind of flat network that lets ransomware spread broadly). M365 file recovery and version history almost always pull you out of this if you don't panic-pay.

Pattern 3: Mailbox compromise plus invoice fraud chain

Variation on Pattern 1. The attacker compromises the mailbox of someone who handles invoicing (often the owner, the controller, or accounts receivable). They watch invoice traffic, and when a real invoice goes out to a customer, they send a follow-up from the same mailbox saying "we've changed banks, please update payment to this account." Customer pays the new account, the attacker disappears, and you find out in 30 days when the customer thinks they've paid and you're chasing them for a missing wire.

Real timelines from cases we've worked: median dwell time (compromise to discovery) is 38 days at the 30-to-50-person company size. Some have been in for over a year. Almost none are caught in the first week without external alerting.

Walking through one full case from compromise through recovery makes this concrete. The M365 breach recovery case study covers a Pattern 1 BEC at a 28-person professional services firm: how it was discovered, what forensics found, what the insurance claim covered, and what the rebuild cost.

The 10 things you must do in the first week

The full enterprise checklist runs 25 steps. At SMB scale you do not need all 25 in week one; you need the right 10. The rest is the 30-day arc.

1. Notify cyber insurance. Why this matters: missing the notification clause voids coverage on the entire event. Single most expensive mistake an owner can make.
2. Preserve evidence (don't delete inbox rules, don't restore from backup, don't reset accounts before forensics says so). Why this matters: forensics needs the artifacts in place to build a timeline, and insurance needs the timeline to pay the claim.
3. Sign out all sessions on the affected user. Why this matters: cuts the attacker's active access without changing the password (which destroys evidence about what password they were using).
4. Export Microsoft 365 sign-in logs and audit logs for the last 90 days. Why this matters: M365 retains these for 90 to 180 days depending on license. Once they age out, they're gone, and so is half the forensic value.
5. Inventory mailbox forwarding rules across all users (not just the obvious one). Why this matters: attackers often plant rules on multiple accounts. The visible one is rarely the only one.
6. Disable legacy authentication tenant-wide. Why this matters: legacy auth (POP, IMAP, SMTP basic auth) bypasses MFA. If you don't shut it off during the response, the attacker comes back through it the moment you reset the password.
7. Reset passwords and revoke active tokens for affected users (after forensics says go). Why this matters: a password reset alone doesn't kick out someone holding a refresh token. You have to revoke tokens explicitly.
8. Audit OAuth app consents on affected mailboxes. Why this matters: this is how attackers maintain access after you reset the password. The malicious app keeps reading mail.
9. Tell your staff something calm and specific (see the "what to tell your team" section). Why this matters: the rumor that fills the silence is always worse than the truth.
10. Decide on customer notification with your attorney, not on instinct. Why this matters: notifying when you don't have to creates liability and damages reputation. Not notifying when you should is a regulatory violation. Your lawyer reads the law.

A common starting move on item 5 is auditing forwarding rules across the tenant. A generalist IT person can run this in Exchange Online PowerShell:

Connect-ExchangeOnline

# Find any mailbox with external forwarding configured
Get-Mailbox -ResultSize Unlimited |
  Where-Object { $_.ForwardingSmtpAddress -ne $null -or $_.ForwardingAddress -ne $null } |
  Select-Object UserPrincipalName, ForwardingSmtpAddress, ForwardingAddress, DeliverToMailboxAndForward

# Find inbox rules that forward or redirect mail (the more common attacker move)
Get-Mailbox -ResultSize Unlimited | ForEach-Object {
  $upn = $_.UserPrincipalName
  Get-InboxRule -Mailbox $upn |
    Where-Object {
      $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo
    } |
    Select-Object @{N='Mailbox';E={$upn}}, Name, Enabled, ForwardTo, RedirectTo, Description
} | Export-Csv inbox-forwarding-audit.csv -NoTypeInformation

A clean output is a forwarding row count of zero (or only rows you can explain). Anything else is a finding. Don't delete what you find. Document it and hand the CSV to forensics.

What to tell your team

Staff communication is where most owners go wrong in two opposite directions. Some go vague ("we had an incident") and create a panic vacuum that fills with worse rumors. Some over-share ("we got hacked, the Russians have everything, we don't know if payroll will run") and create panic directly.

What works: specific, calm, action-oriented. Tell them what's known, what's protected, and what you need from them.

The better version does five things at once: confirms the scope, names what is and isn't affected, signals adult supervision is engaged, gives the team a specific defensive action, and creates a single trusted reporting channel.

A more detailed breakdown of staff messaging across the response timeline lives in the M365 breach FAQ.

What to tell customers

Customer notification is part legal, part communications, part trust. Your attorney owns the legal trigger. You own the tone.

When notification is required:

• State law: If personally identifiable information of state residents was exposed (definitions vary by state). All 50 states plus DC have notification laws.
• Contractual: Many B2B customer contracts include a security incident notification clause, often with a 24-to-72 hour timeline. Your contracts say what they say. Read them.
• Regulatory: If you handle payment cards (PCI), health data (HIPAA), or work in a regulated industry (financial services, defense), there are sector-specific rules.
• Reputational: Even when not legally required, if a customer's data was touched, telling them before they read about it elsewhere is the right call.

What "good" customer notification looks like:

• Sent from a person, not a "do-not-reply" address.
• Names what happened in plain language (no "incident" euphemism if it was a breach).
• Names the data categories actually affected (and ideally the data categories not affected).
• Says what you've done and what you're doing.
• Says what the customer should do, specifically.
• Provides a real contact for follow-up questions.
• Does not over-promise. "We are committed to protecting your data" reads as corporate fog. "We've enabled phishing-resistant MFA across our tenant and disabled the legacy email protocols that allowed this access" reads as an actual answer.

The worst possible customer message is "we have no information to share at this time." Customers read it as "we don't know what happened" or "we're hiding something," and both interpretations are damaging. If you genuinely have nothing to share, it's because notification is premature, in which case wait until you do.

Notification timing in practice: most state laws say "without unreasonable delay" with a 30-to-60-day outside window. The right pace is usually 10 to 21 days from discovery: enough time for forensics to confirm scope, not so much that you're sitting on confirmed exposure.

The 30-day recovery arc

Past the first week, response settles into a longer arc. Roughly:

• Days 1 to 7: Containment, forensics engagement, evidence preservation, internal communication. The ten items above.
• Days 7 to 14: Forensics report draft, scope confirmation, customer notification preparation with counsel, technical remediation begins (revoke tokens, reset accounts, harden tenant baseline).
• Days 14 to 21: Notifications go out (customers, regulators where required). Insurance claim documentation. Tenant baseline rebuild continues.
• Days 21 to 30: Final forensics report. Insurance claim filed. Lessons-learned exercise. Incident response plan written or updated. Monitoring controls deployed so the next compromise is caught in days, not months.

The full 25-step technical and operational arc, including the steps not covered here, is in the 25-step data breach response checklist. Use this playbook for the owner's perspective, and use the checklist as the operational reference.

The five expensive mistakes SMBs make

Worth their own section because each one routinely costs five or six figures more than it should.

1. Trying to investigate it yourself

You or your IT person are competent generalists. Forensics is a specialty. The instinct to "just figure out what happened" deletes evidence, breaks chain of custody, and tanks the insurance claim. Confine your in-house work to documenting and preserving. Let forensics investigate.

2. Not engaging insurance early enough

We've covered it twice already because owners still get this wrong. The carrier is your first call. Late notification is the most common reason small-business breach claims get denied or reduced.

3. Paying the ransom without legal counsel

Ransom payments to entities on the OFAC sanctions list are illegal in the US, regardless of intent. Paying the wrong group can land you in front of Treasury. Even when paying is legal, payment doesn't reliably restore data and signals to the attacker community that you'll pay again. If the question even comes up, your breach coach decides, not you.

4. Restoring from backup before eradication

If the attacker is still in your environment, restoring last week's clean backup gets you a clean backup running in a compromised environment for about 12 hours, until they re-encrypt or re-exfiltrate. Eradication first, restoration second. Always.

5. No incident response plan after the incident

The next compromise is coming. The cheapest insurance against it is a one-page IR plan written in the calm of the post-incident review: who to call in what order, where the policy lives, where the logs live, who has admin access, what gets disconnected first. Write it while the lessons are fresh. The cyber insurance renewal questionnaire that arrives in eleven months will ask you for it.

For owners thinking about whether their cyber insurance posture is renewable after an incident, the related cyber insurance compliance checklist on InsurableIT walks through what carriers will require at renewal.

Common questions

How do I know if it's a real breach versus a false alarm?

A successful unauthorized sign-in, an inbox rule the user didn't create, an email actually sent from one of your accounts that the owner didn't send, or a vendor reporting payment fraud traced to a message from your domain are all real-breach signals. A failed login attempt, a phishing email that nobody clicked, or spam impersonating your CEO are not breaches by themselves. When in doubt, treat it as real and call insurance. The cost of a precautionary call is zero, and most policies don't penalize you for a notification that turns out to be a false alarm.

My IT vendor wants to "just clean it up." Should I let them?

No, not until insurance and forensics are engaged. A well-meaning cleanup destroys exactly the evidence forensics needs. Tell your vendor: "Document everything, preserve everything, change nothing." Most MSPs understand this, but smaller IT shops without breach experience will reflexively start fixing. Stop them politely. The carrier-assigned forensics team takes the lead.

Do I have to notify customers if I think it's small?

"Think it's small" is not a legal standard. Notification is triggered by what data was accessed or potentially accessed, not by your judgment of severity. Your attorney maps the affected data categories to state notification laws. If five customers in California had their email plus password exposed, that's a notification-required event, full stop. The size of the breach is irrelevant to the legal trigger.

What does this typically cost a 30-person company?

For a contained Pattern 1 BEC with no wire fraud loss: $40,000 to $90,000 in forensics, legal, and notification costs, most of it covered by a $1M cyber policy with a $5,000 to $10,000 retention. For a Pattern 1 with a successful wire fraud of $150,000: add the wire amount (which may or may not be covered depending on whether the policy includes social engineering coverage; many small-business policies do not, or cap it at $50,000 to $100,000). For ransomware: highly variable, but the recovery alone usually runs $25,000 to $75,000 even when no ransom is paid. The single biggest variable is whether you caught the dwell time at week 2 or month 3.

We don't have cyber insurance. Now what?

Get a breach coach (a cyber-experienced attorney) directly. They engage forensics on your behalf and structure the work under privilege. Without insurance you pay full freight, but the privilege protection still matters and the engagement model still works. Then, after this is over, get a policy. Renewal underwriting will be harder for the first year because of the incident, but most carriers will quote post-incident as long as you can show the remediation work. The longer-term posture and what carriers want to see is in the cyber insurance compliance checklist.