> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dqlabs.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Data Protection

> Encryption, masking, tokenization, and audit logging for sensitive data.

<script type="application/ld+json">
  {`{
            "@context": "https://schema.org",
            "@type": "TechArticle",
            "headline": "Data Protection",
            "description": "Encryption, masking, tokenization, and audit logging for sensitive data.",
            "url": "https://docs.dqlabs.ai/security/data-protection",
            "publisher": {
              "@type": "Organization",
              "name": "DQLabs Inc",
              "logo": "https://media.brand.dev/332adc35-5bc4-4d2b-bf78-256aa4a5e414.svg"
            }
            }`}
</script>

## Overview

Prizm employs comprehensive data protection measures across the entire data lifecycle. Data protection in Prizm is a layered system designed to protect data at rest, in transit, and during processing. All protection mechanisms are continuously monitored and enforced through automated controls.

## Encryption Standards

### Data at Rest

All data stored within the Prizm platform is encrypted at rest to protect against unauthorized access to the underlying storage infrastructure.

| Data Type             | Standard    | Key Management                                                       |
| --------------------- | ----------- | -------------------------------------------------------------------- |
| Database records      | AES-256-GCM | Platform-managed keys with HSM protection                            |
| File storage          | AES-256-CBC | Per-object encryption keys                                           |
| Backups               | AES-256-GCM | Separate backup encryption keys                                      |
| Credentials / Secrets | AES-256-GCM | Vault-managed (see [Vault Integration](/security/vault-integration)) |

### Data in Transit

All data transmitted between clients and the Prizm platform, as well as between internal services, is encrypted using modern TLS standards.

* **TLS 1.3** enforced for all external client connections
* **TLS 1.2** minimum for legacy system compatibility (configurable)
* **Certificate pinning** available for mobile and thick client integrations
* **HSTS** (HTTP Strict Transport Security) enabled for all web interfaces
* **Mutual TLS (mTLS)** supported for service-to-service communication

## Data Classification

### Classification Levels

Prizm uses an automated tagging system to categorize data sensitivity. Classification is applied at ingest and can be updated by authorized users.

| Level | Label            | Example Data                             | Access Control               |
| ----- | ---------------- | ---------------------------------------- | ---------------------------- |
| L1    | **Public**       | Marketing materials, published reports   | All authenticated users      |
| L2    | **Internal**     | Business metrics, internal documentation | All employees, SSO required  |
| L3    | **Confidential** | Financial data, strategy documents       | Role-based, need-to-know     |
| L4    | **PII**          | Names, emails, IDs, health data          | Explicit assignment required |
| L5    | **Restricted**   | Keys, credentials, audit logs            | Admin only, dual approval    |

### Automated Classification

Prizm's classification engine applies tags to data based on:

* **Pattern matching** for known PII formats (SSN, credit card numbers, email addresses)
* **Machine learning models** trained on labeled enterprise data sets
* **Keyword and metadata analysis** based on configurable rule sets
* **Manual override** by authorized data stewards

## Access Controls

Fine-grained access controls enforce data classification policies across the platform:

* Access to classified data requires an explicit role assignment that includes the relevant tag
* The RBAC + ABAC model enables tag-based filtering (see [Role-Based Access Control](/security/rbac))
* Data owners can grant and revoke access to resources within their domain
* Temporary access grants with configurable expiry are supported via `assignment.expiry_date`
* Emergency access procedures require dual approval and are fully audited

## Data Masking and Tokenization

PII and sensitive data is masked for users who are not explicitly granted PII access, protecting sensitive information while maintaining data utility for analytics and reporting.

| Data Type          | Masking Technique | Example             |
| ------------------ | ----------------- | ------------------- |
| Email addresses    | Partial masking   | `j***@example.com`  |
| Names              | Initial masking   | `J*** D***`         |
| Phone numbers      | Partial masking   | `+1 (***) ***-1234` |
| SSN / National IDs | Full masking      | `***-**-****`       |
| Financial data     | Tokenization      | `tok_a1b2c3d4e5f6`  |
| IP addresses       | Partial masking   | `192.168.*.*`       |

## Audit Logging

Comprehensive audit logging tracks all data access and modification events:

<CardGroup cols={2}>
  <Card title="Immutable logs" icon="lock">
    Audit logs are stored separately from operational data and cannot be modified or deleted.
  </Card>

  <Card title="Full operation coverage" icon="list-check">
    Every read, write, and delete operation is logged with user, timestamp, and resource.
  </Card>

  <Card title="Configurable retention" icon="calendar">
    Log retention follows configurable policies. Minimum 1 year recommended for compliance.
  </Card>

  <Card title="SIEM integration" icon="plug">
    Logs are exportable in JSON and CSV formats and support real-time SIEM streaming.
  </Card>
</CardGroup>

<Note>
  Real-time alerting is available for anomalous access patterns and policy violations. Configure alert rules in **Admin Settings → Audit & Alerts**.
</Note>

## Key Management

Encryption key management follows industry best practices:

* **Hardware Security Modules (HSM)** protect master encryption keys
* **Vault integration** provides secrets management for application credentials
* **Key rotation schedules** are enforced automatically (configurable intervals)
* **Key escrow and recovery** procedures are documented and tested annually
* **Separate keys** are used for different data classifications and environments

## Data Residency

Prizm supports data residency requirements for regulated industries and jurisdictions:

* Data region selection is configurable at the tenant level
* Cross-region replication can be restricted for sensitive data classifications
* Data residency controls are enforced at the storage layer and documented for compliance audits

Prizm employs comprehensive data protection measures across the entire data lifecycle. Data protection in Prizm is a layered system designed to protect data at rest, in transit, and during processing. All protection mechanisms are continuously monitored and enforced through automated controls.

## Encryption Standards

### Data at Rest

All data stored within the Prizm platform is encrypted at rest to protect against unauthorized access to the underlying storage infrastructure.

| Data Type             | Standard    | Key Management                                                       |
| --------------------- | ----------- | -------------------------------------------------------------------- |
| Database records      | AES-256-GCM | Platform-managed keys with HSM protection                            |
| File storage          | AES-256-CBC | Per-object encryption keys                                           |
| Backups               | AES-256-GCM | Separate backup encryption keys                                      |
| Credentials / Secrets | AES-256-GCM | Vault-managed (see [Vault Integration](/security/vault-integration)) |

### Data in Transit

All data transmitted between clients and the Prizm platform, as well as between internal services, is encrypted using modern TLS standards.

* **TLS 1.3** enforced for all external client connections
* **TLS 1.2** minimum for legacy system compatibility (configurable)
* **Certificate pinning** available for mobile and thick client integrations
* **HSTS** (HTTP Strict Transport Security) enabled for all web interfaces
* **Mutual TLS (mTLS)** supported for service-to-service communication

## Data Classification

### Classification Levels

Prizm uses an automated tagging system to categorize data sensitivity. Classification is applied at ingest and can be updated by authorized users.

| Level | Label            | Example Data                             | Access Control               |
| ----- | ---------------- | ---------------------------------------- | ---------------------------- |
| L1    | **Public**       | Marketing materials, published reports   | All authenticated users      |
| L2    | **Internal**     | Business metrics, internal documentation | All employees, SSO required  |
| L3    | **Confidential** | Financial data, strategy documents       | Role-based, need-to-know     |
| L4    | **PII**          | Names, emails, IDs, health data          | Explicit assignment required |
| L5    | **Restricted**   | Keys, credentials, audit logs            | Admin only, dual approval    |

### Automated Classification

Prizm's classification engine applies tags to data based on:

* **Pattern matching** for known PII formats (SSN, credit card numbers, email addresses)
* **Machine learning models** trained on labeled enterprise data sets
* **Keyword and metadata analysis** based on configurable rule sets
* **Manual override** by authorized data stewards

## Access Controls

Fine-grained access controls enforce data classification policies across the platform:

* Access to classified data requires an explicit role assignment that includes the relevant tag
* The RBAC + ABAC model enables tag-based filtering (see [Role-Based Access Control](/security/rbac))
* Data owners can grant and revoke access to resources within their domain
* Temporary access grants with configurable expiry are supported via `assignment.expiry_date`
* Emergency access procedures require dual approval and are fully audited

## Data Masking and Tokenization

PII and sensitive data is masked for users who are not explicitly granted PII access, protecting sensitive information while maintaining data utility for analytics and reporting.

| Data Type          | Masking Technique | Example             |
| ------------------ | ----------------- | ------------------- |
| Email addresses    | Partial masking   | `j***@example.com`  |
| Names              | Initial masking   | `J*** D***`         |
| Phone numbers      | Partial masking   | `+1 (***) ***-1234` |
| SSN / National IDs | Full masking      | `***-**-****`       |
| Financial data     | Tokenization      | `tok_a1b2c3d4e5f6`  |
| IP addresses       | Partial masking   | `192.168.*.*`       |

## Audit Logging

Comprehensive audit logging tracks all data access and modification events:

<CardGroup cols={2}>
  <Card title="Immutable logs" icon="lock">
    Audit logs are stored separately from operational data and cannot be modified or deleted.
  </Card>

  <Card title="Full operation coverage" icon="list-check">
    Every read, write, and delete operation is logged with user, timestamp, and resource.
  </Card>

  <Card title="Configurable retention" icon="calendar">
    Log retention follows configurable policies. Minimum 1 year recommended for compliance.
  </Card>

  <Card title="SIEM integration" icon="plug">
    Logs are exportable in JSON and CSV formats and support real-time SIEM streaming.
  </Card>
</CardGroup>

<Note>
  Real-time alerting is available for anomalous access patterns and policy violations. Configure alert rules in **Admin Settings → Audit & Alerts**.
</Note>

## Key Management

Encryption key management follows industry best practices:

* **Hardware Security Modules (HSM)** protect master encryption keys
* **Vault integration** provides secrets management for application credentials
* **Key rotation schedules** are enforced automatically (configurable intervals)
* **Key escrow and recovery** procedures are documented and tested annually
* **Separate keys** are used for different data classifications and environments

## Data Residency

Prizm supports data residency requirements for regulated industries and jurisdictions:

* Data region selection is configurable at the tenant level
* Cross-region replication can be restricted for sensitive data classifications
* Data residency controls are enforced at the storage layer and documented for compliance audits