HIPAA Technical Safeguards

This guide details each technical safeguard required by the HIPAA Security Rule and provides practical implementation guidance for SaaS and technology companies.

Key Takeaways

Quick Answer: Technical safeguards cover access controls (unique IDs, MFA, encryption), audit logging, data integrity, authentication, and transmission security. Most modern SaaS companies already implement many of these controls; the key is ensuring completeness, documentation, and alignment with HIPAA requirements.

Technical Safeguard Overview

The HIPAA Security Rule defines five technical safeguard standards:

Access Control (§164.312(a))

Access control is the foundation of ePHI protection. It ensures only authorized individuals can access health information.

Unique User Identification (Required)

Requirement: Assign a unique name and/or number for identifying and tracking user identity.

What this means:

• Every user has a unique identifier
• No shared accounts
• User actions can be tracked individually
• Identifiers aren't reused

Implementation:

1Requirements:
2- Unique username or ID for each user
3- Integration with identity provider (IdP)
4- User provisioning and deprovisioning processes
5- Tracking of all active user accounts
6
7Common approaches:
8- Email addresses as unique identifiers
9- Employee ID numbers
10- UUID-based user IDs
11- SSO with enterprise IdP

Common mistakes:

• Shared service accounts for applications
• Generic "admin" or "support" accounts
• Reusing identifiers after employee departure

Emergency Access Procedure (Required)

Requirement: Establish procedures for obtaining necessary ePHI during an emergency.

What this means:

• Define what constitutes an emergency
• Document how to access ePHI when normal processes fail
• Ensure availability during system outages
• Balance emergency access with security

Implementation:

1Emergency access plan should cover:
2- Definition of emergency situations
3- Break-glass procedures for emergency access
4- Logging of all emergency access
5- Post-emergency review process
6- Alternative access methods if primary fails
7
8Example scenarios:
9- Primary authentication system down
10- Key personnel unavailable
11- Disaster recovery situations
12- Urgent patient care needs

Automatic Logoff (Addressable)

Requirement: Implement electronic procedures that terminate sessions after inactivity.

What this means:

• Sessions timeout after period of inactivity
• User must re-authenticate to continue
• Prevents unauthorized access to unattended sessions

Implementation:

1Recommended configurations:
2- Web applications: 15-30 minute session timeout
3- API tokens: Short-lived (1 hour or less)
4- Admin sessions: 15 minutes or less
5- Workstation screen lock: 5-15 minutes
6
7Technical approaches:
8- Session timeout in application code
9- Idle timeout in identity provider
10- Screen lock policies on endpoints
11- Token expiration for APIs

If you determine this is not reasonable:

• Document the rationale
• Implement equivalent alternative measures
• Consider risk factors (workstation location, data sensitivity)

Encryption and Decryption (Addressable)

Requirement: Implement mechanisms to encrypt and decrypt ePHI.

What this means:

• Encrypt ePHI at rest
• Use appropriate encryption algorithms
• Manage encryption keys securely

Implementation:

1Encryption at rest:
2- Database encryption (AES-256)
3  - AWS RDS: Enable encryption
4  - GCP Cloud SQL: Enable encryption
5  - Azure SQL: Enable TDE
6- File storage encryption
7  - S3: Server-side encryption (SSE)
8  - GCS: Default encryption
9  - Azure Blob: Encryption at rest
10- Full disk encryption on endpoints
11  - macOS FileVault
12  - Windows BitLocker
13  - Linux LUKS
14
15Encryption standards:
16- AES-256 for symmetric encryption
17- RSA-2048+ for asymmetric encryption
18- Use cloud provider KMS for key management
19- Rotate keys according to policy

Key management considerations:

• Who has access to encryption keys?
• How are keys rotated?
• Where are keys stored?
• What happens if keys are compromised?

Audit Controls (§164.312(b))

Requirement: Implement hardware, software, and/or procedural mechanisms to record and examine activity in systems containing ePHI.

What to Log

Log Content Requirements

Each log entry should include:

1Required fields:
2- Timestamp (UTC, precise)
3- User identifier
4- Action performed
5- Resource accessed
6- Outcome (success/failure)
7- Source IP address
8
9Recommended fields:
10- Session identifier
11- User agent/client info
12- Geographic location
13- Request parameters (sanitized)
14- Response code

Log Storage and Protection

1Requirements:
2- Retain logs for 6 years (HIPAA documentation requirement)
3- Protect logs from tampering
4- Ensure logs are accessible when needed
5- Back up logs appropriately
6
7Implementation:
8- Centralized log aggregation (SIEM, log management)
9- Write-once or append-only storage
10- Separate access controls for log access
11- Encrypted log storage
12- Cross-region replication for durability

Log Review and Monitoring

1Processes:
2- Automated alerting for security events
3- Regular log review (daily/weekly)
4- Anomaly detection
5- Incident investigation using logs
6
7Alert triggers:
8- Multiple failed login attempts
9- Access outside normal hours
10- Large data exports
11- Admin actions
12- Access from new locations

Integrity (§164.312(c))

Standard: Implement policies and procedures to protect ePHI from improper alteration or destruction.

Mechanism to Authenticate ePHI (Addressable)

Requirement: Implement mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner.

Implementation:

1Data integrity controls:
2- Checksums or hashes for stored data
3- Digital signatures where appropriate
4- Database integrity constraints
5- Version control for records
6- Audit trail of modifications
7
8Validation approaches:
9- Input validation
10- Output encoding
11- Database constraints (foreign keys, check constraints)
12- Application-level validation
13
14Backup integrity:
15- Verify backup integrity regularly
16- Test restoration procedures
17- Checksums on backup files
18- Monitor for backup failures

Practical implementation:

• Use database transactions for data modifications
• Implement optimistic locking to prevent conflicts
• Log all data modifications with before/after values
• Regular integrity checks on stored data

Person or Entity Authentication (§164.312(d))

Requirement: Implement procedures to verify that a person or entity seeking access to ePHI is the one claimed.

Authentication Methods

Implementation Requirements

1User authentication:
2- Strong password policy (length > complexity)
3- Multi-factor authentication required
4- Account lockout after failed attempts
5- Password change procedures
6- Credential reset with identity verification
7
8System-to-system authentication:
9- API keys or tokens (short-lived)
10- Certificate-based authentication
11- OAuth 2.0 / OpenID Connect
12- Service accounts with minimal privileges
13- Regular credential rotation
14
15Best practices:
16- No plaintext password storage
17- Use bcrypt, scrypt, or argon2 for password hashing
18- Implement rate limiting on authentication endpoints
19- Monitor and alert on suspicious authentication patterns

MFA Implementation

1MFA requirements:
2- Required for all ePHI access
3- Required for administrative access
4- Backup authentication methods available
5- MFA enrollment process documented
6
7MFA options:
8- Authenticator apps (Google Authenticator, Authy)
9- Hardware security keys (YubiKey, Titan)
10- Push notifications (Duo, Okta Verify)
11- SMS (less secure, acceptable as backup)
12
13Configuration:
14- Enable MFA at identity provider level
15- Enforce MFA for all users, not just admins
16- Require MFA re-enrollment periodically
17- Monitor for MFA bypass attempts

Transmission Security (§164.312(e))

Standard: Implement technical security measures to guard against unauthorized access to ePHI transmitted over electronic communications networks.

Integrity Controls (Addressable)

Requirement: Implement security measures to ensure that electronically transmitted ePHI is not improperly modified without detection until disposed of.

Implementation:

• TLS provides integrity through MAC (Message Authentication Code)
• Application-level checksums where appropriate
• Digital signatures for critical data

Encryption (Addressable)

Requirement: Implement a mechanism to encrypt ePHI whenever deemed appropriate.

Implementation:

1In-transit encryption requirements:
2- TLS 1.2 or higher for all connections
3- HTTPS required, HTTP rejected
4- Strong cipher suites only
5- Certificate validation
6
7Web application:
8- HTTPS everywhere (no mixed content)
9- HSTS headers
10- Secure cookies (Secure, HttpOnly, SameSite)
11- Certificate pinning for mobile apps
12
13API security:
14- TLS required for all API endpoints
15- Mutual TLS (mTLS) for service-to-service
16- API authentication required
17- Rate limiting and throttling
18
19Email:
20- Avoid PHI in email when possible
21- Use secure messaging platforms
22- If email necessary, use encryption (S/MIME, PGP)
23- Consider email alternatives for PHI
24
25File transfer:
26- SFTP, SCP, or HTTPS for file transfers
27- No FTP, Telnet, or unencrypted protocols
28- Encrypted file containers if needed

TLS configuration best practices:

1Supported protocols:
2- TLS 1.3 (preferred)
3- TLS 1.2 (minimum)
4- TLS 1.1, 1.0, SSL: DISABLED
5
6Cipher suites (example for TLS 1.2):
7- ECDHE-RSA-AES256-GCM-SHA384
8- ECDHE-RSA-AES128-GCM-SHA256
9- Avoid: RC4, DES, 3DES, MD5
10
11Certificate requirements:
12- 2048-bit RSA or 256-bit ECC minimum
13- SHA-256 or stronger hash
14- Valid certificate chain
15- Not expired or revoked

Technical Safeguards Checklist

Access Control

• Unique user identification implemented
• No shared accounts
• Emergency access procedures documented
• Automatic session timeout configured
• Encryption at rest implemented
• Key management procedures documented

Audit Controls

• Logging enabled on all ePHI systems
• Authentication events logged
• Data access logged
• Administrative actions logged
• Logs retained for 6+ years
• Log monitoring and alerting implemented
• Regular log review process

Integrity

• Data validation implemented
• Database integrity constraints in place
• Modification audit trail maintained
• Backup integrity verified
• Checksums/hashes used where appropriate

Authentication

• Strong authentication implemented
• MFA required for ePHI access
• MFA required for admin access
• Password policy enforced
• System-to-system authentication secure
• Credential rotation procedures

Transmission Security

• TLS 1.2+ required for all connections
• HTTPS enforced, HTTP rejected
• Strong cipher suites configured
• Certificate management procedures
• Internal traffic encrypted where appropriate

Common Technical Safeguard Gaps

Gap 1: Inadequate Logging

Problem: Logging exists but doesn't capture enough detail for audit.

Solution: Review logs against requirements, add missing event types, ensure retention meets 6-year requirement.

Gap 2: MFA Not Universal

Problem: MFA only required for some users or systems.

Solution: Require MFA for all users accessing ePHI, including developers and support staff.

Gap 3: Development Environment Access

Problem: Developers have production ePHI access for debugging.

Solution: Use de-identified data in development, implement proper data masking, restrict production access.

Gap 4: Service Account Management

Problem: Service accounts with broad access, no rotation.

Solution: Implement least privilege for service accounts, regular credential rotation, monitoring of service account usage.

Gap 5: Legacy Systems

Problem: Older systems don't support modern encryption or authentication.

Solution: Isolate legacy systems, implement compensating controls, plan for modernization.

How Bastion Helps

Bastion helps technology companies implement technical safeguards:

• Gap assessment: Identify missing or inadequate controls
• Implementation guidance: Configure controls correctly
• Architecture review: Ensure security architecture supports HIPAA
• Documentation: Document implementations and decisions
• Validation: Verify controls work as intended

Ready to strengthen your technical safeguards? Talk to our team

Sources

• HIPAA Security Rule Technical Safeguards - Official HHS guidance
• NIST SP 800-66 - Implementing the HIPAA Security Rule
• NIST Cybersecurity Framework - Complementary security framework