A $4.3 Million Penalty That Started with a Missing Safeguard

In 2016, the University of Texas MD Anderson Cancer Center lost an unencrypted laptop and two USB drives containing patient data. The OCR investigation didn't just find careless employees — it found a covered entity that had written encryption policies but never actually implemented them. The result was a $4.3 million penalty that an administrative law judge upheld on appeal.

The lesson? Knowing what technical safeguards are is not the same as deploying them. And regulators will check the difference.

If you've landed on this page, you're probably asking a straightforward question: technical safeguards are: what, exactly? I've spent years helping organizations untangle HIPAA's Security Rule, and I can tell you this — these safeguards are where policy meets technology, and where most breaches actually happen.

Technical Safeguards Are: The Technology Controls Protecting ePHI

Under the HIPAA Security Rule at 45 CFR § 164.312, technical safeguards are the technology and the policies and procedures governing its use that protect electronic protected health information (ePHI) and control access to it.

That's the regulatory language. Here's what it means in practice: technical safeguards are the digital locks, alarm systems, and surveillance cameras on your ePHI. They're the mechanisms built into your systems — not the physical doors or the HR policies, but the actual technology-driven controls.

HHS breaks technical safeguards into five standards. Each one carries specific implementation specifications — some required, some addressable. Let's walk through every one.

The Five Standards That Make Up Technical Safeguards

1. Access Controls (§ 164.312(a)(1))

Access controls are the front door. They determine who gets into your systems and what they can see once inside. This standard has four implementation specifications:

  • Unique User Identification (Required): Every person who touches ePHI must have a unique login. No shared accounts. No generic "front desk" credentials. I've seen clinics with six staff members all logging in as "admin1." That's a violation waiting to become a breach.
  • Emergency Access Procedure (Required): You need a documented method for accessing ePHI during an emergency — a system crash, a ransomware attack, a natural disaster. If your only copy of patient data is locked behind a downed server and nobody knows the backup protocol, patients suffer.
  • Automatic Logoff (Addressable): Systems should terminate sessions after a period of inactivity. "Addressable" doesn't mean optional. It means you must implement it or document why an equivalent alternative is reasonable.
  • Encryption and Decryption (Addressable): Encrypt ePHI. MD Anderson learned this the hard way. If you choose not to encrypt, your risk analysis better explain why — and your alternative better be bulletproof.

2. Audit Controls (§ 164.312(b))

Audit controls are your system's memory. They record who accessed what, when, and from where. This is a required specification with no wiggle room.

In my experience, most small practices install EHR systems and never look at the audit logs. That's like installing security cameras and throwing away the footage. When OCR investigates a breach, audit logs are one of the first things they request. If you can't produce them — or if they show that nobody was monitoring them — you've got a problem.

Review your logs regularly. Set up alerts for unusual access patterns. A billing clerk accessing oncology records at 2 a.m. should trigger a flag.

3. Integrity Controls (§ 164.312(c)(1))

Integrity controls ensure that ePHI hasn't been altered or destroyed in an unauthorized manner. The implementation specification here is a mechanism to authenticate ePHI — confirming that data hasn't been tampered with during storage or transmission.

Think checksums, hash verification, and digital signatures. If a lab result changes between the sending system and the receiving system, integrity controls catch it. Without them, you can't trust your own data.

4. Person or Entity Authentication (§ 164.312(d))

This standard requires you to verify that the person or entity seeking access to ePHI is actually who they claim to be. It's a required specification.

Passwords alone don't cut it anymore. Multi-factor authentication — something you know, something you have, something you are — has become the industry standard. A password plus a token or biometric scan. I've watched organizations resist MFA because staff complained about the extra step. Then I've watched those same organizations explain to OCR how a stolen password led to a breach of 50,000 records.

5. Transmission Security (§ 164.312(e)(1))

When ePHI moves — across a network, through email, over the internet — it needs protection. Transmission security has two implementation specifications:

  • Integrity Controls (Addressable): Ensure data isn't modified during transmission.
  • Encryption (Addressable): Encrypt ePHI in transit. TLS 1.2 or higher is the current expectation. If you're still running unencrypted email containing patient information, you're exposed.

"Addressable" keeps coming up. Let me be blunt: in 2026, there is almost no defensible reason to skip encryption. The cost of encryption tools has plummeted. The risk of not encrypting is enormous. Treat addressable specifications as required unless you have an extraordinarily well-documented reason not to.

What Exactly Are Technical Safeguards in HIPAA?

Technical safeguards are the subset of HIPAA Security Rule requirements that specifically address the technology used to protect ePHI. They cover access controls, audit trails, data integrity verification, user authentication, and transmission security. Unlike administrative safeguards (policies) or physical safeguards (facility protections), technical safeguards live inside your software, hardware, and network infrastructure. Every covered entity and business associate must implement them.

The Mistake I See Most Often

Organizations treat technical safeguards as an IT project. They hand the Security Rule to their network administrator and say, "Handle this." That's a recipe for gaps.

Technical safeguards require collaboration between IT, compliance officers, and executive leadership. Your IT team can configure access controls, but someone in compliance needs to define who should have access to what. Leadership needs to fund the tools. And your entire workforce needs training on how these safeguards work in daily practice.

That's why comprehensive HIPAA training for your workforce isn't a nice-to-have. It's the connective tissue between a technical safeguard existing and a technical safeguard working. The best encryption in the world fails if an employee shares their login credentials on a sticky note.

Real Enforcement: What Happens When Technical Safeguards Fail

The OCR enforcement database is full of cases where technical safeguard failures led to massive penalties:

  • Anthem, Inc. (2018): A $16 million settlement — the largest HIPAA penalty in history at the time — after hackers breached 78.8 million records. OCR found failures in access controls, audit controls, and technical policies. Read the resolution agreement.
  • Premera Blue Cross (2020): A $6.85 million settlement after a breach affecting over 10.4 million people. Insufficient access controls and failure to conduct adequate technical evaluations were key findings.

These aren't abstract scenarios. They're the direct consequences of ignoring the standards spelled out in § 164.312.

How to Audit Your Technical Safeguards Right Now

Here's a practical checklist I use with clients. Walk through it this week:

  • Unique logins: Does every single user — including temps, volunteers, and contractors — have an individual account?
  • MFA: Is multi-factor authentication enabled on all systems that touch ePHI?
  • Encryption at rest: Are databases, laptops, mobile devices, and removable media encrypted?
  • Encryption in transit: Is ePHI transmitted via TLS 1.2 or higher? Are unencrypted email channels still in use?
  • Audit log review: When was the last time someone actually reviewed access logs? Is there a schedule?
  • Automatic logoff: Do workstations lock after inactivity? What's the timeout setting?
  • Integrity mechanisms: Do you verify that ePHI hasn't been altered during storage or transmission?
  • Emergency access: Is there a documented and tested procedure for accessing ePHI during system outages?

If you can't answer "yes" to all of these, you've found your next compliance project.

Technical Safeguards Don't Work Without Trained People

I keep coming back to this because it's the gap that sinks organizations. You can deploy every technical control on the market, but if your receptionist clicks a phishing link or your physician uses an unauthorized cloud app to share patient notes, the safeguards collapse.

HIPAA's Security Rule explicitly ties technical safeguards to "the policies and procedures for their use." That means documentation and training are embedded in the requirement itself. Explore the full range of HIPAA compliance training options to make sure your team understands these controls — not just your IT department.

The Bottom Line on Technical Safeguards

Technical safeguards are the technological core of HIPAA compliance. They're not suggestions. They're not aspirational goals. They are specific, enforceable requirements that OCR will examine when — not if — a breach occurs.

The organizations that get this right treat technical safeguards as a living system: implemented, monitored, tested, and updated. The ones that get it wrong treat them as a checkbox from five years ago.

Don't be the next case study on the HHS enforcement highlights page. Know what your technical safeguards are, verify they're working, and make sure every person in your organization understands their role in keeping them intact.