The technical safeguards in the HIPAA Security Rule were written in general terms, for hospitals and health plans as much as for software companies. Read from inside a SaaS company, they raise questions the text does not answer directly. Whose users does "unique user identification" cover? Is a session timeout in your product your obligation or your customer's? Does a database snapshot in another region count?
This article reads each technical safeguard in 45 CFR 164.312 from the position of a SaaS business associate. It covers what each standard asks, how it lands in a multi-tenant product, and where ePHI tends to leak outside the systems you thought were in scope. For how the technical safeguards relate to the administrative and physical ones, see the three safeguard types.
Two populations of users
Every SaaS company that handles ePHI has two groups of people with access to it, and the technical safeguards apply to each differently.
Your workforce. Engineers, support staff, and anyone else who can reach production data. These are your users in the Security Rule's sense. You choose their identity system, their authentication, and their permissions, and you answer for all of it.
Your customers' users. Clinicians, billing staff, and administrators who log in to your product. They are your customer's workforce, not yours. Your customer, the covered entity, is responsible for who gets access and what they can see. But they can only meet their obligations if your product gives them the means: individual accounts, configurable timeouts, audit trails, and access controls fine enough to match their policies.
Keep the two apart in your documentation. A security questionnaire that asks about "automatic logoff" may mean your admin console, your customer-facing product, or both. Answer for each.
Access control
The access control standard requires technical policies and procedures that allow access to ePHI only to people or software programs that have been granted access rights. It has four implementation specifications.
Unique user identification (required). Every person gets their own identifier, so activity can be traced to them. For your workforce, that rules out shared admin accounts and shared database credentials. Service accounts are fine if each one is named, owned, and used by one workload. In your product, it means individual logins for every customer user, never one shared practice account.
Emergency access procedure (required). You need a documented way to reach necessary ePHI during an emergency. For a SaaS team this is usually a break-glass account or role: stored securely, used only under defined conditions, alerting when used, and reviewed afterward. The procedure matters as much as the account. Write down who may invoke it and what record they leave.
Automatic logoff (addressable). Electronic sessions end after a predetermined period of inactivity. Set it for your internal tools and production access. In your product, give customers a setting and choose a sensible default, because many customers will never change it.
Encryption and decryption (addressable). This is encryption at rest. It is addressable, but declining it for a system that stores ePHI needs a documented reason and an equivalent alternative, and that is hard to defend when your cloud provider offers storage encryption as a configuration option. Cover the places that get forgotten: snapshots, replicas, backups, object storage exports, and search indexes.
Least privilege for your own staff sits under this standard too. Production access to customer data should be granted per task and expire, not held standing by every engineer. Managing privileged access covers the patterns.
Audit controls and integrity
Audit controls (required) are hardware, software, or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. The standard has no implementation specifications and names no retention period, which leaves the design to you and your risk analysis.
For a SaaS product, there are two audit trails to build. One records your workforce's access to production systems and customer data. The other records customer users' activity in your product, such as who viewed or changed which record. Healthcare customers will ask for the second, because they need it to investigate their own users.
Recording is half the standard. Examining is the other half, and the administrative safeguards separately require regular review of activity records. A log nobody reviews meets neither.
Integrity requires policies and procedures to protect ePHI from improper alteration or destruction. The addressable specification asks for electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner. In practice that means database constraints, checksums on stored files, version history for clinical records, and change controls on anything that writes to them.
Person or entity authentication
This required standard asks for procedures to verify that a person or entity seeking access to ePHI is the one claimed. The current text does not mention multi-factor authentication.
That does not settle the question. Passwords alone are a weak answer to "verify," and your risk analysis has to explain why the method you chose is reasonable. For workforce access to production, multi-factor authentication is the expected answer, and enforcing MFA for every user covers how to get there without exceptions piling up. For your product, offer MFA and single sign-on to customers, so they can apply their own policies.
HHS has proposed Security Rule changes that would make specific controls, multi-factor authentication among them, more explicit. A proposal is not the current rule. Check its status before you cite it either way.
Transmission security
Transmission security requires technical measures to guard against unauthorized access to ePHI sent over an electronic communications network. Both implementation specifications, integrity controls and encryption, are addressable.
For a SaaS product, the obvious part is TLS on every external endpoint. The less obvious parts are internal: traffic between services, connections to managed databases, replication between regions, and calls to third-party APIs. Also check outbound channels your product uses to reach patients or customers, such as email notifications, SMS, file exports, and webhooks. Each one is a transmission of ePHI if the payload contains it.
Where ePHI escapes your scope
The technical safeguards are usually designed around the production database. ePHI rarely stays there. These are places a SaaS team commonly finds it during a careful inventory:
Application logs. Request bodies, error messages, and debug output that include patient data, shipped to a logging service with broad access.
Non-production environments. Copies of production data in staging or on a developer's machine, without production's controls.
Support tooling. Screenshots, attachments, and ticket text pasted from the product into a help desk.
Analytics and product telemetry. Event properties that carry record identifiers or free text.
Data exports and reports. Files customers download, or files your team generates for them, sitting in shared storage.
Third-party services. Email delivery, error tracking, and AI or search APIs that receive ePHI in a payload.
Each of these is a system that creates, receives, maintains, or transmits ePHI. Each needs the same safeguards, or a decision to keep ePHI out of it. Keeping it out is often cheaper: scrub logs at the source, use synthetic data outside production, and send identifiers rather than content to analytics. Any third-party service that does receive ePHI needs a business associate agreement.
The evidence a buyer or investigator expects
The rule names safeguards, not artifacts, so expect to assemble these yourself:
Identity provider configuration showing individual accounts and MFA enforcement for production access.
The break-glass procedure, and the log of each time it was used.
Session timeout settings for internal tools and the product default.
Encryption configuration for every data store, backup, and replica that holds ePHI.
Sample audit log entries for workforce and customer activity, plus records showing someone reviews them.
TLS configuration for external endpoints and internal service traffic.
The data flow inventory that shows where ePHI goes, including logs and third parties.
For every addressable specification you did not implement as written, the documented reasoning and the alternative measure.
The HIPAA framework page lists each technical standard and its implementation specifications.
How TrustLynce helps
TrustLynce collects configuration evidence from your cloud, identity, and code systems on a schedule, timestamped and attributed (evidence collection). Continuous monitoring checks controls such as storage encryption and MFA enforcement between collections and routes each failure to its owner.