A property management company in Bellevue runs on three IT people and a lot of trust. They manage about two hundred rental units across King County, which means they hold tenant applications with credit histories, bank statements, background check results, and signed leases. Last year, one of their property managers got a text message that appeared to come from the CEO asking her to approve a password reset for the finance system. She did. Within forty minutes, an attacker was inside their accounting software downloading tenant payment histories and W-9s for every contractor they'd ever paid. The IT lead found out when a tenant called to ask why someone had tried to open a credit card in her name.
That's not a sophisticated attack. It's a commodity attack that worked because nobody had decided, in advance, what to do when something felt wrong.
The window you actually have
Most small IT teams think incident response is what happens after you discover the breach. That is partially true, but the part that determines outcome happens in the first fifteen minutes after something strange occurs. Not strange as in 'the server is slow.' Strange as in 'this login came from Romania and our CFO is in a meeting ten feet from me' or 'someone just disabled our backup job and I didn't do it.'
In that window, your team makes decisions:
- Do we cut network access for this user right now, or wait to see what happens?
- Do we shut down this server, or leave it running to preserve logs?
- Who do we tell, and in what order?
If you have not made those decisions in advance, you will make them under pressure, with incomplete information, while wondering if you are overreacting. Attackers count on that hesitation. The MITRE ATT&CK framework documents this as Defense Evasion and Persistence—techniques designed specifically to make you doubt whether what you are seeing is actually hostile.
What compliance does not give you
A lot of small teams inherit incident response templates from compliance frameworks. ISO checklists, NIST guidelines, insurance questionnaires that ask 'do you have an incident response plan.' You can answer yes, and still have no functional readiness.
Compliance documentation tells you to have a plan. It does not tell you that your plan needs to account for the fact that your entire IT team is two people, one of whom is on vacation half the time, and your 'security contact' is a managed service provider who bills hourly and may not answer the phone at 7 p.m. on a Friday.
Real readiness means you have tested the plan with the actual people who will execute it, using the actual communication tools you will have access to during an incident. If your plan assumes you will all log into Slack to coordinate, but the attacker has already changed your Slack admin password, your plan is decorative.
The list that matters
Here is what a small IT team in Washington or Oregon needs to have written down and tested, not just documented:
Who has authority to make isolation decisions. If you see an active intrusion, can you disable a user account without calling someone first? Can you take a server offline? Write down who can make that call. If the answer is 'only the owner,' and the owner is unreachable, you have a decision bottleneck that will cost you hours. Contact information that is not in the compromised system. Phone numbers, personal emails, Signal handles—whatever gets you in touch with your responders when your email is locked or your VPN is down. Print it. Keep it somewhere physical. A communication channel you control. If you coordinate through Microsoft Teams and your Microsoft account is compromised, you have no way to coordinate. A separate channel—a group text, a shared phone bridge, anything outside your primary environment—gives you a fallback. Log locations and access steps. When you need to see what happened, where do you look? Not which system. Actual steps: 'Log into Azure Portal, navigate to Entra sign-in logs, filter by user, export last 72 hours.' If only one person knows how to do this, the plan breaks when that person is unavailable. A decision tree for the first fifteen minutes. Not a flowchart with twenty branches. Three or four decision points: If we see this, we do this. If the compromise appears to involve admin credentials, we do this immediately. If we are unsure, we call this person and execute this holding action while we assess.What testing actually means
Run a tabletop. Not a full simulation with actors and props. Just gather your IT team, describe a scenario—'We just got an alert that someone logged into our financial system from an IP in Latvia, what do we do right now'—and talk through the steps. You will discover gaps. You will find out that nobody knows where the firewall admin password is saved, or that your 'backup contact' changed jobs six months ago and nobody updated the sheet.
Do this twice a year. It takes ninety minutes.
What you are defending against
The attacks that hit small businesses in the Pacific Northwest are not novel. They are phishing emails that lead to credential theft, then MFA push fatigue until someone approves the login. They are unpatched VPN appliances that allow initial access. They are business email compromises that start with a spoofed domain one character off from your real one.
You are defending against attackers who are efficient, not creative. They succeed because small teams have not pre-decided how to respond when the efficient attack lands.
You do not need a security operations center. You need a tested plan and the authority to execute it when something is wrong.
Visit craftworkgrp.com/contact if you need help building a plan that works with the team you actually have.