Skip to content

HIPAA Security Rule 2003

Deprecated Framework

This framework has been superseded by HIPAA Omnibus Final Rule 2013. Organizations should migrate to the 2013 rule, which strengthened privacy and security protections and expanded compliance obligations to business associates.

Best for: Covered entities and business associates that create, receive, maintain, or transmit electronic protected health information (ePHI). This includes hospitals, clinics, health insurers, billing companies, and cloud providers handling ePHI under a BAA. There is no size or revenue threshold. SaaS vendors serving healthcare customers are business associates and must comply directly. HHS OCR enforcement carries civil penalties up to $2.13 million per violation category per year.

Mandatory?Mandatory for covered entities and business associates
Who validates?No formal certification; HHS/OCR enforcement
RenewalNo fixed cycle; periodic risk assessments required
ScopeElectronic protected health information (ePHI)

🏛 U.S. Department of Health and Human Services (HHS), Office for Civil Rights (OCR) · HIPAA Security Rule 2003 (superseded by Omnibus 2013) Official source →

Get Started

module "..." {
  source  = "hipaasecurity2003.compliance.tf/terraform-aws-modules/<module>/aws"
  version = "<version>"
}

What Compliance.tf Covers vs. What You Handle

  • What Compliance.tf automates

    • Audit Logging and Monitoring: Nine controls covering CloudTrail configuration (multi-region, S3 data events, log validation, CloudWatch integration), API Gateway stage logging, CloudFront access logs, CloudWatch log group retention at 365 days, and CodeBuild project logging.
    • Encryption at Rest: Verifies encryption on API Gateway stage caches, CloudTrail log files (KMS CMK), and AWS Backup recovery points. The full benchmark extends coverage to S3, EBS, RDS, and other storage services beyond the sample controls shown here.
    • Encryption in Transit: Checks CloudFront TLS enforcement and ACM certificate expiration within 30 days. The full benchmark adds ELB listener configurations and other transit encryption checks.
    • Backup and Recovery: Four controls: AWS Backup plan retention minimums (35 days), recovery point retention periods, manual deletion protection on recovery points, and Auto Scaling health check configuration for availability.
    • Incident Response Readiness: Checks that the AWS account security contact is registered and that CloudWatch alarms have configured actions, confirming alerts are wired to responsible personnel.

  • What you handle

    • Audit Logging and Monitoring: Defining which logs constitute your ePHI audit trail, establishing review procedures, and training workforce members on log analysis. You also need a documented process for responding when log anomalies are detected.
    • Encryption at Rest: Key management policy, rotation schedules, IAM-based key access restrictions, and documented encryption standards. The addressable specification under §164.312(a)(2)(iv) requires you to assess whether encryption is reasonable and appropriate for your environment and record your rationale if you choose an alternative measure.
    • Encryption in Transit: Selecting minimum TLS versions, managing certificate lifecycle beyond expiration alerting, and confirming that all network paths carrying ePHI (including internal service-to-service traffic) enforce encryption.
    • Backup and Recovery: Developing and testing a full contingency plan per §164.308(a)(7), including disaster recovery and emergency mode operation procedures. This means documented RTO/RPO targets, periodic recovery testing, and a process for activating emergency mode operations.
    • Incident Response Readiness: Writing an incident response plan that satisfies §164.308(a)(6), training your workforce on breach notification procedures under the HITECH Act's Breach Notification Rule, and running periodic tabletop exercises. Compliance.tf confirms the alerting infrastructure exists but cannot verify your human response processes.

Controls by Category

Administrative Safeguards: Contingency Plan (§164.308(a)(7)) (1 control)

The paper-versus-practice gap is where organizations fail §164.308(a)(7) most often. A documented backup policy does not satisfy an auditor who can demonstrate that manual deletion of recovery points was never disabled. Assessors want retention enforced at the infrastructure level, not just described in a policy document, and they check health check configurations as evidence that availability commitments are backed by actual controls.

Backup plan min frequency and min retention check

Administrative Safeguards: Security Management Process (§164.308(a)(1)) (1 control)

A missing security contact on an AWS account is a concrete signal that incident response ownership has not been formalized. Alongside designated contacts, assessors check for active alarm configurations, confirming both that the organization can detect security events and that someone is wired to receive the alert. §164.308(a)(1) requires procedures to prevent, detect, contain, and correct security violations, and these two controls are the minimum infrastructure evidence for that requirement.

CloudWatch alarm should have an action configured compliance.tf module

Technical Safeguards: Audit Controls (§164.312(b)) (7 controls)

The most common finding here is logging enabled on primary services but absent from supporting infrastructure like API gateways and build pipelines. §164.312(b) requires hardware, software, and procedural mechanisms that record and examine activity in systems containing ePHI. Assessors want to see log integrity controls (CloudTrail validation is the obvious one) and retention periods long enough to support incident investigations.

API Gateway stage logging should be enabled CloudFront distributions access logs should be enabled compliance.tf module At least one enabled trail should be present in a region CloudTrail trails should be integrated with CloudWatch logs CloudTrail trail log file validation should be enabled Log group retention period should be at least 365 days compliance.tf module CodeBuild projects should have logging enabled

Technical Safeguards: Encryption at Rest (§164.312(a)(2)(iv)) (2 controls)

Backup recovery points and API Gateway caches are where assessors most often find gaps. The core question is whether ePHI at rest is encrypted as an access control mechanism and whether key management is defensible. KMS-managed CMKs carry more weight than default encryption when you're explaining your key management posture.

API Gateway stage cache encryption at rest should be enabled CloudTrail trail logs should be encrypted with KMS CMK

Technical Safeguards: Transmission Security (§164.312(e)(1)) (1 control)

Expect an assessor to examine TLS configuration, certificate validity, and HTTPS enforcement on every public-facing endpoint carrying ePHI. Expired or soon-to-expire certificates get flagged because they can trigger fallback to unencrypted connections or availability outages. Internal service-to-service paths are a frequent gap that falls outside what these controls check.

CloudFront distributions should require encryption in transit compliance.tf module
Additional Controls (58)

AWS Database Migration Service (1)

DMS replication instances should not be publicly accessible compliance.tf module

AWS IAM (1)

IAM password policies for users should have strong configurations

AWS Lambda (2)

Lambda functions should be configured with a dead-letter queue compliance.tf module Lambda functions should be in a VPC compliance.tf module

AWS WAF (1)

AWS WAF rules should have CloudWatch metrics enabled

Amazon CloudWatch Logs (1)

Log group encryption at rest should be enabled compliance.tf module

Amazon DynamoDB (3)

DynamoDB table should be encrypted with AWS KMS compliance.tf module DynamoDB table should have encryption enabled compliance.tf module DynamoDB table point-in-time recovery should be enabled compliance.tf module

Amazon DynamoDB Accelerator (1)

DynamoDB Accelerator (DAX) clusters should be encrypted at rest

Amazon EBS (1)

Attached EBS volumes should have encryption enabled compliance.tf module

Amazon EC2 (3)

EC2 instance should have EBS optimization enabled compliance.tf module EC2 instances should be in a VPC compliance.tf module EC2 instances should not have a public IP address compliance.tf module

Amazon EFS (2)

EFS access points should enforce a user identity EFS file system encryption at rest should be enabled compliance.tf module

Amazon EKS (1)

EKS clusters should be configured to have kubernetes secrets encrypted using KMS compliance.tf module

Amazon EMR (1)

EMR cluster Kerberos should be enabled compliance.tf module

Amazon ElastiCache (1)

ElastiCache Redis cluster automatic backup should be enabled with retention period of 15 days or greater compliance.tf module

Amazon OpenSearch Service (4)

OpenSearch domains should have encryption at rest enabled compliance.tf module OpenSearch domains should use HTTPS compliance.tf module OpenSearch domains should be in a VPC compliance.tf module OpenSearch domains node-to-node encryption should be enabled compliance.tf module

Amazon RDS (6)

RDS DB instance backup should be enabled compliance.tf module RDS DB instance encryption at rest should be enabled compliance.tf module RDS DB instances should have iam authentication enabled compliance.tf module Database logging should be enabled compliance.tf module RDS DB instance multiple az should be enabled compliance.tf module RDS DB instances should prohibit public access compliance.tf module

Amazon Redshift (5)

AWS Redshift clusters should have automatic snapshots enabled compliance.tf module Redshift cluster encryption in transit should be enabled compliance.tf module Redshift cluster audit logging and encryption should be enabled compliance.tf module AWS Redshift clusters should be encrypted with KMS compliance.tf module Redshift clusters should prohibit public access compliance.tf module

Amazon S3 (12)

S3 bucket cross-region replication should be enabled compliance.tf module S3 bucket default encryption should be enabled compliance.tf module S3 bucket default encryption should be enabled with KMS compliance.tf module S3 buckets should have lifecycle policies configured compliance.tf module S3 bucket logging should be enabled compliance.tf module S3 bucket object lock should be enabled compliance.tf module S3 bucket policy should prohibit public access compliance.tf module S3 buckets should prohibit public read access compliance.tf module S3 buckets should prohibit public write access compliance.tf module S3 buckets with versioning enabled should have lifecycle policies configured compliance.tf module S3 bucket versioning should be enabled compliance.tf module S3 public access should be blocked at account level compliance.tf module

Amazon SNS (1)

SNS topics should be encrypted at rest compliance.tf module

Amazon SageMaker (4)

SageMaker endpoint configuration encryption should be enabled SageMaker notebook instances should not have direct internet access SageMaker notebook instances should be encrypted using CMK SageMaker notebook instance encryption should be enabled

Elastic Load Balancing (4)

ELB application and classic load balancer logging should be enabled compliance.tf module ELB application load balancer deletion protection should be enabled compliance.tf module ELB application load balancers should be configured to drop HTTP headers compliance.tf module Application Load Balancer should be configured to drop invalid http headers compliance.tf module

Other (3)

ES domain encryption at rest should be enabled ES domains should be in a VPC Elasticsearch domain node-to-node encryption should be enabled

  • NIST 800-53 Rev 5 — 🟢 High overlap (72%)

    Mappings between HIPAA Security Rule requirements and NIST 800-53 are typically derived from NIST guidance (for example, NIST SP 800-66), while HHS OCR's published crosswalk is to the NIST CSF. Organizations already compliant with the NIST 800-53 moderate baseline will satisfy most HIPAA technical and administrative safeguard requirements, though HIPAA-specific obligations around ePHI definitions, business associate management, and breach notification are not covered by NIST 800-53 alone.

  • NIST CSF v1.0 — 🟢 High overlap (60%)

    HHS released guidance mapping the HIPAA Security Rule to the NIST Cybersecurity Framework. The CSF's Protect, Detect, and Respond functions share some requirements with HIPAA's technical safeguards. The CSF is a voluntary risk management framework, however, and lacks HIPAA's specific requirements for workforce training, business associate agreements, and ePHI handling procedures.

  • SOC 2 — 🟡 Medium overlap (55%)

    SOC 2 Trust Services Criteria for Security, Availability, and Confidentiality partially overlaps with HIPAA's technical safeguards. Many healthcare SaaS vendors pursue SOC 2 alongside HIPAA compliance. SOC 2 does not address HIPAA-specific requirements like the Privacy Rule, breach notification, or business associate obligations.

Frequently Asked Questions

Does HIPAA apply to my organization if we only handle ePHI as a vendor, not as a healthcare provider?

Yes. If you create, receive, maintain, or transmit ePHI on behalf of a covered entity, you are a business associate under HIPAA. The HITECH Act of 2009, implemented through the 2013 Omnibus Rule, made business associates directly liable for compliance with the HIPAA Security Rule (administrative, physical, and technical safeguards) and certain Privacy and Breach Notification Rule provisions. You must sign a Business Associate Agreement (BAA) and implement the required safeguards independently. This applies to cloud providers, SaaS companies, IT consultants, and any other vendor with access to ePHI.

Is there a formal HIPAA certification or audit report like SOC 2?

No. HHS does not recognize any official HIPAA certification, and there is no accredited third- party certification program. Organizations demonstrate compliance through documented risk assessments, policies, and evidence of implemented controls. Firms that offer 'HIPAA compliance assessments' produce a report, but it carries no regulatory standing. HHS OCR evaluates compliance through its own investigations and audit program. Your primary compliance artifact is a thorough, current risk analysis per §164.308(a)(1)(ii)(A).

How does the 'addressable' vs 'required' distinction work for implementation specifications?

Required specifications must be implemented as stated. Addressable specifications require you to assess whether the specification is reasonable and appropriate for your environment. If it is, implement it. If not, document why and implement an equivalent alternative, or document why the safeguard does not apply. 'Addressable' does not mean optional. Failing to document your rationale for not implementing an addressable specification is itself a violation. Encryption under §164.312(a)(2)(iv) and §164.312(e)(2) are the most common addressable specifications where organizations must make and record this decision.

How often must we conduct a HIPAA risk assessment?

The Security Rule at §164.308(a)(1)(ii)(A) requires an accurate and thorough risk analysis but does not specify a frequency. HHS OCR guidance and enforcement history make clear that risk assessments must be reviewed and updated periodically and whenever significant environmental changes occur. Annual reviews are the widely accepted standard. OCR has penalized organizations that performed a risk assessment once and never revisited it. Major infrastructure changes, new systems processing ePHI, and security incidents should all trigger a reassessment.

What is the relationship between this 2003 Security Rule and the HITECH Act?

The HITECH Act (2009) substantially strengthened HIPAA enforcement. It extended Security Rule obligations directly to business associates, introduced mandatory breach notification requirements, restructured civil monetary penalties with a statutory annual cap of $1.5 million per violation type (adjusted annually for inflation to over $2 million at the top tier), and authorized state attorneys general to bring HIPAA enforcement actions. The 2013 Omnibus Rule codified HITECH's changes into the HIPAA regulations. The controls in this benchmark address the Security Rule as modified by those subsequent rules.