Security and trust
A cap table is a permanent record. We build like it.
Agreements, milestones and data rooms on GetSweaty are records that people will rely on years after they were made. This page sets out how those records are protected, who we trust to help hold them, and what we will send you if you ask.
How we think about it
Four commitments, and the last one is the load-bearing one.
Security claims are cheap to write and expensive to keep. These are the ones the rest of this page has to answer to.
The database decides, not the application
Row-level security is switched on for every table in the application database, and every policy written against it requires a signed-in member. A signed-out visitor holds no read privileges at all. So a page that forgets a filter, or a request crafted to skip the interface entirely, still returns nothing — because the answer was never the application's to give.
Nothing consequential happens without a record
Signing and data-room access are written down by the same database transaction that performs them, into logs the product itself cannot rewrite. A record assembled afterwards is a reconstruction. One written at the time, by the thing that did it, is evidence.
Few moving parts, and we name them
The providers below are the ones behind the service, each with what it does and what reaches it. We would rather run a short list well than assemble a supply chain nobody can hold in their head, and the privacy policy carries the full processor list in writing.
We do not claim what we have not earned
We hold no certification we have not been through, and this page names none. Where a control is partway, it says so — you will find one below saying exactly that. Ask us where we stand on anything here and you will get the real answer rather than a badge.
Platform controls
What is actually switched on.
Fifteen controls, each running in production today rather than scheduled — including the one that is only half finished, which says so.
Two ways in, and no third
You sign in with an email address and password, or with a passkey. There is no social login, no SMS codes and no anonymous accounts, so no third-party identity provider sits between you and yours. Every account is tied to an email address that has been confirmed before it can be used.
Passkeys
A passkey registered for GetSweaty is created against our own domain, and your browser will hand it back only to that domain. There is no shared secret for anyone to capture and nothing to replay on a lookalike site. Passkeys are phishing-resistant by design; what we have done is bind ours to us and verify the origin again on the server.
Two-factor, enforced in three places
Two-factor with an authenticator app is available to every member and optional by design. Once a member enrols one, it is enforced in front of the API, again inside the feature code, and independently by the database — which refuses data requests from an enrolled account that has not completed its second factor. Every one of those checks fails closed.
Sessions
Access tokens last an hour and refresh tokens rotate on use, so an intercepted token has a narrow window and a replayed one invalidates the session it came from. We never take the browser's word for who you are: the token on each request is verified against the identity provider's published signing keys before it is honoured.
Password recovery, boxed in
A reset link is good for one thing. While a recovery session is live it is confined to the reset and two-factor screens — it cannot post, message anyone or open a data room, and the database refuses its requests directly. It expires quickly, and we sign it out rather than waiting for you to.
Bots and credential stuffing
Sign-in, sign-up and password reset each require a Cloudflare Turnstile challenge, verified server-side by the authentication service before a password is ever checked. A production build fails outright if that key is missing or is one of the published test keys, so a release cannot ship the forms wired to a practice widget.
Confidential files
Data-room documents, documents out for signature and message attachments live in storage a browser cannot read on its own. Every view and every download goes through our servers, which authenticate the request and confirm the permission in the database first, then either stream the file back or issue a link that opens one file and expires in minutes.
Encryption in transit
Everything is served over HTTPS, plain HTTP is redirected, and Strict-Transport-Security is sent on every response with a two-year lifetime — so a browser that has seen us once will not be talked back down to an unencrypted connection.
Encryption at rest
The database, object storage and video sit on managed infrastructure that encrypts stored data at rest and manages the keys for it. Those providers are named below, along with what each of them holds.
Browser hardening
Framing is denied outright, MIME sniffing is off, referrers are trimmed cross-origin, and Permissions-Policy switches off camera, microphone, geolocation, payment, USB and ad-topic APIs. A content security policy is enforced on this site; on the platform it currently runs in reporting mode while it is tuned against real traffic, and the violations it reports come back to us.
Everything that arrives is checked
Untrusted input is parsed against a declared schema at every boundary before it reaches the database, all database access is parameterised rather than assembled as text, and uploads are type- and size-checked, then re-verified against what actually landed. Profile images are decoded and re-encoded on our servers rather than stored as sent.
Secrets cannot reach the browser
Every module that reads a private credential is marked server-only, so the build fails outright rather than bundling one into browser code. Three values are shipped to your browser deliberately, all three designed to be public, and a scan of the compiled bundle found no key material of any kind.
Payments
Card details never touch our servers. There is no card field anywhere in the product and no payment script runs in your browser on our pages: subscribing and cancelling both happen on Stripe's own hosted surfaces. Our database holds Stripe identifiers and a status, and no table exists that could hold a card number. Incoming billing events are rejected unless their signature verifies.
Audit trails the product cannot rewrite
The signing event log is append-only: the application's database role can insert and read, and cannot update or delete. Data-room activity is written by the same database function, and so in the same transaction, as the change it records — a download link is not even issued unless the download was logged first.
How a change ships
TypeScript runs in strict mode with a dozen further correctness flags, and our own application code carries no type-suppression comments at all. The release gate is five hundred test files, including suites that run inside a real PostgreSQL database as an ordinary member so the access rules are genuinely enforced, and a browser suite across Chromium, Firefox and WebKit against a production build.
Documents
A signed agreement is evidence, or it is just a file.
The difference is whether anyone can tell it has been altered since it was signed.
When the last signer finishes, the final PDF is rendered on our servers and sealed with a cryptographic signature covering the whole document, from its first byte to its last. We record a SHA-256 fingerprint of the original and of the sealed file, and we check the seal before the document is stored. Change one byte afterwards — a date, a number, a name — and the seal no longer matches the bytes it was made over.
- Every step is appended to a log the product cannot edit — created, sent, opened, consented, signed, sealed, filed — with who acted and when. A database trigger strips the signer's typed name and email out of that metadata, because the log is there to prove the act, not to repeat the person.
- Completed agreements are filed by our servers into a managed folder that is append-only for everyone using the product, the company's own administrators included. What lands there cannot be renamed, replaced, moved or trashed.
- Documents uploaded for signature are validated and rebuilt from their page content, so embedded scripts, auto-run actions and attachments do not travel into a signed document.
And the room those documents live in.
A data room is where a founder puts the things that would hurt most if they leaked. It is built to be shut, and opened deliberately.
- A room starts closed. Nothing is shared until an administrator shares it, folder by folder or file by file, to a person or a group.
- Viewing and downloading are separate rights, and a grant can carry an expiry date after which it simply stops working.
- Every download is written to the room's log before the file is released. If the record cannot be written, no link is handed back.
- Pages read in the browser can be watermarked per viewer, and the reference code in the watermark is the one in the audit log.
Trusted vendors
The providers behind it, and what each of them holds.
A vendor list is only useful if it is specific about the data. Here is what reaches each of them.
- Vercel
Application hosting, delivery, DNS and scheduled jobs
Serves this site and the platform, and processes request traffic in transit. It is not the system of record.
- Supabase
The system of record
Postgres, authentication, realtime and file storage. Account, profile, engagement and document data live here, under the policies above.
- Cloudflare
Turnstile, and Turnstile only
The challenge on sign-in, sign-up and password reset. It sees that interaction. No account data, and no other Cloudflare service is in front of us.
- Stripe
Subscription billing, as merchant of record
Handles card entry on its own hosted pages. Your name and email create the customer record; no card data comes back to us.
- Mux
Hosting and encoding for video posts
Receives the video file, an internal reference and a fixed title. No file name, no uploader name, no account data.
- Resend
Transactional email delivery
Receives the address a message is going to and the message itself — confirmations, notifications and password resets.
- Google
Places, for standardising a location
Receives the location text you type, called from our servers rather than your browser. No Analytics, no Tag Manager, no Ads, no reCAPTCHA, no Sign in with Google.
- SSL.com
Digital certificates
Our certificate authority. No member data reaches it, and the private key behind our document seal never leaves our servers.
These are the providers most people ask about; the privacy policy carries the authoritative list of everyone who processes data on our instructions, and we will send the full schedule to anyone doing a vendor review. Some of these providers store or process data outside the country you are in, including in Australia, the United States and the European Union.
Privacy
The quietest thing we could build.
This website sets no cookies, runs no analytics and embeds no advertising or social pixels. The only thing kept on your device is whether you chose light or dark, and it never leaves your browser.
Inside the product there is no Google Analytics, no Segment, no Mixpanel, no advertising pixel and no third-party tag of any kind. We run open-source analytics software ourselves, on infrastructure we control. Requests from your browser go only to getsweaty.com and our own servers relay them onward, so no analytics vendor ever sees your browser or your address. Signed out, nothing is measured at all.
Nothing you enter is sent to an AI provider. There is no AI vendor account, no model key and no AI library in the product. Where we offer help drafting something, the product hands you a prompt to take to whichever assistant you already use and checks the answer inside your own browser when you bring it back.
You can ask for a copy of what we hold about you, ask us to correct it, or ask us to delete it. Write to privacy@getsweaty.com and we will act on it. The privacy policy and the cookie policy set out the detail.
Enterprise
Running this for your own community.
Accelerators, funds, universities and corporate venture arms all want the same two things: the marketplace inside their own walls, and the paperwork their organisation can actually sign off.
Your community, your terms
If you run a programme and you want GetSweaty for the founders and experts inside it — your members, your terms, your data, your reporting — talk to us. We will scope what that looks like with you, including the controls, the data residency and the administrative separation your organisation needs.
Write to hello@getsweaty.com and tell us who your community is and what you need it to do.
Compliance documentation
For SOC 2 Type 2, ISO 27001, GDPR and HIPAA — where we stand, what we hold, what is under way and what we can commit to for your organisation — contact us and we will answer specifically rather than point you at a badge.
Security questionnaires, data processing agreements and vendor reviews go to legal@getsweaty.com. Tell us the deadline you are working to and we will meet it or say plainly that we cannot.
Responsible disclosure
Found something? Tell us.
Write to security@getsweaty.com with what you found and how to reproduce it.
We read and acknowledge every report. We will not pursue legal action over research done in good faith — that means testing against your own account, not accessing anyone else’s data, not degrading the service for other people, and giving us a reasonable chance to fix it before you publish. If you would like credit once it is fixed, say so and you will have it.
Ask us anything on this page
We would rather answer a specific question than be taken on trust. We open in Australia and the United Kingdom in October 2026.
Free for founders and experts. Nothing moves until the agreement is signed.