"Our auditor wants proof of S3 compliance, what do we give them?" Automating HIPAA S3 evidence for your auditor

#hipaa #aws #s3 #security

✓ Human-authored analysis; AI used for formatting and proofreading.

The Reddit Question

The thread on r/aws: "Our auditor wants proof of S3 HIPAA compliance. We have AWS Config and SecurityHub, but they want something more structured. What do we give them?"

The usual answers such as console screenshots, CSV exports, GRC platform PDFs are not what auditors need.

What Auditors Want

Auditors want evidence: deterministic, reproducible artifacts traceable to specific HIPAA requirements.

What was evaluated — which controls, mapped to which HIPAA sections
When it was evaluated — a timestamp for the compliance period
What the result was — COMPLIANT, NON_COMPLIANT, or AT_RISK with findings
That the evaluation is repeatable — same inputs, same output

How Stave Produces Evidence

Stave produces deterministic, machine-readable compliance evidence with HIPAA section citations in every finding:

stave evaluate \
  --controls controls/s3/ \
  --observations observations/ \
  --eval-time 2026-04-08T00:00:00Z \
  --format json

The JSON output follows the out.v0.1 schema:

{
  "schema": "out.v0.1",
  "evaluated_at": "2026-04-08T00:00:00Z",
  "summary": {
    "total_controls": 12,
    "total_assets": 5,
    "compliant": 4,
    "non_compliant": 1
  },
  "security_state": "NON_COMPLIANT",
  "findings": [
    {
      "asset": "phi-reports-bucket",
      "control": "CTL.S3.PRESIGNED.001",
      "severity": "MEDIUM",
      "status": "UNSAFE",
      "compliance": {
        "hipaa": "164.312(a)(1)"
      },
      "message": "Presigned URL access unrestricted",
      "remediation": "Add s3:signatureAge or s3:authType condition"
    }
  ],
  "risk_signals": [
    {
      "asset": "phi-logs-bucket",
      "control": "CTL.S3.LOCK.003",
      "signal": "approaching-threshold",
      "detail": "Retention period 2200 days, minimum 2190 days"
    }
  ]
}

Every finding includes the HIPAA section citation. The auditor can trace each finding to the regulatory requirement it maps to.

CI Pipeline Integration

The real power is running Stave in CI on every deployment. Exit codes make this straightforward:

# .github/workflows/hipaa-compliance.yml
name: HIPAA S3 Compliance Check
on:
  push:
    paths:
      - 'terraform/s3/**'
      - 'observations/**'

jobs:
  compliance:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build Stave
        run: cd stave && make build

      - name: Evaluate S3 compliance
        run: |
          stave evaluate \
            --controls controls/s3/ \
            --observations observations/ \
            --eval-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
            --format json \
            > compliance-report.json

      - name: Upload evidence artifact
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: hipaa-compliance-${{ github.sha }}
          path: compliance-report.json
          retention-days: 2190  # 6 years per HIPAA

Exit codes drive the pipeline:

Exit Code	Meaning	Pipeline Action
0	All controls pass	Deploy proceeds
3	Violations found	Deploy blocked
2	Input error	Pipeline fails, investigate
4	Internal error	Pipeline fails, investigate

Every CI run produces a compliance artifact tied to a specific commit SHA. Over time, this creates a continuous compliance trail of evidence for every deployment.

Stop giving auditors screenshots. Give them JSON reports with HIPAA section citations, produced by a deterministic tool, run on every deployment, stored as build artifacts with 6-year retention. Stave makes compliance evidence a CI artifact that is reproducible, traceable, and machine-readable. When the auditor asks "prove this bucket was compliant on March 15th," you pull the artifact from that date's deployment and hand them the JSON.

How this relates to existing compliance mods

For the HIPAA dashboard the auditor will recognize on sight — control-family layout, pass/fail per requirement, framework section labels matching their workpaper — turbot/steampipe-mod-aws-compliance ships a dedicated HIPAA Security Rule benchmark with the framework's section IDs already mapped to controls. That's the auditor-facing dashboard half of the evidence story. The snapshot-anchored, commit-SHA-tied, 6-year-retention CI artifact this article describes is the machine-readable proof half — deterministic JSON the auditor can re-run, not a dashboard screenshot they have to take on faith. Both halves serve the same auditor; both halves should ship in the same compliance pipeline. Framework benchmark on the dashboard surface for recognizability, snapshot-anchored verdicts in the artifact store for reproducibility. The two-tool decision matrix: aws-compliance-mod.

DEV Community