TrackLayer Security& Architecture Whitepaper

TrackLayer is a server-side tracking and event-delivery platform designed to receive customer-controlled events, normalize them, apply consent and privacy rules configured by the customer, and forward permitted events to customer-selected destinations. The ingestion layer runs on Cloudflare Workers at the edge, placing request handling close to the originating visitor and reducing exposure created by centralized collection tiers. Edge execution also allows TrackLayer to apply validation, rate limits, routing, hashing, and destination fan-out policies before events enter durable storage.

Primary relational persistence is provided by Supabase Postgres in the European Union for EU-pinned workspaces, with strict logical boundaries between customer tenants. TrackLayer does not rely on long-term PII retention to provide attribution or delivery services. Personal data is not retained long term without customer configuration and valid consent. Where identity signals are needed for advertising or analytics interoperability, TrackLayer pseudonymizes or hashes them before egress whenever the downstream protocol supports that form.

The platform follows a control-plane and data-plane model. The control plane stores workspace configuration, roles, routing policies, destinations, consent settings, and audit events. The data plane receives events and executes customer-defined routing. This separation supports least-privilege operation: personnel who maintain billing or account state do not receive broad access to event payloads, and automated workers operate with scoped service credentials.

TrackLayer classifies data by sensitivity, purpose, retention requirement, and access path. Classification determines storage controls, retention limits, support workflow, logging treatment, and review priority during incidents. Customer administrators remain responsible for selecting which event fields to send and for ensuring those fields are compatible with their own notices, consents, and lawful basis.

TrackLayer requires encrypted transport for application, API, dashboard, webhook, and destination communication. Public endpoints support TLS 1.3 in transit. Legacy cipher suites are disabled where provider controls permit, and certificate renewal is automated to reduce operational risk. Customers should also enforce HTTPS on their own storefronts and any server-to-server integrations that send events to TrackLayer.

Data at rest is encrypted using AES-256 through Supabase managed Postgres storage and provider-managed encryption for supporting services. Backups inherit provider encryption and access controls. For enterprise deployments, TrackLayer supports customer-controlled encryption through bring-your-own-key arrangements backed by an HSM. Under that model, the customer controls the key lifecycle, including creation, rotation, revocation, and emergency disablement procedures.

TrackLayer uses role-based access control for customer workspaces. Standard roles are admin, editor, and viewer. Admins can manage users, destinations, security settings, billing references, and deletion requests. Editors can configure routing and operational settings without changing workspace ownership. Viewers receive read-only access to reporting, logs, and configuration surfaces appropriate to their workspace.

Enterprise identity features include SAML SSO and SCIM provisioning. SCIM allows customers to automate joiner, mover, and leaver workflows from their identity provider. SAML SSO can be enforced for managed domains to reduce password exposure and align TrackLayer access with corporate authentication policies. All administrator actions are recorded in an audit log, including user invitations, role changes, destination updates, key rotations, retention changes, and deletion requests.

Internal production access follows least-privilege principles. Access is granted by role, reviewed periodically, and removed when no longer needed. Sensitive operations are logged, and support personnel are expected to use customer-scoped views rather than broad database access. Emergency access is time-bounded and reviewed after use.

Customer API keys are never stored in plaintext for routine verification. TrackLayer hashes and salts customer API keys with bcrypt, then compares presented credentials against the stored verifier. This design reduces the blast radius of an application database exposure because the verifier cannot be used directly as an API credential.

TrackLayer recommends and enforces a 90-day rotation policy for production secrets where technically feasible. Customers may create overlapping keys during migration windows to rotate without downtime, then revoke old keys from the dashboard or API. Webhook signing secrets and destination credentials should be rotated whenever an employee with access leaves, whenever a CI system is reconfigured, and after any suspected exposure.

All CI workflows include secret scanning before code is promoted. Detected secrets block release until reviewed and removed. The same policy applies to infrastructure definitions, application configuration, and test fixtures. Production credentials are not committed to source control and are distributed through scoped secret stores with audit trails.

TrackLayer is designed to minimize personal data movement. Email addresses and phone numbers are normalized, hashed with SHA-256, and transmitted in hashed form before egress to destinations that accept hashed identifiers. Customers should avoid sending raw PII unless required for a contracted use case and explicitly supported by the relevant integration.

IP address and user-agent data are retained for 30 days only for security, debugging, abuse prevention, and delivery diagnostics. After that period, operational use relies on aggregated or pseudonymous records where possible. TrackLayer does not use customer event data to build unrelated advertising profiles or to enrich data for other customers.

Data subject deletion is available through the data_subject_requests endpoint and customer-facing workflows. A deletion request is validated, scoped to the relevant workspace, and propagated across identity records, retained events, delivery logs, and eligible downstream references under TrackLayer control. Customers remain responsible for coordinating deletion in independent systems that receive data outside TrackLayer.

TrackLayer offers two primary data-residency regions: United States, hosted in us-east-1, and European Union, hosted in eu-central-1. Regional selection determines where durable workspace data is stored and where supporting operational services are provisioned when provider capability permits. Transient edge processing may occur near the requester to provide low-latency ingestion, but durable persistence follows the selected region.

Enterprise customers can pin a workspace to one region. Region pinning is appropriate for regulated procurement, internal policy, or contractual commitments that restrict storage location. Cross-region movement is treated as a controlled migration and is not performed casually. If a customer changes residency requirements, TrackLayer will provide a migration plan that addresses downtime, backup handling, and validation.

TrackLayer runs SAST in CI using Semgrep rules covering common web application, TypeScript, infrastructure, and secret-management risks. Dependency and container findings are triaged by severity, exploitability, affected surface, and compensating controls. Critical vulnerabilities affecting externally reachable production systems are prioritized for immediate remediation or mitigation.

Dynamic application security testing is performed quarterly against representative production-like surfaces. TrackLayer also commissions an annual penetration test by an independent provider. Findings are tracked through remediation, validation, and closure. Executive summaries are made available to enterprise customers under NDA when the report is current and disclosure does not increase risk to other customers.

TrackLayer maintains a disclosure channel at security@tracklayer.io. Security reports receive acknowledgement within 72 hours. A valid report should include affected asset, reproduction steps, potential impact, and whether any customer data was accessed.

TrackLayer's assurance program is built around evidence, repeatable controls, and customer-verifiable commitments. SOC 2 Type II is in progress with a target completion in Q3 2026. ISO 27001 certification is targeted for Q4 2026. Until reports are available, TrackLayer can provide security questionnaires, architecture summaries, policy excerpts, and control narratives under appropriate confidentiality terms.

TrackLayer is designed to support GDPR and CCPA compliant operation when customers configure the service consistently with their own legal basis, consent requirements, notices, and retention policies. The platform provides data minimization, hashing, deletion, access control, regional storage, and audit capabilities that support those obligations. HIPAA BAA coverage is available for enterprise customers with an approved architecture and contracted scope.

TrackLayer uses subprocessors to deliver edge compute, database storage, email, application hosting, and search-related services. Current core subprocessors include Cloudflare, Supabase, AWS SES, Vercel for edge application delivery, and Brave Search. Each subprocessor is reviewed for purpose, region, security posture, contractual terms, and data protection commitments before use.

The authoritative current list is maintained at /legal/subprocessors. Customers should rely on that page for additions, removals, and notice periods. Where a subprocessor change materially affects the processing of customer personal data, TrackLayer provides notice consistent with the applicable agreement.

TrackLayer maintains a four-phase incident response plan: Detect (auto alerts) → Contain (within 1h) → Eradicate (root cause fix) → Review (post-mortem). Detection sources include application alerts, infrastructure telemetry, abnormal delivery patterns, authentication events, customer reports, and provider notifications. Initial triage assigns severity, owner, affected systems, and communication path.

Containment focuses on stopping active harm within one hour for high-severity incidents where TrackLayer controls the affected system. Actions may include revoking keys, disabling integrations, blocking abusive traffic, isolating services, pausing egress, or applying emergency configuration changes. Eradication addresses root cause through code changes, credential rotation, infrastructure repair, or provider escalation.

Review produces a post-mortem for material incidents. The review records timeline, impact, contributing factors, customer communication, corrective actions, and control improvements. Customer notification obligations are assessed under the DPA, applicable law, and the facts known at the time.

TrackLayer provides secure processing infrastructure, configurable privacy controls, hashing, access management, audit logging, deletion workflows, and destination delivery safeguards. TrackLayer does not determine whether a customer may collect a given data element, whether a marketing pixel should fire for a visitor, or whether a destination is lawful for a specific campaign. Those determinations remain with the customer as controller or business operator.

Customers are responsible for consent UX, CMP selection, local policy language, cookie banners, preference centers, lawful basis analysis, and honoring regional opt-out rules. Customers must configure TrackLayer to match those choices, including consent gates, destination routing, retention settings, and identity field selection. Customers must also protect their own API keys, assign appropriate roles, remove departed users, review audit logs, and keep destination credentials current.

TrackLayer will provide technical documentation and reasonable support for secure configuration, but it cannot substitute for customer legal review or local compliance operations. A strong deployment pairs TrackLayer controls with a current privacy notice, a properly configured CMP, documented internal ownership, and regular review of destination behavior.

AES-256

A symmetric encryption standard used for data stored at rest.

BAA

A Business Associate Agreement for regulated healthcare workloads.

BYOK

Bring Your Own Key, where an enterprise customer controls encryption key material.

CAPI

Conversions API, a server-side destination for advertising events.

CMP

Consent management platform selected and configured by the customer.

DAST

Dynamic application security testing against running application surfaces.

HSM

Hardware security module used to protect and operate cryptographic keys.

PII

Personal information that can identify, contact, or locate a person.

RBAC

Role-based access control that grants permissions through defined roles.

SAML SSO

Security Assertion Markup Language single sign-on for enterprise identity.

SAST

Static application security testing performed against source code.

SCIM

System for Cross-domain Identity Management for user provisioning.