Security

What we do not claim

It is worth starting here, because most security pages bury it. NumoForms is not certified to ISO 27001, has not completed a SOC 2 Type I or Type II audit, and does not hold Cyber Essentials or Cyber Essentials Plus. If a procurement process requires one of those as a hard gate, we do not meet it today, and we would rather you found that out on this page than three weeks into an evaluation.

What follows is a description of controls that exist in the product now. Every item is something you could verify in the application's behaviour. If you need any of it evidenced in writing for a supplier assessment, ask via the contact page and we will answer a security questionnaire or a DPIA rather than send a brochure.

Where your data lives

The application database, authentication and file storage all run on Supabase, hosted on Amazon Web Services in the London region (eu-west-2). Survey definitions, responses, partial answers and uploaded files are held there. In ordinary use, survey data does not leave the United Kingdom.

Two providers sit outside the UK. Resend sends notification emails, which say a response arrived and carry no answers. Anthropic processes the text a survey author types when using AI drafting or translation. Neither ever receives a respondent's answer, and automated summarisation of responses is still not built. Those transfers rest on the UK International Data Transfer Addendum or the EU Standard Contractual Clauses. Each provider, what it processes and where, is on the sub-processor page, which we update before a new provider begins processing.

Encryption

Traffic between a browser and the application is encrypted in transit using TLS. Data at rest is encrypted with AES-256 by the platform, which covers the database and the storage bucket that holds uploaded files. Surveys are served and submitted over HTTPS.

Access control inside the database

Row-level security

Access is enforced in the database, not only in the interface. Row-level security policies are applied across the tables that hold survey content and responses, so a query that is not entitled to a row does not return it, whatever the calling code asks for.

Organisation isolation is pinned server-side

An account can belong to several organisations. The organisation a request is acting as is resolved on the server from the authenticated session, not read from a value the browser supplies. This is the control that matters most in a multi-tenant product: a client that edits its own request cannot widen its access, because the identifier it would have to change is not one it gets to send.

Roles, and protecting the last owner

Organisation members hold one of three roles — owner, admin or member. The last remaining owner of an organisation is protected at database level from being removed or demoted. It is a small rule with a large effect: an organisation cannot be accidentally or maliciously orphaned into a state where nobody can administer it.

Partial answers

The save and continue feature keeps partially completed responses so a respondent can resume from a link keyed on a 24-character token. Those partials are held in a table with no row-level security policies at all, which means no direct client access is possible; they are reachable only through SECURITY DEFINER database functions that check the token. Deny-by-default, with a narrow, audited door.

Uploaded files

File uploads are written to a private bucket. There are no public object URLs, so a link cannot leak by being guessed, forwarded or indexed. When someone in the owning organisation views or downloads an attachment, the application mints a signed URL that expires after 300 seconds. Clearing test responses deletes the associated uploads and partials as well as the response rows, so a tidy-up before going live does not leave orphaned documents behind.

Limits enforced by the database, not the interface

Responses insert directly from the respondent's browser, which means any rule enforced only in the interface is advisory. Close dates and response caps are therefore enforced by a database trigger. Once a survey has closed or hit its cap, a submission is rejected by the database, not merely discouraged by a hidden button. The respondent sees the survey owner's custom closed message.

Scoring and hidden fields

Scoring only counts questions the respondent actually saw, so branching cannot penalise someone for a question that conditional logic hid. Hidden fields are declared per survey and read from the query string; they are stored with the response, so treat them as data you have collected and describe them in your own privacy notice accordingly.

Your obligations, and ours

For most surveys you are the data controller and we are the processor. That split is set out on the UK GDPR page, and the terms that govern it are in our data processing agreement, which you can request before you sign up. Practically, it means you decide what questions to ask, how long to keep the answers and who in your organisation may see them; we keep the platform secure and act on your instructions.

Reporting a vulnerability

If you believe you have found a security issue, please report it through the contact page with enough detail to reproduce it, and give us a reasonable period to respond before disclosing it publicly. We will not pursue anyone who reports a genuine issue in good faith and does not access, alter or retain other people's data while investigating. There is no paid bounty programme.

Changes to this page

This page describes the product as at 22 July 2026. When a control changes materially — a new region, a new sub-processor, a change to how access is resolved — we update this page and the sub-processor list before the change takes effect where we can, and promptly afterwards where we cannot.