This page describes the security mechanisms that exist in FieldScroll today, stated plainly. It is written for the IT reviewer who needs specifics, not assurances.
Encryption
- In transit. All connections — dashboard, mobile app, and API — use TLS. There is no unencrypted access path.
- At rest. Data lives in a managed Postgres database whose storage is encrypted at rest by the hosting provider.
Isolation between customers
Each of your customers' data lives in its own organization, and access is enforced by row-level security policies in the database itself — every user-session query (dashboard and mobile) is filtered by the requesting user's organization membership and current organization context, so an application bug in those surfaces cannot widen the result set. The customer API enforces the same boundary through each key's organization binding, checked on every request and again inside the database functions that perform the work. The full mechanism, including what is shared versus isolated, is described in multi-tenancy. The policies are tested directly, including tests that attempt cross-organization access and verify it fails.
API keys
- The plaintext key is shown once, at creation. After that, the dashboard shows only the prefix.
- We store a SHA-256 hash of the key, never the plaintext. A database read cannot recover a usable key.
- Keys carry explicit scopes (
forms:read,records:write, and so on) and are bound to one organization, or to the instance for owner-minted keys. A key cannot act outside its scopes or its binding. - Keys can be revoked at any time and are never deleted, preserving the audit trail. An optional expiry date makes a key lapse on its own.
- The auth middleware compares hashes in constant time.
Details are in authentication; key management lives at API keys.
Credentials you give us for other systems
Some features need a credential for a system that is not ours — a database or Salesforce org a data source mirrors, a Box or Google Drive account a report files documents into, the signing secret on a webhook destination.
- Connected accounts are authorized on the provider's own sign-in page. We never see the password, and we receive tokens rather than credentials. The tokens are stored encrypted and used by the server only.
- Signing secrets on report destinations are write-only. Once saved, the value cannot be read back through the dashboard, through the API, or by any query a signed-in browser session can make. A read returns only whether a secret is set.
- Revoking access on the provider's side is enough to stop us. The destination or data source then reports that it needs authorizing again rather than failing silently.
Audit trail on records
Every submitted record permanently carries:
- Who — the submitting user.
- When — the submission timestamp.
- Device — model, operating system and version, and app version at capture time.
- Where — GPS coordinates, when the form captures location.
- Integrity — a SHA-256 checksum of the field values, computed on the device at upload and stored with the record as an integrity fingerprint.
Records cannot be deleted from the dashboard, and edits are limited to data managers or explicit per-form grants. Each record stays tied to the exact published form version it was captured against, so the trail reflects what the field worker saw.
How long we keep things
Your records, media, forms, and reports are kept for the whole term of your agreement. Nothing on that list is deleted on a timer, and there is no expiry that quietly removes field data. Deletion happens when you ask for it in writing, through the organization-deletion procedure described in the Data Processing Addendum.
The supporting logs are different. Each has a fixed window, and a daily job removes anything past it:
| What | Kept for |
|---|---|
| Audit logs — who did what, with IP address and user agent | 365 days |
| Upload diagnostics from the mobile app | 90 days |
| Webhook delivery history, including the payload that was sent | 90 days after the delivery succeeded or failed for the last time |
| AI assistant usage records | 365 days |
| Operational metrics | 30 to 90 days |
A webhook delivery still waiting or still retrying is not removed by that job. See webhooks if you need a longer record than 90 days — the answer is to store deliveries on your side as they arrive.
Backups
- Database. The hosting provider takes daily backups and keeps them seven days. There is no point-in-time recovery.
- Media. The media bucket is copied daily to a second bucket in the same region, and every copy is checked for completeness by size and checksum. Media backup copies are deleted along with the organization rather than rotated on a schedule, so a deletion you ask for reaches the backups too.
Restoring one organization, or a whole bucket, is a documented procedure that our operators run. The recovery point objective is 24 hours.
What the AI assistant sends out
The AI assistant in the form, report, and webhook builders is not local. When you use it, your messages, the form or report or webhook definition you are working on, and any image you attach are sent to Anthropic, which generates the proposal. Anthropic is listed on our subprocessor page. The panel says so above the message box.
Two things follow from that. Do not paste record data or personal information into the assistant — nothing in the interface stops you, and it would leave your workspace. And the assistant is off unless it has been turned on for your workspace, so a workspace without it sends nothing to Anthropic at all.
Legal documents
The contract terms are published in full at fieldscroll.com/legal: Terms of Service, the End User License Agreement for the web and mobile apps, the Data Processing Addendum, and the list of subprocessors that handle customer data. The privacy notice is at fieldscroll.com/privacy.
The Terms, EULA, and DPA are published as version 1.0 drafts while counsel reviews them, and each page says so. The signed copy attached to your Order Form is what controls.
Access control
Permissions are role-based and enforced in the database alongside the isolation policies — see roles and permissions. The dashboard hides instance-owner screens from everyone else; all other checks happen in the database, so bypassing the UI gains nothing.
What we do not claim
FieldScroll does not currently hold formal certifications such as SOC 2 or ISO 27001, and we will not imply otherwise. If your review requires specific controls, documentation, or answers to a security questionnaire, contact support — we would rather answer the exact question than leave you guessing.