Privacy

GDPR · CCPA
answer-ready for the second call

Answer-ready for the second call.

The privacy posture Driftlock commits to in writing — mirrored from the data- handling claims a regulated security reviewer already read on /security, plus the retention windows per data class, the named subprocessor list, and the GDPR / CCPA-style data-subject rights with a contact channel.

Encryption

AES-256 · TLS 1.2+ · customer-managed keys

The same four-surface posture Driftlock commits to on /security — at-rest, in-transit, customer-managed keys, and data residency.

Retention

Per-data-class windows

Account, audit, support, and billing — each class declares its own window and the rationale behind it. Tax / billing retention floors stay.

Subprocessors

Named, region-tagged

Hosting, Postgres, email proxy, Strip Connect (billing) — the four subprocessors a DPOC names on the day-one register.

Overview

Same posture a security reviewer read on /security, in privacy-notice form.

The Driftlock privacy notice is written for the regulator who arrives after the demo closes — the same vocabulary, the same protection terms, the same surface-by-surface commitments. The four surfaces below mirror the four a reviewer runs through on day one; the retention, subprocessor, and rights sections add the privacy-specific artefacts a DPOC asks for.

Driftlock operates as a managed service on Team / Platform tiers (in the region you select at sign-up) and as a self-hosted deployment on the Enterprise tier. The privacy terms on both tiers are the same; the Enterprise tier refines the data residency posture so no per-PR audit data, signing keys, or SBOM payloads ever leave the customer VPC.

Last updated: 2026-08-12 · GDPR + CCPA-aligned

Data handling

Encryption posture, end to end — with keys you control.

Every Driftlock surface is encrypted at rest and in transit. The protection that lands on each surface uses your KMS as the root of trust; the private half of any key never leaves your boundary. The Enterprise tier refines the posture further: HSM-backed signing via PKCS#11, an air-gapped runner, and an on-prem Helm chart for fully disconnected deployments.

The four surfaces below mirror the surface list on /security#data-handling so a reviewer cross-reading both pages does not need to reconcile vocabulary.

Encryption at rest

AES-256 encryption on every storage tier — primary database, ledger pg_append, object-storage mirror, snapshot bucket. Envelope encryption per tenant boundary.

custody

Per-tenant DEKs wrapped by a KMS-resident KEK you control. The KEK never leaves your KMS; Driftlock reads only the public half.

Encryption in transit

TLS 1.2 minimum across every internal hop (TLS 1.3 preferred where both peers support it) — watcher → sandbox → signer, sandbox → registry, GitHub webhook → watcher. mTLS on the internal mesh; no plain-text on any service-to-service link.

custody

Hosted cluster pins the CA bundle in your KMS-managed trust store; Enterprise tier swaps to your private CA for air-gapped deployments.

Customer-managed keys (CMK / BYOK)

Platform tier routes every envelope key through your KMS alias — KMS-managed by default, Customer-Managed Key (CMK) opt-in via a single key alias. Enterprise tier swaps to your HSM via PKCS#11.

custody

The private half never leaves your boundary. Driftlock receives the wrapped DEK; it never holds plaintext key material outside the sandbox.

Data residency

Team and Platform tiers run as a managed service in the region you select at sign-up. Enterprise tier self-hosts inside the customer VPC; no per-PR audit data, signing keys, or SBOM payloads ever leave the customer network.

custody

Region selected at chart install. No Driftlock-managed object storage carries customer artefacts; the platform never has a path to read them.

AES-256 at rest
TLS 1.2+ in transit
KMS-resident KEK
customer-managed keys · no Driftlock-managed key material

Data retention

One window per data class — with the rationale behind it.

Driftlock splits retention into four data classes — account & profile, per-PR audit metadata, support / contact submissions, and billing receipts. Each class declares its own default window and the rationale behind it. The audit class inherits the same 7y hot / 10y cold window documented on /security#rbac-audit.

Data class

Examples

Default window

Rationale

account-profile

Account & profile data

Login email, identity (GitHub App installation), seat assignments, billing contact, organisation settings.

For the active subscription period + 30 days (closure window), then purged.

30 days posts the cancellation window so reactivation restores the same tenant; thereafter only an anonymised billing receipt remains for tax compliance.

audit-trail

Per-PR audit metadata

Alert id, triage verdict, drafted diff bytes, hermetic-build hash, approver chain, signature, SBOM hash — the seven columns documented on /security.

7 years hot · 10 years cold (same as /security).

Mirrors the SOC 2 Type II observation window + a regulatory retention floor set by the auditor and the SOC 2 Trust Services Criteria.

support-contact

Support / contact submissions

Inbox messages submitted through the contact-form module, screenshot attachments in-line, blackbox reproductions, and any agent reply thread.

24 months from last contact.

Two years covers a regulator look-back window plus the typical timeframe a customer returns with a follow-up question. Re-identifying PII is purged on request.

billing-receipts

Billing receipts

Stripe invoice metadata, line items, charge id, tax id fields, refund records, and any dispute evidence bundled with the receipt.

7 years from invoice date.

Hard floor set by tax authorities (e.g. IRS 7-year recordkeeping in the United States) — never shortened below this window.

four classes · tax / billing floors respectedconfigurable on Enterprise
Ask for a longer / shorter window per data class
Enterprise tier · write-window into your DPA

Subprocessors

The four systems on the day-one register.

A DPOC names the subprocessors Driftlock uses on day one, and the data each subprocessor handles. Material additions to this list are announced at least thirty days in advance on this page and by email to the privacy contact on file; existing customers may object under the DPA procedures the contract specifies.

Vendor

Purpose

Data shared

Region

hosting

Polsia — managed node runtime

Hosts the application runtime (Next.js + Node) and Anycast routes requests through Polsia's edge.

Request payloads encrypted in transit (TLS 1.2+); at-rest ciphertext only; no customer plaintext logs leave the chosen region.

Region selected at sign-up; configurable per-tenant at the deploy seam.

database

Polsia — Postgres (managed rdbms)

Stores Driftlock-internal state (account, audit metadata append-only ledger, support inbox records, scheduled-job bookkeeping) and serves the zod-typed API routes.

Account email, audit-trail rows (the seven /security columns), support messages, billing metadata — everything in this notice.

Region selected at sign-up; same region as the hosting runtime.

email

Polsia — email proxy

Sends transactional mail on Driftlock's behalf — contact-form receipts, account/security notifications, alert digests. The proxy is the only outbound mail path; no direct vendor SMTP/Postmark/Resend integration exists in this codebase.

Recipient address, message body, optional in-line html — the standard transactional mail envelope; no attachment or BCC support, no custom From headers.

Region transit handled by the email proxy; the inbox that receives inbound mail is the per-tenant {slug}@polsia.app address.

billing

Polsia — Stripe Connect (via stripe-billing module)

Issues subscription invoices, processes recurring payments, manages tax + VAT, and routes payouts to Driftlock as a Stripe Connect platform.

Customer billing name + email, payment method tokens (Stripe never shares the raw PAN), invoice line items, last-4 of card for receipt display.

Stripe chooses its data-processing region per Stripe DPA defaults; the Stripe Connect operating entity is the one nominated in your MSA / invoice receipt.

four subprocessors · day-one register30-day notice on material change
hosting
postgres
email proxy
stripe connect
Stripe DPA + Polsia DPA apply per subprocessor

Your rights

GDPR + CCPA-aligned — three rights, one channel.

Driftlock recognises three data-subject rights consistent with the European General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA): Access, Export, and Deletion. Each right has a 30-day identity-verified turnaround, and the channel is the contact-form module mounted below — every message lands on the privacy + security inbox.

access

Access — request a copy of your data

Receive a copy of the per-PR audit rows Driftlock retains on your behalf, plus the account / profile fields your tenant holds.

how to act

Send a request through the contact form below; mark the body "data-subject · access" so the privacy officer routes it on the same day.

window

Within 30 days of confirming your identity.

export

Export — portable archive

Receive a CycloneDX-aligned audit trail plus a JSON account profile — the same shape your downstream compliance tooling already ingests.

how to act

Send a request through the contact form below; mark the body "data-subject · export" and name the receiving system if you have one.

window

Within 30 days of confirming your identity.

deletion

Deletion — erasure of audit metadata

Erase the per-PR audit metadata Driftlock retains on your behalf, subject to the tax / billing retention floors in the table above.

how to act

Send a request through the contact form below; mark the body "data-subject · deletion" and identify the tenant + the relevant window.

window

Within 30 days of confirming your identity; tax / billing floors remain.

GDPR-aligned
CCPA-aligned
identity-verified · 30-day response

Data-subject requests

Submit through the contact-form channel — every message lands on the privacy + security inbox.

Every data-subject request — access, export, deletion, or any CCPA / GDPR question the contact form does not frame — lands on the same privacy-and-security inbox the rest of this notice points at. Two-business-day first response; the same channel handles coordinated-disclosure security reports.

Mark the body with the right you are exercising ("data-subject · access" / "export" / "deletion") so the privacy officer picks it up on the same day. Adjacent security reports (cryptographic weakness, key-handling incident, supply-chain finding) are routed to the same inbox — mark those "security · cryptographic" instead.

Data-subject requests

Data-subject request

Exercising one of the rights above, or any other GDPR / CCPA question? Send it through the contact-form channel below — every message lands on the privacy + security inbox; we respond within two business days.

routed to the privacy + security inbox · two-business-day first response · same channel as coordinated-disclosure security reports

researcher-friendly
2 business days first response
Email us
tideline-5xcqop@polsia.app · same inbox as coordinated disclosure

The full trust surface

The privacy notice, the security posture, and the terms — one vocabulary across three documents.

This page is the privacy posture; /security is the SOC 2 + encryption posture; /legal/terms names the reviewer's contract template. All three use the same surface vocabulary (at-rest · in-transit · customer-managed keys · data residency) so a regulator cross-reading them reads the same terms on the same per-record surfaces.

SOC 2 Type II
customer-managed keys
compliance pack ships under NDA · two-business-day turnaround