How we keep your data safe.

Our primary database is Supabase Postgres hosted on AWS in the Mumbai region (ap-south-1) — so your data physically sits in India by default. File uploads (resume PDFs you import, profile pictures) go to Supabase Storage in the same region.

The application is hosted on Vercel’s edge network. Static assets and pages are cached globally; dynamic requests are served from the closest data centre. Vercel servers see requests routing through them but do not have direct database access.

AI inference (Job Insights, Tailored Resume, embeddings, resume parsing) calls Google’s Gemini API or Groq’s llama-3.1 API. Profile snippets are sent in transit for each call and are not retained by the provider for model training. See Privacy section 5 for the full subprocessor list.

In transit: TLS 1.2 or higher on all connections to slatebook.in and to our database. HTTP Strict Transport Security is enabled. Authentication cookies are HttpOnly + Secure + SameSite=Lax.

At rest: Supabase Postgres data is encrypted with AES-256. Supabase Storage uses server-side encryption (SSE) via AWS. Backups inherit the same encryption.

Secrets:Service-role keys, API keys, and OAuth client secrets are stored in Vercel’s encrypted environment-variable store and never appear in client-side code or logs.

Every table in our database has Postgres Row-Level Security (RLS) policies enabled. That means even if application code had a bug, a logged-in user could not read another user’s rows — the database itself enforces the boundary.

Service-role access (which bypasses RLS) is restricted to server-side code only and is gated to the smallest possible operations — primarily writes from AI workflows and admin actions. Service role keys never run in the browser.

Internal access is limited to people who genuinely need it (currently a very small team). Production database access is via SSO + 2FA. All admin actions are audited via Supabase logs.

We use Supabase Auth, which is built on industry standards. Supported sign-in methods: email + password (PBKDF2-hashed), Google OAuth, and magic links. We don’t store passwords in plaintext, ever; even we can’t see them.

For Google OAuth, we request the minimum scopes needed (email + basic profile). When we send transactional email from your own Google Workspace account on your behalf, additional scopes are explicitly requested at that point — see Privacy for the scope list.

Sessions are managed via secure HttpOnly cookies with automatic refresh. We don’t persist sensitive tokens in localStorage.

Supabase takes daily automated backups of our Postgres database, retained for 30 days. Point-in-time recovery is available within that window. Backups are encrypted at the same level as the live database.

On account deletion (see Privacy section 10), your data is removed from the live database immediately. It may persist in encrypted backups for up to 30 days before being overwritten; we will not restore your data from those backups except in a disaster scenario.

Every change to the codebase passes through a TypeScript type-check, lint, and review process before being deployed. Database schema changes go through migration files version-controlled in Git — no ad-hoc production schema edits.

Deployments happen via Vercel from the production branch. Rollback to a previous deployment is one click. We use feature flags for risky changes so we can disable them server-side without re-deploying.

All AI-powered actions (Job Insights, Tailored Resume, resume parsing, etc.) are rate-limited per user at the database level via SECURITY DEFINER RPCs. This prevents both accidental run-away costs and intentional abuse.

Authentication-sensitive endpoints (signup, password reset, OAuth callback) are rate-limited via Supabase Auth’s built-in protections. Repeated failed attempts trigger CAPTCHA challenges.

If we discover a security incident affecting your data, we will:

• Investigate immediately — the on-call engineer is paged.
• Contain the issue (isolate compromised credentials, roll keys, take affected systems offline if needed).
• Notify affected users within 72 hours, per DPDP Act obligations.
• Notify the Data Protection Board of India where required.
• Publish a post-incident report once the investigation is complete.

We welcome reports from security researchers. If you’ve found a vulnerability, please email support@slatebook.in with:

• A clear description of the issue.
• Steps to reproduce, ideally with a proof-of-concept.
• Your assessment of the impact (e.g. authentication bypass, data exfiltration vector, XSS).

We commit to:

• Acknowledging your report within 2 business days.
• Working with you in good faith to validate and patch.
• Not pursuing legal action against researchers who follow this responsible-disclosure process — no testing beyond what’s necessary to validate the issue, no exfiltration of real user data, no public disclosure before we’ve patched (or 90 days, whichever comes first).
• Crediting you on a public security acknowledgements page if you wish.

We don’t currently run a paid bug-bounty programme. We’re looking at one for late 2026.

We operate under the Digital Personal Data Protection Act, 2023 (DPDP) as a data fiduciary. We aim to align with GDPR best practices for cross-border users, even though we don’t actively target EU markets.

A formal SOC 2 Type II audit and ISO 27001 certification are on the roadmap once we hit the scale that justifies the audit cost — likely 2027. In the meantime this page (and Privacy) describes the controls in detail.