Security

People answer honestly when they know the answers are safe.

Surveys hold some of the most sensitive data an organization keeps. Everything below describes how Grabitt works today, not what we intend to build.

In transit and at rest

Every Grabitt domain sits on the HSTS preload list, so browsers refuse to connect to us over plain HTTP. There is no unencrypted route into the product.
Data is encrypted at rest by the infrastructure it runs on, Google Cloud and MongoDB Atlas.
Credentials and signing keys live in Google Secret Manager. None are baked into our container images or committed to our code.

Getting in

Administrators sign in with Google, with a Microsoft work or school account, or with a password we never receive: the person setting it types it at verification time, and it is stored only as a scrypt hash.
Sessions are signed cookies, sent only over HTTPS and scoped to a single host, so a session from our staging environment carries no meaning in production.
Changing a password invalidates every session issued before the change.
The API runs under a service account holding only the permissions it needs, and the identity that deploys is separate from the identity that runs.

Keeping customers apart

Every team-scoped request re-checks that the signed-in user holds an active membership of that team before anything happens, and their role decides what they may do with it.
The browser origins allowed to call our API are an explicit list, never a wildcard. Tests hold that list in place, including against hostnames built to look like ours.

Confidentiality for the people answering

An anonymous survey uses no participant list, and Grabitt keeps no technical link between its responses and the identity of whoever answered. Even so, a question asking for identifying details, or what someone writes in an open answer, can make a person recognizable.
A confidential survey tracks participation but does not hand out individual responses: the team can know who completed the survey, not what they answered. Each participant identifies themselves with their email and a verification code, results are published in aggregate and with confidentiality controls only once the survey is closed, comments on open questions are shown without author, date or segment, and it allows no individual export and no comparison with other measurements. Available on PAYG, PRO and Enterprise.
An identified survey is neither anonymous nor confidential: each response is linked to its participant, and authorized team members can export individual responses with each participant's email and name.
On paid plans, results and reports never show a segment with fewer than five responses. On demo access the threshold is one response. A confidential survey always requires at least five people, even if the plan changes later, and this cannot be lowered. The threshold cannot be changed from the workspace, and it does not apply to the export of individual responses from anonymous and identified surveys; confidential surveys never allow individual downloads.
In anonymous and identified surveys, deleting a participant removes their answers from every count, mean and tally, not only from the roster. In confidential surveys, someone who has already responded cannot be deleted from the workspace, and the results published at closing do not change.

Sharing results

A report is shared either behind an unguessable link or restricted with a passcode the report's author sets and hands out themselves, checked again on every view, so changing it takes effect immediately.
Access to a restricted report is a short-lived signed token issued once the passcode is entered, not a password that circulates.

Endpoints anyone can reach

Survey and demo endpoints are rate limited per address and per survey, and cap the size of what they accept. An anonymous survey can also cap how many responses its shared link will take.
A submission is checked against the survey's own structure: required answers must cover the questions that participant could actually see, and consent is enforced on the server rather than trusted from the browser.

If something goes wrong

The database is backed up automatically every day.
Requests carry a correlation identifier through structured logs, so an incident can be traced end to end.

What we do not claim yet

Grabitt does not hold a SOC 2 or ISO 27001 certification today, and we would rather say so here than let a security page imply otherwise. Formal certification is where we intend to take this as we work with larger organizations. Until then, the practices above are what we can show you, and if your team has a security questionnaire, send it and we will answer it honestly.

Bring your security questions.

We would rather answer them before you buy than after.

Request access