Security Architecture · PII Redaction Platform

Data Security & Trust

Privacy enforced
at the infrastructure
layer.

Treza doesn't bolt privacy onto existing systems — it enforces it at runtime, before sensitive data can reach models, logs, or downstream services. No configuration drift. No manual review gaps.

Designed for security and compliance teams that need verifiable guarantees — not checkbox policies.


Security architecture

Layer 01

Runtime Enforcement

PII is intercepted and stripped before it enters any downstream system. Field-level policies enforce minimum-necessary access — no overrides, no logging of what was removed.

Layer 02

Encrypted Vault

Sensitive fields are stored in an encrypted vault with AES-256 at rest and TLS 1.3 in transit. Decryption requires an explicit, declared purpose — not just a valid token.

Layer 03

Consent-Gated Access

Every retrieval is tied to a stated purpose and subject identity. Access without a valid consent record is denied at the API level — not just logged after the fact.

Layer 04

Immutable Audit Log

Every access event — granted or denied — is written to a tamper-evident log. Records include actor, purpose, timestamp, and record ID. Exportable for any audit framework.


Compliance coverage

GDPR

Lawful basis, data minimization, erasure rights, Article 30 records

CCPA / CPRA

Consumer opt-out, data deletion, purpose limitation

HIPAA

PHI access controls, audit controls, minimum necessary standard

SOC 2 Type II

Availability, confidentiality, processing integrity evidence

Trust principles

Zero-trust data access

No implicit access by role or service. Every retrieval must declare intent and match an active consent record.

No plaintext in transit or at rest

PII fields are encrypted end-to-end. Treza staff cannot access customer data — only customers and their designated systems can.

Breach containment by design

Because sensitive fields are stripped before reaching models or logs, a downstream breach exposes redacted data — not raw PII.