AWS for Industries
How to prepare for the proposed HIPAA Security Rule update with AWS Backup and the HIPAA Assistant
This post is for informational purposes only and is not legal advice. The requirements described here come from a proposed rule and are subject to change when a final rule is published. Customers are responsible for their own compliance with HIPAA. Consult qualified legal and compliance counsel.
If your organization creates, receives, maintains, or transmits electronic protected health information (ePHI), the proposed HIPAA Security Rule update is the most significant change to the Security Rule’s safeguards since the rule was published in 2003. In January 2025, the U.S. Department of Health and Human Services (HHS) published a Notice of Proposed Rulemaking (NPRM) that would turn many of today’s flexible safeguards into specific, measurable requirements: multi-factor authentication (MFA) for the systems that touch ePHI, encryption of ePHI at rest and in transit, backups no more than 48 hours old, restoration of critical systems within 72 hours, and a documented compliance audit every 12 months.
The final rule has not been published, and the most recent entry in the Office of Management and Budget (OMB) Unified Agenda lists the rulemaking under long-term actions with a projected final action date of July 2027. That delay is not a reason to wait. The existing Security Rule remains fully enforceable, the proposed controls are sound security practice regardless of when the rule is finalized, and the larger projects it describes (network segmentation, annual penetration testing, tested incident response plans) take budget cycles to land.
In this post, we summarize what HHS has proposed, when it is likely to matter, and how to use Amazon Web Services (AWS) to start closing the gaps now. We cover how AWS Backup maps to the three proposed backup and recovery obligations, and we introduce the HIPAA Assistant, an open source sample from AWS that reviews your infrastructure-as-code and application code for Security Rule gaps and cites each finding to the exact paragraph of the regulation. We close with a six-step plan that sequences the larger projects, such as network segmentation and penetration testing, into your next budget cycle.
Who the proposed rule applies to
The Security Rule applies to covered entities and their business associates, so the proposed changes reach well beyond hospitals. The regulated population includes hospitals, health systems, and clinics; health plans and payers; software vendors and SaaS platforms that handle ePHI; and billing companies and clearinghouses. It also includes any subcontractor that creates, receives, maintains, or transmits ePHI on behalf of one of those organizations. If you build or operate software for any of them, assume the rule applies to you until counsel tells you otherwise.
What is changing
The current Security Rule divides its implementation specifications into required and addressable categories. An addressable specification is not optional, but a regulated entity can decide, based on its risk analysis, that the specification is not reasonable and appropriate for its environment, document why, and adopt an equivalent alternative. Encryption of ePHI is the best-known example: today it is addressable.
The NPRM proposes to remove the distinction between required and addressable implementation specifications and make all of them required, with specific, limited exceptions. HHS also proposes to replace “implement procedures” language with a requirement to deploy technical controls, and to attach explicit timeframes (24 hours, 48 hours, 72 hours, six months, 12 months) to obligations that today have none.
Timeline
The following table summarizes the milestones as of this writing. The compliance date is an estimate based on the periods HHS proposed in the NPRM. The rule would take effect 60 days after publication, followed by the standard 180-day compliance period, for roughly 240 days in total. HHS could set different periods in the final rule.
| Milestone | Date | Source |
| Proposed rule published | January 6, 2025 (90 FR 898) | Federal Register |
| Public comment period closed | March 7, 2025 | Federal Register |
| Final action projected | July 2027 | OMB Unified Agenda, RIN 0945-AA22 |
| Compliance date (estimated) | About 240 days after the final rule is published; early 2028 if the July 2027 projection holds | NPRM, 45 CFR 160.105 |
The Unified Agenda entry classifies the rulemaking as a long-term action, which signals that HHS may take additional time to work through the public comments it received, and the final rule may narrow or adjust specific provisions. Plan against the direction of the rule, not the exact parameters.
The proposed requirements at a glance
HHS proposed changes throughout 45 CFR Part 164, Subpart C. The following two tables condense the proposals that most affect how you build and operate on AWS. Paragraph citations refer to the proposed regulatory text in the NPRM and will change when the rule is finalized.
Technical safeguards
The following table lists the proposed technical safeguards that map most directly to how you configure AWS services.
| # | Proposed requirement | Proposed citation |
| 1 | Deploy MFA to all technology assets in relevant electronic information systems, with limited exceptions | 45 CFR 164.312(f)(2)(ii) |
| 2 | Encrypt all ePHI at rest and in transit, with limited exceptions | 45 CFR 164.312(b)(2) |
| 3 | Maintain a written technology asset inventory and network map; review at least every 12 months and after relevant changes | 45 CFR 164.308(a)(1)(ii)(A) through (C) |
| 4 | Deploy controls that record all activity in relevant electronic information systems in real time; retain required documentation for six years | 45 CFR 164.312(d)(2)(ii); 164.316(b)(1) |
| 5 | Protect ePHI from improper alteration or destruction (integrity), as a required rather than addressable control | 45 CFR 164.312(e) |
| 6 | Run automated vulnerability scans at least every six months, or more often if your risk analysis requires | 45 CFR 164.312(h)(2)(i)(A) |
| 7 | Perform penetration testing by a qualified person at least every 12 months | 45 CFR 164.312(h)(2)(iii) |
| 8 | Keep retrievable copies of ePHI no more than 48 hours old; restore critical systems and data within 72 hours of a loss | 45 CFR 164.312(i)(2)(i); 164.308(a)(13)(ii)(D)(1) |
| 9 | Test restores of a representative sample of backed-up ePHI at least monthly; review and test backup controls at least every six months | 45 CFR 164.312(i)(2)(iv); 164.312(j) |
| 10 | Segment relevant electronic information systems to limit lateral movement, with written policies to match | 45 CFR 164.312(a)(2)(vi); 164.308(a)(10)(ii)(E) |
Governance and process requirements
The following table lists the proposed governance and process requirements that shape how you document and run your security program.
| # | Proposed requirement | Proposed citation |
| 11 | Notify other regulated entities within 24 hours when a workforce member’s access to ePHI changes or ends; business associates notify covered entities within 24 hours of activating a contingency plan | 45 CFR 164.308(a)(9)(ii)(D)(2); 164.314(a)(2)(i)(D) |
| 12 | Perform and document an audit of compliance with each standard and implementation specification at least every 12 months | 45 CFR 164.308(a)(14) |
| 13 | Covered entities obtain written verification from each business associate, at least every 12 months, that it has deployed the required technical safeguards | 45 CFR 164.308(b)(2)(ii) |
| 14 | Deploy anti-malware protection across all technology assets and maintain hardened configurations | 45 CFR 164.312(c)(1); 164.312(c)(2)(i) through (iv) |
| 15 | Maintain written security incident response plans and procedures; test and revise them | 45 CFR 164.308(a)(12) |
| 16 | Maintain a written risk analysis that maps assets, threats, and vulnerabilities; review and update it at least every 12 months | 45 CFR 164.308(a)(2) |
The penalty structure
Civil monetary penalties for HIPAA violations are already in force and adjust for inflation each year. The following amounts are the most recent adjustment, which HHS published on January 28, 2026 as its 2025 annual inflation adjustment under 45 CFR Part 102 (91 FR 3665); they apply to penalties assessed on or after that date. They apply to today’s Security Rule and will extend to any new requirements when the final rule takes effect.
| Tier | Level of culpability | Per violation (minimum to maximum) | Calendar-year cap for violations of an identical requirement | Annual cap HHS applies under its 2019 enforcement discretion |
| 1 | Did not know and, exercising reasonable diligence, would not have known | $145 to $73,011 | $2,190,294 | $25,000 |
| 2 | Reasonable cause, not willful neglect | $1,461 to $73,011 | $2,190,294 | $100,000 |
| 3 | Willful neglect, corrected within 30 days | $14,602 to $73,011 | $2,190,294 | $250,000 |
| 4 | Willful neglect, not corrected within 30 days | $73,011 to $2,190,294 | $2,190,294 | $2,190,294 (full regulatory cap) |
In April 2019, HHS announced that, as a matter of enforcement discretion, it applies the lower annual caps in the last column to the first three tiers: $25,000 for tier 1, $100,000 for tier 2, and $250,000 for tier 3, “as adjusted for inflation,” with the full cap applying only to tier 4 (84 FR 18151). HHS has said it will use that structure until further notice, so the practical annual exposure at tiers 1 through 3 is well below the regulatory figures, although the per-violation amounts are unchanged. The calendar-year cap applies separately to each requirement violated, so an organization that falls short on several distinct requirements carries exposure under each of them. Beyond penalties, a documented failure to meet the Security Rule increases your liability after an unauthorized disclosure of ePHI, raises litigation risk, and can complicate contracting with customers and vendors who require satisfactory assurances before they will share ePHI.
Shared responsibility on AWS
Under the AWS Shared Responsibility Model, AWS is responsible for the security of the cloud: the physical facilities, network, and hypervisor layers that run AWS services. You are responsible for security in the cloud: configuring workloads, managing identities and access, managing encryption keys, classifying which resources hold ePHI, and deploying the safeguards the Security Rule requires within your environment. Nothing in the NPRM changes that split. What changes is how specific your side of it becomes.
Two foundations come before anything else. First, accept the AWS Business Associate Addendum (BAA) in AWS Artifact before you process ePHI; if you use AWS Organizations, you can accept the BAA once for every account in the organization. Second, confirm that every service that handles ePHI appears on the HIPAA Eligible Services Reference, which listed more than 170 services as of October 2026 and is updated as services are added. AWS Backup, Amazon Bedrock, and the Kiro agentic IDE (excluding Kiro Web) are all on the list, which matters for the tooling later in this post.
Backup and recovery on AWS
The NPRM introduces three distinct backup and recovery obligations: a 48-hour recovery point objective for ePHI, a 72-hour recovery time objective for critical systems and data, and a monthly restore test with documented results. The following sections show how AWS Backup helps you meet each one.
48-hour backup recovery point
AWS Backup is a policy-driven service that centralizes backup across supported AWS services. A backup plan the schedule. Snapshot backups can run as frequently as hourly from the console, the AWS Command Line Interface (AWS CLI), or a cron expression, well inside the proposed 48-hour window. For supported resources, continuous backup adds point-in-time recovery on top of scheduled snapshots.
Backups that an unauthorized user can delete do not satisfy the intent of the proposal. AWS Backup Vault Lock in compliance mode addresses that risk: after the grace period you configure expires, neither the recovery points nor the lock itself can be altered or deleted by any user, including the account root user, or by AWS, until the retention period ends. Pair the lock with a logically air-gapped vault or a cross-account copy so that a unauthorized access to the production account does not reach the copies you will restore from.
72-hour restoration window
Restoring within 72 hours is an orchestration problem as much as a storage problem. AWS Step Functions lets you express the full recovery sequence as a state machine: start the restore jobs from the backup vault, rebuild compute, storage, and database resources from infrastructure-as-code, redeploy applications, and run smoke tests, with retries and error handling defined once and exercised on every run. A recovery workflow that runs as code is one you can time, which is exactly the evidence the proposed 72-hour requirement calls for.
Monthly restore testing
AWS Backup restore testing automates the monthly test the NPRM proposes. A restore testing plan runs on a cron schedule you choose, selects specific or random recovery points from the vaults you include, infers the metadata each restore needs, performs the restores, and records how long they took. You can add validation by having an Amazon EventBridge event invoke an AWS Lambda function that queries the restored resource and reports success or failure back to AWS Backup, and the service deletes the test resources after the validation window closes. The results, together with the reports in AWS Backup Audit Manager, give your compliance officer dated evidence of successful restores without touching production.
Find your gaps with the HIPAA Assistant
Knowing the requirements is one thing. Finding the handful of places in a large AWS estate that would fail a Security Rule review is another. The HIPAA Assistant is an open source sample published under aws-samples with the MIT-0 license. Point it at your AWS CloudFormation or Terraform templates and it lists potential gaps in plain terms, each tied to the Code of Federal Regulations (CFR) text it comes from, with a link to the exact paragraph on eCFR.gov.
The HIPAA Assistant is a sample project, not an AWS service. It carries no service level agreement or support commitment, it does not make compliance determinations, it never reports a resource as compliant, and it cannot know which of your resources hold ePHI. Treat its output as cited guidance to confirm with your security and privacy officers and qualified counsel.
What it does
The tool has two surfaces that share one cited core written in Go. The command line interface runs in your terminal or your CI/CD pipeline, and a Model Context Protocol (MCP) server exposes the same logic to an AI assistant such as Kiro. In both cases it does the following:
Reviews infrastructure-as-code. review-infra scans CloudFormation (JSON and YAML) and Terraform (HCL) for Security Rule gaps such as unencrypted storage, disabled backups, and missing audit trails. It runs offline and needs no AWS account.
Reviews application code. review-code looks for issues such as hardcoded secrets, disabled TLS verification, weak cryptography, and ePHI written to logs. That analysis needs a large language model: the command line calls Amazon Bedrock in your own account and AWS Region, and the MCP server hands the same cited checklist to your assistant’s own model. Either way, the tool checks that each finding’s quote appears verbatim in your file.
Cites every finding. Each result names the control and links to the exact eCFR paragraph; through the MCP server, answers also include the verbatim regulation text and its version date. The regulation text is fetched live from the eCFR API and cached, so citations stay current without a new release.
Produces reports. Findings render to HTML, Markdown, CSV, or SARIF 2.1.0 for code-scanning dashboards.
How to get started
The tool is distributed as Go source. Install it with Go 1.26 or later, which places the binary in your Go bin directory (usually ~/go/bin), then run a review against a template or directory. The infrastructure review runs offline:
Install (requires Go 1.26+; add $(go env GOPATH)/bin to your PATH)go install github.com/aws-samples/sample-hipaa-assistant/cmd/hipaa-assistant@latest
# Review infrastructure-as-code (offline, no AWS account needed)hipaa-assistant review-infra path/to/your/infra # replace with your template or directory
# Review application code (calls Amazon Bedrock in your account; needs AWS credentials)hipaa-assistant review-code path/to/your/src –region us-east-1 # replace path; –region defaults to us-east-2
# Write a shareable report (.html, .md, .csv, or .sarif)hipaa-assistant review-infra path/to/your/infra –out report.html
# Gate a CI/CD pipeline: exits 1 when potential issues are found, 0 when cleanhipaa-assistant review-infra path/to/your/infra –fail-on-findings –out results.sarif
# If you use AWS CDK, synthesize first, then review the CloudFormation outputcdk synth && hipaa-assistant review-infra cdk.out/
The review-code command sends the source files you point it at to Amazon Bedrock in your account and transmits nothing else; the review-infra, command is fully offline, and the find_controls, and get_regulation tools make no model calls; they only fetch public regulation text from eCFR.gov. If you use the AWS Cloud Development Kit (AWS CDK), run cdk synth first and review the synthesized CloudFormation in cdk.out/, as the last example shows. The repository README includes a minimal AWS Identity and Access Management (IAM) policy that grants review-code only the Bedrock model invocation permissions it needs.
Connect it to your AI assistant
The HIPAA Assistant also runs as an MCP server, so you can ask compliance questions in plain language from Kiro or another MCP client such as Claude Code. One command writes the client configuration for you:
# Kiro: writes ~/.kiro/settings/mcp.json
hipaa-assistant install-mcp --kiro
# Claude Code: writes .mcp.json in the current directory
hipaa-assistant install-mcp --claudeAfter you reload your assistant, you can give it requests such as “Explain what HIPAA requires for encrypting patient data at rest on AWS” or “Review this CloudFormation for HIPAA gaps,” and the assistant answers with the control citation, the verbatim eCFR text, and the regulation’s version date. The server exposes five tools:
| Tool | What it does |
find_controls |
Finds the Security Rule controls relevant to a question or AWS topic |
get_regulation |
Returns verbatim CFR text with citation, version date, and source URL |
review_infra |
Reviews CloudFormation or Terraform for potential issues |
review_code |
Supplies the cited concerns to check and verifies that each finding’s quote appears verbatim in the file |
generate_report |
Produces a shareable, cited findings report for a compliance officer |
The HIPAA Assistant reviews templates and code before they deploy. Pair it with the AWS Config conformance pack for HIPAA Security and AWS Security Hub for continuous coverage of the resources already running in your accounts.
What you should do today
You do not need to wait for the final rule to start. The following six steps are ordered so that each one produces evidence you will need regardless of how the final rule reads.
Step 1: Put the foundation in place. Accept the AWS BAA in AWS Artifact, at the organization level if you use AWS Organizations, and confirm that every service handling ePHI is on the HIPAA Eligible Services Reference.
Step 2: See where you stand. Install the HIPAA Assistant and run hipaa-assistant review-infra against your templates. Each finding tells you what is missing and which paragraph of the regulation it relates to.
Step 3: Close the direct gaps first. Verify encryption at rest with AWS Key Management Service (AWS KMS) and in transit with TLS on Elastic Load Balancing listeners and private connectivity through AWS PrivateLink. Require MFA for everyone who accesses ePHI; AWS IAM Identity Center can prompt for MFA on every sign-in. Check that your AWS Backup plans produce recovery points at least every 48 hours and that the vaults are locked.
Step 4: Connect the tooling to your workflow. Run hipaa-assistant install-mcp --kiro so that developers get cited answers while they work, and add --fail-on-findings to your pipeline so that templates with open findings do not deploy.
Step 5: Build your roadmap. Inventory the systems that hold ePHI so that you know which assets need the new controls. Then scope the larger projects: network segmentation, a penetration testing vendor, written and tested incident response plans, and the annual compliance audit. Talk to your AWS account team about architecture guidance and introductions to AWS Partners with healthcare compliance practices.
Step 6: Generate your evidence. Run hipaa-assistant review-infra path/to/your/infra --out report.html to produce a cited report, export AWS Backup restore test results, and store both in a compliance repository: an Amazon Simple Storage Service (Amazon S3) bucket with S3 Object Lock in compliance mode, so that evidence cannot be altered or deleted during its retention period. The Security Rule already requires that this documentation be retained for six years, and the NPRM keeps that requirement.
Budget planning belongs alongside these steps. Penetration testing vendors, incident response retainers, segmentation projects, and staffing all run on procurement and budget cycles that are longer than the proposed 180-day compliance period, and scoping them early avoids the premium cost of emergency implementation.
Conclusion
In this post, we summarized the proposed HIPAA Security Rule update: the removal of the addressable category, the 16 requirements that most affect how you build on AWS, the penalty tiers already in force, and the July 2027 projected final action date. We described how AWS Backup, AWS Backup Vault Lock, restore testing, and AWS Step Functions map to the proposed 48-hour, 72-hour, and monthly backup obligations, and how the open source HIPAA Assistant finds and cites Security Rule gaps in your templates and code before they reach production.
Start with the BAA and the eligible services check, run the HIPAA Assistant against your infrastructure this week, and bring the findings to your next budget conversation. For help interpreting the requirements, identifying gaps, or carrying out remediation, contact your AWS account team, or use the AWS Partner Solutions Finder to find AWS Partners who specialize in healthcare compliance. To learn more about HIPAA on AWS, see the HIPAA compliance page. If you have feedback about this post or the HIPAA Assistant, open an issue in the GitHub repository.
This post is for informational purposes only and is not legal advice. Requirements described are proposed (NPRM) and subject to change on finalization. Based on HHS OCR NPRM 90 FR 898 (January 6, 2025), the OMB Unified Agenda entry for RIN 0945-AA22, 45 CFR Part 102 (civil monetary penalty amounts as adjusted on January 28, 2026), the HHS Notification of Enforcement Discretion Regarding HIPAA Civil Money Penalties (84 FR 18151, April 30, 2019), and AWS documentation as of October 2026. Customers are responsible for their own compliance. Consult qualified legal and compliance counsel.