6.6 Implementing Data Processing Segregation

6.6 Implementing Data Processing Segregation

Quick Summary: Segregation keeps personal data, and the processing that uses it, separated so that one compromise, one query, or one team cannot see everything. Privacy engineers separate identity from behavior, separate tenants from each other, separate environments (production, testing, analytics), and separate processing by purpose. The aim is to make linkage and misuse hard by design rather than relying on everyone following policy.

The BoK lists "implement data processing segregation" as a collection-stage control because segregation decisions are made when data enters a system: which store receives which fields, under which keys, and who can join them later.

---

Four Kinds of Segregation

Environment segregation deserves special attention because test and staging systems usually have weaker access control and logging than production. Use synthetic data or masked copies (with consistent tokenization so joins still work), block production credentials in lower environments, and scan non-production stores for real personal data. Purpose segregation supports purpose limitation (Section 7.5): if marketing systems physically cannot read the security-only phone number store, function creep requires a deliberate, reviewable change rather than a quiet query.

Architectural Segregation: Decoupling Identity from Behavior

A critical failure mode in enterprise system design is the monolithic datastore pattern, in which direct personally identifiable information (PII)—such as legal names, email addresses, government identifiers, and billing records—resides in the same database tables or clusters as behavioral event streams, search histories, clickstream logs, and sensor telemetry.

Under this flawed model, any security breach, SQL injection, unauthorized internal query, or data export immediately links sensitive behavioral activities to real-world individuals.

The Dual-Datastore Segregation Pattern

Privacy-by-design architectures enforce architectural segregation by separating data across two isolated trust zones:

The Tokenization and Identity Mapping Service

To correlate behavioral trends with user cohorts without exposing identities, systems deploy an isolated Identity Mapping Service (also known as a Pseudonymization Proxy or Tokenization Vault):

1. When an event occurs, the client or edge gateway sends the event to the Ingestion Router.
2. The Ingestion Router strips all direct identifiers and queries the Identity Mapping Service to exchange the real user_id for a cryptographically secure, randomized surrogate token (pseudo_id = f98c3e8a-2114-41b9-8c99-0129a084ef72).
3. The mapping table between user_id and pseudo_id resides in a hardened, isolated database protected by dedicated envelope encryption.
4. Behavioral logs are committed to the data lake referencing only pseudo_id.
5. If an analytical report requires contacting a specific cohort (e.g., notifying users affected by an operational issue), only an authorized compliance microservice with elevated privileges can submit the pseudo_id list to the mapping service to resolve the underlying contact information.

---

Multi-Tenant Data Isolation Architectures

In Software-as-a-Service (SaaS) and cloud-native applications, systems frequently process personal data belonging to thousands of independent enterprise tenants. Preventing tenant data bleed—where a query, indexing bug, or caching defect exposes Tenant A's customer PII to Tenant B—requires rigorous structural isolation.

+-----------------------------------------------------------------------------------+
|                         MULTI-TENANT ISOLATION MODELS                             |
|                                                                                   |
|  1. SILO MODEL (Database-per-Tenant)                                              |
|  +--------------------+   +--------------------+   +--------------------+         |
|  | Tenant A Database  |   | Tenant B Database  |   | Tenant C Database  |         |
|  | (Independent Keys) |   | (Independent Keys) |   | (Independent Keys) |         |
|  +--------------------+   +--------------------+   +--------------------+         |
|  [Max Isolation, Zero Bleed Risk, Independent Retention & Crypto-Shredding]       |
|                                                                                   |
|  2. BRIDGE MODEL (Schema-per-Tenant)                                              |
|  +-----------------------------------------------------------------------------+  |
|  | Single Database Instance                                                    |  |
|  |  +-----------------------+  +-----------------------+  +-----------------+  |  |
|  |  | Schema: tenant_a      |  | Schema: tenant_b      |  | Schema: tenant_c |  |  |
|  |  +-----------------------+  +-----------------------+  +-----------------+  |  |
|  +-----------------------------------------------------------------------------+  |
|  [Logical Isolation via SQL Namespaces, Shared Resources, High DDL Overhead]      |
|                                                                                   |
|  3. POOL MODEL (Shared-Schema with Row-Level Security)                            |
|  +-----------------------------------------------------------------------------+  |
|  | Single Database Instance & Single Shared Schema                             |  |
|  |  +-----------------------------------------------------------------------+  |  |
|  |  | Unified Table (orders, users) with tenant_id Column                   |  |  |
|  |  | Postgres Row-Level Security: USING (tenant_id = current_setting('...')) |  |  |
|  |  +-----------------------------------------------------------------------+  |  |
|  +-----------------------------------------------------------------------------+  |
|  [Highest Cost Efficiency, Operational Simplicity, Risk of App Logic Leakage]     |
+-----------------------------------------------------------------------------------+

Comparison of Tenancy Architectures

Enforcing Row-Level Security (RLS) in Shared-Schema Models

When operating a pooled architecture, reliance on application-layer code to append WHERE tenant_id = :current_tenant is an anti-pattern that inevitably results in data leaks. Instead, isolation must be enforced directly at the database engine level via Row-Level Security (RLS):

-- Enable Row-Level Security on the target table
ALTER TABLE customer_profiles ENABLE ROW LEVEL SECURITY;

-- Force security policies even for table owners
ALTER TABLE customer_profiles FORCE ROW LEVEL SECURITY;

-- Define tenant isolation policy using session context
-- (a permissive policy; a RESTRICTIVE policy alone would deny every row,
--  because PostgreSQL requires at least one permissive policy to grant access)
CREATE POLICY tenant_isolation_policy ON customer_profiles
  USING (tenant_id = current_setting('app.current_tenant_id', true)::uuid);

Before executing any query on a pooled database connection, the application middleware must execute:

SET LOCAL app.current_tenant_id = 'e7b1c34a-9812-421b-8012-110022334455';

SET LOCAL (or set_config(..., true)) scopes the value to the current transaction, so it disappears at COMMIT or ROLLBACK and cannot leak into the next request that reuses the pooled connection. It has no effect outside a transaction block, so the middleware must open a transaction first. If the setting is missing, current_setting(..., true) returns NULL and the policy matches no rows, which fails closed.