Compliance Exemptions¶

Some resources will fail a compliance check for reasons you have already accepted: a test workload inside the boundary that does not need cross-region backup, a legacy service whose risk is formally documented. Left alone, those failures accumulate and the scan stops being a signal -- everyone learns to ignore the red.

The Stratus compliance mod handles this with resource tags. Tag a resource with the check it should be excused from, and the scan reports it as skipped rather than failing, carrying your justification alongside the result. The exemption lives on the resource, in your cloud, in the same place as the thing being exempted.

The three tags¶

The reason and expiry tags do nothing on their own. They are only read for resources that already match on compliance_exempt.

These are the default tag keys. They are configurable in the mod, so if your deployment overrides them, use your deployment's keys instead.

Getting the format exactly right¶

The tag value is split on the colon character with no cleanup: no whitespace trimming, no alternative separators. Each resulting ID is then matched independently, case-insensitively. Everything else is literal. These are the behaviors that matter, each one verified against the scan logic:

The tag key is case-sensitive even though the value is not. Compliance_Exempt and COMPLIANCE_EXEMPT do not work -- only compliance_exempt. This bites hardest in the Azure portal, which preserves whatever capitalization you type.

Expiry dates¶

The expiry tag is matched against a strict YYYY-MM-DD pattern. Anything else fails the pattern and is treated as no expiry at all, which means the exemption is permanent:

Use plain YYYY-MM-DD with no time component. An expired exemption is designed to be loud: it fails the check and says why, which is what forces the renew-or-remediate conversation instead of letting the exemption quietly outlive its justification.

Choosing what to put in the tag¶

Indicator ID or check ID¶

Tagging KSI-RPL-ABO excuses the resource from every check under that indicator. Tagging KSI-RPL-ABO.11 excuses it from that one check only.

Prefer the specific check ID. An indicator-level exemption is a standing instruction to ignore a whole class of finding on that resource, including checks added to the indicator later, which you have not reviewed and did not intend to excuse.

One tag can affect several indicators¶

Twenty-nine of the 176 exemptable checks are shared across multiple indicators -- the same test evidences more than one KSI. Excusing a resource from one of them excuses it from all of them, because there is only one underlying test.

The widest example is the Azure Key Vault secret expiry check, which evidences seven indicators at once: KSI-IAM-AAM.20, KSI-IAM-AAM.21, KSI-SVC-ACM.21, KSI-SVC-ACM.22, KSI-SVC-ACM.23, KSI-SVC-ASM.20, and KSI-SVC-SIN.20. A single tag on one secret moves the needle on all seven. Check the reference table for what a check ID actually covers before you use it.

Which resource to tag¶

Usually the answer is obvious: the resource named in the failing result is the one to tag. In eight cases it is not, because the check grades rows that cannot carry tags and keys the exemption off the parent instead.

Tag the parent, not the graded row¶

Note what this means for security groups: you cannot exempt one offending rule. The exemption applies to the whole group, including rules added later. If that is too broad, the answer is to split the group, not to widen the exemption.

Reference: every exemptable check by resource type¶

Find the resource type you are tagging, and the checks that tag can excuse.

Checks that cannot be exempted¶

Fifty checks ignore the tag entirely. Tagging a resource for one of these does nothing at all -- it will not error, and the check will keep failing.

For these, an accepted risk has to be handled in GRC-ITSM rather than in the cloud: record the Vulnerability Deviation and let the check keep reporting its finding, with the deviation as the governing record.

Tagging a resource¶

The tag is an ordinary cloud resource tag. Apply it however you normally manage tags -- infrastructure as code is strongly preferred, because a tag applied by hand in a console is invisible to review and disappears on the next redeploy.

resource "aws_backup_vault" "test_workloads" {
  name = "test-workloads"

  tags = {
    compliance_exempt            = "KSI-RPL-ABO.11"
    compliance_exemption_reason  = "VD-1284: non-production test vault, encryption not required. Risk accepted by CISO."
    compliance_exemption_expiry  = "2027-02-01"
  }
}

resource "azurerm_storage_account" "test_data" {
  name                     = "testdata"
  resource_group_name      = azurerm_resource_group.test.name
  location                 = azurerm_resource_group.test.location
  account_tier             = "Standard"
  account_replication_type = "LRS"

  tags = {
    compliance_exempt           = "KSI-CNA-IBP.22"
    compliance_exemption_reason = "VD-1290: test fixture data, no federal information. Risk accepted."
    compliance_exemption_expiry = "2027-02-01"
  }
}

aws backup tag-resource \
  --resource-arn "arn:aws:backup:us-east-1:111122223333:backup-vault:test-workloads" \
  --tags '{
    "compliance_exempt": "KSI-RPL-ABO.11",
    "compliance_exemption_reason": "VD-1284: non-production test vault. Risk accepted by CISO.",
    "compliance_exemption_expiry": "2027-02-01"
  }'

az resource tag \
  --ids "/subscriptions/<sub>/resourceGroups/test/providers/Microsoft.Storage/storageAccounts/testdata" \
  --tags \
    compliance_exempt="KSI-CNA-IBP.22" \
    compliance_exemption_reason="VD-1290: test fixture data, no federal information." \
    compliance_exemption_expiry="2027-02-01" \
  --is-incremental

Multiple checks on one resource go in a single compliance_exempt value, colon-separated:

compliance_exempt = "KSI-RPL-ABO.11:KSI-RPL-RRO.10"

Verify an exemption¶

Because every formatting mistake fails silently, confirm the result rather than assuming it.

1. Re-run the scan. Wait for the next scheduled run or trigger one by hand.
2. Check the resource's status. It should report as skip, not alarm. If it still fails, the tag did not match -- re-read Getting the format exactly right, and check the tag key's capitalization first.
3. Confirm the reason came through. The result text should carry your justification. A skip with no reason means compliance_exemption_reason is missing or its key is misspelled.
4. Confirm the counts moved. In GRC-ITSM, open the child validation ticket whose summary starts with that check ID and read the newest row on its Validations tab. Fail Count should drop by the resources you exempted, and Pass Count should not increase, because skipped resources count as neither. A Fail Count that renders blank means zero failures.

That last point is the one people misread. An exempted resource does not become evidence of compliance; it drops out of the measurement entirely. A check with ten resources where six pass and four are exempt reports six passing, not ten.

Keeping exemptions honest¶

An exemption tag is a control you have chosen not to enforce, so it needs the same lifecycle as any other accepted risk.

Every exemption is visible in the scan output, including its reason and expiry, so the set of exemptions is itself reviewable evidence. That is the point of putting them in tags rather than suppressing findings after the fact: the decision stays attached to the resource, and it shows up in the same place as the thing it excuses.