IT Guidance for Compliance Clients in the Pacific Northwest

I work with organizations in Washington and Oregon that face compliance requirements they did not budget for and do not fully understand. A healthcare clinic in Tacoma gets a HIPAA inquiry. A credit union in Eugene renews cyber insurance and the questionnaire now asks eighteen questions about endpoint detection instead of three. A law firm in Seattle signs a Fortune 500 client whose contract includes a security addendum requiring annual SOC 2 attestation. The compliance landscape shifted while these organizations were running their operations. What worked three years ago does not work now.

The Pacific Northwest has a particular regulatory mix. Washington's My Health My Data Act applies to any organization that collects health data, not just covered entities under HIPAA. Oregon's consumer privacy law took effect in July 2024. If you process data for Oregon residents, you are subject to it regardless of where your office is located. The FTC Safeguards Rule applies to any business that touches consumer financial information — not just banks, but also auto dealers, mortgage brokers, accountants who prepare tax returns. These are not theoretical obligations. They are enforceable frameworks with documented consequences for noncompliance.

Most organizations I meet do not have a compliance problem. They have an evidence problem. They believe they are doing the right things, and in many cases they are. But belief is not what an auditor or a regulator will accept. An auditor will ask for documented controls with implementation dates, screenshots showing the control in operation, logs that demonstrate monitoring, and records of testing or review. If those do not exist, the control does not exist in the auditor's view. That is the gap.

Here is what evidence looks like in practice. MFA is a control. Enabling MFA in your admin console is a step toward implementation. Full implementation means MFA is enforced for all users, there is no opt-out path, the enforcement is documented with a date, and you have a process to review exceptions if they exist. Evidence would include the policy that defines the requirement, the configuration screenshot showing enforcement, and the access review logs that confirm no unauthorized exceptions. That is one control. Compliance frameworks ask for dozens.

Organizations in the Pacific Northwest tend to operate with small internal IT teams or no dedicated IT staff at all. A law firm with twelve attorneys does not employ a full-time security engineer. A medical practice with two locations does not have a compliance officer. They rely on outside providers to build and maintain their IT posture, and that reliance creates a responsibility gap when compliance comes up. The provider may have implemented strong technical controls, but if those controls are not documented in a way that satisfies an auditor, the organization is still exposed. Documentation is not overhead. It is the artifact that proves the control exists.

What we do at TCG is close that gap before it becomes a finding. When a new client comes to us with a compliance requirement, we start by mapping what they actually have in place to what the framework requires. This is not a sales audit. It is a technical inventory. Endpoint protection: what is deployed, what is it logging, where are those logs going, who reviews them, how often. Access controls: who has admin rights, when were those rights last reviewed, is there a documented process for onboarding and offboarding. Backups: what is the schedule, where is the offsite copy, when was the last restore test. Encryption: at rest, in transit, key management. Incident response: is there a written plan, has it been tested, who owns it.

From that inventory, we build an implementation plan that addresses the gaps. But implementation alone does not close the loop. The second piece is documentation that will survive a review. That means policies that describe controls, screenshots that show configuration, logs that demonstrate monitoring, and evidence of testing or review on a defined schedule. The third piece is ongoing operation. Compliance is not a one-time certification. It is a continuous posture. Access reviews have to happen quarterly. Policies have to be updated when the environment changes. Logs have to be reviewed and findings addressed. An auditor will ask to see evidence of that continuity, not just evidence of initial setup.

I am not an auditor and I do not attest compliance. What I do is help organizations build a defensible posture and the evidence trail that supports it. When an auditor shows up, or when a regulator sends an inquiry, or when a customer asks for proof of controls, there is something substantive to provide. That is the difference between a posture that holds up under scrutiny and a posture that falls apart when tested.

If you are facing a compliance requirement and you are not certain your current environment would survive an audit, that is the conversation we should have. Contact us at craftworkgrp.com.