A surveillance platform is itself a record-keeping obligation. Here is how DataTap is actually run — the same answers we give in diligence, public.
Every tenant-owned table carries a tenant id, and the database layer refuses any query that isn't scoped to one — isolation doesn't depend on application code remembering. Cross-tenant access exists in exactly one operator module, on purpose, for platform administration.
Case files, reports, and audit packages land in an append-only store with SHA-256 recorded at write; package manifests are chain-hashed (each hash commits to the one before). Nothing dispositive is editable after the fact.
Dispositions, control changes, cluster splits, and package releases require a proposer and a different approver — enforced server-side, re-fetching the acting user. Hiding a button is never the control.
Passwordless magic links or per-tenant SSO (OIDC); optional TOTP 2FA; server-side session revocation; 8-hour idle timeout; rate limits on every token-consuming endpoint. Credentials never appear in logs — parameter filtering is on everywhere.
Nightly logical backups with content hashes, retained 14 deep, restore-drilled (the drill is documented in the DR runbook, with the measured RPO), and replicated off-box to object storage. The rebuild-from-zero path is written down and has been executed.
Retention windows per data class with per-tenant overrides; regulator-trail tables are exempt from pruning by construction (Reg 1.31 posture). Offboarding purges every tenant-owned row — the DPA's deletion promise is a tested code path, not a policy PDF.
Dependency audit runs in CI on every commit. The HTTP surface sits behind a strict content-security policy; the ops stack (error capture, rate limiting, job queue, object-store client) is built in-repo rather than bolted on from third-party services, which keeps the data-flow diagram short.
The readiness program is underway: change-management evidence (append-only admin log), quarterly access reviews generated from live state, and control mapping are already producing artifacts. Ask for the current state in diligence and we'll show the actual screens, not a roadmap.
Four classes, each with a home, an access rule, a retention window and enumerated exit paths: C0 public (these pages), C1 internal (deploy and incident logs, job queue — no tenant data), C2 tenant-confidential (trades, book, settlements, KYC attributes as hashed tokens — tenant-guarded at the query layer, purged on offboarding) and C3 regulated records (WORM reports, packages, admin and access logs — exempt from pruning, released only as chain-hashed packages). A derived artifact takes the highest class of its inputs. The full map is available in diligence.
Every third party that can touch service or tenant data is listed, with data class, region and status, at /subprocessors — planned providers appear before they go live. No advertising, analytics or session-replay vendors.
/status shows the 90-day history derived from the incident log (a day is degraded only when an incident was open) and the deploy log written at every boot — version, image and commit — so "what changed and when" has one answer.
Live health: /status · Vulnerability reports and security questions: the contact form, marked "security". Questions a questionnaire asks that this page doesn't answer: send the questionnaire.