Security overview

Last updated August 17, 2026 · Footings is in active beta

Footings holds financial records, so security is a design requirement, not a feature. This is an honest summary of the controls that exist today.

Tenant isolation and roles

• Every table is protected by database-level row security: a company's rows are invisible to every other company, enforced in the database itself, not just the app.
• Access inside a company follows least privilege: field crew see their assigned jobs and their own uploads; project managers see and manage only the jobs they're on; the general ledger, payments and tax records are restricted to owner, admin and accounting roles. The crew schedule follows the same rules.
• These rules are covered by an automated attack-test suite (hundreds of checks) that tries to break them on every release — cross-tenant reads, privilege escalation, record retargeting — and must pass before anything ships.

Footings support access

• There is one exception to "nobody outside your company sees your company", and it is us. An authorized Footings operator can open a single customer company in a support session and read and change that company's business records, in order to support it.
• The session is bounded by the database, not by process: one named operator from a platform administrator list, one target company at a time, a written reason, and an expiry of 30 minutes with a 60-minute hard ceiling and no way to extend.
• Every write inside a session is stamped in the customer's own audit trail as a Footings support action. It is never recorded as something one of their users did, and the trail has no edit or delete path in the product.
• The session is a visibility change, not a new privilege. It grants nothing that is protected by a database grant: password hashes, MFA secrets, sign-in sessions, payment-processor and administrative keys are as unreachable inside a session as outside one. It also cannot read the company's invite code, change its owner, change its plan or add a member.
• Support Mode has its own fail-first test cases in the suite above, including that an expired session refuses every read and write rather than falling back to anything.
• What it does not claim: it is accountability, not confidentiality. Once a session is open the operator can see the books. The control is that it cannot happen quietly. The privacy policy states the same thing in full.
• Support Mode is built but not yet enabled in production.

Evidence integrity

• Posted financial records are immutable — corrections happen by reversal or credit note, never silent edits.
• A document filed against a record can't be swapped, unfiled or renamed; changes to sensitive data are written to an append-only audit trail.
• Subcontractor tax identifiers are stored separately, masked in the interface, and every full reveal is audited.

Infrastructure

• Data is stored in a Canadian data-centre region, encrypted in transit (TLS) and at rest.
• The app ships with a strict content-security policy and hardened HTTP headers.
• No payment card data is collected during the beta.

Reporting a concern

If you believe you've found a security problem, please tell us privately through the support page — include steps to reproduce. We take reports seriously and reply.