The HIPAA Security Rule Explained: 9 Technical Safeguards Your Cloud Infrastructure Must Have

Your health system enterprise customer just sent you a 60-question security questionnaire. Questions 23 through 41 are specifically about your HIPAA Security Rule technical safeguard implementation. Your CTO opened it, spent 45 minutes googling "HIPAA technical safeguards AWS," and sent it to you.

This guide is the answer to that document — written for engineers and technical leaders who need precise, implementable guidance, not regulatory summary.

The HIPAA Security Rule (45 CFR Part 164, Subpart C) requires all covered entities and business associates to implement technical safeguards protecting electronic Protected Health Information (ePHI). Some specifications are required — you must implement them. Others are addressable — you must assess whether they are reasonable and appropriate for your organization and either implement them or document an equivalent alternative measure.

Here is exactly what each safeguard requires, and what it looks like implemented in AWS, GCP, and Azure.

The 5 Technical Safeguard Standards

The HIPAA Security Rule § 164.312 defines five technical safeguard standards, each with required and/or addressable implementation specifications:

Access Controls (§ 164.312(a)(1))
Audit Controls (§ 164.312(b))
Integrity (§ 164.312(c)(1))
Person or Entity Authentication (§ 164.312(d))
Transmission Security (§ 164.312(e)(1))

Within these five standards, there are nine distinct implementation specifications — some required, some addressable.

Safeguard 1: Unique User Identification

Regulation: § 164.312(a)(2)(i) — Required Standard: Access Controls

What the regulation requires: Assign a unique name and/or number for identifying and tracking user identity.

This is the foundational access control requirement: every person or system that accesses ePHI must have a unique identifier. Shared accounts (e.g., a shared "admin" login used by multiple engineers) are non-compliant.

Implementation

AWS:

Create individual IAM users for all personnel (not service accounts) — never share root account credentials
Enforce IAM Identity Center (formerly AWS SSO) for human user access to AWS Console and APIs
Implement unique service account identities using IAM roles (not IAM users for services)
Use Amazon Cognito or Auth0 for application-level user identity in your product

GCP:

All users must authenticate with individual Google accounts (not shared credentials)
Use Workload Identity Federation for service-to-service authentication (eliminates shared service account keys)
Cloud Identity for workforce identity management
Implement unique service accounts per workload/service — never share service accounts across applications

Azure:

Every user accesses resources through their individual Azure Active Directory / Microsoft Entra ID account
Managed Identities for Azure resources (eliminates shared credentials for service-to-service authentication)
Azure Privileged Identity Management (PIM) for just-in-time privileged access with full audit trails

Evidence for auditors: IAM user list showing individual accounts, access logs showing user-level attribution for all ePHI access events.

Safeguard 2: Emergency Access Procedure

Regulation: § 164.312(a)(2)(ii) — Required Standard: Access Controls

What the regulation requires: Establish and implement necessary procedures for obtaining necessary ePHI during an emergency.

This requires a documented, tested procedure for accessing ePHI when normal authentication mechanisms are unavailable (e.g., identity provider outage, MFA device lost during an emergency).

Implementation

Document a break-glass access procedure with specific steps, approvals required, and logging requirements
Store emergency credentials in a sealed vault (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) with access alerts
Require dual-person authorization for emergency access initiation (requires two named individuals to approve)
Configure real-time alerting when emergency credentials are accessed
Require full documentation of the incident, the access taken, and post-incident review

Engineering implementation: Create a dedicated AWS IAM role or GCP service account with emergency access permissions. Enable CloudTrail/Cloud Audit Logs alerting via SNS/Pub Sub or EventBridge when this role is assumed. Restrict assumption of the role to a specific named group requiring MFA approval.

Safeguard 3: Automatic Logoff

Regulation: § 164.312(a)(2)(iii) — Addressable Standard: Access Controls

What the regulation requires: Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.

For addressable specifications, you must assess whether implementation is reasonable and appropriate. For most SaaS companies handling ePHI, automatic session termination is clearly appropriate.

Implementation

Application level: Configure session timeouts in your application. Best practice: 15-minute inactivity timeout for clinical applications, 30 minutes for administrative applications. Implement re-authentication (not just session extension) after timeout.

AWS Console: Set maximum session duration for IAM roles used for console access. AWS Organizations SCPs can enforce maximum session durations across all accounts.

GCP Console: Set Cloud Identity session duration policies under Admin Console → Security → Session Control.

Azure Portal: Azure Conditional Access session controls set maximum sign-in frequency and persistent browser session policies.

Workstation level: Enforce screen lock after 5–15 minutes inactivity via MDM (Jamf for macOS, Intune for Windows). Document this in your workstation use policy.

Safeguard 4: Encryption and Decryption

Regulation: § 164.312(a)(2)(iv) — Addressable Standard: Access Controls

What the regulation requires: Implement a mechanism to encrypt and decrypt ePHI.

Despite being "addressable," encryption of ePHI at rest is essentially a required standard in practice. HIPAA's Breach Notification Rule provides a safe harbor for breaches of encrypted data — if your ePHI is properly encrypted and you control the keys, a data breach may not trigger notification obligations. No reasonable HIPAA implementation leaves ePHI unencrypted.

Encryption at Rest Implementation

AWS:

RDS: Enable encryption at instance creation (cannot be added post-creation without snapshot migration). Use AWS KMS CMK (Customer Managed Key) not AWS managed key, for full key control
S3: Enable SSE-KMS (Server-Side Encryption with KMS) on all buckets containing ePHI. Enforce via S3 Bucket Policy (deny PutObject without encryption header)
EBS volumes: Enable EBS encryption by default at the AWS account level (Settings → EC2 → EBS Encryption)
DynamoDB: Encryption at rest enabled by default using AWS owned key; upgrade to CMK for enhanced control
Secrets Manager: Encrypted at rest using KMS by default
Enable KMS key rotation (annual rotation minimum)

GCP:

Cloud Storage: Enable Customer-Managed Encryption Keys (CMEK) for all buckets containing ePHI via Cloud KMS
Cloud SQL: Enable CMEK for Cloud SQL instances at creation
BigQuery: Enable CMEK for all ePHI-containing datasets
Compute Engine: Enable disk encryption with CMEK for all VMs accessing ePHI

Azure:

Azure SQL Database: Transparent Data Encryption (TDE) enabled by default; use Customer-Managed Keys in Azure Key Vault for enhanced control
Azure Blob Storage: Storage Service Encryption enabled by default; configure Customer-Managed Keys via Key Vault
Azure Disk Encryption: Use Azure Disk Encryption (BitLocker for Windows, DM-Crypt for Linux) for all VMs
Azure Key Vault: Manage all encryption keys with automatic rotation policies

NIST-approved encryption standard: AES-256 for data at rest is the accepted standard. NIST SP 800-111 governs storage encryption.

Safeguard 5: Audit Controls

Regulation: § 164.312(b) — Required Standard: Audit Controls

What the regulation requires: Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI.

This is one of the most specific and auditor-scrutinized technical safeguards. You must log who accessed ePHI, when, from where, and what they did — and you must retain those logs and have a process for reviewing them.

Implementation

Application-level audit logging: Your application must generate structured audit logs for every ePHI access event. At minimum, each log record should capture:

Timestamp (UTC, synchronized via NTP)
User identifier (unique user ID, not username — which can be reused)
Action performed (read, create, update, delete, export)
Resource accessed (patient record ID, document ID)
Outcome (success, failure)
Source IP address

This is application code — your engineers must implement it. No cloud service provides application-level audit logging automatically.

Infrastructure-level audit logging:

AWS:

AWS CloudTrail: Enable in all regions, all accounts, with log file validation enabled. Enable CloudTrail Insights for anomaly detection. Store logs in S3 with S3 Object Lock (WORM compliance, immutable logs)
Amazon CloudWatch Logs: Ship application logs to CloudWatch Logs with KMS encryption and defined retention policies (minimum 12 months)
Amazon GuardDuty: Enable for threat detection across CloudTrail, VPC Flow Logs, and DNS logs
VPC Flow Logs: Enable for all VPCs containing ePHI workloads — ship to CloudWatch Logs or S3

GCP:

Cloud Audit Logs: Enable Admin Activity logs (always on), Data Access logs (must be explicitly enabled per service — enable for Cloud Storage, Cloud SQL, BigQuery for ePHI workloads), and System Event logs
Cloud Logging: Configure log retention buckets with _Default and _Required buckets — set retention to minimum 12 months
Cloud Storage for log archival: Use Bucket Lock for WORM-compliant log storage
Security Command Center: Enable for aggregated threat detection and security findings

Azure:

Azure Activity Log: Provides subscription-level audit trail — retained 90 days by default, configure Log Analytics Workspace for longer retention
Azure Monitor: Centralize all diagnostic logs from Azure resources
Microsoft Defender for Cloud: Enable for security posture management and threat detection
NSG Flow Logs: Enable for all network security groups in ePHI-containing environments
Azure Sentinel: Implement as SIEM for log correlation, alerting, and incident detection

Log retention: HIPAA does not specify a retention period for audit logs. OCR guidance and best practice indicate 6–12 years is appropriate given the HIPAA documentation retention requirement of 6 years from the date of creation or the date when it was last in effect.

Mid-Article CTA

Does your cloud infrastructure meet HIPAA Security Rule requirements?

QuickTrust's engineers will assess your AWS, GCP, or Azure environment against all HIPAA technical safeguards — and implement what is missing.

Get your cloud infrastructure security gap report →

Safeguard 6: Integrity Controls

Regulation: § 164.312(c)(2) — Addressable Standard: Integrity

What the regulation requires: Implement electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner.

Implementation

File integrity monitoring:

AWS: AWS Config with custom rules to detect configuration changes. Amazon Macie for S3 object-level access monitoring. AWS Config + CloudTrail for detecting unauthorized object modifications
GCP: Cloud Storage Object Versioning enabled for ePHI-containing buckets. Cloud Asset Inventory for resource configuration change detection
Azure: Azure Blob Storage Soft Delete and versioning. Microsoft Defender for Storage for anomalous access detection

Database integrity:

Enable database-level audit logging for all INSERT, UPDATE, DELETE operations on ePHI tables
Implement application-level checksums or hashes for critical ePHI records (especially for regulated data like signed consent forms or diagnostic images)
Enable point-in-time recovery for all databases containing ePHI (AWS RDS PITR, Cloud SQL PITR, Azure SQL PITR)

S3/GCS/Blob integrity:

AWS S3: Enable S3 Object Lock in Compliance mode for records that must not be altered (audit logs, consent records). Enable S3 Versioning for ePHI buckets
GCP: Enable Object Versioning on Cloud Storage buckets containing ePHI. Use Bucket Lock for retention-locked data
Azure: Enable immutable storage policies (time-based retention) for Blob storage containing ePHI

Safeguard 7: Person or Entity Authentication

Regulation: § 164.312(d) — Required Standard: Authentication

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

This is the MFA requirement in practice. Password-only authentication for any system containing ePHI does not meet the person or entity authentication standard — a password can be stolen, shared, or guessed without any certainty that the authenticated person is who they claim to be.

Implementation

Multi-Factor Authentication (MFA) enforcement:

AWS:

Enforce MFA for all IAM users with console access using IAM policy condition: "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "true"}}
Require MFA for all AWS CLI/API access via IAM policy or AWS Organizations SCP
AWS IAM Identity Center: Enforce MFA at the Identity Center level for all workforce users
For application users: Implement TOTP, FIDO2/WebAuthn, or SMS-based MFA via Amazon Cognito or integrated identity provider (Okta, Auth0, Duo)

GCP:

Enforce 2-Step Verification for all Cloud Identity accounts via Admin Console → Security → 2-Step Verification → Enforcement
Organization Policy: constraints/iam.disableServiceAccountKeyCreation to prevent service account key export
VPC Service Controls: Restrict API access to authorized networks and identities

Azure:

Azure Conditional Access: Create policies requiring MFA for all users accessing ePHI systems (Entra ID Conditional Access)
Privileged Identity Management (PIM): Require MFA activation for privileged role assignments
Block legacy authentication protocols (basic auth) that bypass MFA via Conditional Access policy

Authentication standards:

NIST SP 800-63B defines authentication assurance levels. For ePHI systems, implement at minimum AAL2 (requiring a two-factor authenticator)
Enforce phishing-resistant MFA (FIDO2/WebAuthn hardware keys) for administrator access to ePHI systems
Implement risk-based authentication that escalates MFA requirements for anomalous login patterns

Safeguard 8: Transmission Security — Encryption in Transit

Regulation: § 164.312(e)(2)(ii) — Addressable Standard: Transmission Security

What the regulation requires: Implement a mechanism to encrypt ePHI whenever deemed appropriate.

Like encryption at rest, transmission encryption is addressable but practically required. The risks of transmitting ePHI over unencrypted channels are obvious, and any risk assessment will conclude that encryption in transit is appropriate.

Implementation

TLS enforcement:

Minimum standard: TLS 1.2. Recommended: TLS 1.3 only, with TLS 1.2 as fallback if compatibility requires it. Disable TLS 1.0, TLS 1.1, and SSL 3.0 entirely
NIST SP 800-52 Rev 2 provides federal guidance on TLS implementation

AWS:

Application Load Balancer (ALB): Configure HTTPS listeners with TLS 1.2+ security policy. Use ACM-issued certificates. Redirect HTTP to HTTPS
Amazon CloudFront: Set minimum TLS version to TLSv1.2_2021 security policy
RDS: Enforce SSL connections via RDS parameter group (rds.force_ssl = 1 for PostgreSQL; require_secure_transport = ON for MySQL)
API Gateway: HTTPS only, no HTTP endpoints for APIs that handle ePHI

GCP:

Cloud Load Balancing: Configure HTTPS load balancers with modern TLS policies. Certificate Manager for managed certificates
Cloud SQL: Enforce SSL connections via sslMode = REQUIRE and upload client certificates where applicable
Cloud Run / Cloud Functions: HTTPS enforced by default; configure ingress to reject HTTP

Azure:

Application Gateway / Azure Front Door: Configure TLS 1.2 minimum policy, enable HTTPS-only mode
Azure SQL Database: Enforce SSL via ssl_enforcement = ENABLED. Set minimal TLS version to 1.2
Azure API Management: Disable deprecated TLS/SSL protocols in backend settings

Internal service communication:

Implement mutual TLS (mTLS) for service-to-service communication within your infrastructure (service mesh like Istio, AWS App Mesh, or GCP Traffic Director)
Enforce encrypted communication between microservices — do not assume internal network communication is secure

Safeguard 9: Integrity — Transmission Integrity

Regulation: § 164.312(e)(2)(i) — Addressable Standard: Transmission Security

What the regulation requires: Implement security measures to ensure that electronically transmitted ePHI is not improperly modified without detection.

Implementation

TLS provides inherent transmission integrity — any modification of data in transit causes the MAC (Message Authentication Code) verification to fail, triggering connection termination
For API-transmitted ePHI, implement HMAC signatures on request/response payloads where additional integrity assurance is required
For file transfers containing ePHI, generate and verify checksums (SHA-256) before and after transfer
For FHIR-based ePHI exchange: implement SMART on FHIR with OAuth 2.0 and validate resource digital signatures where applicable

Putting It All Together: HIPAA Technical Safeguard Implementation Checklist

Safeguard	Specification	Status Required
Unique User Identification	Individual accounts, no shared credentials	Required
Emergency Access Procedure	Break-glass procedure documented and tested	Required
Automatic Logoff	Session timeout configured (application + OS)	Addressable
Encryption at Rest	AES-256 via KMS (AWS/GCP/Azure) on all ePHI stores	Addressable (effectively required)
Audit Controls	Application-level + infrastructure-level logging, 12-month retention	Required
Integrity Controls	Versioning, WORM storage, file integrity monitoring	Addressable
Person/Entity Authentication	MFA enforced on all ePHI system access	Required
Transmission Security — Encryption	TLS 1.2+ on all ePHI transmission paths	Addressable (effectively required)
Transmission Security — Integrity	TLS MAC verification + payload checksums where applicable	Addressable

Conclusion

HIPAA Security Rule technical safeguard implementation is not ambiguous. The required specifications must be implemented. The addressable specifications require a documented assessment — and for nearly every addressable specification, the correct answer for a cloud-native SaaS company is to implement them.

What separates HIPAA-compliant SaaS companies from non-compliant ones is not knowledge of the requirements — it is execution. Configuring CloudTrail with immutable log storage, enabling KMS encryption with CMKs and key rotation, enforcing TLS 1.2+ across all load balancers, implementing application-level ePHI audit trails — these require engineering time and expertise.

QuickTrust's security and DevOps engineers implement these controls directly in your AWS, GCP, or Azure environment. Not document them. Implement them. With evidence that your enterprise healthcare customers can verify.

[→ See our complete HIPAA compliance guide for healthcare SaaS founders] [→ Learn how to achieve HIPAA compliance without hiring a full-time security team] [→ Understand the difference between HIPAA certified and HIPAA compliant]

Get Your Cloud Infrastructure Security Gap Report

QuickTrust's engineers will review your AWS, GCP, or Azure configuration against every HIPAA Security Rule technical safeguard — and deliver a gap report showing exactly what needs to be implemented, with effort estimates and prioritization.

Get your cloud infrastructure security gap report →

Open-source platform: github.com/rahuliitk/quicktrust

The HIPAA Security Rule Explained: 9 Technical Safeguards Your Cloud Infrastructure Must Have