What is held, and what protects it.

Six kinds of record. Nothing on this list is inferred from a form; each one is a table or a store the application reads and writes.

Briefs and enquiries

The answers typed into the intake — business name, contact name, email, phone, and whatever was written in the free-text answers. Stored in Neon Postgres and kept for two years from submission.

Project material

Messages, page notes, approvals, and the files a client uploads to their own portal: photographs, documents, brand assets. The rows live in Postgres; the file bytes live in Vercel Blob, created private and served through the app rather than from a public URL.

Portal identity

Name, email address, role, and the session records that keep somebody signed in. Held by the identity layer in the same database as everything else.

Documents

Scopes, contracts, and the events around them — issued, viewed, signed, declined. The signed file is kept in private storage with its own record; the signature itself is collected on the signing provider's page, not on ours.

Payment records

Amount, status, and what each payment was for. Card numbers are entered in Stripe's checkout and never reach this site, this database, or this team.

Analytics

Page views, referrer, device class, and a click event when somebody follows a call to action. No cross-site profile is built from them. When advertising is running, Meta Pixel may be loaded for attribution and hashed contact details may be sent to Meta via the Conversions API; no other advertising pixel is loaded.

Named, because a vendor review is mostly this list. The same names appear on the subprocessor page with the data category each one touches.

Vercel

Hosting, the CDN, TLS, Web Analytics and Speed Insights — and Vercel Blob for uploaded files, created private and read through the app with a token.

Neon

Managed Postgres, the database behind briefs, portals, documents and payments. A pooled connection over TLS; the app refuses to start without a connection string.

Resend

Transactional email only: brief confirmations, sign-in codes, portal notices, team invitations. Open and click tracking are switched off.

Stripe

Deposits and retainer payments for builds run through the client's own Stripe account. Plan purchases made on the plan page run through Nimos Websites' Stripe account. Payments settle there; this site holds the key needed to create a checkout and read its status — not the account holder's login, and not any bank detail.

Documenso

Signature envelopes for scopes and contracts. The signing page is the provider's, and the provider keeps its own record of the signature; the completed file is kept here as well, in private storage, so the record survives a change of vendor.

GitHub

The repository and the CI that tests, type-checks and builds every change before it reaches production.

Meta (optional)

Advertising attribution, only when advertising is running: Meta Pixel on pages and the Conversions API for Lead and Purchase events. Hashed contact details, IP address and user agent are sent; card numbers are not, because they never reach us.

Sentry

Error reports, where a DSN is configured for the build. What leaves is scrubbed first: URLs lose their token segments and query strings, request bodies are dropped, cookie and authorization headers never leave, and anything shaped like a key or an email address is replaced before the event is kept.

The subprocessor list →

Controls that exist today, with the part that is missing said out loud where there is one. None of this is a certification, and none of it is a promise that nothing can go wrong.

Transport

TLS on every request. The certificate and the edge are Vercel's; there is no plain-HTTP origin behind it.

Response headers

Every response carries nosniff, a referrer policy, a permissions policy that closes camera, microphone and location, and a cross-origin opener policy. Pages holding client data also deny framing outright; the only exception is a demo page of our own, which is allowed same-origin because the cockpit inspects it in a frame. A content security policy runs in report-only mode: it enforces nothing yet, and it is how we find out what a blocking policy would break before one ships.

Sessions

The portal and the back office refuse an unauthenticated visitor rather than rendering around them, and are served no-store with frame denial — so a page holding client data cannot sit in a proxy cache or inside somebody else's frame.

Two-factor

Available on every account: an authenticator app on a 30-second window, plus ten single-use backup codes. It is not enforced on everyone — a client who signed up to read a quote is not made to install an app first. The studio's back office sits behind a separate passphrase door as well as a login.

Roles

Owner, admin and member. A client's team is invited to their own build and sees that build; the role decides what each person can change.

Least privilege

Provider tokens are read at runtime from the environment or the settings store and are never written into the repository. Where a job only needs to read, the token is read-only — the DNS reader can list zones and records and change nothing.

Credentials a client asks us to connect

Sealed with AES-256-GCM before they reach a row, with the provider name bound in as authenticated data, so a value lifted from one provider's row and pasted into another's fails to decrypt. With no encryption key the app stores nothing and says so.

Backups

A logical dump of the database into private blob storage once a day at 09:17 UTC; fourteen are kept. The newest copy is re-read and checked rather than assumed. Binary files are deliberately excluded from the dump — a restore needs the blobs too, which is written down instead of discovered during an incident.

Briefs and enquiries

Two years from the day they are submitted, then deleted — unless we are still working with you.

Project data

For as long as the account runs, and a reasonable period after, so the site can still be serviced.

Contracts and payments

Six years. A signed agreement and a payment record have to outlive a request to erase them: tax law requires the record, and destroying it would be a different offence.

Analytics

Aggregate. No per-person profile is built from it.

Ask for a copy or for erasure through the contact form with “privacy request” in the first line and the address you used. The answer is due within 30 days. Erasure is scheduled with a 24-hour cooling-off and then runs on a clock rather than on somebody remembering to do it.

The receipt names what was erased and what was kept, with a reason and an end date for every kept row. Files are deleted after the rows, and a failure there is recorded as a failure — a record that says “erased” while the photograph is still downloadable would be the worst outcome of all.