Skip to main content

DATACLASS controls (5)

CTL.DATACLASS.PROD.UNTAGGED.001​

Production Data-Bearing Resource Must Not Be Unclassified

  • Severity: high
  • Type: unsafe_state
  • Domain: governance
  • Compliance: soc2: CC6.1;

A data-bearing resource in a production environment with no data-classification tag is treated as HIGH severity, not as routine hygiene. The fail-loud principle applied to classification: absence of classification in production is not "unclassified" — it is "unknown, assume worst case." Production data that no control knows is sensitive is the root cause behind a large share of data-leak incidents. The collector emits governance.environment (the resolved environment, e.g. production, derived from account tag / name pattern / org unit), governance.is_data_bearing, and governance.data_classification. This predicate fires on production + data-bearing + no classification.

Remediation: Classify the resource immediately with an approved taxonomy value. If it truly holds no sensitive data, tag it public/internal explicitly — silence is not an acceptable classification in production.

CTL.DATACLASS.TAG.INVERTED.001​

Data Classification Tag Contradicts Resource Access Posture

  • Severity: medium
  • Type: unsafe_state
  • Domain: governance
  • Compliance: hipaa: 164.312(a)(1); nist_800_53_r5: AC-4; pci_dss_v4.0: 3.4.1; soc2: CC6.1;

A resource carries a high-sensitivity classification tag (confidential, restricted, pii, phi, pci) but its access configuration is publicly accessible. The classification declares the data is sensitive; the access posture exposes it. This is a cross-property semantic inversion: the tag and the configuration contradict each other. Either the classification is wrong (the data is actually public) or the access posture is wrong (the resource should not be publicly accessible). Both states are dangerous — a wrong tag means controls scoped to that classification fire incorrectly; a wrong posture means sensitive data is exposed.

Remediation: Either remove public access (disable PubliclyAccessible, enable BlockPublicAccess, remove wildcard principals from resource policies) or reclassify the resource as public if the data is genuinely non-sensitive.

CTL.DATACLASS.TAG.MISSING.001​

Data-Bearing Resource Must Carry a Classification Tag

  • Severity: medium
  • Type: unsafe_state
  • Domain: governance
  • Compliance: soc2: CC6.1;

Every data-bearing resource (S3 bucket, RDS instance, DynamoDB table, Secrets Manager secret, OpenSearch collection, Redshift cluster, EFS filesystem) must declare a data-classification tag. Stave's intent-tag controls only fire when a classification tag EXISTS and mismatches reality — a resource with NO classification tag is invisible to them: there is no declared intent to check against. This control closes that blind spot by treating absence of classification as a violation, not a silent pass. The collector normalizes whichever tag key the organization uses (data_classification, data-classification, classification, sensitivity) into the derived signals this predicate reads: governance.is_data_bearing (the asset stores data and is therefore in scope) and governance.data_classification (the resolved classification value, absent when no recognized tag is present). Fail-loud: an in-scope resource with no classification is a governance gap, not "unclassified data is fine." Tag it, then the value-level controls (taxonomy, PHI markers, retention) can reason about it.

Remediation: Apply a data-classification tag drawn from the approved taxonomy (public, internal, confidential, restricted, pii, phi, pci). Wire tagging into the resource's IaC module so new resources are classified at creation.

CTL.DATACLASS.TAG.SENSITIVE.UNTAGGED.001​

Sensitive-Service Resource Missing Classification Tag

  • Severity: medium
  • Type: unsafe_state
  • Domain: governance
  • Compliance: nist_800_53_r5: AC-4; soc2: CC6.1;

A resource in a high-sensitivity service category (S3, DynamoDB, RDS, Secrets Manager, Lambda, SageMaker, OpenSearch, Redshift) has no data-classification tag. Unlike the generic CTL.DATACLASS.TAG.MISSING.001 which flags all data-bearing resources, this control targets resources in services that routinely handle sensitive data and are common participants in data flows. An untagged resource in these services is a PART OF gap: other resources in the same data flow may be tagged, but this one is not, creating a hole in classification-driven governance. Controls scoped to "confidential" or "pii" data cannot evaluate an untagged resource — it is invisible to every classification-based invariant.

Remediation: Apply a data-classification tag from the approved taxonomy (public, internal, confidential, restricted, pii, phi, pci). Wire tagging into the resource's IaC module so new resources are classified at creation.

CTL.DATACLASS.TAG.TAXONOMY.001​

Data-Classification Tag Must Use an Approved Taxonomy Value

  • Severity: medium
  • Type: unsafe_state
  • Domain: governance
  • Compliance: soc2: CC6.1;

When a data-bearing resource declares a data-classification, the value must come from the approved taxonomy: public, internal, confidential, restricted, pii, phi, or pci. Freeform values ("important", "sensitive-ish", "team-data") defeat sensitivity-scoped controls just as surely as a missing tag — a control that keys on data_classification == "phi" never matches "phi-data" or "Protected Health Info". This control flags any non-approved value so the taxonomy stays machine-comparable. The collector emits governance.data_classification as the resolved tag value. This predicate fires when that value is present but is none of the approved terms.

Remediation: Replace the freeform value with an approved term: public, internal, confidential, restricted, pii, phi, or pci. Enforce the allowed set in the tagging policy / IaC validation.