✓ 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:
- The acknowledged risk — what control is bypassed and why
- Compensating controls — what alternative measures reduce the risk
- 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.
Top comments (0)