Sensitive Data & Compliance Tags

Summary

Attribute definitions in Keymate carry compliance metadata that controls how the platform handles sensitive information. Each definition can be marked as sensitive, configured with UI masking, assigned a data classification label, protected with encryption flags for data at rest and in transit, governed by a retention policy with anonymization behavior, and flagged for legal restriction visibility. Administrators declare these settings at the definition level, and the platform applies them across admin interfaces, API responses, and data storage.

Why It Exists

Regulatory frameworks such as KVKK (Turkish Personal Data Protection Law) and GDPR require organizations to identify, classify, and protect personal and sensitive data throughout its lifecycle. Embedding compliance metadata directly into attribute definitions ensures that protection rules travel with the data. Administrators configure protections once at the schema level, and the platform applies them consistently — regardless of which interface or process accesses the attribute value.

Where It Fits in Keymate

Compliance metadata on attribute definitions affects behavior across multiple platform layers:

• Admin interfaces — respect the masking setting to hide sensitive values in UI displays, showing masked representations instead of raw data.
• API responses — apply legal restriction rules to control whether attribute values appear in responses for users with legal restrictions.
• Data storage — honor encryption flags to protect attribute values at rest and in transit.
• Data lifecycle — retention period and anonymization-on-delete settings govern how long data is kept and what happens when it is removed.
• Policy Engine — can reference data classification metadata during policy evaluation to inform access controls based on data sensitivity.

Boundaries

Sensitive data and compliance tags cover:

• Marking attribute definitions as sensitive with UI masking
• Assigning data classification labels to attribute definitions
• Configuring encryption flags (at rest, in transit) per attribute definition
• Defining retention policies with anonymization behavior
• Controlling attribute visibility for users with legal restrictions

Sensitive data and compliance tags do not cover:

• Consent management workflows — consent collection and tracking are outside the attribute system
• Data residency constraints — storage location decisions are handled at the infrastructure level
• Right-of-access or right-to-erasure request processing — these are operational workflows, not schema-level metadata
• Attribute value inheritance or scope resolution — see Attribute Value Inheritance

How It Works

Sensitive flag and UI masking

Each attribute definition carries a sensitive flag that marks it as containing personal or sensitive data. A separate UI masking setting controls whether the attribute value is hidden in admin interfaces. When administrators enable masking, admin console screens display a masked representation instead of the raw value.

Data classification

Each definition can carry a data classification label — a free-text value that categorizes the sensitivity level of the attribute. Examples include "personal data," "sensitive personal data," or "public." This label serves as metadata that policies, audit reports, and data governance processes can reference.

Encryption flags

Attribute definitions provide two independent encryption flags:

Control	Purpose
Encryption at rest	Indicates the stored attribute value requires encryption
Encryption in transit	Indicates the attribute value requires encrypted transmission

These flags operate independently. An attribute can be flagged for encryption at rest without requiring in-transit encryption, or vice versa, depending on the data protection requirements for that specific attribute.

Retention policy

Each attribute definition can declare a retention policy that governs how long the platform retains attribute values and what happens when data is removed:

• Retention period — describes how long attribute values should be retained
• Anonymize on delete — when enabled, removing an attribute value replaces it with an anonymized representation instead of removing it entirely, preserving referential integrity while eliminating personally identifiable information

Legal restriction masking

Some users carry a legal restriction flag (for example, individuals under legal protection orders). When the platform resolves effective user attributes, it checks each attribute definition's legal restriction visibility setting:

• If the definition is marked as visible under legal restrictions, the attribute value appears normally in API responses regardless of the user's legal restriction status.
• If the definition is not marked as visible, the platform replaces the attribute value with a masked value in API responses for users with an active legal restriction.

The platform evaluates legal restriction masking at the user level (based on whether the user has a legal restriction) and controls it at the definition level (based on the visibility setting). The platform applies masking automatically during effective attribute resolution — see Attribute Value Inheritance.

Diagram

Example Scenario

Scenario

A compliance officer configures a national identification number attribute with full compliance protections. The attribute must be flagged for encryption at rest, masked in admin interfaces, and hidden from API responses when a user has a legal restriction.

Input

• Actor: Compliance officer configuring the attribute definition
• Resource: Attribute definition for national identification number
• Action: Set compliance metadata
• Context: Sensitive flag enabled, UI masking enabled, data classification set to "sensitive personal data," encryption at rest enabled, retention period configured, anonymize-on-delete enabled, legal restriction visibility set to not visible

Expected Outcome

• Applied
• Why: Admin console screens display a masked representation instead of the raw value for this attribute. When the platform resolves attributes for a user with an active legal restriction, the national identification number returns a masked value in the API response. If the attribute value is removed, the platform replaces it with an anonymized representation.

Common Misunderstandings

• "Marking an attribute as sensitive automatically encrypts it." — The sensitive flag and encryption flags are independent settings. An attribute can be marked sensitive without enabling encryption, and encryption can be enabled on non-sensitive attributes. Configure each control according to the specific data protection requirements.
• "Legal restriction visibility is per-attribute." — Legal restriction is a per-user condition (the user either has a legal restriction or does not). The attribute definition controls whether its values are visible or masked for users who have a legal restriction. The same attribute shows or hides depending on the user whose data is being accessed.
• "Data classification labels enforce automatic behavior." — Classification labels are metadata values, not enforcement triggers. They inform policies, governance processes, and reporting, but they do not by themselves activate encryption, masking, or retention. Configure the specific compliance flags alongside the classification label.

warning

Enabling anonymize-on-delete is irreversible for removed data. Once an attribute value is anonymized, the original value cannot be recovered. Verify that retention and anonymization settings align with your regulatory requirements before enabling this setting.

Design Notes / Best Practices

• Mark personal data attributes as sensitive from the start. Retrofitting compliance metadata after values exist requires reviewing all stored data and potentially migrating it.
• Enable encryption at rest for regulated data. National identification numbers, financial data, and health information should use encryption at rest regardless of other sensitivity settings.
• Configure legal restriction visibility for all identity attributes. Any attribute that could identify a protected individual — name, address, contact information, identification numbers — should be hidden when the user has a legal restriction.
• Use data classification labels consistently across all definitions. Establish a standard classification taxonomy (such as "public," "internal," "personal data," "sensitive personal data") and apply it uniformly to support governance reporting and policy conditions.

tip

Review compliance metadata settings during attribute definition creation — not after data is already stored. Changing encryption or retention settings on an existing attribute may require migration steps that are more involved than configuring the settings upfront.

Related Use Cases

• Configuring national identification attributes with encryption and legal restriction masking for KVKK compliance
• Setting retention policies for temporary employee attributes that should be anonymized after contract termination
• Marking health-related attributes as sensitive with UI masking to prevent inadvertent exposure in admin interfaces
• Applying data classification labels to support compliance reporting across all attribute definitions

Related Docs

Attribute Definition Model

Schema-driven attribute definitions where compliance metadata is configured

Attribute Value Inheritance

How attribute values resolve across scopes, with legal restriction masking applied after resolution

Authorization Concepts

How attribute metadata can inform policy evaluation decisions

Glossary — Attribute

Platform-wide definition of an attribute