Security Overview

This page summarises how Fieldmark protects customer data. It describes the security mechanisms in place in 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

Organisations are logically separated at the database layer, and again in the application. The two are enforced independently, so a defect in one is caught by the other.

• Database-enforced isolation. Every table carries PostgreSQL row-level security (RLS) policies keyed to the requesting user's organisation, and the application connects as a restricted database role that cannot bypass them. A missing or incorrect scope in application code cannot return another organisation's data — the database refuses it, not the application.
• Application-layer scoping. Every database query is independently written 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, at both layers. 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. A second gate verifies enforcement at the database layer directly, connecting as the application's own restricted role and attempting cross-organisation reads and writes. The current build passes both.

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.
• Single sign-on — Microsoft and Google (included, all plans). Organisations can connect their Microsoft Entra tenant or their Google Workspace domain so their team signs in with existing work accounts. Minimal scopes (OpenID Connect sign-in only — no directory, mailbox or Drive read access); new sign-ins are invite-matched by default, with per-organisation opt-in to automatic joining; admins can require single sign-on workspace-wide, with a preview of exactly who is affected before the switch.
• 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. Credentials we hold on your behalf — two-factor authenticator secrets and outbound webhook URLs — carry an additional layer of application-level encryption, and API responses only ever return them masked.

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

• Operational data (observation notes, audit records) is sent to our AI providers — Anthropic and Google — to generate summaries and recommendations. The provider and model are selected per task; neither is chosen by the customer. This data is not used to train AI models.
• Every AI call is usage-metered and gated by a monthly per-organisation token allowance, which is enforced before the call is made. Some runs are batched at the organisation level; others run in response to a specific user action, such as asking for a note to be cleaned up.

Subprocessors

Auditability

• Authentication ledger. Sign-ins, failed attempts, and account security events (password resets, two-factor changes, session revocations) are recorded in an append-only ledger with timestamp, IP address, and client details.
• Record change history. Changes to business records such as corrective actions are recorded field-by-field — who changed what, when, with the previous and new values.
• Tamper-evident submissions. Completed audit submissions are stamped with a content hash of their responses, so later alteration of the underlying records is detectable on verification.

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.)
• Data portability: organisation administrators can export their organisation's complete data self-serve at any time — structured records plus a manifest of stored photos and media.

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

Backups & recovery

• Managed, automated backups. Production data runs on managed PostgreSQL (Supabase, AWS us-east-2) with automated daily backups and point-in-time recovery, so a restore can target a moment rather than only the last nightly snapshot.
• Photos and files are stored separately in Cloudflare R2 with its own durability guarantees, and are referenced by durable keys rather than copied into the database — so a database restore does not lose or duplicate media.
• Schema changes are ledgered. Every migration is recorded and applied idempotently, so a restored database can be brought back to the current schema deterministically rather than by hand.

Incident response

• Detection. Authentication events, privileged administrative actions and platform errors are logged append-only (see Auditability above), and infrastructure alerting covers availability and error-rate anomalies across the API, database and web tiers.
• Notification. If we determine that customer data has been improperly accessed or disclosed, we will notify affected organisations' administrators without undue delay, with what we know, what we are doing, and what — if anything — is required of them. Canadian privacy law (PIPEDA) additionally obliges us to report breaches creating a real risk of significant harm to the Office of the Privacy Commissioner and to maintain a breach record.
• Recovery and review. Every incident ends with a written record of cause and correction. Where the cause is a code defect, a regression test is added as a release gate before the fix ships — the same gates described under change management.

Change & vulnerability management

• CI gates on every change. Alongside compile and full-build checks, a suite of purpose-built static gates must pass before code ships — including a route/authentication registration check (no API endpoint ships without an explicit authentication decision), cross-tenant query-scoping checks, and a migration ledger that blocks unaudited data changes.
• Continuous dependency scanning. Dependencies are scanned continuously for known vulnerabilities and malware; fixes for disclosed CVEs arrive as automated patch proposals, and a scheduled dependency audit runs weekly. Lockfiles are committed and 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. The evidence groundwork a SOC 2 program requires — an append-only authentication ledger, continuous dependency scanning, an incident log — is already in place and accumulating history.
• We do not currently offer a contractual uptime SLA, SAML federation / SCIM provisioning (Microsoft and Google single sign-on are supported — see above), 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.
• Database-enforced isolation covers organisation-scoped data. A small number of platform-wide reference tables — compliance framework catalogues, plan definitions and similar shared content — are readable across the platform by design. They hold no customer operational data.

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 August 2026.