Stop Tagging for FinOps. Start Tagging for SecFinOps.

Tagging is the first thing every AWS cost guide tells you to do. Tag your resources. Allocate your costs. Build your chargeback model.

Most teams do this. They tag by team, by environment, by project. Cost Explorer filters work. Chargeback reports run. The FinOps team is happy.

Then a FinOps review recommends deleting 40 idle databases. Three of them contain unscrubbed PII from a production load test. No compliance tag. No data classification. No destruction record. The saving was real. The legal review that followed was not cheap.

The tagging model answered the cost question. It never asked the security question. That is the gap this post fixes.

What a FinOps Tagging Model Looks Like

A standard FinOps tagging strategy covers four dimensions:

• team: who owns the resource
• environment: production, staging, dev
• project: which product or initiative
• cost-centre: for chargeback

These tags are useful. They are also incomplete. They tell you what a resource costs and who pays for it. They do not tell you whether it is safe to touch.

The FinOps Foundation FOCUS specification, the open billing standard for cloud cost data, defines a normalised schema for cost and usage data. It does not include security classification. That gap is intentional in the spec and a problem in practice.

What SecFinOps Tagging Adds

A SecFinOps tagging model adds four dimensions that standard FinOps tags do not cover.

data-classification: pii | confidential | internal | public
compliance-scope: pci-dss | hipaa | gdpr | sox | none
security-posture: clean | misconfigured | under-review
data-destruction-required: true | false

These tags change what FinOps can do with a resource. A database tagged data-classification: pii cannot be deleted without a data destruction record. An EC2 instance tagged compliance-scope: pci-dss cannot be rightsized without a security review. A resource tagged security-posture: misconfigured is not an optimisation candidate until the misconfiguration is resolved.

Without these tags, FinOps operates on cost data alone. With them, both teams are reading the same resource context before making any decision.

The Lazy Engineer Problem

Here is what actually happens when you introduce new required tags without enforcement.

A developer needs to deploy a new RDS instance before a sprint deadline. The pipeline requires data-classification and compliance-scope tags. The developer does not know what classification applies. They set data-classification: none and compliance-scope: none to unblock the deploy. The resource goes live. The tags are wrong. Nobody notices until a compliance audit six months later.

This is not a people problem. It is a process problem. Tags without enforcement are documentation. Documentation nobody reads.

Three layers of enforcement prevent this:

Layer 1: Shift-left in IaC

Catch missing or incorrect tags before terraform apply runs. Tools like Checkov and Trivy scan Terraform and CloudFormation templates for tag compliance as part of the CI/CD pipeline. A pipeline that fails on a missing data-classification tag stops the untagged resource from being created in the first place.

Open Policy Agent (OPA) with Conftest takes this further. You can write custom policies that enforce not just the presence of tags but the validity of their values. A policy that rejects data-classification: none as a valid value for any resource in a production account is a one-time write that runs on every plan.

Layer 2: Runtime enforcement via AWS Config

AWS Config with the required-tags managed rule flags resources that do not have the required tag set within minutes of creation. Pair it with an AWS Systems Manager Automation runbook that notifies the owning team and removes the resource from FinOps optimisation reports until it is correctly tagged.

Layer 3: IAM guardrails on sensitive operations

Use AWS IAM condition keys to block deletion of classified resources without the right role. A Deny on DeleteDBInstance, TerminateInstances, and DeleteBucket for any principal that does not hold the secops-data-destruction role, scoped to resources tagged data-destruction-required: true, means the FinOps automation cannot delete a classified resource without SecOps sign-off. The guardrail is in the policy, not in a process document.

{
  "Effect": "Deny",
  "Action": ["rds:DeleteDBInstance", "ec2:TerminateInstances", "s3:DeleteBucket"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:ResourceTag/data-destruction-required": "true"
    },
    "StringNotEquals": {
      "aws:PrincipalTag/role": "secops-data-destruction"
    }
  }
}

Enforcing at the Organisation Level

Individual account enforcement is not enough. Tags need to be consistent across every account in your AWS Organisation or the IAM conditions and Config rules break on string mismatches.

AWS Organizations tag policies enforce tag key and value standardisation across all accounts. Without them, data-classification: PII and data-classification: pii are two different tags. Define your taxonomy in a tag policy, attach it at the organisation root or the relevant OU, and new resources that do not conform are flagged immediately.

Service Control Policies (SCPs) go further. An SCP can deny ec2:RunInstances entirely if the request does not include the required tags. This is the ceiling of enforcement. The resource cannot be created at all without the correct tags, regardless of what IAM permissions the principal has.

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:instance/*",
  "Condition": {
    "Null": {
      "aws:RequestTag/data-classification": "true"
    }
  }
}

Feeding Tags Into the FinOps Workflow

In AWS Cost Explorer, you can filter and group by any tag. Add data-classification and compliance-scope as dimensions in your cost allocation reports.

A cost optimisation recommendation filtered to data-classification: public and compliance-scope: none is a safe list. Everything on it can be actioned without a security review. Everything outside that filter needs one.

Note: Cost Explorer tag filters only apply to costs incurred after the tag was activated for cost allocation. Retroactive tagging does not update historical spend data. Start tagging now. The value compounds over time.

Easy Hack: Start With Your Top 20 Resources by Spend

You do not need to tag everything at once. Start with the top 20 resources by monthly spend. Apply the full SecFinOps tag set to those 20 resources. You will immediately see which of your highest-cost resources are unclassified, which are in compliance scope, and which have open security findings.

That list is more useful than a full tag audit that takes three months and never gets finished.

Maintaining this discipline manually across hundreds of resources is where it breaks down in practice. CostObserver surfaces unclassified resources automatically, flagging any resource that appears in a cost optimisation recommendation without a complete SecFinOps tag set, before the recommendation reaches the FinOps team.

Try CostObserver. Read-only access, no credit card, connects in minutes. Or explore the demo without signing up.