Trust and security

The short version#

• We do not sell data. Not to anyone, for any purpose.
• We do not train machine-learning models on your tickets, photos or signatures.
• The capture form loads no third-party code. No analytics, no fonts, no CDN, no tracking cookie. The person in the field is not measured.
• Nothing is written to your Procore without one of your people approving it.
• Data is encrypted in transit and at rest, and we share it only with the four sub-processors listed below.

Where the data goes#

One path, three steps, and it is worth being precise about which system holds what.

1. The field to Fieldstub. Somebody scans a capture code and fills in a form in their phone browser. That submission (the work described, labor, equipment, materials, photos, and a signature) is sent over TLS and stored in our database.
2. Review, inside Fieldstub. The ticket waits in a queue. Somebody from your company opens it, checks the line items and the budget code each one will be filed to, and approves or rejects it. Until that happens nothing has left our system.
3. Fieldstub to your Procore. On approval we create a Change Event in your Procore account, with the line items, the photos, and the capture details on the record.

What we store#

About your staff: an email address, taken from your Procore company directory, and the timestamp of their last sign-in. There are no passwords, because there are no passwords in the product: sign-in is a single-use link sent by email.

About the work: the ticket. A description, why it was needed, who directed it, labor and equipment and material lines, and a total.

About people in the field: this is the part that needs care. A ticket carries the name and role of whoever signed it, an image of the signature they drew, the name of whoever directed the work, and photos. If the phone offers a location and the browser permits it, a photo also carries the coordinates and the time it was taken.

Those people are usually subcontractors or crew who have no Procore seat, no Fieldstub account, and no relationship with us at all. We hold their data as a processor on behalf of the general contractor, we use it for nothing except showing that ticket to the reviewer and filing it, and we never build a profile of a person across tickets or across companies. The contractor is the controller and is responsible for telling their field workers what is being collected.

About usage: see the analytics section below. It is deliberately thin.

Access control#

Your Procore company directory is the access list. There is no separate user list to maintain here, no invite flow, and no way to grant somebody access to your tickets except by putting them in your directory in Procore.

The check runs on every request to the office side, not only at sign-in, so removing somebody in Procore removes them here within minutes. If Procore is unreachable we serve the last known answer rather than locking out an entire company over an outage, which means a stale answer can only ever grant what Procore told us minutes ago, never more.

Every query is scoped to one company. Tenant isolation is not a filter applied at the end; the company id is the first argument to every operation in the service layer. A ticket id belonging to another customer does not return a permission error, it returns a 404, because confirming the record exists is itself a leak.

Security practices#

• Encryption in transit. All traffic, on both the site and the app, is served over TLS.
• Encryption at rest. The application and its database run on Railway, which is SOC 2 Type II and SOC 3 certified and encrypts all data at rest at the storage level, backups included, with nothing for us to switch on. Everything runs in Railway’s San Francisco region, in the United States.
• Nothing identifying goes into the logs. Log lines carry a masked address, d*****@company.com, rather than the real one, so a copy of your staff directory does not accumulate in a hosting provider’s log retention. No ticket content, photo, signature or API key is ever logged.
• No passwords. Sign-in is a one-time link. Tokens are single use, recorded once redeemed so they cannot be replayed, and expire.
• API keys are stored as a SHA-256 hash, never in plaintext, alongside a short non-secret prefix used to find the row before a constant-time comparison. A copy of our database does not give anybody a working key. Keys are revocable and every key is scoped to one company.
• Least privilege against Procore. The integration can reach fourteen endpoints and no others. The full list is published on our install page rather than described in general terms.
• Secrets are never committed to source control, and the signing key for our published trust manifest lives outside the repository entirely.
• Security-relevant behavior has tests written as attacks: forged cookies, replayed sign-in tokens, and requests for the company next door.

Analytics, and what the field never sends#

The capture form contains no third-party code of any kind. No analytics script, no web font, no CDN, no tag manager, no cookie. That began as a performance requirement: it has to work on an old Android on one bar of signal. It is now also a privacy property we intend to keep.

Elsewhere we use PostHog, and what reaches it is restricted by an allow-list in the code rather than by intention. Events are named individually and each one declares exactly which properties may travel with it, so a property cannot be added by accident.

No ticket content is ever sent: no descriptions, no names, no photographs, no signatures, no amounts. An approved ticket sends the number of lines and how many were unrouted. That is the shape of it.

Where an event is associated with a person, the email address is replaced with a keyed HMAC rather than a plain hash. A plain hash of an email is reversible in practice, because there are only so many plausible addresses at a company; keying it means the analytics vendor cannot turn its own data back into your staff directory.

Sub-processors#

The complete list of third parties that can touch data, each for one defined purpose. We will update this list, and we will aim to tell account holders before a new sub-processor handling customer data takes effect.

Procore is deliberately absent, for the reason given above: it is your system, not our vendor.

Retention and deletion#

Tickets, photos and signatures are kept while your account is active, because the review queue and the record of what was filed are the product.

You can ask us to delete a ticket, a project's worth of tickets, or your entire account at any time by emailing privacy@fieldstub.com, and we will confirm when it is done.

Uninstalling the app in Procore cuts our access to your Procore immediately. Change Events already written stay in Procore. They are your records, created by your employee, and removing an integration should not reach into your financial history.

If we go down#

Our recovery targets are four hours to restore service and a twenty-four hour worst-case data window, bounded by our provider’s backup schedule. These are targets we work to, not a contractual SLA. We will not sell you one we cannot yet stand behind.

The exposure is smaller than that second number suggests, for a reason worth understanding:

• Approved tickets are already in your Procore. Once your reviewer approves, the Change Event, its line items and its photos live in your system. Our copy is a record of what we sent you. If we lost everything, your money would still be where it belongs.
• Tickets being typed are on the phone. The capture form saves to the device on every keystroke, so a ticket in progress is not ours to lose.
• What is genuinely at risk is the narrow set of tickets submitted but not yet approved.

Restores are rehearsed rather than assumed. The drill restores a backup into a scratch database and checks that photographs came back as real images rather than empty rows, because a photo can restore as a zero-length record while every count still looks correct, and nobody notices until a reviewer opens a ticket months later and the evidence is gone.

Compliance#

• SOC 2: we do not have one. No report, no audit in progress. We will publish the status here when that changes, and we will not imply a certification we do not hold.
• GDPR and CCPA: you can request access to, correction of, or deletion of personal data at any time. See the Privacy Policy for the detail.
• Data Processing Agreement: available, and published in full at /dpa/. Email us if you need a countersigned copy.
• Insurance and security questionnaires: send them. We would rather answer a long questionnaire honestly than have you assume.

Reporting a vulnerability#

Email security@fieldstub.com with what you found and how to reproduce it. We will acknowledge it, work with you in good faith, and tell you when it is fixed. Please give us a chance to fix it before disclosing publicly.

There is no bug bounty. We are a small team and would rather be straight about that than advertise a programme we cannot fund.

Machine-readable contact details are at /.well-known/security.txt.