The security team thought everything was ready for HITRUST, but a single over-permissive S3 role killed the mood, the timeline, and the compliance report.
If you want HITRUST certification and you’re running on AWS, your S3 access structure matters more than you think. Auditors will dig into IAM policies, identity inheritance, and the principle of least privilege. A read-only role that leaks into write permissions—even by accident—breaks your compliance story.
HITRUST maps controls across HIPAA, ISO, NIST, and more. For AWS S3 specifically, the relevant control requirements demand strict, job-specific permissions. A compliant read-only design involves:
- Minimal privilege scope for the role.
- Explicit deny for all write operations.
- Tight resource ARN matching without wildcards.
- Intentional session duration for role assumption.
- Active logging and immutable audit trails.
It’s common to overuse s3:* in IAM policy actions, assuming a bucket policy will handle the guardrails. Under HITRUST, this isn’t enough. The role itself must enforce least privilege with s3:GetObject, s3:ListBucket, and nothing more—unless you can justify the risk and log an approved exception.