US privacy laws for engineers: how to tag and encrypt data

The Real Technical Impact of US Privacy Law on Software Architecture

The California Consumer Privacy Act, as amended by the CPRA and enforced by the California Privacy Protection Agency (CPPA) and the California Attorney General, set the template that a fast-growing list of states (including Virginia, Colorado, Connecticut, Texas and others) has followed. For engineering teams these laws are not just a privacy notice on a website: they shape schema design, caching layers, log hygiene, third-party SDKs and key management.

Teams can no longer dump raw JSON into document stores or ship unfiltered user telemetry to every analytics vendor. Data minimization, purpose limitation, honoring opt-out signals and deleting data on request all have to be designed in, and HIPAA, GLBA and state breach-notification laws add their own obligations on top.

A 4-Tier Data Classification Taxonomy

Before writing a single migration, establish a classification taxonomy mapped to storage controls:

• Restricted: Sensitive personal information as defined by the CPRA, such as Social Security numbers, account credentials, precise geolocation, biometric and health data, plus payment card data. Requires field-level envelope encryption, dedicated customer-managed HSM keys and multi-person authorization.
• Confidential: Other personal information such as names, contact details, home addresses and payroll records. Requires column-level encryption and masking in lower environments.
• Internal: Operational logs, vendor contracts, system architectures and internal metrics. Requires storage-level encryption at rest (AES-256).
• Public: Marketing material, published whitepapers and press releases.

Schema Changes: Consent and Opt-Out Ledgers

Users can opt out of the sale or sharing of their data, limit the use of sensitive personal information, and send a Global Privacy Control (GPC) signal that must be honored. A boolean opted_out flag on a users table gives no verifiable history. Production systems need an append-only ledger:

-- Append-only privacy preference ledger
CREATE TABLE user_privacy_preference_ledger (
    event_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID NOT NULL REFERENCES users(id) ON DELETE RESTRICT,
    purpose_code VARCHAR(64) NOT NULL,
    preference VARCHAR(24) NOT NULL CHECK (preference IN ('CONSENT_GRANTED', 'CONSENT_REVOKED', 'OPT_OUT_SALE_SHARE', 'LIMIT_SENSITIVE')),
    source VARCHAR(24) NOT NULL DEFAULT 'USER_SETTING', -- or 'GPC_SIGNAL', 'AGENT_REQUEST'
    ip_address INET NOT NULL,
    user_agent TEXT NOT NULL,
    recorded_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW(),
    data_retention_deadline TIMESTAMP WITH TIME ZONE NOT NULL
);
CREATE INDEX idx_privacy_user_purpose ON user_privacy_preference_ledger(user_id, purpose_code, recorded_at DESC);

Handling Consumer Requests: Access, Correction and Deletion

Consumers can request to know, correct or delete the personal information a business holds, and businesses generally have 45 days to respond. Engineering architectures should implement automated request pipelines that:

1. Verify identity and check whether a legal retention obligation (for example, financial recordkeeping rules) overrides the deletion request.
2. Use cryptographic erasure (destroying the per-user data encryption key) where physically deleting data from immutable backups is not feasible.
3. Propagate deletions across caches (Redis), search indexes (Elasticsearch/OpenSearch), message queues (Kafka/RabbitMQ) and downstream service providers.