Skip to content

Attributes & Attribute Groups

Before you can write a Policy or configure protection, you need to define what you're protecting.

An Attribute is a reusable label for one type of sensitive data, for example Email, CreditCard, or Salary. Once a field is classified as an Attribute, every place that Attribute appears across your systems inherits the same default protection, so you're not re-defining "this is a credit card number" separately in every dataset, every API, every database table it happens to live in.

An Attribute Group is a named collection of related Attributes, for example a "Financial Data" group containing Salary, BankAccount, and CreditCard. Grouping lets a Policy protect a whole category of data at once instead of one Attribute at a time, which matters once you have dozens or hundreds of individual Attributes and don't want to attach each one to every relevant Policy by hand.

This page covers how to create and configure both. Access it via Central Services → Data Management → Attribute Groups. A new Attribute Group starts empty; Attributes are added afterward.

Video walkthrough

From an earlier product version, so field names or screens may have shifted slightly.

Adding an Attribute Group

Click the "+" button on the Attribute Groups page and fill in:

  • Name: name of the attribute group

Adding an Attribute

Within an Attribute Group, click the "+" button to add an attribute, and fill in:

  • Attribute Group: the group this attribute belongs to
  • Attribute Name: the name of the attribute
  • Attribute Enum: the enum value of the attribute
  • Attribute Description: a short description
  • Attribute Classification: Corporate, Employee, Financial, or Personal
  • Attribute Sensitivity: Highly Restricted, Internal, Public, or Restricted
  • Attribute DataType: Date, Decimal, Integer, String, Boolean, or Timestamp
  • Maximum Field Length
  • Attribute Type: Email, Phone Number, or IP Address
  • List: the List a replacement value can be drawn from
  • Default Data Subject Type: requires additional approval

Editing an Attribute

Click the pencil icon in the row of the chosen attribute to edit any of the above fields.

Meta Tags

Unlike a generic key-value pair, which is fluid and can drift in naming and meaning across an organisation, a Meta Tag is predefined: a fixed, named piece of metadata everyone in the tenancy uses consistently. This came out of a specific client need for standardised tagging rather than freeform fields that different teams might label differently over time.

Meta Tags attach to Manifests and Policies, letting an organisation record additional structured context against either. The flagship use case is tagging a Policy with the regulation or internal policy driving it, for example:

  • GDPR, where a Policy exists to enforce cross-border data-sharing rules.
  • DORA, where a Policy exists to enforce cross-border operational-resilience rules for financial entities.

This makes it possible to answer "which Policies exist because of GDPR" or "show me everything driven by DORA" directly, rather than relying on naming conventions or memory.

Evolving feature

Meta Tags exist today, but their extensive use against Policies (the regulation-tagging use case above) is a planned direction rather than something fully built out yet. The click-through steps for creating and assigning a Meta Tag haven't been documented, since the shape of that workflow is still settling. Worth revisiting once the Policy-tagging functionality lands.

What's next

With your Attributes defined, the next step is Countries, scoping where each piece of data is allowed to be shared. Attributes say what you're protecting; Countries say where it's allowed to travel.