← The Craftwork Group  ·  Blog

IT security for Pacific Northwest businesses

IT Security for Pacific Northwest Businesses

By Dana Holt · The Craftwork Group · Published 2026-06-11

IT security for Pacific Northwest businesses comes down to one question your provider should be able to answer: what happens in your specific environment when one employee clicks the wrong link? If the answer is vague, the controls are probably vague too.

How do I know if my IT provider is actually protecting us or just selling us tools?

I keep seeing businesses handed a "security roadmap" that is fourteen pages of vendor product sheets with no context for their environment. No explanation of what problem each tool solves or what attack it prevents. Just features and pricing. A reasonable question follows: how do we know what we actually need? You cannot answer that from a product brochure, and neither can I.

Here is what useful guidance looks like. Your IT provider should be able to tell you what would happen if an employee clicked a credential-harvesting link tomorrow morning. Not theoretically. In your environment, with your current controls, on a Tuesday when people are working from the office or home or a coffee shop in Fremont. Can the attacker pivot from that one mailbox to your file server? How long would it take you to notice? If the answer is "we have antivirus," that is not an answer. Antivirus stops known malware. It does not stop an attacker who has valid credentials and is behaving like a legitimate user who happens to be downloading everything at 3am.

What attack patterns are actually targeting businesses in this region?

The pattern we see most against businesses in the Pacific Northwest is straightforward. Phishing email, credential capture, MFA fatigue where push notifications keep coming until the user approves one out of annoyance, then quiet persistence while the attacker maps your network and identifies what is worth taking. They are not breaking in through firewalls. They are logging in as you.

The controls that matter:

Your IT provider should be able to show you whether these are configured and actually firing. Not just enabled. Firing.

Imagine a firm that has Microsoft 365 with every security SKU. On paper, fully licensed. But when you review the conditional access rules, you find three policies: two in report-only mode, one applying only to guest users. No employees subject to device compliance checks. An attacker with a username and password can log in from any device, anywhere, and reach everything. The business is paying for controls that are not controlling anything. That is not a licensing problem. It is a configuration problem. It is common.

Why doesn't a compliance checklist count as a security plan?

Compliance frameworks like CIS Controls or NIST CSF are useful as structure. They are not predictive of whether an attack succeeds against you. I keep seeing environments that were fully compliant with their industry framework and would have folded in hours against a mid-skill attacker who got one set of credentials. The documented policy said MFA was required. The actual configuration allowed legacy authentication protocols that bypassed MFA entirely. Compliance said yes. Security said no. Your provider should be testing both. Compliance is the paperwork. Security is the control that actually says no. They are not the same thing.

What should I actually expect from a local IT provider in Washington or Oregon?

Understanding of how local businesses actually operate. A Seattle law firm works differently from a Spokane HVAC contractor. The attorney is mobile, working from courthouse networks and client offices. The HVAC contractor has techs in trucks with tablets accessing work orders and customer data from job sites across the county. The controls that make sense for one do not automatically translate to the other.

What non-negotiable looks like in each case:

Your provider should be designing controls around your actual risk surface, not a generic template. That is what our managed IT and security work is built for.

What does real incident response planning look like compared to "we monitor your systems"?

Monitoring generates alerts. Somebody has to decide what those alerts mean and what to do about them. When your file server starts encrypting files at 9pm on a Saturday, what is the actual process? Who gets called? What gets disconnected? How do you communicate with staff Monday morning if your email is offline? If your provider cannot walk you through that sequence, you do not have a plan. You have a subscription to a dashboard.

Pacific Northwest businesses tend to be pragmatic and cost-conscious. That is reasonable. But treating security as optional because you are not a Fortune 500 target is not. You are not too small. You are profitable enough, and your customer data is valuable enough. The attacker does not care about your revenue. They care about your surface. If you are easier than the firm across the street, you are the target.

I have been doing this work since the late 1990s, and the gap between what businesses think their controls do and what those controls actually do under pressure is still the most consistent finding. You can close that gap without rebuilding everything. But you have to look at it first.

If your current provider cannot explain what would happen during an actual attack in your actual environment, schedule a conversation with us and we will walk through your configuration together.