Security

How financial data is handled across the Sprint and the Engagement.

Two pathways for financial data. One for the 10-day Sprint, where data flow is export-based and time-bounded. One for the ongoing Engagement, where data flow is continuous and lives inside an isolated, named-user environment. Same controls. Same review standard. Documented in plain language for the operator, with the technical specifics named for procurement.

ResidencySydney by default
Excel modelClient-owned from day one
ProcurementOne-pager available
Pathways

Sprint and Engagement use different access shapes.

Same review standard. Same encryption. The shape of access is different because the work is different. The Sprint is a fixed window with agreed exports. The Engagement is a continuous monthly cadence inside a per-client isolated environment.

Six dimensions named below: how access is granted, how long it runs, where the data sits, how it moves, what leaves the firm, and how the relationship ends.

DimensionCompared
01 / Pathway Sprint 10 business days · export-based
02 / Pathway Monthly · named-user portal
AAccess type
Read-only or export-based.No write access to your accounting system
Portal accounts. Named users only.No shared logins
BDuration
10 business days from data receipt.Fixed window, then archived
Monthly, 30 days' notice from either side.Either party may end
CStorage
Encrypted working environment for the build window.AES-256 at rest, TLS in transit
Per-client database isolation. Row-level security enforced at the database layer.Postgres RLS, every query scoped
DData flow
You provide agreed exports. We work from those exports.No live integration
Monthly accounting export plus operating data agreed at scoping.Live integration optional
EOutputs
Delivered only to the contacts you name.NDA available on request
Portal access for named users. Reviewed pack each cycle.CSV export at any time
FExit
Model and decision pack handed over.Working files retained briefly for support, then archived
Portal access ends within 30 days of notice. Excel model stays with you.Full historical CSV export provided
Same standard
Encryption, founder review, named-user audit, and exit ownership are identical across both pathways. The shape of access changes; the standard does not.
Controls

The technical layer.

Three layers, named, with the control standard at each layer documented. Database, application, portal. Each layer carries the standard procurement reviewers ask for, named explicitly rather than implied. Read top to bottom: a request enters at the portal, passes through the application, and lands at the database, which is where the data actually lives.

Architecture · 3 Layers Stack 03 → 01
Layer 03 Portal Surface

Named users, role-scoped, audit-ready.

Next.js · Session-based auth · Configurable expiry

AUTHMAPROLEAUDIT

User-to-client mapping enforced through user_client_map. Role-based view restrictions. SSO available on request. Named-user audit log exportable at any time. Sessions expire on a configurable schedule; a named user can be revoked in minutes, not days.

Layer 02 Application Service

Encrypted in transit and at rest. No exceptions.

Python FastAPI · TLS 1.2+ · AES-256

TLSAESKEYSROUTE

Service-role keys only for backend access. No long-lived bearer tokens shared with operators. No exceptions on encryption either way: every connection terminates TLS 1.2 or higher, and every persisted byte sits behind AES-256.

Layer 01 Database Foundation

Per-client isolation enforced in SQL.

Supabase Postgres · Row-level security · 7-day PITR

RLSPER-CLIENTPITRSNAPSHOT

Per-client isolation; every query is restricted to the requesting user's mapped clients. Daily automated snapshots with seven-day point-in-time recovery. No cross-tenant queries are possible at the database boundary, regardless of the application path that issued them.

Hosting SOC 2 Type II attested infrastructure. Attestation links available on request.
SupabaseRenderVercel
AI Handling

AI-assisted, founder-reviewed, zero data retention.

AI-assisted analysis is used during the Sprint build and during monthly Engagement cycles for data preparation, reconciliation, anomaly surfacing, and draft commentary. Every output is reviewed by the founder before delivery or publication. Nothing reaches a client unreviewed.

Provider routing: AI calls route through OpenRouter to Anthropic under zero-data-retention API terms. Your data is sent per-query only, is not retained beyond the query, and is not used to train models. The query layer (Ask Your Numbers) operates under the same terms.

AI is mechanism, not headline. The credibility carrier is the reviewed pack, not the model behind it.

Trace · per-query
Req req_zdr_a7f3 Routed openrouter ▸ anthropic
ZDR REVIEW GATED
01 Origin scope: per-querypayload: scoped exports t = 0 msCLIENT
02 OpenRouter routing: pass-throughlog: disabled t = 12 msTRANSIT
03 Anthropic retention: 0training: excluded t = 180 msZDR
04 Founder review required: yesblocking: yes manual gateREVIEW
05 Delivery output: reviewed onlychannel: pack · portal to clientFINAL
Retention0
TrainingExcluded
ReviewRequired
Data Residency

Sydney by default. Other regions on request.

The Engagement database sits in Supabase's Sydney region by default. The API layer sits in Singapore for latency reasons; data passes through encrypted in transit and is not retained there.

If your procurement requires a specific regional commitment in writing, Sydney, Frankfurt, US-east, or another supported region, an alternative region can be provisioned before the Engagement begins. For Sprint clients without ongoing Portal access, residency is determined by the working environment used during the build window, which is documented on request.

Residency · v.2026.1
02 / RegionAPI · Transit
SIN
LAT1.35° N
LON103.82° E
ProviderRender
TransitTLS 1.2+
01 / RegionDatabase · Primary
SYD
LAT33.86° S
LON151.21° E
ProviderSupabase
StorageAES-256
On request
Sydney Frankfurt US-east + supported regions
Provisioned pre-engagement
Exit

You leave with the calculation engine.

The Excel model is client-owned from day one of the Sprint. It contains the full calculation engine: three-way forecast, working-capital cycle, KPI logic, scenario layer, and assumption block.

If the Engagement ends, the workbook stays with you. The Portal is decommissioned. A full CSV export of historical data is provided. There is no proprietary system that must be subscribed to in order to keep using the work, and no part of the calculation logic that lives somewhere you cannot see.

Handover · Manifest
Dochandover_manifest.v.2026.1 Items 3 / 3
01 / 03
Excel model

Yours from day one.

Contains the full calculation engine. Client-owned the moment the Sprint begins.

  • Three-way forecast
  • Working-capital cycle
  • KPI logic
  • Scenario layer
  • Assumption block
  • Open audit trail
OwnershipClient Day 1 · Yours
02 / 03
Portal access

Ends within 30 days of notice.

Decommissioned on exit. No orphan data, no dormant accounts, no lingering access.

  • Sessions terminated
  • Named users disabled
  • Database isolation closed
  • Audit log sealed
OwnershipEnds 30-day · Decommissioned
03 / 03
Historical data

Full CSV export provided.

Every cycle. Client retains the full record. Format documented in writing.

  • All cycles · all packs
  • Schema documented
  • No proprietary blockers
  • Self-reusable in Excel
OwnershipClient Exported · Yours
No lock-in The calculation engine lives in Excel. The Portal is presentation. Both leave with you. v.2026.1
Procurement

Running a security review? Here is the packet.

A one-page security overview is available covering infrastructure, controls, data handling, residency, exit terms, and a procurement FAQ. Covers the questions most review teams ask before they ask them.

For specific questions, email security@infraxus.com or raise it on the fit call. Better to answer a hard procurement question upfront than to find out about it three weeks into the Engagement.