Skip to main content
CloudArq
frameworkhipaa
scopeaws
rule§164.312
compliance guide · aws · hipaa security rule

HIPAA on AWS: map your AWS posture to the Security Rule

A control-by-control guide for teams running healthcare workloads on AWS. Every technical safeguard in the HIPAA Security Rule (45 CFR Part 164 Subpart C) is mapped to the exact AWS setting an assessor will ask about — and to the read-only CloudArq check that evidences it. No fluff, no “get-compliant-fast” tricks — just the rule, the AWS control, and the gap.

Updated 2026-07-20 · ~11 minute read

37
checks mapped to the Security Rule
7
safeguards covered
2
safeguard families below
0
agents installed
audience

Who this is for

Digital-health startups, medtech teams, and SaaS vendors that touch electronic protected health information (ePHI) on AWS and need to show a covered entity — or their own assessor — that the technical safeguards are in place. If a hospital, payer, or enterprise buyer has sent you a security questionnaire that cites “45 CFR §164.312”, this page maps each line to the AWS control it's really asking about.

definition

What the HIPAA Security Rule actually is

The HIPAA Security Rule (45 CFR Part 164, Subpart C) is the part of HIPAA that governs the security of ePHI. It is organised into three safeguard families: administrative (§164.308 — risk analysis, workforce policy, monitoring), physical (§164.310 — facility and device/media controls), and technical (§164.312 — access control, audit, integrity, authentication, transmission security). Much of the rule is policy and process a scanner cannot see. But a large slice — every technical safeguard, plus the parts of the administrative and physical safeguards that live in your cloud configuration — maps cleanly to AWS settings. That is the slice CloudArq inspects: 48 checks across nine safeguards.

scope · honest by design

What this does — and does not — do

what it does
  • Maps 48 read-only AWS checks to the Security Rule's technical safeguards and shows where your configuration falls short.
  • Groups gaps by CFR citation so an assessor can trace each finding to §164.312 / §164.308 / §164.310.
  • Ships a copy-paste CLI / Terraform remediation step and an evidence pointer with every finding.
what it does not do
  • It does not certify, guarantee, or “achieve” HIPAA compliance — a scanner shows posture, it doesn't issue a determination.
  • It is not a Business Associate Agreement and never receives, stores, or processes ePHI.
  • It does not cover the administrative and physical POLICY obligations — workforce training, sanction policy, written contingency plans, BAAs — those are people-and-process, not scannable.

CloudArq the business holds no certifications of any kind. The product maps automated checks to framework controls — it does not make you, or CloudArq, HIPAA-certified.

shared responsibility

AWS secures the platform. You secure the configuration.

AWS will sign a Business Associate Addendum and publishes a list of HIPAA-eligible services; accepting that (via AWS Artifact) covers the platform layer — data centres, hypervisor, hardware. Everything you build on top — encrypting the volumes that hold ePHI, keeping CloudTrail on, closing the security group that exposes a database, enforcing MFA — is your side of the shared-responsibility model. That configuration layer is what an assessor audits, and it is exactly what the checks below inspect.

Technical safeguards (§164.312)

The core of the Security Rule — the safeguards that live directly in your AWS configuration.

6 controls
  • 164.312(a)(1)Access control. CloudArq checks for over-broad IAM (iam_policy_wildcard), excessive agent blast radius (agentic_blast_radius), and workloads reachable from the public internet (runtime_public_network).
  • 164.312(a)(2)(iv)Encryption & decryption. Unencrypted EBS volumes (unencrypted_ebs), unencrypted RDS instances (unencrypted_rds), and gateways without a customer-managed key (gateway_no_cmk).
  • 164.312(b)Audit controls. CloudTrail disabled so there is no audit trail (no_cloudtrail), and Bedrock model-invocation logging switched off (bedrock_invocation_logging_off).
  • 164.312(c)(1)Integrity. S3 buckets without versioning (no_versioning_s3) and without object lock, so records can be silently overwritten or deleted (s3_no_object_lock).
  • 164.312(d)Person / entity authentication. Root without MFA (no_mfa_root), no account password policy (no_password_policy), and stale IAM access keys (old_access_keys).
  • 164.312(e)(1)Transmission security. CloudFront serving over plain HTTP (cloudfront_no_https) or negotiating outdated TLS (cloudfront_outdated_tls), so ePHI could travel unencrypted.

Administrative safeguards (§164.308) — the scannable slice

Most of §164.308 is written policy. These two safeguards leave a configuration trace CloudArq can read.

2 controls
  • 164.308(a)(1)Security management / risk analysis. Threat-detection turned off (guardduty_disabled) and AWS Config not recording resource state (config_not_enabled) — a documented risk analysis expects both to be on.
  • 164.308(a)(5)Security awareness & monitoring. No CloudWatch alarms at all (no_alarm) and, specifically, no alarm on root-account login (no_root_login_alarm).

Physical safeguards (§164.310) — device & media controls

The cloud analogue of media backup and disposal: can you restore ePHI after loss?

1 controls
  • 164.310(d)(1)Device & media controls (backups). RDS automated backups disabled (no_backups_rds) and DynamoDB tables without point-in-time recovery (dynamodb_no_pitr) — no exact retrievable copy of ePHI.
product · output

How CloudArq groups the gaps by safeguard

compliance-gaps · framework · hipaaillustrative example
Critical2High2Medium1
164.312(a)(2)(iv)
RDS instance not encrypted at rest (unencrypted_rds)
db-example-ehr · eu-north-1
fix →
164.312(b)
CloudTrail disabled in a region (no_cloudtrail)
eu-west-1
fix →
164.312(d)
Root account has no MFA (no_mfa_root)
account 0000-0000-0000
fix →
164.312(e)(1)
CloudFront serving over plain HTTP (cloudfront_no_https)
dist Eexample · global
fix →
164.310(d)(1)
RDS automated backups disabled (no_backups_rds)
db-example-claims
fix →

Each failing safeguard ships with a copy-paste CLI / Terraform fix and its evidence pointer for the assessor. Detection and the fix — read-only, never auto-applied.

faq

Frequently asked

01Does CloudArq handle HIPAA compliance for us, or act as a Business Associate?
No. CloudArq is a read-only posture scanner — it maps 48 of its AWS checks to the HIPAA Security Rule's technical safeguards and shows you where your configuration falls short. It does not certify, guarantee, or "achieve" compliance, it is not a HIPAA audit, and it is not a Business Associate: it never receives, stores, or processes ePHI. Compliance is a determination you and your assessor make; CloudArq is evidence for the AWS-infrastructure part of that work.
02Which part of the HIPAA Security Rule does CloudArq cover?
The technical safeguards in 45 CFR §164.312 — access control, encryption/decryption, audit controls, integrity, person/entity authentication, and transmission security — plus the scannable slices of the administrative (§164.308: risk analysis, security monitoring) and physical (§164.310: device/media backups) safeguards. It does NOT cover the administrative and physical POLICY obligations — workforce training, sanction policy, contingency planning on paper, BAAs, or the written risk-management program. Those are people-and-process controls a scanner cannot see.
03Does AWS sign a Business Associate Addendum (BAA) for HIPAA workloads?
Yes. AWS offers a BAA and publishes a list of HIPAA-eligible services; you accept it through AWS Artifact and then restrict ePHI to eligible services. That covers the shared-responsibility split for the AWS platform. The controls ON TOP of that platform — encryption, access, logging, backups — are yours to configure and evidence, and that is exactly the layer CloudArq inspects.
04Is CloudArq read-only? Can it see our ePHI?
CloudArq connects through a read-only IAM role scoped by an ExternalId and reads only configuration metadata — is this EBS volume encrypted, is CloudTrail on, is this security group open. It never reads object contents, database rows, or S3 objects, so it never touches ePHI. It stores no credentials; metadata at rest is AES-256-GCM encrypted and EU-hosted (Helsinki). It detects issues and gives exact remediation steps — it never auto-fixes anything.
05What AWS misconfigurations most often fail the HIPAA Security Rule?
The recurring ones we see: unencrypted EBS or RDS holding ePHI (unencrypted_ebs, unencrypted_rds — §164.312(a)(2)(iv)); CloudTrail disabled so there is no audit trail (no_cloudtrail — §164.312(b)); root without MFA and stale access keys (no_mfa_root, old_access_keys — §164.312(d)); CloudFront serving over plain HTTP or outdated TLS (cloudfront_no_https, cloudfront_outdated_tls — §164.312(e)(1)); and RDS with no automated backups (no_backups_rds — §164.310(d)(1)). Each maps to a specific safeguard, so an assessor can trace the finding straight to the rule.
06Which CloudArq tier includes the HIPAA mapping?
HIPAA is one of the eight frameworks mapped on the Max tier, which unlocks all eight frameworks plus the AI Workload lens. The Pro tier maps four frameworks (CIS, SOC 2, ISO 27001, GDPR); HIPAA is not one of them. The free Starter tier runs the core checks but does not group findings by HIPAA control. See the pricing page for current tier prices.

Where CloudArq helps

CloudArq automates the AWS-side evidence for every technical safeguard on this page. 48 checks are mapped to their HIPAA Security Rule control IDs; the compliance-gaps page groups failing safeguards by CFR citation, and each finding ships with a CLI command or Terraform block you can apply today. It is read-only and never auto-fixes — you stay in control of every change.

Working through more than one framework? See the SOC 2 on AWS checklist and the PCI DSS on AWS control mapping. Most controls overlap — one scan evidences several frameworks at once.