How to Handle a Security Incident at a Small Company

A security incident at a small company usually starts the same way. Someone clicks a phishing link. Or you notice a login from a country where nobody on your team lives. Or a customer tells you their invoice payment went to a different bank account than usual.

Your heart rate spikes. You don't have a security team. You don't have an incident response plan. You're not sure what to do first.

This guide walks through exactly what to do, step by step, so you have a plan before you need one.

What counts as a security incident

Not every IT problem is a security incident. A security incident is any event that compromises or threatens the confidentiality, integrity, or availability of your systems or data.

Common examples at small companies:

An employee's account is compromised (unauthorized login, password changed without their knowledge)
A phishing email is clicked and credentials are entered on a fake site
Malware or ransomware is detected on a device
A laptop with company data is lost or stolen
An ex-employee accesses systems they shouldn't have access to
Customer data is accidentally shared with the wrong person
A vendor you use discloses a breach that may affect your data

The first hour

The first hour determines whether a small problem stays small or becomes a big one. Move fast but stay methodical.

Step 1: Confirm it's real

Before sounding the alarm, verify that something actually happened. A suspicious login alert might be an employee traveling. A "phishing email" might be a legitimate message with a badly formatted link.

Check your logs. Talk to the employee involved. Look at the actual evidence before escalating.

If you can't confirm or deny within 15 minutes, treat it as real and proceed.

Step 2: Contain the damage

Stop the bleeding. Your goal is to prevent the incident from spreading.

Compromised account: Immediately reset the password and revoke all active sessions. If you have SSO, suspend the user's identity provider account. This kills access to every connected tool.

Compromised device: Isolate the device. If it's enrolled in MDM, lock it remotely. Tell the employee to disconnect from the network (turn off WiFi, unplug ethernet). Don't shut it down yet as you may need forensic data from memory.

Data exposure: If customer data was shared with the wrong person, contact them immediately and ask them to delete it. Revoke any sharing links that shouldn't exist.

Ongoing attack (like active ransomware): Disconnect every affected device from the network. Do not pay the ransom. Contact law enforcement (FBI's IC3 or local authorities) and consider engaging a professional incident response firm.

Step 3: Preserve evidence

Don't start "cleaning up" yet. You may need evidence later for legal, insurance, or compliance purposes.

Take screenshots of suspicious emails, login alerts, and error messages
Export relevant audit logs from Google Workspace, Okta, or your identity provider
Note the exact time you discovered the incident and every action you've taken
If a device is compromised, don't wipe it yet. Lock it and set it aside.

Step 4: Notify your internal team

Tell the people who need to know:

Whoever owns IT (even if that's you)
The CEO or founder if customer data may be involved
Legal counsel if you have it (especially if customer data is compromised)

Keep the circle small initially. Don't send a company-wide panic message. Include only the people who need to act.

The first day

Once containment is in place, shift from reactive to investigative.

Determine the scope

Answer these questions:

What was compromised? Which accounts, which systems, which data?
How did it happen? Phishing? Credential reuse? Unpatched vulnerability? Weak password without MFA?
How long was the exposure? When did the compromise start? When was it detected?
What data was accessed? Customer data? Internal communications? Financial information? Source code?

Your identity provider's audit logs are your best friend here. Google Workspace and Okta both provide detailed login and activity logs that show exactly what happened and when.

Assess notification requirements

Depending on what data was compromised and where your customers are located, you may have legal obligations to notify affected parties.

GDPR (EU customers): Notification to the supervisory authority within 72 hours if personal data is involved. Notification to affected individuals if the breach poses a high risk.

State breach notification laws (US): All 50 US states have breach notification laws. Requirements vary by state. Most require notification within 30-60 days.

Contractual obligations: Review your customer contracts. Many include breach notification clauses with specific timelines and procedures.

If you're unsure about notification requirements, consult a lawyer. The cost of legal advice is much less than the cost of failing to notify when required.

Document everything

Start a formal incident log. Include:

Timeline of events (when discovered, when contained, when each action was taken)
Systems and data affected
Actions taken and by whom
Evidence collected
Decisions made and rationale

This document serves multiple purposes: legal protection, insurance claims, customer communications, and your own post-incident review.

The first week

Remediate the root cause

Containment stops the bleeding. Remediation fixes the wound.

If the incident was caused by a compromised password, enforce MFA across all accounts (you should have done this already, but now you definitely will).

If it was a phishing attack, implement additional email security controls. Review your Google Workspace security settings. Consider adding anti-phishing training for employees.

If it was an ex-employee with lingering access, build a proper offboarding process and run an access audit immediately.

Whatever the root cause, fix it so the same thing can't happen again.

Communicate with affected parties

If customer data was involved, communicate clearly and promptly.

What to include in customer notification:

What happened (factual, not speculative)
What data was affected
What you've done to contain and remediate
What you're doing to prevent recurrence
Who they can contact with questions

Don't minimize. Don't deflect. Don't delay. Companies that communicate honestly and quickly during incidents preserve customer trust far better than companies that hide or downplay what happened.

Notify your cyber insurance provider

If you have cyber insurance (and if you don't, consider getting it), notify your insurance provider as soon as possible. Many policies have notification deadlines, and some include access to incident response resources like forensic investigators and legal counsel.

After the incident

Run a post-incident review

Within two weeks of resolution, sit down and review:

What happened and why
How quickly it was detected and contained
What worked well in the response
What didn't work or was missing
What changes will prevent recurrence

Document the findings and action items. Actually execute those action items. An incident you don't learn from is an incident that will happen again.

Update your incident response plan

If you didn't have a plan before this incident, now is the time to write one. If you did have one, update it based on what you learned.

The plan should cover:

How incidents are reported and escalated
Who is responsible for each phase (detection, containment, investigation, communication)
Contact information for key people (IT, legal, insurance, law enforcement)
Notification templates and timelines
Evidence preservation procedures

Keep it simple. A two-page plan that people actually read is better than a 30-page plan that nobody opens.

Preparing before it happens

The best time to prepare for a security incident is before you have one. The baseline controls that prevent most incidents are the same ones I help remote teams implement:

SSO and MFA on every account
MDM on every device
A password manager for all credentials
A documented offboarding process
Regular access reviews

If you want help putting these controls in place and building an incident response plan before you need one, book a call. Prevention is always cheaper than response.