Deploying SOC 2 and HIPAA Controls at the AWS Infrastructure Layer Before Your First Audit

Deploying SOC 2 and HIPAA controls on AWS before a first audit is a sequencing decision. The infrastructure must have access, encryption, logging, and network boundaries enforced before the observation period starts. Teams that build those controls into the foundation arrive with evidence of controls operating.

What the shared responsibility model actually leaves on your plate

AWS’s own SOC 2 report is evidence for the physical infrastructure layer. In a customer’s SOC 2 engagement, AWS controls are “carved out” as a subservice organization. The auditor will want that report, but the customer’s report covers what the customer operates directly. The customer is fully responsible for access permissions, encryption settings, audit logging, and network boundaries.

Running on AWS therefore does not make those configurations partly compliant by inheritance. AWS secures the underlying cloud, while customers secure their workloads, data, and access. HIPAA draws the same distinction. AWS will sign a Business Associate Addendum that opens the legal gate for eligible services, while the customer remains responsible for workload compliance controls.

How SOC 2 Trust Services Criteria and HIPAA technical safeguards map to specific AWS services

SOC 2’s mandatory Security criterion maps to three infrastructure control families. For CC6, logical and physical access, IAM, IAM Identity Center, MFA enforcement, and IAM Access Analyzer address who can gain access. Service Control Policies constrain permissions, while KMS and Secrets Manager protect keys and secrets. Security groups, AWS WAF, Systems Manager Session Manager, S3 Block Public Access, and Macie address network access, administrative access, and data protection. Each configuration needs a defined control purpose.

CC7, system operations, maps to AWS Config, Amazon Inspector, organization CloudTrail with log file validation, CloudWatch alarms, GuardDuty, Security Hub, and Amazon Detective. These support configuration checks, vulnerability detection, logging, monitoring, and investigation. CC8 covers how changes get to production. Infrastructure as code in version control through CloudFormation, CDK, or Terraform supports that change control obligation, together with CodePipeline, CodeBuild, and separate environment accounts.

HIPAA’s technical safeguards under §164.312 overlap with that map. Least-privilege IAM policies and Identity Center support access controls and MFA. KMS supports encryption at rest under §164.312(a) for S3 through SSE-KMS, EBS, RDS, DynamoDB, and EFS, while TLS 1.2 or higher protects endpoints in transit under §164.312(e). For audit controls under §164.312(b), the services are CloudTrail in all regions, VPC Flow Logs, and S3 access logging. PHI workloads belong in a dedicated account with strict access controls.

The scope still needs a firm boundary. Availability, Confidentiality, Processing Integrity, and Privacy are added only when customers or regulations require them. Starting with all five criteria makes the audit harder than the added benefit warrants for most startups. Processing Integrity also extends beyond infrastructure configuration. AWS’s own SOC 2 scope excludes it, so customers need application-layer controls and evidence of test results themselves.

Why CloudTrail configuration is the single most consequential control to get right early

A default CloudTrail setup is not an audit-ready setup. A single-region trail without log file validation, a protected destination bucket, or KMS encryption leaves specific evidence gaps. Those gaps are difficult to repair after the observation period has begun because auditors need to establish the integrity of the records from that period. A trail’s existence is not enough on its own. Without validation, its value as evidence can be contested.

The target configuration has four properties working together. A multi-region trail records API activity outside the primary region as well. Log file validation creates cryptographic digest files that prove logs were not modified after delivery. An immutable destination S3 bucket uses Object Lock in Compliance mode so that administrators, including the root user, cannot change or delete protected logs. KMS encryption applies to the trail and bucket.

For HIPAA, those API records go alongside the network-flow and data-access records from VPC Flow Logs and S3 access logging. Each covers a different class of activity. Application logs need their own protection, too. PHI can appear in CloudWatch log data, so log groups need KMS encryption and applications need to sanitize what they emit.

Multi-account structure as the architectural foundation auditors expect to see

With a single account, regulated workloads, development access, and ownership of logs all sit within the same account boundary. That structure cannot provide the account-level separation needed to make these controls independently enforceable and auditable. Account design is therefore a compliance decision. The foundation separates at least five roles into security, production, staging, development, and sandbox accounts. Security centralizes logging and security-tool aggregation, while production runs regulated workloads under strict organization-level policies.

Staging uses production-equivalent controls for pre-production validation. Development gives engineers relaxed but bounded policies, and the sandbox supports experiments with spend limits. Access and security logs replicate to a dedicated Logs Archive account with Object Lock in Compliance mode. That archive protects the evidence from administrative alteration. Service Control Policies can prohibit disabling CloudTrail, public S3 buckets, IAM user creation, and deployments outside approved regions.

For PHI, a dedicated workload account also bounds the HIPAA compliance scope rather than extending the full control set across every account. Clearway Health needed PHI security from day zero. FivexL deployed its multi-account environment with an account baseline factory, centralized security tooling, SSO, shared networking, KMS encryption, and pre-configured workload accounts. Evidence collection was built into the architecture.

The HIPAA BAA and eligible-services list as a compliance boundary that must be mapped before building

The AWS Business Associate Addendum covers only HIPAA-eligible services. Accepting it through AWS Artifact designates the account, or every account in an AWS Organization, as a HIPAA Account. PHI may then be processed, stored, or transmitted only through services on the HIPAA Eligible Services Reference. This is an architectural constraint. Strong encryption and access controls do not bring an ineligible service inside the agreement.

The reference’s October 15, 2026 update includes Amazon Bedrock and Amazon Bedrock AgentCore. That gives teams building AI inference workflows over PHI services they can assess that fall within the legal boundary. Every service that touches PHI must be mapped against the eligible list before building the workflow. Discovering an ineligible service afterward means rebuilding that part of the architecture. The BAA must also be in place before PHI processing starts, and EBS snapshots or AMIs containing PHI need encryption.

Why AWS Audit Manager's maintenance mode changes evidence collection strategy for new accounts

AWS placed AWS Audit Manager in maintenance mode from April 30, 2026, blocking setup in new accounts or regions. Its two prebuilt HIPAA frameworks had made it a common starting point for automated evidence collection. New-account plans can no longer depend on that path.

AWS points new users toward Config conformance packs instead. These keep checking resource configurations against rules and produce findings that teams can use as compliance evidence. Security Hub’s Foundational Security Best Practices standard is still available to keep checking security controls and finding misconfigurations. It is another place to start looking for gaps. For new accounts, the practical response is to build the evidence strategy around Config conformance packs and Security Hub from the outset, rather than retrofit a plan built around Audit Manager.

Timing the observation period: why controls must be live before the clock starts

SOC 2 Type I assesses control design at a point in time and is typically achievable in two to four months for startups. Type II assesses operating effectiveness over a six-to-twelve-month observation period, and most enterprise buyers require it. The distinction changes the deployment sequence. Controls must be running and evidence must be collected before the Type II window opens. Gaps during that window become audit findings.

The clock does not pause for remediation work. Fixing a control midway through the period does not prove that it worked before the fix. The timing problem is recoverable, but it requires establishing the foundation rather than treating missing controls as paperwork to finish later. Over-scoping compounds the burden when teams include all five criteria despite needing only Security.

CI/CD pipelines and IaC scanning as change-management evidence, not just engineering practice

SOC 2 CC8 requires evidence that changes go through an approved process before they reach production. An automated pipeline through GitHub Actions or CodePipeline creates a deployment record showing who triggered the change, what code was reviewed, what tests passed, and when it reached production. That record supports CC8.1 evidence that review preceded the change. A manual deployment does not produce that pipeline record.

Infrastructure changes need the same scrutiny as application code. Checkov and tfsec are examples of tools that scan Terraform in pull requests for public S3 buckets, unencrypted RDS instances, overly permissive security groups, and missing encryption. Their findings create a visible record of security review before merge. But documentation alone is not an enforced control. Separate production, staging, and development accounts create a boundary that keeps deployment paths from bypassing the pipeline.

This distinction also answers a broader objection to compliance work. A pipeline can generate paperwork without preventing unsafe changes if its controls can be bypassed. Evidence shows what passed through the process. Enforcement establishes whether production changes had to follow it.

CVE management and vulnerability scanning as ongoing compliance obligations, not one-time tasks

A scan run just before an audit proves that someone completed a task. It does not prove that vulnerability management operated throughout the observation period. Amazon Inspector can keep scanning EC2 instances, ECR container images, and Lambda functions. ECR image scanning in the CI/CD pipeline can block deployments with critical CVEs. That gate creates an enforcement record showing that deployments passed the security check before they reached production.

The operating system needs an ongoing process as well. Systems Manager Patch Manager handles OS-level patching during scheduled maintenance windows, and the schedule and execution history show that it ran. Enforcing IMDSv2 on EC2 instances closes a specific credential-exposure vector flagged in infrastructure reviews. These controls address different parts of the environment. None replaces the need to define how quickly findings must be resolved.

Remediation SLAs turn scanner output into a measurable program. A documented standard might allow 30 days for high-risk findings and a longer window for medium-risk findings. Auditors can then compare the record against that commitment. Without a defined deadline, findings show detection but not whether remediation met an agreed standard. Continuous monitoring also helps keep configuration drift from leaving gaps in compliance between audits.

When to move PHI workloads off PaaS and what the infrastructure foundation trade-offs look like

Shared-tenant PaaS infrastructure presents a specific compliance trade-off. Network boundaries, access granularity, and log ownership are areas where shared infrastructure can limit the evidence a team can produce. Teams looking at PHI hosting should therefore check whether a BAA is currently available and what it covers before they commit. The legal mapping exercise is not unique to AWS. A managed platform’s agreement must cover the services that will actually touch PHI.

Building a compliance-ready AWS environment from the start avoids the later cost of migrating and remediating those gaps. The foundation is not free to operate. CloudTrail, Config, GuardDuty, and Security Hub create a baseline infrastructure cost that can be quantified from day one. The less visible expense is engineering time spent on management work and remediation that a proper foundation avoids.

The choice is not simply PaaS simplicity against AWS complexity. The right abstraction layer can preserve deployment speed while giving a team its own cloud account and the controls enterprise sales require. For teams already on shared infrastructure, the account boundaries, protected logs, and enforced deployment controls described here define the destination. They are the starting point for a migration.