HIPAA Engineering Controls

HIPAA Engineering Controls are the technical safeguards that ensure the confidentiality, integrity, and availability of electronic protected health information (ePHI) across systems, networks, and data stores. These controls are mandatory under the HIPAA Security Rule, and their implementation must be precise, auditable, and enforceable—especially during inspections, audits, and incident investigations. They are most critical during system onboarding, security incident response, and annual compliance reviews.

Data Encryption at Rest and in Transit

To satisfy HIPAA’s encryption requirements, systems must protect ePHI both while stored and while being transmitted. The core requirement is that all ePHI must be encrypted at rest and in transit using industry-standard algorithms.

For encryption at rest, a system must ensure that every database, file storage, and backup medium contains ePHI in encrypted form. This includes:

• PostgreSQL: Enable pgcrypto extension and use pg_encrypt with AES-256 for sensitive columns.

  CREATE EXTENSION IF NOT EXISTS pgcrypto;
  ALTER TABLE patients ALTER COLUMN ssn TYPE bytea USING pg_encrypt(ssn, 'AES-256');

• File systems: Use LUKS for full-disk encryption on Linux servers.

  sudo cryptsetup luksFormat /dev/sdb
  sudo cryptsetup open /dev/sdb encrypted_data
  sudo mount /dev/mapper/encrypted_data /mnt/data

• Object storage: Configure AWS S3 buckets to use server-side encryption with AES-256.

  {
    "Rules": [
      {
        "ApplyServerSideEncryptionByDefault": {
          "SSEAlgorithm": "AES256"
        }
      }
    ]
  }

For encryption in transit, all network communications involving ePHI must be secured using TLS 1.2 or higher.

• Nginx configuration to enforce TLS 1.2+ and enable HSTS:

  server {
      listen 443 ssl http2;
      ssl_protocols TLSv1.2 TLSv1.3;
      ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512;
      ssl_prefer_server_ciphers on;
      add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
      # ...
  }

• Client-side: All API clients must validate server certificates, use certificate pinning, and enforce HTTPS for all endpoints.

Common failure modes include:

• TLS 1.1 or earlier accepted, especially when clients use default configurations.
• Missing HSTS header, leading to downgrade attacks.
• Misconfigured pgcrypto: pg_encrypt columns are not indexed, leading to full-table scans on queries.
• Key rotation not automated: Encryption keys remain unchanged for years, failing to meet audit requirements for key lifecycle management.

Access Control and Authentication

All access to systems handling ePHI must be governed by strong access control policies. This includes user authentication, role-based access, and session management.

• Authentication: All users must authenticate using multi-factor authentication (MFA). Implementations must support both time-based (TOTP) and push-based (e.g., FIDO2) MFA.

• Example: Using Google Authenticator with tfa middleware:

    {
      "users": [
        {
          "id": "u-123",
          "name": "Dr. Alice Chen",
          "email": "[email protected]",
          "mfa_secret": "JBSWY3DPEHPK3PXP",
          "mfa_enabled": true
        }
      ]
    }

• Session management: Sessions must expire after 15 minutes of inactivity and 2 hours of total duration. Sessions must be invalidated on logout and on MFA change.

• Example: Session data stored in Redis with TTL:

    # Set session with 2-hour timeout
    SET session:u-123:active "true" EX 7200
    # Set inactivity timer
    SET session:u-123:timestamp "$(date +%s)" EX 900
    # On activity: update timestamp
    SET session:u-123:timestamp "$(date +%s)" EX 900

• Role-based access control (RBAC): Define roles such as Patient, Clinician, Admin, and Auditor, each with granular permissions.

• Example: Permission matrix in JSON:

    {
      "roles": {
        "Clinician": {
          "permissions": [
            "read:patients",
            "create:appointments",
            "write:notes",
            "read:medications"
          ],
          "access": {
            "data": ["demographics", "vitals", "diagnoses"],
            "systems": ["ehr", "scheduling", "laboratory"]
          }
        },
        "Auditor": {
          "permissions": [
            "read:all",
            "export:audit-logs",
            "review:compliance"
          ],
          "access": {
            "data": ["all"],
            "systems": ["all"]
          }
        }
      }
    }

Critical edge cases:

• MFA setup failure: Users set up MFA but the secret is not stored in a recoverable format; after server loss, they cannot log in.
• Session fixation attack: Session tokens are not regenerated on login, allowing attackers to hijack sessions.
• Role inheritance confusion: A Senior Clinician role includes Clinician permissions but does not automatically grant read:medications—a subtle gap missed in audits.

Audit Trail and Logging

Systems must maintain a complete audit trail of all access and actions on ePHI. The audit trail must include:

• Who accessed what
• When and from where
• What changed and how

The audit trail must be immutable, retention-based, and searchable.

• Logging structure:

  {
    "event_id": "evt-45678",
    "timestamp": "2024-03-15T10:32:14Z",
    "actor": {
      "user_id": "u-123",
      "role": "Clinician",
      "ip_address": "192.168.1.10",
      "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15"
    },
    "action": "update",
    "resource": {
      "type": "patient",
      "id": "p-789",
      "name": "John Doe",
      "version": 3
    },
    "details": {
      "fields_changed": [
        {
          "field": "primary_diagnosis",
          "old_value": "Hypertension",
          "new_value": "Type 2 Diabetes"
        },
        {
          "field": "medication",
          "old_value": ["Lisinopril"],
          "new_value": ["Lisinopril", "Metformin"]
        }
      ],
      "source": "web-ui",
      "transaction_id": "txn-9901"
    }
  }

• Audit log storage: Logs must be written to a central system (e.g., Elasticsearch) and archived to immutable storage like AWS Glacier or S3 with versioning and lifecycle policies.

• Example: AWS S3 lifecycle rule for audit logs:

    {
      "Rules": [
        {
          "ID": "audit-log-rotation",
          "Prefix": "audit-logs/",
          "Status": "Enabled",
          "Transitions": [
            {
              "Days": 90,
              "StorageClass": "GLACIER"
            }
          ],
          "Expiration": {
            "Days": 3650
          }
        }
      ]
    }

• Log retention: Logs must be retained for at least 6 years (HIPAA’s minimum), and the system must be able to retrieve logs within 30 minutes of a request.

Common pitfalls:

• Log retention not enforced: Logs are written but not automatically archived; the system grows unbounded.
• Incomplete events: create actions are logged, but delete and import are missing.
• Timestamp drift: Systems across multiple zones have different time zones; logs are not standardized to UTC.
• Audit trail not searchable: Log queries are limited to timestamp and user_id, but no support for field_changed or resource.id.

Data Integrity and Backup

ePHI must be protected against loss, corruption, and tampering. Systems must implement regular backups and integrity checks.

• Backup frequency: Daily full backups and hourly incremental backups for all ePHI data.

• Example: Using borg for incremental backups:

    # Full backup
    borg create /backup/health::$(date +%Y-%m-%d) /data/ehr /data/patients
    # Incremental backup
    borg create --timestamp $(date +%Y-%m-%d) /backup/health::$(date +%Y-%m-%d) /data/ehr /data/patients

• Backup verification: After each backup, run a borg check and log the result.

  borg check --verify-data /backup/health

• Integrity checks: Regularly verify data using checksums or digital signatures.

• Example: Generate SHA-256 hash of all ePHI tables:

    psql -c "SELECT md5(string_agg(oid::text, '')) FROM patients;" -t

• Restore testing: Conduct quarterly restore tests, where a backup is restored to a test environment and validated.

• Example: Restore script:

    # Extract latest backup
    borg extract /backup/health::2024-03-15 /tmp/restore
    # Run integrity check
    psql -d test_db -f /tmp/restore/verify.sql
    # Validate data
    curl -X POST http://test-api/health-check -d '{"test": "restore-validation"}'

Key failure modes:

• Backup not verified: A backup completes but no borg check is run; corrupted data goes unnoticed.
• Restore test not documented: Test results are not archived; the test is performed but not auditable.
• Backup retention not aligned with HIPAA: Retention is set to 5 years, but 6 years are required; the system fails audit for missing one year.

System and Network Security

Network and system-level controls ensure that ePHI is protected from external and internal threats.

• Firewall configuration: All systems must be behind a firewall that enforces rules to allow only necessary traffic.

• Example: iptables rule to allow only HTTPS and internal API traffic:

    iptables -A INPUT -p tcp --dport 443 -j ACCEPT
    iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
    iptables -A INPUT -s 10.0.0.0/8 -j ACCEPT
    iptables -A INPUT -j DROP

• Network segmentation: ePHI systems must be isolated in a dedicated network segment (e.g., VLAN 100), with access controlled via VLANs and subnets.

• Intrusion detection and prevention (IDS/IPS): Deploy tools like Suricata or Snort to detect suspicious traffic.

• Example: Suricata rule for SQL injection detection:

    rule:
      name: "SQL Injection Attempt"
      priority: 1
      metadata:
        tags: [ "web", "sql", "injection" ]
      detection:
        flow: { to_server: true }
        content: [ "SELECT", "FROM", "WHERE" ]
        pcre: [ "/\b(SELECT|INSERT|UPDATE|DELETE|CREATE|DROP)\b.*?(\bFROM\b|\bWHERE\b|\bJOIN\b)/i" ]
        threshold: { type: "packet", count: 5, within: 30 }

• Patch management: All systems must be updated with security patches within 30 days of release.

• Example: systemctl-based update script:

    # Update all packages
    sudo apt update && sudo apt upgrade -y
    # Reboot if kernel or critical service changed
    if grep -q "linux-image" /var/log/apt/history.log; then
      sudo reboot
    fi

Critical oversights:

• Firewall rules not versioned: Rules are modified manually but not documented or stored in code.
• IDS rules not tested: Rules are added but not validated against real traffic; false positives go unnoticed.
• Patch management not automated: Manual patching leads to drift between systems.

Continuous Compliance Validation

To maintain ongoing compliance, systems must validate HIPAA controls continuously.

• Automated compliance checks run daily via cron or CI/CD pipelines:
• Check encryption status of all tables
• Validate audit logs are being written
• Confirm backup completion and verification
• Test restore from last backup

• Compliance dashboard displays health of all controls, with alerts on failures.

• Compliance reports are generated monthly and include:
• Number of ePHI records
• Number of audit events
• Backup success rate
• MFA enrollment rate
• System uptime

All reports must be exportable in PDF and JSON formats for audits.

Failure to run these checks leads to unverified compliance: controls are assumed to be in place but are not proven.

This page was rewritten on 18 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.