Security & Compliance Posture

Defensible architecture for export-controlled work.

SecurePoint Trade is built for compliance teams who get audited. Tenant isolation is enforced by the database, the audit trail is append-only by trigger, signed-URL artifacts never appear in audit metadata, and the production identity boundary flows from a single authoritative source. Below is exactly how that holds.

Architecture pillars

Six controls that hold under audit pressure.

These are not aspirational. Each one is enforced in code, in the database, or at the identity boundary today.

Per-tenant row-level security

Every tenant table — transactions, licenses, audit logs, deliveries, evidence packs — has Postgres RLS enforced by the database. Reads and writes are filtered to the calling org through `current_org()`. The application layer cannot bypass this; isolation is enforced below the ORM.

Append-only audit trail

The `audit_log` and `platform_bridge_audit_log` tables are append-only by database trigger — UPDATE and DELETE are rejected at the SQL level. Every privileged action across screening, license drawdown, approval, packaging, and dispatch writes a row that cannot be quietly retracted.

PII-safe audit metadata

Audit rows store object references and structured codes (objectType, actionCode, resultCode, policyCode), not raw signed URLs, secrets, recipient addresses, or package contents. The audit story is defensible without becoming a leak surface.

Bridge-authoritative authentication

In production, Trade treats validated SecurePoint platform handoff as the authoritative session bootstrap. Local Trade login is disabled unless explicitly placed in migration or break-glass mode. Identity provenance flows from one source, not three.

Encrypted storage + signed-URL artifact access

Evidence packs and delivery artifacts live in private Supabase Storage buckets. Customer-facing downloads are issued as signed URLs with a 5-minute TTL. The signed URL itself is never written to audit metadata; the audit row records that a URL was issued, not what it pointed to.

Scoped API keys + role-based access

API keys are hashed at rest, scoped per integration, revocable in real time, and attributed to the issuing user. The five Trade roles (admin, manager, analyst, viewer, itar_enclave) gate every privileged action. Approval-grade decisions stay admin/manager-only — itar_enclave cannot bypass.

Live controls today

The full inventory of what is in place.

Tenant isolation enforced by Postgres RLS on every tenant-scoped table
`audit_log` and `platform_bridge_audit_log` are append-only by DB trigger
TLS 1.2+ in transit, AES-256 at rest (Supabase Storage)
Private bucket policy on the `exports` evidence bucket; non-demo runtime fails closed
Signed-URL artifact downloads default to 5-minute TTL
US-region infrastructure paired with destination policy, recipient authorization, encrypted transfer, signed access, and audited evidence
Platform-bridge handoff disables local Trade login in production
API keys hashed at rest, scoped, revocable, last-used-tracked
Five-tier role model with admin/manager-only approval enforcement
Cron routes protected by `CRON_SECRET` bearer; rate-limited per org
Sentry server + edge error reporting wired via `instrumentation.ts`
Rate limit (Redis-backed, in-memory fallback) on every API route family
Schema state-machine triggers reject invalid transitions at the SQL level

Honest compliance posture

What we hold today, and what is in flight.

We will not claim certifications we do not hold. The architecture is aligned to the bar regulated buyers expect; the formal report or assessment is named where it stands today.

  • SOC 2 Type II — in active program; report not yet available
  • ISO 27001 — in active program; certification not yet held
  • CMMC Level 2 — architecture aligned; formal assessment scheduled with deployment partners
  • FedRAMP Moderate — not pursued today; relevant only on customer-specific deployment paths
  • Independent penetration test — most recent report shareable under NDA on request

Available under NDA

Diligence package on request.

If your security or procurement team needs to look deeper before signing, we share the following under NDA on request:

  • Most recent independent penetration test report
  • Architecture diagram (data flow, identity boundary, audit chain)
  • Subprocessor list and data residency map
  • Backup, DR, and incident-response runbooks
  • Customer DPA template
Request the diligence package

How the operating record holds

Architecture detail for security teams.

Where customer data lives

Each customer has a dedicated organization row. All transactional, license, delivery, audit, and evidence data references `organization_id` and is filtered by `current_org()` at the database boundary. A second customer cannot read or mutate the first customer's data even if the application layer is compromised.

How the audit chain holds

Privileged actions write to `audit_log` (cross-module ledger) plus a module-specific event ledger (`delivery_events` for CDD, drawdown ledger for licensing). Both are append-only at the trigger level. Every state transition the team takes leaves a row a regulator can inspect.

How artifacts are protected

Evidence packs and delivery artifacts are stored in a private Supabase bucket. Downloads are gated behind a session-authenticated route that issues a short-lived signed URL and writes an audit row referencing the artifact ID — never the URL itself. URL issuance is rate-limited per org.

How US-region posture fits the control model

US-region infrastructure reduces deployment and residency risk, but it is not the whole export-control answer. Controlled delivery still needs recipient authorization, destination policy, classification and license context, approved transfer channel, and evidence that the release followed the approved path.

How retention is handled

Audit rows and event ledgers are retained for the life of the customer relationship by default; per-deployment retention policies are agreed during onboarding for customers with specific record-retention obligations.

FAQ

Security frequently asked

Direct answers for security, procurement, and legal teams evaluating SecurePoint Trade.

Have your security team look at how Trade actually holds up.

We will share the diligence package, walk through the audit chain, and answer the questions your procurement team will ask later.