Best Practices

Naming Conventions

A consistent naming convention reduces confusion, prevents duplicate categories, and ensures tags render predictably in Tenable One dashboards and asset filters.

  • Use Title Case for both category and value — for example, Business Unit:Cloud Platform, not business unit:cloud platform.
  • Keep categories generic and reusable. One Location category with many values is better than dozens of one-off categories.
  • Avoid vague category names like Misc or Other. If you cannot clearly describe what the category means, reconsider the structure.
  • Do not repeat the category name inside the value. Location:East Coast is correct; Location:Location-East Coast is redundant.
  • For compliance scopes, prefix the value with the standard — for example, Compliance:PCI-DSS, Compliance:HIPAA.
  • Establish an approved taxonomy document before tagging begins to prevent drift over time.
  • Use the Category Description and Value Description fields when creating tags. These descriptions are visible to all users and improve discoverability.

Tag Rule Design

  • Prefer specific attributes over broad patterns. Use CIDR ranges, exact OS names, or CPE strings rather than partial-match wildcards wherever possible.
  • Use trailing wildcards (Ubuntu*) rather than leading wildcards (*Ubuntu). Leading wildcards force a full-index scan and degrade performance significantly.
  • Combine a restrictive primary filter (such as an IP range or AWS Region) with secondary qualifiers (such as Source = Nessus Scan) to keep rule scope predictable.
  • If a rule returns too many assets for the engine to process, it fails silently. Split large rule sets into two or more tags, then join them using a nested Tags filter.
  • After creating a dynamic tag, monitor the Assessment column in the Values tab. Any status other than Completed means the engine is still processing or has encountered an error.
  • Avoid building rules with more than 20 complex conditions even though the system limit is 40. Complex rules are harder to troubleshoot and slower to evaluate.
  • Use Resource Tags (By Key) and Resource Tags (By Value) filters to mirror cloud-native tagging from AWS, Azure, or GCP into Tenable One Vulnerability Management automatically — no manual effort required when cloud teams apply tags.

Cross-Product Tagging Strategy

  • Define your Business Context hierarchy in Tenable One before creating tags. Decide which tag categories (such as Business Unit, Location, Compliance) will appear as Business Context segments in Tenable One dashboards.
  • Each Business Context in Tenable One corresponds to one tag value in Tenable One Vulnerability Management. Create one tag per reportable unit, not one tag per individual team member or sub-team.
  • Tags are native to Tenable One Vulnerability Management (cloud). Tenable Security Center Asset Tags can optionally reach Tenable One through Tenable One Synchronization, but only IPv4 addresses within Static and Dynamic Asset Tags are eligible, and the feature requires a Tenable Lumin or Tenable One license. Account for this in hybrid deployment planning — see Tags in Tenable Security Center.
  • When assets migrate between environments (for example, on-premises to AWS), ensure that rule filters using cloud provider attributes will pick them up automatically post-migration.
  • For organizations using both Tenable One Vulnerability Management and Tenable Security Center, align Tenable Security Center Asset Tag names with your Tenable One Vulnerability Management tag taxonomy. Static and Dynamic Asset Tags with matching IPv4 scope are the ones eligible for Tenable One Synchronization, so consistent naming makes cross-product Business Context easier to reconcile.

Governance

  • Restrict tag creation permissions to Scan Managers or Administrators. Basic and Standard users should be able to apply existing tags but should not create new categories without review.
  • Review the tag taxonomy quarterly. Delete or merge categories that have grown stale or redundant.
  • Use the Export function (CSV or JSON) to snapshot your tag library before any major structural changes, providing a rollback reference.
  • Document the owner and purpose for each tag category using the Category Description and Value Description fields in the Create Tag UI.
  • Coordinate tag deletions with report and dashboard owners before proceeding — deleting a category removes it from all assets immediately and can break tag-scoped dashboards or access groups.
  • Use the Permissions page (Settings → Access Control → Permissions) to delegate tag ownership to specific users or groups without granting full Administrator access.
  • When a tag is created, Tenable One Vulnerability Management automatically creates Can Use and Can Edit permissions for the creating user. Administrators can share these permissions with other users or groups as needed.