DEV Community

Bala Paranj
Bala Paranj

Posted on

We have a public bucket for marketing, how do we handle the auditor? HIPAA exception management: how to document intentional risks

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

We have a public bucket for marketing assets. Our security scanner flags it every scan. Do we just suppress it? Suppression is the wrong answer. What you need is a documented exception with compensating controls.

The Problem

Every organization has intentional control deviations such as a public bucket for marketing, relaxed access for a vendor, a legacy bucket that can't be migrated. These are business decisions.

But auditors need three things for every deviation:

  1. The acknowledged risk — what control is bypassed and why
  2. Compensating controls — what alternative measures reduce the risk
  3. Evidence that compensating controls work — verified, not just declared

A suppressed finding gives the auditor nothing. An exception without compensating controls gives them unmitigated risk.

How Stave Handles Exceptions

Stave supports declared exceptions in stave.yaml with mandatory compensating controls. The exception must include a reason, an owner, and at least one compensating control that Stave can verify:

# stave.yaml
exceptions:
  - bucket: marketing-assets-bucket
    control: CTL.S3.PUBLIC.001
    reason: >
      Marketing assets are intentionally public. Bucket contains
      only approved brand materials — no PHI, PII, or internal data.
    owner: marketing-ops@example.com
    review_date: 2027-01-15
    compensating_controls:
      - control: CTL.S3.GOVERNANCE.001
        description: >
          Bucket is tagged data-classification=public to confirm
          no PHI data classification.
      - control: CTL.S3.LOCK.001
        description: >
          Object Lock prevents unauthorized modification of
          approved marketing materials.
Enter fullscreen mode Exit fullscreen mode

The rules are strict:

  • An exception without compensating controls is rejected. You can't just declare "this is fine". You must specify what compensating measures are in place.
  • If compensating controls fail, the original finding stands. Declaring an exception for public access with a compensating control of "bucket is tagged non-PHI" only works if the bucket actually has that tag. If the tag is missing, the exception is invalid and the original public access finding is reported.
  • Every exception has an owner and a review date. Exceptions don't live forever. Someone is accountable, and the exception expires if not reviewed.
stave evaluate \
  --controls controls/s3/ \
  --observations observations/ \
  --eval-time 2026-04-08T00:00:00Z
Enter fullscreen mode Exit fullscreen mode
Security State: COMPLIANT

Exceptions:
  marketing-assets-bucket:
    CTL.S3.PUBLIC.001  EXCEPTED  Intentional public access
      Reason: Marketing assets are intentionally public.
      Owner: marketing-ops@example.com
      Review: 2027-01-15
      Compensating controls: 2/2 passing
        CTL.S3.GOVERNANCE.001  PASS  data-classification=public
        CTL.S3.LOCK.001        PASS  Object Lock enabled
Enter fullscreen mode Exit fullscreen mode

When a compensating control fails, the output changes:

Security State: NON_COMPLIANT

Findings:
  marketing-assets-bucket:
    CTL.S3.PUBLIC.001  UNSAFE  Public access — exception INVALID
      Exception declared but compensating control failed:
        CTL.S3.GOVERNANCE.001  FAIL  data-classification tag missing
      Original finding stands: bucket is publicly accessible without
      verified compensating controls.
Enter fullscreen mode Exit fullscreen mode

Suppressing findings is hiding risk. Declaring exceptions is managing risk. The difference is compensating controls that are verified. Stave enforces this: every exception must have compensating controls, every compensating control must pass, and every exception has an owner and an expiration. When the auditor asks about your public bucket, you hand them the exception report not a scanner with suppressed findings.

Top comments (0)