How Dealase protects your partnering data

• Business records only, never health data

  In place

  Dealase stores organizations, people in their business roles (name, title, business email and phone), assets, deals, activities, meeting schedules and documents you upload, plus public information about companies. It does not store patient information or any other health data, and its terms prohibit uploading it.

• Hosted in the United States

  In place

  The application runs on Vercel and the database, sign-in and file storage on Supabase (Postgres), both in the United States. Background jobs will run on a US-hosted worker on Fly.io or Railway.

• Encryption in transit and at rest

  In place

  Every connection uses TLS 1.2 or higher. Data is encrypted at rest by the hosting providers (Supabase encrypts the database and file storage at rest with AES-256).

• Tenant isolation enforced by the database

  In place

  Every record belongs to exactly one workspace. Row-level security policies on every tenant table stop a query from one workspace reading, changing or even counting records in another. Automated database tests prove that cross-workspace reads, writes and enumeration fail, and they run on every code change.

• Public pages cannot reach customer data

  In place

  Signed-out pages (company pages, the directory, the free partner finder) read the database as a separate read-only role that can see the shared public tables and nothing else. A database test proves it cannot read any workspace table or write anything.

• Server-side keys never reach the browser

  In place

  The database service key is used only on the server; the build fails if browser code imports the server database module. Secrets live in environment variables, never in code.

• Separate production database

  Planned

  A dedicated production Supabase project, separate from the one used during the build, is set up before the first paying customer.

• Backups and restore tests

  Planned

  Before the first paying customer: point-in-time recovery on the production database, a nightly encrypted logical backup to storage controlled by Techowiat, and a restore test every quarter with the result noted in the runbook.

• Export

  In place

  Every list in the app exports to CSV, and the confidentiality register and conference recaps have their own exports. A one-click export of the whole workspace is planned.

• Self-serve workspace deletion

  Planned

  Owners will delete their workspace themselves; records and files leave production within 30 days and backups within the backup retention period, with a confirmation when it completes. Until it ships, a deletion request to support is carried out by the founder and logged.

• No passwords

  In place

  You sign in with a one-time link emailed to your work address, or with Google or Microsoft once they are switched on. Sign-in is handled by Supabase Auth. The session lives in a secure cookie page scripts cannot read, and every page and action checks it on the server before the database checks it again through row-level security.

• Two-step sign-in

  In place

  Each person can turn on an authenticator-app code at sign-in, and owners can require it for everyone in the workspace. If someone loses their phone, an owner who has two-step sign-in resets it for them in Settings, Security (at most five an hour); the reset signs them out everywhere, they sign in again with their emailed link and set up a new app, and it is recorded in the audit log of every workspace they belong to.

• Invitations only, optionally limited to your domain

  In place

  Colleagues join only through an invitation from an owner or admin: a single-use link that expires after 14 days, works only for the address it was sent to once that address is confirmed, and can be withdrawn. Owners can limit invitations to their company's email domains. Nobody joins because their email domain matches.

• Removing people and leaving

  In place

  Owners and admins remove people in Settings, Members (admins remove members and viewers; only owners remove owners and admins), and anyone can leave a workspace. Access ends on the next request, because the database checks membership on every query. In the same database transaction the person's API tokens and calendar feed for that workspace are revoked, pending invitations to them are withdrawn, and the removal is written to the audit log. The records they created stay. A workspace always keeps at least one owner, enforced by the database.

• Session length

  In place

  Owners choose how long a sign-in lasts before people must sign in again.

• Roles

  In place

  Owner, admin, member and viewer. Restricted documents are visible only to the uploader, the people listed on them and admins.

• Audit log with export

  In place

  Changes to workspace records are written to an audit log by the database itself. Owners and admins can read it and export it to CSV.

• Read-only API tokens for AI tools

  In place

  Personal access tokens for the Dealase MCP server can only read, see exactly what their owner can see in one workspace, are stored only as a SHA-256 fingerprint, can expire after 30, 90 or 365 days, and are limited to 120 calls a minute. Each call is logged by tool name only.

• Single sign-on (SAML) and SCIM

  Planned

  Company single sign-on and user provisioning are planned for larger organizations.

• Owner of the hosting accounts

  In place

  As owner of the hosting and database accounts, the founder holds the keys that could technically reach the database. The protection is policy plus tooling that never shows customer content, not a claim that access is impossible.

• No browsing of customer data

  In place

  The founder does not open customer records. Production is touched only to run the product, to respond to an incident, or to carry out a request from the customer, and then only as far as that needs.

• Operator console without business content

  Planned

  An operator console with its own sign-in and required two-factor will list customer companies, their people, roles, plan, seats, billing status and usage, with account actions (suspend, resend an invitation, change plan, run a requested deletion), every action audit-logged. It never reads deals, notes, CDAs, briefs, assets or pipelines, and a test will enforce that.

• Support access only when you grant it

  Planned

  Help inside a workspace will happen only through support access the customer grants: limited to 24 hours, logged, visible to the workspace's admins and revocable at any time. There is no silent back door.

• A record of direct database access

  Planned

  Every direct database session by the founder recorded and shown to a customer on request.

• No selling, sharing or cross-customer use

  In place

  Dealase never sells data, shares it with other customers, or uses one customer's records to enrich another's.

• Not used to train models

  In place

  Your content goes to the model provider (Anthropic) only to produce output for your workspace. Under Anthropic's commercial terms, API inputs and outputs are not used to train its models. Dealase does not train or fine-tune any model on customer data.

• Every model call logged and budget-capped

  In place

  Every model call goes through one module that checks the workspace's AI budget first, records the cost against the workspace, and accepts only output that matches a strict schema.

• Nothing sent on your behalf

  In place

  Models extract fields into forms you see and edit, and draft briefs, follow-ups and meeting requests that you review. Nothing is sent automatically; you send it yourself.

• Free tools use no AI

  In place

  Partner-fit scores, including the free partner finder, come from a fixed formula over public records, not from a language model.

• AI features in production

  Not yet active

  Model calls are switched off on the live site until per-workspace AI budgets are set for real customers. Until then Anthropic receives no customer content.

• ClinicalTrials.govTrials by sponsor: phase, status, conditions, interventions, datesPublic US government data; under 50 requests a minute; every trial links back to its study page
• SEC EDGARFilings, cash and burn for runway estimates, 8-K deal announcementsPublic domain; under 10 requests a second with a User-Agent naming Dealase and a contact address
• NIH RePORTERGrants and awards by organizationPublic US government data; one request a second
• PubMedRecent publications by affiliationNCBI usage guidelines; 3 requests a second, 10 with a key
• openFDAFDA actions and approvalsPublic data with a free key
• USPTOPatents by assigneePublic data with a free key
• Press-release wiresPartnerships, financings and pipeline newsPublic RSS feeds; headline, date and link stored, with the link kept
• Companies' own websitesPipeline tables and team names and titlesThe company's own domain only, robots.txt honored, one request a second, at most 8 pages a company per run

Anyone can ask for a correction, or for their name to be removed, from the link on every public company page.

• SOC 2

  Planned

  Dealase has no SOC 2 report today. A SOC 2 Type 1 audit is planned once the product has paying customers, followed by Type 2. The controls on this page are the ones that audit will test.

• No health data, so no HIPAA scope

  In place

  Dealase is not a HIPAA service and signs no business associate agreements, because it holds no health data and refuses it.

• Penetration test

  Planned

  No third-party penetration test has been done yet. One is planned before or alongside the SOC 2 Type 1 audit.

• Data processing agreement

  Planned

  A standard data processing agreement customers can accept online is planned before launch.

• Vulnerability reporting

  In place

  Report security issues to support@dealase.com. You get an answer within two business days, updates until it is fixed, and credit if you want it. Please do not test against other customers' data.