Building a HITRUST i1-Ready Environment on AWS
AWS has published a new implementation guide for organizations preparing cloud-based healthcare systems for a HITRUST i1 validated assessment. The guide moves beyond high-level compliance principles and demonstrates how HITRUST security objectives can be implemented using specific AWS architecture patterns, security services, and operational processes.
The paper uses a fictional connected medical-device platform to explain how an organization might define its assessment boundary, structure AWS accounts, isolate workloads, protect patient data, centralize security monitoring, and produce evidence for an assessor. It focuses on 11 HITRUST technical domains with direct AWS implementation components, including access control, configuration management, vulnerability management, network protection, encryption, incident management, audit logging, data protection, and disaster recovery.
The most important lesson, however, is not about any individual AWS service. HITRUST readiness depends on treating security controls as an operating system for the business, not as configurations enabled shortly before an audit.
HITRUST i1 is focused, but still substantial
The HITRUST i1 assessment uses a fixed set of 182 curated controls evaluated at the Implemented maturity level. It is valid for one year and is commonly used by healthcare vendors, business associates, and mid-market organizations that need stronger third-party assurance than an entry-level assessment but do not require the broader, risk-based scope of HITRUST r2.
A fixed control set makes i1 more predictable than r2, but it does not make the assessment automatic or purely technical. The AWS guide addresses the portions that can be implemented through cloud architecture and AWS services. Organizational requirements such as workforce training, governance, human-resources processes, third-party management, and policy documentation remain the customer’s responsibility.
That distinction should influence project planning from the beginning. A technically sound AWS environment is necessary, but certification also requires documented processes and evidence showing that those processes are consistently followed.
The first major decision is the assessment boundary
A common misconception is that HITRUST certifies an entire company. In practice, the organization defines an implemented system for assessment. That system might be a product, application platform, business unit, or other controlled environment.
The boundary includes more than the application code. It can include:
The AWS accounts and services running the application
Databases and storage containing ePHI
Identity and access-management systems
Logging, monitoring, and incident-response services
Deployment and change-management processes
The employees and operational procedures supporting production
The AWS guide describes the implemented system as the application, its infrastructure, the security controls applied to that infrastructure, and the people and processes that keep it operating securely.
Systems outside the organization’s operational control may be excluded. For example, a patient’s personal phone may fall outside the assessment boundary, while the backend API used by the mobile application remains in scope. Similarly, an external EHR platform may be outside the boundary, while the FHIR API transmitting ePHI to that platform remains part of the assessed system.
The practical scoping question is therefore not simply, “Which AWS accounts do we include?” It is:
Which systems create, receive, process, store, transmit, or derive information from PHI, and do we have enough operational control to demonstrate that the required controls are functioning?
Overly broad scoping increases the number of systems, services, people, and processes that must be assessed. Scoping too narrowly can omit important dependencies or produce a certification that does not cover what customers expect. The boundary should follow PHI data flows and operational responsibility.
AWS certification does not certify the customer’s application
AWS operates under a shared responsibility model. AWS is responsible for the physical data centers, hardware, networking infrastructure, hypervisor, and underlying operation of managed services. AWS maintains its own HITRUST certification for applicable infrastructure controls, allowing customers to inherit supporting assurance evidence.
The customer remains responsible for everything configured or operated above that infrastructure layer, including:
IAM roles, permissions, and identity-provider configuration
Application security
Operating-system hardening and patching
Encryption keys and data classification
VPCs, security groups, routing, and firewall policies
CloudTrail, monitoring, and alert-response procedures
Backup configuration and recovery testing
Vulnerability remediation
Operational policies and evidence
The assessor evaluates the customer’s configuration and operational practices and not the security of an AWS data center.
AWS Artifact can provide the HITRUST Customer Responsibility Matrix and other assurance documentation needed to demonstrate inherited controls. Those documents reduce duplicated assessment work, but they do not remove the customer’s responsibility for configuring and operating AWS correctly.
Multi-account architecture becomes part of the control environment
The reference architecture uses a landing-zone-based, multi-account AWS organization. Foundational responsibilities are separated into dedicated accounts for management, security monitoring, log storage, networking, and shared identity services. Production workloads are then separated into accounts based on functional domains.
In the fictional example, device telemetry, clinical alerting, patient-data services, and device-lifecycle management each operate in separate production accounts.
This provides several compliance and security advantages:
An IAM error in one workload account is less likely to expose another workload.
Service Control Policies can enforce different restrictions based on data sensitivity.
Each account can use separate AWS KMS keys.
CloudTrail and configuration evidence can be associated with a clearly defined workload.
Network traffic can be routed through centralized inspection.
Unrelated development or corporate systems can remain outside the assessment boundary.
A compromise has a smaller potential blast radius.
A single production account may initially appear simpler, but it can create a much larger and less precise assessment surface. Every service, permission, network path, and operational dependency in that account may need to be evaluated or explicitly excluded. AWS therefore recommends account boundaries that reflect business capabilities and data-handling responsibilities.
Evidence generation must begin before the assessment
One of the most consequential planning details in the guide is the 90-day operational requirement. The assessed system must generally be installed, configured, and operating under the organization’s control for at least 90 days before the assessment begins.
During that period:
Security services must be enabled and generating records.
Access reviews and log-review procedures must be occurring.
Vulnerability scans must be running.
Findings must be triaged and remediated.
Incident-response procedures must be operational.
Backups and recovery processes must be exercised.
Configuration changes must be recorded through the approved process.
An organization cannot finish deploying its environment and immediately begin the assessment. New services introduced after the evidence period begins may also be difficult to include in the current assessment cycle.
The 90-day period should not be treated as idle waiting time. It is the period in which the organization proves that its controls operate consistently.
Turning AWS services into a control and evidence system
The guide maps HITRUST security objectives to AWS services and implementation patterns. Examples include:
Identity and access management
AWS IAM Identity Center, IAM roles, MFA, short-lived credentials, permission sets, and AWS Systems Manager Session Manager can support centralized authentication, least-privilege access, privileged-access controls, and audited administrative sessions.
The guide favors temporary credentials over long-lived access keys and recommends separating privileged and non-privileged access. AWS Secrets Manager can protect and rotate application and database credentials.
Configuration and vulnerability management
Infrastructure as code through AWS CloudFormation or the AWS Cloud Development Kit creates a repeatable baseline. AWS Config detects drift, while Security Hub aggregates security findings across accounts.
Amazon Inspector and Amazon ECR scanning can continuously evaluate virtual machines, container images, and compute environments for known vulnerabilities. The organization must still define remediation deadlines, assign ownership, document exceptions, and show that findings are resolved consistently.
Network protection
AWS Network Firewall, Transit Gateway, AWS WAF, Route 53 Resolver DNS Firewall, security groups, network ACLs, and VPC endpoints can support centralized traffic inspection and default-deny network policies.
In the reference architecture, production accounts do not independently expose broad internet access. Traffic is routed through a dedicated network account, inspected centrally, and restricted to documented ports, protocols, and destinations.
Encryption and data protection
AWS KMS supports separate encryption keys for sensitive workloads. AWS Certificate Manager, TLS policies, mutual TLS, API Gateway, Application Load Balancers, and AWS PrivateLink protect data moving between users, devices, applications, and services.
The organization remains responsible for deciding what data is sensitive, where it is allowed to flow, how long it is retained, and whether production data is permitted in non-production environments.
Logging and monitoring
The guide recommends an organization-wide, multi-Region CloudTrail configuration that sends activity to a centralized log-archive account. CloudWatch Logs, VPC Flow Logs, identity-provider logs, application logs, and data events provide additional visibility.
Amazon S3 Object Lock can make audit records tamper-resistant. GuardDuty, Security Hub, EventBridge, and Amazon SNS can detect events, aggregate findings, trigger remediation, and notify responders.
The value is not merely having logs. The organization must know which events are reviewed, who reviews them, what generates an alert, how alerts are escalated, and how response activity is documented.
Business continuity and recovery
AWS provides Multi-AZ deployment options, cross-Region replication, point-in-time recovery, AWS Backup, infrastructure-as-code reconstruction, health checks, and automated failover capabilities.
HITRUST readiness also requires the organization to define recovery objectives, test restoration procedures, document the results, and correct problems found during exercises. AWS can automate backup creation, but it cannot determine whether the organization’s recovery plan meets its business and patient-safety requirements.
Automation improves readiness, but does not produce certification
AWS Config records, CloudTrail events, Inspector scan results, GuardDuty findings, Security Hub reports, backup reports, and infrastructure-as-code repositories can significantly reduce manual evidence collection.
They can demonstrate:
When a control was enabled
Whether resources comply with a baseline
Who changed a configuration
When a vulnerability was identified
How quickly a finding was resolved
Whether logs remain complete and immutable
Whether backups and restore tests succeeded
This changes compliance work from assembling screenshots near the assessment date to maintaining a continuously observable control environment.
However, AWS explicitly cautions that the guide is generalized. It is aligned with the security objectives of HITRUST domains but is not a control-by-control substitute for the organization’s MyCSF assessment workbook. The assessed entity remains responsible for defining scope, satisfying the applicable evaluative elements, and demonstrating control effectiveness to a HITRUST Authorized External Assessor.
A practical readiness sequence
Organizations planning an i1 assessment on AWS should begin with the following sequence:
Define the implemented system. Document PHI flows, production dependencies, AWS accounts, Regions, users, supporting services, and exclusions.
Establish the shared-responsibility boundary. Obtain AWS assurance documentation and identify which controls are inherited, shared, or fully customer-operated.
Create the MyCSF assessment object. Use the actual MyCSF requirements as the authoritative control baseline.
Build or validate the landing zone. Separate production workloads, security monitoring, log storage, networking, and non-production environments.
Map controls to evidence. Identify the AWS service, configuration record, operational procedure, owner, and evidence source for every applicable requirement.
Automate evidence collection. Centralize CloudTrail, Config, Security Hub, GuardDuty, Inspector, vulnerability, backup, and access-review records.
Operate for at least 90 days. Perform reviews, resolve findings, test recovery, document changes, and retain the evidence.
Conduct a readiness review. Identify gaps before submitting the environment to an external assessor.
This sequence makes HITRUST readiness part of normal cloud operations rather than a separate audit project.
How Healthcare Blocks can help
Healthcare Blocks helps healthcare and life-sciences organizations design, operate, and assess secure AWS environments. Our managed AWS solution includes centralized auditing, CloudTrail and CloudWatch monitoring, GuardDuty analysis, Inspector vulnerability scanning, WAF management, disaster-recovery architecture, and monthly risk assessments.
Our advisory services also include system architecture reviews, platform engineering, AWS security training, and preparatory work for HITRUST and SOC 2 certifications.
For organizations pursuing HITRUST i1, that work can include:
Defining and documenting the AWS assessment boundary
Reviewing account and organizational-unit architecture
Mapping technical requirements to AWS services
Identifying configuration and evidence gaps
Centralizing security monitoring and logs
Implementing infrastructure-as-code baselines
Establishing evidence-retention workflows
Preparing the environment for assessor review
HITRUST certification is ultimately awarded through a formal validated assessment. The objective of readiness work is to make the environment defensible, observable, and operationally consistent before that assessment begins.
Closing Thoughts
AWS’s new guide provides a useful technical blueprint for organizations pursuing HITRUST i1 on AWS. Its strongest message is that successful assessment preparation requires more than enabling a collection of security services.
The organization must define the correct system boundary, isolate sensitive workloads, understand shared responsibility, operate controls consistently, and produce reliable evidence over time.
When those requirements are incorporated into the AWS architecture and everyday operating model, HITRUST readiness becomes more predictable, and the resulting environment is more secure, auditable, and resilient regardless of the assessment itself.
