Security and privacy at fastform

Patient data is stored and processed in us-east1, a United States region of Google Cloud. The database, object storage, and backups are all in that region, and backups stay in the United States.

We have a Business Associate Agreement in place with Google Cloud covering every service that touches PHI. It is executed, not merely available.

Submission answers are envelope-encrypted: each submission gets its own AES-256-GCM data key, and those keys are wrapped by a key-encryption key held in Google Cloud KMS. Key material is versioned, so keys can be rotated without rendering old data unreadable, and malformed key material fails closed rather than falling back to something weaker.

Uploaded files are stored under a customer-managed encryption key. Connections to the database require TLS, the application sends HSTS on every response including forms served on your own domain, and outbound delivery of answers is HTTPS-only.

• Access to patient data is role-based inside your workspace, and limited to what a support request requires.
• Every read of patient data is written to an append-only audit log — enforced by database triggers, not by convention — attributed to a named individual, and exportable by you.
• Unusual bulk reads are flagged by an anomaly detector.
• Two-factor authentication is available on every account. When it is enabled it is enforced on every way of signing in: password, magic link, Google, and Microsoft. We do not yet let a workspace require it of all its members; that is on the list, and we would rather say so than let you assume otherwise.
• Administrative access to the platform is itself audited and requires two-factor authentication.

You choose, and the choice is enforced by a daily job rather than by policy alone.

• Default: seven years (2,555 days), which is what most practices' record-retention obligations call for.
• Configurable from 30 days to seven years by a workspace owner or admin. The change is audit-logged.
• Or zero. In on-delivery mode a submission is cryptographically destroyed the moment every configured delivery has been confirmed — so if your EHR is the system of record, we stop being a copy of it. Anything whose delivery has not confirmed is held and flagged to you rather than silently erased.

Erasure is a crypto-shred: the submission's key is destroyed, which makes the answers permanently unreadable, and uploaded files are purged with every stored version. What remains is a metadata skeleton that never contained patient data — timestamps, form version, completion status — which is what your drop-off analytics is built from. That is why deleting patient data does not cost you your analytics.

One caveat we would rather state than have you find: erased submissions can survive in Google Cloud's managed database backups for up to 14 days, and in point-in-time recovery logs for up to 7. Those backups are encrypted, covered by the Google Cloud BAA, and unreadable by our application — no code path can query a backup.

• Access. You can export a single patient's designated record set across every form they have filled, and there is a patient-facing copy path. Requests run against a 30-day clock with a denial workflow, per §164.524.
• Accounting of disclosures. Every outbound delivery of PHI is recorded in an append-only ledger at the dispatch point, with recipient and purpose, and can be reported per individual, per §164.528.
• Erasure. You can erase an individual submission on request; it uses the same crypto-shred path as the retention sweep.

The services that can touch systems holding PHI:

We will tell you before adding a subprocessor that can access PHI.

Patient submissions are never sent to the model. No builder tool reads submissions, automations make no model calls at all, and test runs use synthetic answers. Message text is scrubbed and vaulted before it leaves us.

The one pathway that can carry PHI is a file you upload to the builder as reference material — a photo of a paper intake form, for instance. Those files are passed to the model as you provided them. So that pathway is gated rather than assumed away: uploading requires acknowledging a warning that says to use a blank template instead, the acknowledgement is audited, files are malware-scanned in quarantine first, and only a clean scan is ever sent. We do not have a BAA with Anthropic, which is exactly why that gate exists.

When you connect your own HubSpot, Snowflake, BigQuery, Twilio, Slack, or a webhook, that runs on your credentials, to your account. Delivering to it is a disclosure you direct to your own vendor, and any BAA you need with that vendor is yours to hold. We capture that direction in writing at connect time — a blocking attestation from an owner or admin, audited, and re-confirmed if the credentials rotate.

If we discover a breach of unsecured PHI affecting your workspace, we notify you — by email to your owners and admins, with the full record readable in-app. Notification is tracked through an audited state machine with internal escalation before the §164.410 sixty-day deadline, not a calendar reminder. The notification email itself carries metadata and a link only; your inbox stays outside the PHI boundary by construction.

• No SOC 2 report. Type I work begins Q4 2026. If a current SOC 2 report is a hard gate for you today, we are not the right vendor yet, and we will say so on the call rather than after your procurement cycle.
• No workspace-level requirement for two-factor authentication. It is available and enforced when enabled; a workspace cannot yet mandate it.
• Our BAA template is not yet through outside legal review. It is live, it is signed, and counsel review is scheduled.

We would rather you read this section than discover it.

If your security questionnaire needs something that is not here, email hi@getfastform.com and you will get an answer from the person who built the system, not a form response.