Introduction

If you're building software that handles patient data or offers a SaaS product to enterprise clients, you're likely dealing with HIPAA, SOC 2, or any other regulation.

The problem is that regulations don't specify what compliance looks like in code. They describe objectives. Translating those objectives to your infrastructure, evaluating them, and keeping pace with your evolving codebase is left entirely to you.

We built GRC XL to close that gap: a compliance knowledge framework that translates regulatory requirements into structured, checkable controls tied to specific AWS configurations, with a pipeline that automatically evaluates your Terraform infrastructure against those controls. It starts with HIPAA and SOC 2, but the model is extensible for any regulation, cloud, and programming language.

If your team ships software that needs to stay compliant with every deployment, not just at audit time, this can help you build that assurance into your development process and stay on top of exactly what gets evaluated and how. In this post, we walk through how the framework is structured, how the pipeline works, and what it surfaced when we ran it against a real open source healthtech codebase.

From Regulation to Checkable Control

To better understand how to perform that technical translation and how to conduct automated evaluations, we break down regulation into categories, each category into domains, and each domain into controls. This is what each of them is:

• Framework: the regulatory standard the organization is measured against: SOC 2, HIPAA, but extendable.
• Category: a broad area of concern within that framework. For instance, SOC 2 groups its requirements into Security, Privacy, Process Integrity, Availability, and Confidentiality. We try to stick to them when we consider that it’s applicable to code review.
• Domain: a specific subject inside a category: access control, data handling, network security, for instance. The domain is where an abstract requirement becomes a concrete topic an engineer or agent can reason about.
• Control: a single, checkable requirement inside a domain. It states what must be true, why, and how to demonstrate it.

One real path through the tree:

SOC 2  > Security > Access Control > CTRL-S-AC-01: IAM Role-Based Access Architecture: 

“IAM role-based access architecture is used for all AWS account access; long-lived IAM user credentials are not used for production workloads”

But how do we evaluate the controls? Each domain has a runbook: a document that lists all the controls for that domain, provides detailed instructions on how to evaluate them, and documents when to classify them as “fail,” “pass,” or “needs more evidence.”

An example of a SOC 2 /  Privacy / Data Handling control is included at the end of this article.

From Controls to Findings: How the Pipeline Works

The pipeline has one job: check the controls defined in the framework against real infrastructure.

For each control, the system collects the Terraform files that count as evidence: IAM policies, S3 configurations, KMS settings, and any other resources identified by the control’s evaluation logic. That evidence is paired with the control definition and evaluated through a structured, rules-based assessment workflow. The result is a control verdict, supporting reasoning, and references to the exact resources examined.

The following are the three possible verdicts:

Because the assessment workflow reads static configuration, it can run anywhere the code lives, including on every pull request.

Running GRC XL on Open Source Healthtech Infrastructure

We ran GRC XL against the public Terraform repository of HealthStack from Momentum, a healthcare software and development company.

The pipeline returned findings on two transmission security controls: CTRL-H-DH-01 (ePHI Encryption in Transit) and CTRL-H-DH-05 (Minimum TLS Version Policy Enforcement). The reasoning in each finding pointed to the same thing: S3 buckets across three modules had no explicit bucket policy denying unencrypted transport or connections below TLS 1.2.

AWS's default allows both HTTP and HTTPS unless a deny policy is present. Without it, plaintext access is not explicitly blocked, even in infrastructure designed for healthcare data.

The change is two deny statements per bucket:

# HIPAA §164.312(e) - Transmission Security
{
  Sid       = "DenyInsecureTransport"
  Effect    = "Deny"
  Principal = "*"
  Action    = "s3:*"
  Resource  = ["${aws_s3_bucket.data.arn}", "${aws_s3_bucket.data.arn}/*"]
  Condition = {
    Bool = { "aws:SecureTransport" = "false" }
  }
},
{
  Sid       = "DenyOutdatedTLS"
  Effect    = "Deny"
  Principal = "*"
  Action    = "s3:*"
  Resource  = ["${aws_s3_bucket.data.arn}", "${aws_s3_bucket.data.arn}/*"]
  Condition = {
    NumericLessThan = { "s3:TlsVersion" = "1.2" }
  }
}

The Momentum evaluation ran in minutes, surfaced concrete findings, and the PR was merged.

What This Means for Your Team

GRC XL keeps compliance in the codebase. As your infrastructure changes, the pipeline re-evaluates it automatically. A change that affects a control gets flagged before it merges.

GRC XL is built and maintained by Xmartlabs. If you want to evaluate your infrastructure against HIPAA or SOC 2 controls, identify where it meets the requirements and where it doesn't, and integrate compliance checks into your CI workflow, we'd like to help. Talk to the Xmartlabs team

Are you handling compliance as part of your development cycle, or is it something that gets addressed when an audit comes up? We'd like to know