Most health tech teams I audit have an IAM policy document that says “we follow the principle of least privilege.” Then I pull the IAM configuration and find admin-level policies attached to application roles, wildcard resource ARNs on S3 actions, and service roles that haven’t been scoped since the second engineer set them up eighteen months ago. The policy says least privilege. The configuration says full access. Auditors notice the gap immediately.
Here’s what a defensible IAM posture looks like for PHI workloads, mapped to the HIPAA and SOC 2 controls that actually get tested.
No IAM users for application workloads. This is the single common finding in health tech audits: an IAM user with long-lived access keys embedded in application code or environment variables, used to access S3 buckets containing PHI. The fix is IAM roles everywhere. EC2 instance profiles, ECS task roles, Lambda execution roles. The access key rotation policy in your SOC 2 control matrix becomes irrelevant where there are no access keys. Auditors checking HIPAA §164.312(d) — person or entity authentication — and SOC 2 CC6.1 want to see that application-level access to PHI is role-based with temporary credentials issued by STS, not static keys that live in a .env file.
Scope IAM policies to specific resources, not wildcards. The policy “Resource”: “*” on an S3 action means every bucket in the account, including the ones with PHI, the ones with audit logs, and the ones your backup process writes to. Auditors will ask for a sample of IAM policies attached to roles that access PHI and check whether the Resource field is scoped to the specific bucket ARN and prefix. The pattern that passes: “Resource": ["arn:aws:s3:::phi-data-prod", "arn:aws:s3:::phi-data-prod/*"] . The pattern that fails: “Resource": "*" . Same applies to KMS keys policies, DynamoDB table ARNs, and Secret Manager secret ARNs. Every PHI-touching action should reference a specific resource.
Separate roles per workload, not one shared role. A single ECS task role shared across your API service, your background worker, and your data pipeline means the background worker has the same PHI access as the API, even if it never needs it. Auditors testing CC6.3 — role-based access — want to see that each workload component has its own role with only the permissions that component requires. The evidence is straightforward: an IAM role inventory showing role-to-service mapping, with each role’s policy document demonstrating scope limited to that services's function. If your API reads from a PHI bucket and your worker writes to an analytics bucket, those should be two roles with two different policy documents.
Permission boundaries on developer roles. Developers need IAM permissions to build and deploy. They should not have permissions to read PHI in production. Permission boundaries solve this: attach a boundary policy to every developer IAM role that explicitly denies access to PHI-tagged resources in production, regardless of what other policies are attached. The control narrative for HIPAA §164.312(a)(1) — access control — reads: Developer roles are constrained by permission boundaries that prevent access to production PHI resources, enforced at the IAM layer independent of individual policy grants. This is the kind of defense-in-depth statement that closes the access control section cleanly.
IAM Access Analyzer, enabled and reviewed. Access Analyzer does two things auditors care about: it identifies resources shared externally (S3 bucket, KSM keys, IAM roles with cross-account trust), and it generates least-privilege policy recommendations based on actual CloudTrail usage. Enable it in every region, run the unused access analysis quarterly, and document the review. The evidence package is the Access Analyzer findings report, a reviewer signoff showing which findings were remediated and which were accepted with justification, and the date. This maps directly to CC6.1 periodic access reviews and HIPAA §164.308(a)(4) — information access management.
Service control policies at the org level for PHI accounts. If you’re running AWS Organizations — and you should be — SCPs on your PHI account should deny actions that could expose data outside the account boundary. Deny sharing AMIs publicly, deny disable CloudTrail, deny creating public S3 buckets, deny creating IAM users with console access in production. SCPs are the guardrail layer that catches misconfigurations before they become audit findings. The evidence is the SCP JSON attached to the PHI organizational unit, and a CloudTrail log showing a denied action as proof the SCP is actively enforced.
The pattern across all of these: IAM for PHI workloads is about provable constraints, not documented intentions. Your access control policy can say anything. What auditors test is whether the IAM configuration enforces it, whether the enforcement is continuous, and whether you have evidence that it was reviewed on a defined cadence. The gap between “we follow least privilege” and “here is the IAM policy, the permission boundary, the Access Analyzer report, and the quarterly review signoff” is the gap between a clean audit and a qualified finding.
If your IAM configuration predates your compliance program and you’re not sure what access your production roles actually have, the 2-week Transivone audit includes a full IAM posture review — every role, every policy, every cross-account trust, mapped to HIPAA and SOC 2 controls with a remediation priority list.
— Manan