Documentation / Tag Policy

Tag Policy

Define the tags every resource in your organisation should carry, see how compliant each tenant is, and get a list of the resources that need fixing.

On this page

Overview

Most organisations have a tagging standard — owner, department, environment, platform — and most Azure estates only partly follow it. Untagged resources can't be allocated to a cost centre, can't be rolled into a Tag Collection budget, and can't be traced back to the person who should be asked about them.

A tag policy is the list of tag keys your organisation treats as mandatory. Cirrova checks every resource it collects against that list and shows you, per tenant and per tag, how much of your estate complies — and exactly which resources don't.

Cirrova reports on compliance; it never writes tags to Azure. To enforce tagging at deployment time, pair your Cirrova policy with an Azure Policy assignment that requires the same tags.

Define your policy

  1. Open Organisation Settings → Tag policy.
  2. Click Add mandatory tag and enter the tag key — for example owner.
  3. Optionally add guidance describing what the value should be, such as Email address of the accountable owner. Guidance is shown alongside the policy so the people fixing tags know what's expected.
  4. Repeat for each tag you want to require, then click Save policy.

A policy can contain up to 25 mandatory tags. Saving replaces the whole list, so to drop a tag, remove its row and save. The policy applies to every tenant in the organisation — there is no per-tenant variation.

How compliance is judged

A resource is fully compliant when it carries every mandatory tag. The rules are deliberately strict, so the numbers reflect what is actually on each resource:

  • Keys match case-insensitively. A policy tag of owner is satisfied by Owner or OWNER on the resource.
  • Blank values count as missing. A tag that exists but has an empty or whitespace-only value does not satisfy the policy.
  • Tags must be on the resource itself. A tag on the resource group is not inherited by the resources inside it. If you rely on inheritance, use Azure Policy's Inherit a tag from the resource group effect so the tag is copied onto each resource.
  • Resource types that can't carry tags are excluded. Some Azure resource types do not support tags at all. Cirrova uses Microsoft's published tag-support list to leave these out of the calculation, so they never drag your compliance figure down. The number excluded is shown alongside the compliance summary.
  • Azure-internal tags are ignored. System tags whose keys begin with hidden-link: are not treated as user tags.

Compliance is calculated from the resource data Cirrova already collects, so changes you make to tags in Azure show up after the next data refresh.

Compliance view

Below the policy on the Tag policy page, the Compliance panel shows:

  • The percentage of taggable resources that carry every mandatory tag, and the total number of taggable resources considered.
  • A per-tag figure — the percentage of resources carrying each individual mandatory tag. This tells you which tag is causing most of the shortfall.
  • A per-tenant table with the same breakdown, so you can see which tenants are well-tagged and which need work.

The compliance view only includes tenants you have access to. An organisation owner sees every tenant; other members see the tenants they've been granted.

Tag reports

Two report types build on the tag policy. Both can be run on demand or scheduled for email delivery, work across every tenant in the organisation, and export to CSV, PDF, or Excel.

Missing mandatory tags

Lists every active resource that is missing one or more mandatory tags, with the missing tags named and counted on each row. Columns: Tenancy, Subscription, Resource group, Name, Resource type, Location, Missing tags, Missing count.

By default the report checks against your organisation's tag policy, so it stays in step as the policy changes. To check a different set of tags — for example, a stricter standard for one team — enter the tag keys in the report's Mandatory tags field instead. Scheduled weekly to the owners of each platform, this is the simplest way to keep tagging from drifting.

Resources by tag

Lists every active resource carrying a tag key you choose, optionally restricted to specific values, across all tenants. Columns: Tenancy, Subscription, Resource group, Name, Resource type, Location, Tag, Tag value, Est. monthly cost, Currency.

Use it to answer questions like "what does the payments platform run, and what does it cost?" — set the tag key to platform and the value to payments. Leave the values blank to list every resource with the key, sorted by value.

API access

The tag policy and tag-based filtering are available through the public API:

  • GET /tag-policy returns the organisation's mandatory tags and their guidance.
  • GET /resources lists resources across every tenant the API key can access.
  • GET /tenants/{tenantId}/resources lists resources within one tenant.

Both resource endpoints accept three tag filters:

  • tagKey — only resources carrying this tag.
  • tagValue — used with tagKey, only resources where the tag has this value.
  • missingTagKey — only resources that do not carry this tag. Combine it with GET /tag-policy to build your own compliance checks or feed non-compliant resources into a ticketing system.
GET /api/public/v1/resources?missingTagKey=owner

Permissions

Only an organisation owner can change the tag policy. Every member of the organisation can view the policy and the compliance figures for the tenants they have access to. See Access Control for how roles work.

Previous Reporting