Security

Fillo renders your forms inside your own product and collects the responses on your behalf, so the same data-handling rules that govern your app apply to us. This page describes how we host, encrypt, and isolate that data today, and how to reach us about a security issue. It is a plain summary, not a contract — our processing commitments are in the Data Processing Agreement.

Where your data lives

Fillo runs on servers in the European Union, and the responses your forms collect are stored there too. Uploaded files go to the storage you connect — your own Google Drive, Box, or S3-compatible bucket (including AWS S3 and Cloudflare R2) — not to a Fillo-owned bucket. Fillo keeps the response itself, each file’s metadata, and a reference to where the file lives.

Encryption

• Every request uses TLS in transit, and the database that stores your responses is encrypted at rest.
• App-used provider credentials — S3 keys and connected Google Drive, Box, and Notion tokens — are encrypted at rest with AES-256-GCM, and are never logged.
• Optional identity verification signs your respondent identities with HMAC-SHA256 using a workspace secret held only on your server.

Workspace isolation

Every form, response, file reference, storage connection, publishable key, and integration is scoped to a workspace and checked server-side on each request. Management surfaces return a 404 rather than reveal a form id you cannot access, so ids from the client are never trusted on their own.

Submissions, uploads, and files

• Public submission endpoints validate against the shared form schema, cap request size, rate-limit abuse, and use honeypot protection.
• Uploads go browser-direct to your connected storage; Fillo controls multipart completion and cleanup and does not keep a long-term copy of the file bytes. For Drive and Box, authenticated downloads may stream through Fillo so workspace members can open a file.
• An uploaded file reference must belong to the expected form before it can be attached to a response.
• Webhooks are signed with a per-form secret and are delivered over HTTPS in production; requests never follow redirects.

Saved progress and respondent identity

Save and resume is off unless a form owner turns it on. When it is on, in-progress answers are stored server-side and read back with a one-time token held in the respondent’s browser — no answer content is kept in localStorage. Respondent identity from identify() is stored only when your app sends it, and you can require it to be server-signed before Fillo records it.

Deleting data

You can export and delete responses at any time, and erase a person — their profile, drafts, and identity, and optionally their responses and connected files — across the workspace. When a delete touches connected storage that is unreachable, it fails closed and can be retried rather than silently orphaning data.

Sub-processors

We share data only with the providers that help us run Fillo — EU hosting, transactional email, optional AI drafting, diagnostics for server errors, and coarse product or documentation usage measurement. Documentation events are sent server-side without analytics cookies or form answers. Documentation search text stays in the browser; only coarse length and word-count ranges plus result counts are sent. Ordinary request security and rate limiting may still process an IP address. The full list, with legal entities, purpose, location, and safeguards, is on the Sub-processors page. Destinations you connect yourself — webhooks, Google Sheets, Notion, or Zapier — are controlled by you, not engaged by us.

What we do not offer yet

We want to be straight about the gaps. Fillo does not yet hold a formal third-party certification such as SOC 2 or ISO 27001, publish a real-time status page, or offer a contractual uptime SLA. If your review needs any of these, email us and we’ll tell you where we actually stand rather than imply more than we can back up.

Report a vulnerability

If you believe you have found a security issue, email hello@fillo.so with enough detail to reproduce it — the affected URL or endpoint, the steps, and the impact you observed. Please give us a reasonable window to fix it before any public disclosure, and avoid accessing data that is not yours while testing. We welcome good-faith reports and will not pursue researchers who follow this.