An untagged storage bucket or virtual machine has no owner to call, no data classification to protect it and no expiry date to retire it, so during an incident or a cost spike nobody can say whether it matters. This template is a ready-to-adopt standard for tagging cloud resources (compute, storage, databases, networks, accounts, subscriptions and projects) with the small set of tags that security, operations and finance controls depend on: owner, environment, data classification, criticality and lifecycle. It is written with [Organisation] placeholders and maps to the documented tagging features of AWS, Google Cloud and Microsoft Azure, listed alphabetically. Tags for machine identities themselves (service accounts, roles, API keys) are covered by the Machine Identity Naming and Tagging Standard Template; this page covers the resources those identities act on. It is for cloud platform, security and FinOps teams.
How to use this template
- Replace text in square brackets, such as [Organisation], [Cloud platform team] and [CMDB], with your own names and systems. Values and review periods marked as recommendations are NHI Mgmt Group starting points, not requirements of any provider or framework.
- "Must" is mandatory; "should" is recommended and may be waived through the exceptions process in section 10.
- Adopt sections 5 and 6 first. Five mandatory tags enforced at creation give most of the value; the control uses in section 7 then follow.
- Check provider limits in section 8 before fixing key names. A key format valid in one cloud may be rejected or changed in another.
- Pilot enforcement in audit or report-only mode on one account, subscription or project before you block creation organisation-wide.
1. Purpose
1.1 This standard sets the tags every cloud resource at [Organisation] must carry, so that each resource can be traced to an accountable owner, an environment, a data classification, a business criticality and a lifecycle state.
1.2 Tags under this standard are control inputs, not labels for reporting only. They drive access decisions, policy enforcement, backup and monitoring scope, alert severity, cost allocation and decommissioning.
1.3 The standard supports inventory and accountability (NIST SP 800-53 Rev 5 CM-8 System Component Inventory and CM-8(4) Accountability Information), security categorisation (RA-2), security attributes (AC-16) and the NIST CSF 2.0 outcomes ID.AM-02, ID.AM-05 and ID.AM-08.
2. Scope
2.1 This standard applies to every taggable resource in every [Organisation] cloud environment, including production, non-production and sandbox, and including:
- Containers for resources: AWS accounts, Azure subscriptions and resource groups, Google Cloud projects and folders.
- Compute, containers and serverless functions; storage buckets, file shares and disks; databases and data warehouses.
- Network resources: virtual networks, gateways, load balancers, DNS zones and public IP addresses.
- Security and key resources: key vaults, keys, secrets stores and certificates.
- AI resources: model endpoints, notebooks, training jobs and vector stores.
2.2 Resources that cannot be tagged must be recorded in [CMDB] against a taggable parent (for example the resource group, project or account) that carries the mandatory tags.
2.3 Machine identities follow the [Machine Identity Naming and Tagging Standard].
3. Definitions
- Tag: a key and value pair attached to a resource. In this standard "tag" covers AWS tags, Azure tags, and Google Cloud labels and tags.
- Google Cloud labels and tags: labels are metadata on a resource, used for billing filters, not inherited and without IAM or organisation policy support; tags are separate resources managed with IAM, inherited down the resource hierarchy and usable in IAM conditions and some organisation policy conditions. Use tags for keys that drive access or policy, labels for keys used only in billing or operations.
- Owner: the named individual accountable for the resource. A team may operate it, but a person must be recorded.
- Control tag: a tag that an access policy, guardrail or security tool reads to make a decision. Changes to control tags are privileged (section 9).
- System of record: [CMDB], which holds the authoritative owner and application data and is reconciled with tags.
4. Roles and responsibilities
| Role | Responsibility |
|---|---|
| [Cloud platform team] | Owns this standard and the allowed-values lists; implements enforcement in policy and infrastructure-as-code modules; runs compliance reporting. |
| Resource owner | Sets accurate tags at creation, updates them when facts change, confirms them at review and approves decommissioning. |
| [Security team] | Defines the control tags and what each value triggers; reviews changes to control tags; uses tags in detection and triage. |
| [Data governance] | Maintains classification values in line with the [Data Classification Policy]. |
| [FinOps team] | Uses cost tags for allocation and anomaly routing; reports untagged spend. |
5. Tag key convention
5.1 Tag keys must use lowercase words separated by hyphens, with the organisation prefix [org] where the platform permits it, for example [org]-owner. AWS documents this pattern (lowercase, hyphens, an organisation prefix with a colon) as a best practice. Google Cloud label keys are limited to lowercase letters, digits, underscores and hyphens, so the colon form must not be used where the key also has to work as a Google Cloud label; the hyphen form works in all three clouds.
5.2 Tag values must come from the allowed-values lists in section 6 wherever one exists. Free-text values are permitted only for [org]-purpose.
5.3 Tags must not contain personal data, secrets, credentials or confidential information. AWS states that tags are not intended for private or sensitive data and are accessible to many services, including billing. Microsoft states that tags are stored as plain text and can be exposed through cost reports, deployment histories, exported templates and logs. Google Cloud advises against putting sensitive information, including a person's name, in labels.
5.4 Owners must be recorded as an employee ID or directory object ID, not a name or email address, so the tag does not hold personal data in clear text.
5.5 Keys prefixed aws: are reserved by AWS and must not be used.
6. Mandatory and recommended tags
6.1 Every in-scope resource must carry the mandatory tags at creation. Provisioning pipelines and cloud policy must reject a resource missing a mandatory tag, after the pilot in the implementation guidance.
| Tag key | Status | Allowed values | Control it drives |
|---|---|---|---|
| [org]-owner | Mandatory | Employee or directory object ID of a named person | Incident contact, access review, decommissioning approval |
| [org]-app | Mandatory | Application code from [CMDB] | Link to business service, criticality and change records |
| [org]-env | Mandatory | prd, stg, tst, dev, sbx | Environment isolation, guardrail strength, alert severity |
| [org]-data-class | Mandatory | public, internal, confidential, restricted (match the [Data Classification Policy]) | Encryption, public access blocks, data loss controls, backup tier |
| [org]-cost-centre | Mandatory | Cost centre code from [Finance system] | Cost allocation and anomaly routing |
| [org]-criticality | Recommended | tier1, tier2, tier3 | Backup frequency, recovery objectives, patch priority |
| [org]-expiry | Mandatory for sbx, dev and tst; recommended elsewhere | ISO date YYYY-MM-DD | Automatic stop and deletion of temporary resources |
| [org]-compliance-scope | Recommended | none, pci, phi, [other scopes] | Inclusion in audits, stricter logging and access rules |
| [org]-exposure | Recommended | internal, internet | Approved internet exposure; anything public without "internet" raises an alert |
| [org]-managed-by | Recommended | terraform, cloudformation, bicep, console, [tool] | Drift detection; console-created resources flagged for review |
6.2 Where a container (account, subscription, project or resource group) carries a tag, child resources must still carry it unless the platform applies it automatically. Azure resources do not inherit tags from their resource group or subscription by default; Google Cloud tags are inherited down the hierarchy, labels are not.
6.3 Resources that hold data must take the highest data classification of any data they store.
7. Controls driven by tags
7.1 The following controls must read tags rather than maintain separate lists. [Security team] owns the mapping and reviews it annually.
| Control | Tag input | Example rule |
|---|---|---|
| Attribute-based access | [org]-app, [org]-env | A deployment role may act only on resources whose app and env tags match its own, using AWS conditions such as aws:ResourceTag and aws:PrincipalTag, or Google Cloud IAM conditions on tags. See the Authorisation Models Guide. |
| Public access guardrail | [org]-data-class, [org]-exposure | Storage tagged confidential or restricted must never be public; any public resource without exposure=internet raises a high-severity finding. |
| Backup scope | [org]-criticality, [org]-env | Backup plans select resources by tag, so tier1 production resources join the immutable backup plan automatically. |
| Monitoring and alert severity | [org]-env, [org]-criticality | Findings on prd tier1 resources page the on-call team; sbx findings go to a queue. |
| Cost and anomaly routing | [org]-cost-centre, [org]-owner | Cost anomalies are routed to the owner and to security with owner context. See Cloud Cost Anomalies as Security Signals. |
| Lifecycle and decommissioning | [org]-expiry, [org]-owner | Resources past expiry are stopped after notice and deleted after [14] days unless the owner extends. See Cloud Account and Resource Decommissioning. |
| Audit scope | [org]-compliance-scope | Evidence collection and stricter logging apply to every resource in scope. |
8. Platform mapping
8.1 Provider documentation as of November 2026 sets these limits. Some services set lower limits, so confirm in the provider's documentation for each resource type.
| Item | AWS | Google Cloud | Microsoft Azure |
|---|---|---|---|
| Tags per resource | 50 user-created tags | Up to 64 labels per resource | 50 name-value pairs; some services 15 |
| Key length | 128 characters | Labels 63; tags 256 | 512 (128 for storage accounts) |
| Value length | 256 characters | Labels 63; tags 256 | 256 characters |
| Case | Keys and values case sensitive | Label keys and values: lowercase letters, digits, underscores and hyphens; keys start with a letter | Names case-insensitive for operations; values case sensitive |
| Enforcement feature | AWS Organizations tag policies; service control policies with request tag conditions | Tags with IAM conditions and organisation policy conditions; mandatory tag enforcement in Preview as of November 2026 | Azure Policy built-ins such as "Require a tag on resources" and "Inherit a tag from the resource group if missing" |
| Compliance view | Tag policy compliance in Resource Groups and the management account | Cloud Asset Inventory and billing export by tag or label | Azure Policy compliance and remediation tasks |
8.2 AWS tag policies standardise case and allowed values for tagged resources; AWS states that untagged resources are not evaluated by tag policies, so [Cloud platform team] must also detect missing tags, for example with AWS Config rules or a request-tag condition in a service control policy. Azure's append effect does not change existing resources; use the modify effect with a remediation task to backfill. See the Azure Policy and Management Groups Guide and the Google Cloud Organization Policy Guide.
9. Protecting control tags
9.1 Because tags drive access and guardrails, changing a control tag can grant access or remove protection. Only [Cloud platform team] pipelines and named roles may add, change or remove [org]-app, [org]-env, [org]-data-class and [org]-exposure on existing resources.
9.2 Access policies must deny tagging and untagging actions on control tag keys to all other principals, using provider conditions on tag keys (for example aws:TagKeys in AWS) or IAM permissions on tag values in Google Cloud. In Azure, the Tag Contributor role can tag any resource without access to the resource itself, so it must be treated as privileged and assigned only through [PAM process].
9.3 Changes to control tags must be logged and alerted on. A change that downgrades data classification or changes env from prd must raise a security event.
10. Exceptions
10.1 Exceptions must be recorded in [exceptions register] with the resource, the missing or non-standard tag, the reason, a compensating control and an expiry date no more than [90] days ahead.
10.2 Resource types that cannot be tagged do not need an exception if they are covered under 2.2.
11. Compliance and review
11.1 [Cloud platform team] must report monthly: percentage of resources with all mandatory tags; untagged spend as a share of total; resources past expiry; control tag changes and who made them.
11.2 Owners must confirm tags on their resources at least [annually] and when ownership changes. Resources whose owner has left [Organisation] must be reassigned within [30] days or scheduled for decommissioning.
11.3 This standard must be reviewed at least annually and when a new cloud provider or major resource type is adopted.
Implementation guidance
- Start in report-only mode. Run tag policies, Azure Policy and detection rules in audit mode for one billing cycle on a pilot account, subscription or project, fix the infrastructure-as-code modules, then switch to deny for new resources. AWS recommends testing a tag policy on a single account before applying it to an OU or the organisation.
- Put tags in the templates. Make mandatory tags required variables in Terraform, CloudFormation and Bicep modules, so engineers cannot forget them. Most untagged resources come from the console and from tools that create resources on a user's behalf.
- Backfill by container first. Tag accounts, subscriptions, projects and resource groups, then use inheritance or remediation tasks to push owner and environment down, and reconcile with [CMDB].
- Rollback. If enforcement blocks a critical deployment, move that scope back to audit mode, record an exception and fix the template; do not remove the policy organisation-wide.
- Measure. Track mandatory tag coverage (target 98% or more of resources), untagged spend, time to find an owner during incidents, and expired temporary resources still running. Tag coverage also improves the inventory described in the Asset Inventory and CMDB Security Guide.
- Common failure patterns. Tags used for cost only and never read by security tools; classification tags anyone can change; owners recorded as email addresses or departed staff; four spellings of the same key across teams; and tag policies trusted to catch resources that have no tags at all.
Standards and references
- AWS: Best practices and strategies for tagging
- AWS: Tag policies in AWS Organizations
- AWS: What is ABAC for AWS?
- AWS: Global condition context keys
- Google Cloud: Tags overview
- Google Cloud: Labels overview
- Microsoft Learn: Use tags to organize your Azure resources
- Microsoft Learn: Assign policy definitions for tag compliance
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Machine Identity Naming and Tagging Standard Template · Asset Inventory and CMDB Security Guide · Data Classification Policy Template · Cloud Security Posture Management (CSPM) Guide · Cloud Account and Resource Decommissioning