What SOC 2 and HIPAA Actually Require From Your IT Environment

"We need to be SOC 2 compliant" or "our HIPAA obligations require X" are sentences we hear constantly from clients who are right about the goal and fuzzy on the specifics. Neither framework hands you a checklist of software to install, they describe outcomes, and it's up to your environment to demonstrate you meet them. Here's what that translates to in practice.

HIPAA: it's about the safeguards, not a single tool

HIPAA's Security Rule organizes requirements into three categories, and each one maps to concrete IT decisions:

• Administrative safeguards: documented security policies, workforce training, and a designated security officer, this is process, not infrastructure, but auditors will ask your IT team to prove the process is followed technically (e.g., access is actually revoked on termination, not just policy-stated).
• Physical safeguards: controlled access to servers and workstations that handle patient data, relevant even in cloud environments, where it shifts to your cloud provider's data center certifications.
• Technical safeguards: this is where most IT work lives, access controls (unique user IDs, role-based permissions), audit logging of who accessed what patient data and when, encryption of data at rest and in transit, and automatic logoff for idle sessions.

In practice, HIPAA compliance for a typical healthcare client means: encrypted email for anything containing patient data, role-based access so front-desk staff can't see clinical notes they don't need, audit logs retained and reviewable, and a documented incident response plan specifically covering breach notification timelines.

SOC 2: trust criteria, demonstrated with evidence

SOC 2 is built around five "trust services criteria", security, availability, processing integrity, confidentiality, and privacy, though most audits focus heavily on security plus whichever others apply to your business. Unlike HIPAA, SOC 2 isn't a legal requirement; it's a voluntary attestation your customers increasingly demand before they'll sign a contract.

• Security: firewalls, endpoint detection, vulnerability management, and, critically, evidence that these controls actually ran, not just that they exist on paper.
• Availability: documented uptime commitments, backup and disaster recovery procedures, and monitoring that proves you'd notice an outage.
• Confidentiality: data classification and encryption for anything marked confidential in a client agreement.

Both frameworks care less about which tools you bought and more about whether you can prove the controls ran, consistently, over time.

The infrastructure decisions that satisfy both

Despite covering different industries, HIPAA and SOC 2 converge on a similar technical baseline:

1. Multi-factor authentication enforced on all accounts with access to sensitive data
2. Role-based access control, reviewed periodically, not set once and forgotten
3. Centralized logging with retention long enough to support an audit or investigation
4. Encryption at rest and in transit for regulated or confidential data
5. A documented, tested incident response and disaster recovery plan
6. Regular vulnerability scanning with a defined remediation timeline

The part that trips businesses up: evidence, not intent

Auditors don't take your word for it. They want screenshots, log exports, signed policy acknowledgments, and dated test results. A business that has all the right controls but no record of them running consistently will still fail an audit. This is why compliance advisory work is as much about documentation discipline as it is about technical configuration.

Where to start if you're behind

Begin with a gap assessment against the specific framework you need, HIPAA and SOC 2 overlap heavily but aren't identical. From there, prioritize access control and logging first (they're foundational to almost every other control), then build out the documented policies and testing cadence that turn "we have security" into "we can prove it."