Security Overview

This page summarises how Fieldmark protects customer data. It describes the security mechanisms in placein the current platform — it is not a claim of formal certification (see “What we don't have yet” below). For data handling, retention, and subprocessor detail, see also our Privacy Policy.

Architecture & hosting

Fieldmark is a multi-tenant SaaS platform with a clear separation between the browser, the application backend, and the database:

• Web app — Next.js, hosted on Vercel.
• API — FastAPI, hosted on Render.
• Database — Supabase (managed PostgreSQL), AWS us-east-2.
• File/photo storage — Cloudflare R2.

The browser never connects directly to the database or the API. All authenticated calls go through a server-side proxy, so the session token is never exposed to client-side JavaScript.

Tenant isolation

• Application-layer isolation.Every database query is scoped to the requesting user's organisation; cross-organisation access is denied.
• No external database API surface.The database's auto-generated data API is disabled, so tables are not reachable from outside the application.
• Continuously verified.An automated cross-tenant isolation test runs as a pre-release gate — it authenticates as two separate organisations and attempts to read and modify each other's data; any cross-organisation access blocks release. The current build passes this gate.

Authentication & access control

• Token-based auth. Signed JWTs; the web app stores the token in an httpOnly cookie (not readable by JavaScript) and forwards it server-side.
• Two-factor authentication (optional). Org-admin and platform-operator accounts can enable app-based two-factor authentication (TOTP — e.g. Google Authenticator, 1Password, Authy) in addition to their password, with one-time backup codes for recovery. The authenticator secret is encrypted at rest.
• Per-request validation. Tokens are checked against the live user record on every request, so deactivating a user revokes access immediately.
• Role-based access. Roles (org admin, audit designer, executive, field auditor, display/monitor) gate functionality; a separate platform-operator role for cross-tenant administration is enforced server-side.
• Display-only accounts.Wall-display (“monitor”) accounts are read-only — state-changing requests are rejected server-side.
• Guest capture (optional, per-deployment). Where explicitly enabled, walk-up contributors can submit observations via a separate, narrowly-scoped, short-lived (2-hour) token limited to a single session. Guest tokens cannot reach any other organisation's data or any non-capture function, and submissions are held for review (or auto-accept) before affecting reporting. Covered by the isolation gate.
• Rate limiting is applied to login and public endpoints.

Data protection

• In transit: all traffic over TLS/HTTPS.
• Passwords: stored as bcrypt hashes; never plain text.
• Photos: served via short-lived presigned URLs, not public links.
• Secrets: stored as platform environment variables, never in source control.
• Security headers: X-Content-Type-Options, X-Frame-Options, HSTS, Permissions-Policy.
• At rest: data is stored with our infrastructure providers (Supabase, Cloudflare R2), which encrypt data at rest by default.

Payments

Payments are processed by Paddle, acting as the Merchant of Record. Fieldmark does not see or store credit-card or full payment details; we retain only subscription status and the Paddle customer/subscription identifiers needed to manage the account.

AI features & data handling

• AI features are available on AI-tier subscriptions only.
• When enabled, operational data (observation notes, audit records) is sent to our AI provider (Anthropic by default; Google as an alternate) to generate summaries and recommendations. This data is not used to train AI models.
• AI calls are batched at the deployment/organisation level (not per observation), are usage-metered, and are gated by a monthly allowance.

Subprocessors

Data retention & deletion

• Active accounts: data retained while the account is active.
• Cancelled accounts: access is gated, but audit/compliance records are retained (they may be needed for regulatory, legal, or insurance purposes).
• Deletion requests: honoured within 30 days, subject to any legal hold or regulatory retention requirement.
• Soft deletes: records are deactivated via status flags rather than destroyed. (Transient, never-submitted guest sessions are the exception — they are discarded.)

See the Privacy Policy for the full retention and data-subject-rights treatment (PIPEDA / Alberta PIPA).

Change & vulnerability management

• CI gates run on every change: a backend compile check and a full web build must pass before code ships.
• Dependency lockfiles are committed; dependency changes are reviewed.
• The cross-tenant isolation gate is run before releases.

What we don't have yet

In the interest of an honest assessment:

• Fieldmark is not currently SOC 2 or ISO 27001 certified.
• We do not currently offer a contractual uptime SLA, SSO/SAML, or enterprise single-tenancy.
• Two-factor authentication is available for admin/operator accounts but is not yet enforceable organisation-wide — it is per-user opt-in.

We're happy to discuss roadmap and specific requirements for a given deployment.

Responsible disclosure & contact

If you believe you've found a security issue, please contact support@fieldmark.works and allow us a reasonable opportunity to respond before public disclosure.

For security questions or a vendor assessment, contact support@fieldmark.works.

This Security Overview describes mechanisms in the current platform and is subject to change as the product evolves. Last updated June 2026.