✓ 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.

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 
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

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.

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.