Security

1. Where your data lives

Application data — organisations, users, tests, questions, candidates, invitations and submissions — is stored in a managed Postgres database provided by Supabase. The application itself runs on Vercel. Both are hosted in the United States, so if you access Up&Up from elsewhere your data is transferred to and processed in the United States. Video, screen and audio recordings are stored separately in Cloudflare R2.

2. Separation between organisations

Every record in the database belongs to exactly one organisation. Separation is enforced in two independent places:

• In the database. Row-level security is enabled on every application table. Policies match each row against the organisation of the signed-in user, so a query that asks for another company's submissions returns nothing — even if the application layer were to ask for it.
• In the application. Employer API routes resolve the caller's organisation from their user record and check it against the resource being requested before doing any work. File keys in our media storage are prefixed with the owning organisation's ID, and download requests are rejected if the prefix does not match the caller.

3. Encryption

All traffic to and from the platform is served over HTTPS/TLS. Data at rest is encrypted by the infrastructure providers we use — Supabase for the database, Cloudflare R2 for recordings. We do not operate our own servers or disks.

4. Payments

Billing runs through Stripe Checkout. When you buy a plan or a credit pack, you are sent to a page hosted by Stripe to enter your card details. Card numbers are never posted to, processed by, or stored on Up&Up servers — we hold only a Stripe customer ID, the plan you are on and your credit balance. Card details cannot be viewed by us or by our support team, because we never receive them.

5. Recordings and candidate media

Webcam footage, screen captures, video answers and ID verification images are written to a private Cloudflare R2 bucket. Nothing in that bucket is publicly readable. There are exactly two ways to get at a file:

• Playback through an authenticated endpoint, which requires a signed-in employer user and looks the file up under row-level security, so it will only stream recordings that belong to that user's organisation. Responses are marked private and are not cached by shared caches.
• A pre-signed URL generated on request for a signed-in user whose organisation owns the file. These URLs are time-limited and stop working when they expire (one hour by default). They are generated on demand, never embedded in emails or shared links.

Recordings are retained for as long as the associated submission exists. You can ask us to delete specific recordings at any time, and all recordings are deleted within 30 days of an account being closed. See the Privacy Policy for the full retention statement.

6. Accounts, passwords and access

• Authentication is handled by Supabase Auth. We never see or store a plaintext password; password hashing and session issuing happen in the auth service, not in our application code.
• Accounts inside an organisation have roles — owner, admin and member. Billing actions (starting a subscription, buying credits, changing a plan) are restricted to owners and admins.
• Server-side operations that need elevated database access use a separate service credential that is held only in server environment variables and is never exposed to the browser.

7. Abuse protection and rate limiting

API requests pass through a global rate limit keyed on client IP before they reach any handler — the only exemptions are the Stripe billing webhook and the authentication callback, so that payments and sign-ins are never dropped by a traffic burst. On top of that, the endpoints that are reachable without an employer login — loading a test from an invitation link, creating and updating a submission, requesting an upload URL, running an AI voice call — carry their own, tighter limits. Expensive AI operations are additionally limited per organisation so a compromised or runaway account cannot burn through capacity. Requests that exceed a limit receive a 429 with a Retry-After header rather than being silently dropped.

8. What candidates are told

Before a candidate enters any answers, the start screen shows the organisation running the assessment, the test title and description, the estimated duration, and — if the employer has switched any of it on — an explicit notice listing which invigilation features apply, such as webcam recording, screen capture, fullscreen enforcement, tab tracking or ID verification. Camera, microphone and screen capture can only begin after the browser's own permission prompt has been accepted by the candidate. See Responsible use for how we ask employers to handle this.

9. Subprocessors

We do not build infrastructure we can buy. The full list of third parties that process data on our behalf — including Supabase, Stripe, OpenAI, Cloudflare R2, Postmark, Vercel and Upstash — is published in section 4 of our Privacy Policy, together with what each of them processes. Assessment content and candidate responses are sent to our AI provider for question generation, scoring and voice interviews; if that is not acceptable for a role, do not enable the AI features for that test.

10. Data ownership, export and deletion

For candidate assessment data, the employer running the assessment is the data controller and Up&Up is the processor. Deleting a test from the dashboard removes its invitations and submissions along with it. For a full account export or erasure, or to remove specific candidate records or recordings, email hello@upandup.work and we will handle it directly. Candidates asking about their own assessment data should contact the employer who invited them; we will support that employer in responding.

11. What we have not done

We would rather lose a deal than win one on a claim that is not true. As of the date at the top of this page:

• We are not SOC 2 audited.
• We are not ISO 27001 certified.
• We have not commissioned an independent penetration test.
• We do not offer SAML single sign-on or SCIM provisioning.
• We do not offer multi-factor authentication on employer accounts.
• We do not provide a customer-visible audit log of admin actions.
• We do not offer data residency outside the United States.

If any of these is a hard requirement for your procurement process, tell us before you buy rather than after. We will give you a straight answer about whether and when we expect to meet it.

12. What we are working toward

This is a roadmap, not a promise with a date attached. In rough order of how often buyers ask for it:

• Multi-factor authentication for employer accounts.
• A standard data processing agreement customers can review and sign.
• An independent penetration test, with a summary letter we can share.
• A customer-visible audit log covering logins, exports and recording access.
• Self-serve export and erasure, so neither you nor we have to send an email.
• SOC 2 Type II readiness work, and single sign-on for larger teams.

13. Reporting a security issue

If you believe you have found a vulnerability, email hello@upandup.work with the subject line "Security report". Please include enough detail to reproduce the issue. We ask that you do not run automated scanning against production, do not access, modify or retain data belonging to anyone else, and give us a reasonable opportunity to fix the issue before disclosing it publicly. We do not currently run a paid bug bounty, and we will not take legal action against anyone who reports in good faith and follows the above.

For anything else — a security questionnaire, an architecture question, a diligence call — the same address reaches us. See Contact.