Inside Our Compliance Stack

Introduction

This article walks through our compliance stack layer by layer: what each component does, how they connect, and why the layering matters. It is the technical companion to our Vanta partnership announcement, which covers the business context, and our article on why manual compliance fails at scale, which explains what this approach replaces.

The stack is not complicated. It has three layers, each with a clear responsibility:

1. Infrastructure layer (HealthStack): provisions compliant cloud resources.
2. Application layer: implements security controls in code.
3. Monitoring layer (Vanta): verifies controls continuously and collects evidence.

The value is not in any individual layer. It is in the fact that the monitoring layer can verify the infrastructure and application layers continuously, without manual intervention, across multiple compliance frameworks simultaneously.

Layer 1: Infrastructure (HealthStack)

HealthStack is our open source collection of Terraform modules for deploying HIPAA-compliant AWS infrastructure. It handles the cloud resources that most compliance frameworks require: isolated networking, encryption, access controls, logging, and backup.

What HealthStack deploys

VPC networking. Private subnets for PHI processing. No PHI-touching workloads run in public subnets. NAT gateways for outbound traffic. VPC Flow Logs capture all network traffic for audit purposes.

KMS encryption. Customer-managed encryption keys with annual rotation, VPC-scoped access policies, and 30-day deletion windows. KMS keys encrypt RDS databases, S3 buckets, EBS volumes, and ElastiCache clusters. The key configuration denies non-VPC access explicitly.

RDS database hardening. AES-256 Transparent Data Encryption with KMS-managed keys. Multi-AZ deployment for clinical systems. 35-day backup retention minimum. Deletion protection enabled. No public accessibility. CloudWatch log exports for audit trail.

S3 bucket security. KMS encryption (not SSE-S3). Versioning enabled for data integrity. Public access blocks on all four settings. Bucket key optimization for cost efficiency.

IAM access controls. Least-privilege IAM policies scoped to specific resources. Service-linked roles for AWS services that need cross-service access. No root account usage in production. MFA enforcement for console access.

Logging and monitoring. CloudTrail enabled with multi-region coverage and log file validation. AWS Config for continuous configuration compliance monitoring. GuardDuty for threat detection. CloudWatch for application and infrastructure metrics. Security Hub for centralized security findings.

Why this matters for compliance

When Vanta connects to a HealthStack deployment, the automated compliance checks pass from day one. There is no remediation phase for infrastructure controls because HealthStack encodes the compliance requirements into the Terraform configuration. The infrastructure is not compliant by accident or by manual configuration; it is compliant by design.

This also means infrastructure compliance is reproducible. New environments (staging, production, disaster recovery) get the same compliance posture automatically. There is no manual checklist for "make sure encryption is enabled on the new database." The Terraform module handles it.

Layer 2: Application Controls

Infrastructure compliance is necessary but not sufficient. The application that runs on the infrastructure must also implement security controls. These controls are built into the codebase, not managed through AWS console settings.

Encryption

At rest: All PHI is encrypted using AES-256 before storage. Database-level encryption via RDS TDE handles storage encryption transparently. Application-level encryption adds a second layer for sensitive fields (SSN, clinical notes) using envelope encryption with KMS-managed data keys.

In transit: TLS 1.2 or higher for all connections. This includes client-to-server (via ALB), server-to-database (via RDS SSL), and server-to-server (via VPC internal traffic). Certificate management is automated through AWS Certificate Manager.

Access control

Role-based access control (RBAC). Users are assigned roles that map to specific permissions. A clinician role can read patient records; an administrator role can manage user accounts; an audit role can read logs but not modify data. Permissions are defined in code and enforced at the API layer.

Session management. Session timeouts are configured based on context: 15 minutes for clinical workstation sessions, 5 minutes for mobile sessions. Sessions are invalidated on logout, password change, and role change. Session tokens are cryptographically random, stored server-side, and transmitted only over TLS.

Authentication. Multi-factor authentication for all user accounts with access to PHI. OAuth 2.0 with PKCE for API authentication. Password policies enforce minimum complexity requirements. Failed login attempts trigger progressive delays and account lockout after configurable thresholds.

Audit logging

Every access to PHI generates an audit log entry. The entry captures: who accessed the data (user ID, role, IP address), what was accessed (resource type, record identifier, no actual PHI values), when (timestamp in UTC), the action performed (read, create, update, delete), and the outcome (success or failure with reason).

Audit logs are immutable. They are written to a dedicated log store with append-only permissions. No user role, including administrators, can modify or delete audit records. Logs are retained for a minimum of 6 years (HIPAA requirement) and are available for search and export.

The logging implementation follows a principle from our HIPAA compliance guide: never include actual PHI values in logs. Log entries reference records by identifier, not by content. This means the audit trail itself does not become a PHI storage location that requires its own compliance controls.

Integrity controls

Data validation at every system boundary. Input from users, external APIs, and file uploads is validated against expected schemas before processing. This prevents both data corruption and injection attacks.

Change tracking for all PHI records. Every modification creates a versioned record with the previous state, the new state (excluding PHI content in the audit record), the user who made the change, and the timestamp. This satisfies HIPAA's integrity control requirements and provides a complete modification history for audit purposes.

Layer 3: Monitoring (Vanta)

HealthStack builds compliant infrastructure. Application controls enforce security policies in code. Vanta verifies that both layers are working correctly, continuously, across all applicable compliance frameworks.

How Vanta connects

Vanta integrates with the cloud environment through API connections, not agents. It reads configuration state from:

• AWS: IAM policies, S3 bucket configurations, RDS settings, VPC network configuration, CloudTrail status, KMS key policies, Security Hub findings.
• Identity providers: User accounts, MFA status, access permissions, group memberships.
• Development tools: Repository access controls, branch protection rules, CI/CD pipeline configurations, code review requirements.
• HR systems: Employee records, onboarding/offboarding status, training completion.

These connections are read-only. Vanta monitors your environment; it does not modify it.

What gets checked

Vanta runs automated checks against framework-specific control requirements. For a typical healthcare deployment with HIPAA, SOC 2, and GDPR, the checks include:

Infrastructure checks:

• Encryption enabled on all storage resources (RDS, S3, EBS, ElastiCache).
• KMS key rotation policies active.
• VPC Flow Logs enabled.
• CloudTrail enabled with log file validation.
• No public S3 buckets.
• No unrestricted security group rules (0.0.0.0/0 inbound).
• Multi-AZ deployment for production databases.
• Backup configurations meet retention requirements.

Access control checks:

• MFA enabled for all user accounts.
• No root account access keys.
• Least-privilege IAM policies (no wildcard permissions on production resources).
• Inactive user accounts flagged for review.
• Former employee accounts deactivated within required timeframes.

Organizational checks:

• Security awareness training completed by all employees.
• Background checks completed for employees with PHI access.
• Vendor risk assessments documented for all subprocessors.
• Incident response plan current and tested.
• Business continuity plan documented.

Continuous evidence collection

Every automated check produces a timestamped evidence artifact. These artifacts are stored in Vanta and organized by framework and control. When an auditor requests evidence for a specific control, the evidence already exists as a series of timestamped records showing the control's status over time.

This replaces the manual evidence collection cycle (quarterly screenshots, configuration exports, access list downloads) with continuous records. The difference matters during audits: instead of showing that a control was in place on the four dates you checked, you show that it was in place continuously, with an alert history showing any temporary deviations and their remediation.

Alert and remediation flow

When a check fails (a control drifts from its expected state), Vanta generates an alert. The alert includes:

• Which control failed.
• Which frameworks are affected.
• What the expected state is and what the current state is.
• When the drift was detected.

Momentum's operations team receives these alerts and either remediates directly (for infrastructure and configuration changes) or notifies the client's team with specific remediation steps. The goal is to resolve drift within hours, not at the next quarterly review.

Cross-Framework Control Mapping

One of the most valuable functions of the monitoring layer is cross-framework control mapping. A single technical control often satisfies requirements in multiple frameworks.

For example, encryption at rest with AES-256 satisfies:

• HIPAA 45 CFR 164.312(a)(2)(iv): Encryption and decryption mechanism.
• SOC 2 CC6.1: Logical and physical access controls, encryption of data at rest.
• GDPR Article 32(1)(a): Encryption of personal data.

In a manual model, you track this control three times in three separate spreadsheet tabs with three different descriptions. When the encryption configuration changes, you update three places (or, more commonly, you update one and forget the other two).

In the automated model, Vanta maintains the mapping. When it checks the encryption configuration, it updates the compliance status for all three frameworks simultaneously. A single change produces a single evidence artifact that satisfies all applicable controls.

For a typical healthcare deployment, the overlap between HIPAA, SOC 2, and GDPR covers approximately 40% of the combined control requirements. Automating the cross-framework mapping turns that overlap from a source of confusion (which controls map where?) into a source of efficiency (one check, three frameworks).

What a Deployment Timeline Looks Like

For a new healthcare product starting from scratch with HealthStack:

Week 1 to 2: HealthStack deployment. HIPAA-compliant AWS infrastructure provisioned via Terraform. VPC, RDS, S3, KMS, IAM, CloudTrail, Config, GuardDuty configured.

Week 2 to 4: Application controls implemented. Encryption, RBAC, audit logging, session management, authentication integrated into the application codebase.

Week 3 to 4: Vanta onboarding. Cloud integrations connected, identity provider linked, initial baseline scan completed, framework-specific control mappings configured.

Week 4 onward: Continuous compliance. Automated checks running, evidence collecting, alerts configured. The system is in steady state.

For existing products that need compliance remediation, the timeline depends on the gap analysis findings. Infrastructure gaps (missing encryption, incomplete logging) typically take 2 to 4 weeks to address. Application gaps (missing access controls, incomplete audit trails) may take 4 to 8 weeks depending on the codebase.

The compliance automation (Vanta) layer connects after the remediation work is complete. In some cases, we connect it during remediation to track progress: you can see the failing checks turn green as each gap is addressed.

Talk to Us

If you want to see this stack in the context of your own infrastructure and compliance requirements, we start with a gap analysis. It identifies where your current architecture stands relative to your target frameworks and produces a concrete engineering plan for closing the gaps.

Contact us to discuss your compliance architecture.