How TrackIt protects your data
This page describes what is actually built and verified today, and is explicit about what isn't yet in place. We'd rather tell you the honest current state than leave you to assume more than is true.
Tenant isolation, enforced by the database
Every tenant-scoped table carries a Postgres row-level security policy keyed on the requesting organization, applied per-request via SET LOCAL — not just an application-layer check that a forgotten filter could bypass. Policies are FORCE-enabled, so even the table owner is subject to them. Verified: a session scoped to one organization returns zero rows for another; an unscoped session returns zero rows rather than everything.
Project isolation within an organization
Every route enforces that a user has both an active organization membership and an active project membership before returning project content. For transport request data specifically, this is additionally backed by a database-level restriction: a session scoped to one project cannot read or write another project's transport requests, even via a raw query, regardless of application-layer bugs.
Tamper-evident audit ledger
Governance actions are recorded in a hash-chained ledger — each entry’s signature incorporates the previous entry’s, so altering or deleting a past record breaks the chain in a way that is independently verifiable, not just logged. A separate HMAC-signed activity log covers general application events.
Encryption
Sensitive fields (SSO client secrets, SAP connection credentials) are encrypted at rest with AES-256-GCM. All traffic is served over TLS. Database role credentials are rotatable via a provided operator script, and the platform enforces least-privilege database roles for the application, background workers, and migrations separately.
Privileged access is audited and time-boxed
Platform operators (TrackIt staff) can see organization, project, and user counts and manage billing and lifecycle state — never the content of your transports, approvals, or messages. Reaching into a specific project’s content requires an explicit, time-limited "firefighter" session that is itself an audited governance event, not a standing bypass.
Backup and recovery
Nightly logical backups (checksummed) plus continuous write-ahead-log archiving for point-in-time recovery, replicated off the primary host. Restore procedures are exercised on a schedule, not assumed to work — a restore that only produces a partial database fails loudly rather than reporting false success.
Compliance roadmap — where we are today
We are not yet SOC 2 or ISO 27001 certified, and the platform has not yet had an independent third-party penetration test. Both are on our roadmap. If either is a requirement for your procurement process, tell us — we plan around real customer timelines rather than a fixed date, and can share our internal security review findings under NDA in the meantime.
Every claim above this section was verified directly against a running instance of the system — not asserted from documentation — as part of an internal security review. That review is not a substitute for independent, third-party certification, and we say so plainly rather than implying otherwise.
Questions about a specific control, or need documentation for your security review? Get in touch.