Skip to content

Tenure Comp Intelligence

Security overview

Version v1.0 · Effective 17 May 2026

This page describes how Tenure protects your data. It is honest about what we have, what we do not have yet, and what is on our roadmap. We update it whenever something material changes.

1. The short version

  • Tenure is built on Supabase (Postgres + Auth + Storage), Vercel (hosting), Stripe (billing), and Resend (email). All four are enterprise-grade vendors with their own security programmes
  • Data is encrypted at rest and in transit
  • Access to your data is restricted by row-level security at the database layer, not just the application layer
  • We do not yet hold SOC 2 or ISO 27001 certification; we will pursue formal certification when customer demand justifies the audit cost (typically at our first enterprise contract or $500k ARR, whichever comes first)
  • We have not had a security incident affecting customer data as of this document's effective date

2. Data storage

2.1 Where your data lives

Data type Vendor Region
Account, org, subscription, dashboard data Supabase Postgres EU (Frankfurt)
File uploads (benchmark CSVs, CVs) Supabase Storage EU (Frankfurt)
Payment data (card details) Stripe US, EU (Stripe holds, we never see card numbers)
Email send records Resend US
Application hosting Vercel Global edge network, primary US
Application errors Sentry EU

2.2 Encryption

  • Data at rest: AES-256 (Supabase managed)
  • Data in transit: TLS 1.2 or higher, enforced
  • Backups: encrypted, same standard as primary storage

2.3 Backups

Supabase runs daily backups with 7-day point-in-time recovery on our current plan. Backups are stored in the same region as the primary database with vendor-managed redundancy.

3. Access control

3.1 Authentication

  • Magic-link one-time password (no stored passwords)
  • Tokens expire after 1 hour
  • Sessions expire after 7 days of inactivity

3.2 Authorisation

We use row-level security (RLS) in Postgres. This means access rules are enforced at the database level, not just in application code. A bug in the application layer cannot bypass these rules.

Specifically:

  • A user in org A cannot read any data belonging to org B, even by manipulating client-side state or API parameters
  • An org member without owner/admin role cannot access billing settings
  • Benchmark uploads are org-private and cannot be read by any other org

3.3 Internal access

  • The founder (Liam Digan) is the only person with administrative access to the production database
  • No employees have access (Tenure has no employees as of the effective date)
  • Vendor support staff (Supabase, Stripe) do not have access to your data except as needed to investigate a specific support request you raise, governed by the vendors' own data processing agreements

4. Authentication and identity

  • All authentication is via magic-link email (Supabase Auth)
  • We do not store passwords
  • We do not yet support SAML/SSO; this is on the roadmap for the enterprise tier (deferred per product spec)
  • We support per-user, per-org role assignment (owner / admin / member)

5. Data handling commitments

  • We never sell personal data
  • Aggregate B2B output never identifies individual candidates
  • Your benchmark uploads are org-private, encrypted, isolated by RLS, never combined into the aggregate Pay Index, never visible to other orgs
  • CSV exports include a watermark fingerprint linking the export to the org and user who generated it; this lets us trace leaks

Full data handling details are in the Privacy Policy at tenurecareers.io/privacy.

6. Sub-processors

The full list of sub-processors who may process your data:

Vendor Purpose Data processed Region
Supabase Database, auth, storage All personal and account data EU (Frankfurt)
Stripe Payment processing, invoicing Billing data (we never see card numbers) US, EU
Resend Transactional and marketing email Email addresses, send context US
Anthropic AI features (CV review, salary matching, benchmarking match) Specific text inputs, never combined with directly identifying fields US
Vercel Application hosting and CDN All inbound and outbound traffic Global edge, primary US
Apollo Org enrichment at B2B signup Org domain US
exchangerate.host Currency conversion rates No personal data EU
Sentry Application error monitoring Error context (excludes PII by configuration) EU

Each sub-processor operates under a data processing agreement. We will give 30 days' notice before adding or removing any sub-processor.

7. Incident response

7.1 Response levels

Level Definition Initial response time
P0 Active data breach OR app down OR data demonstrably wrong at scale 4 hours
P1 Suspected data breach OR major feature broken 24 hours
P2 Minor security finding OR confirmed UX defect 5 business days
P3 Cosmetic or nice-to-have Backlog

7.2 Notification

If we become aware of a personal data breach that risks the rights of data subjects, we will:

  • Notify affected customers without undue delay, typically within 72 hours of discovery
  • Notify the UAE Data Office where required
  • Notify the Saudi Data and Artificial Intelligence Authority (SDAIA) where required (within 72 hours per Saudi PDPL Implementing Regulations)
  • Publish a public post-mortem after the incident is resolved, where doing so does not compromise security

7.3 How to report a suspected incident

Email security@tenurecareers.io or legal@tenurecareers.io. Provide:

  • A description of what you saw
  • The time the issue was first observed
  • Your contact details for follow-up
  • Any URLs, screenshots, or other context

We acknowledge security reports within 1 business day.

8. Vulnerability disclosure

We welcome responsible disclosure of security vulnerabilities. If you find one, please:

  1. Email security@tenurecareers.io with a clear description
  2. Give us a reasonable opportunity to investigate and remediate before public disclosure (we aim for 14 days for critical issues, 30 days for non-critical)
  3. Do not exploit the vulnerability beyond what is necessary to demonstrate the issue
  4. Do not access or modify other users' data

We do not currently run a paid bug bounty programme. We will publicly acknowledge researchers who report valid issues responsibly, with consent.

9. What we do not have yet

For transparency, here is what we explicitly do not have:

  • SOC 2 Type II certification (planned for year 2 or first enterprise contract)
  • ISO 27001 certification (not on the immediate roadmap)
  • HIPAA compliance (not applicable; we do not process health data)
  • Penetration test report for the current architecture (commissioning planned for Q1 2027)
  • 24/7 security operations centre (solo-founder reality; alerting is automated, response is best-effort)
  • A formal Bug Bounty programme

If your organisation's procurement requires any of the above before purchase, please contact legal@tenurecareers.io to discuss timing.

10. Customer obligations

Strong security is a shared responsibility. You agree to:

  • Keep User credentials confidential
  • Notify us immediately of any suspected unauthorised access to your account
  • Use unique, strong authentication for the email account linked to Tenure (since magic links route through email)
  • Promote former Users to inactive status when they leave your organisation
  • Comply with the Data Use Agreement when handling Tenure Data

11. Status

Our service status, including data freshness and uptime history, is at status.tenurecareers.io. Incidents above P3 are published there with timeline and resolution.

12. Contact

Purpose Email
Security incident or vulnerability report security@tenurecareers.io
Privacy or data rights privacy@tenurecareers.io
Legal or contract questions legal@tenurecareers.io
Support support@tenurecareers.io

Change log

Date Version Change Author
17 May 2026 v1.0 Initial Security Overview for B2B launch AI Privacy Expert

End of SECURITY-OVERVIEW.md v1.0