Security

This page lists the controls we actually operate today — not the ones we intend to add. We are a small EU company running a young platform, so it is deliberately specific about what exists and silent about what does not. If your review needs something that is not on this page, ask us and we will tell you straight whether we have it.

1. Encryption

In transit

All data transmitted between your device and our servers is encrypted using TLS 1.3. We enforce HTTPS on all endpoints and use HSTS headers to prevent protocol downgrade attacks.

At rest

All data stored in our databases and file storage is encrypted at rest using AES-256 encryption. Database backups are also encrypted. Key management is handled by our infrastructure providers — we neither hold nor rotate the keys ourselves.

2. Infrastructure

• Our platform runs on Supabase and Vercel, both of which maintain SOC 2 Type II. That is their certification, not ours.
• Edge functions execute in isolated environments with no shared state between tenants.
• Database access is restricted through row-level security (RLS) policies, ensuring users can only access their own data. RLS is enabled on every table in the application database, without exception.
• Database changes ship as version-controlled migrations applied from source control, so every schema change has a reviewable history.

3. Authentication & Access Control

• User passwords are hashed using bcrypt with industry-standard work factors.
• Session tokens are securely generated and stored with appropriate expiration.
• Role-based access control spans every module, with six role levels enforced in the database by row-level security rather than in the UI alone.
• Administrative access to production runs through our providers' own consoles and is limited to the company's staff. We are a small team; there is no offshore support tier with a login.
• We do not issue a public API or customer API keys. There is no API-key surface to leak or revoke.

4. Application Security

• Database access goes through a parameterised client layer, and every query is constrained by row-level security regardless of what the caller asks for.
• We serve HSTS, X-Content-Type-Options: nosniff, X-Frame-Options: DENY and a strict referrer policy. We do not yet serve a Content Security Policy — it is not deployed, and we would rather say so than imply a header you can check for in seconds.
• Every pull request runs a blocking secret scan, a type-check and the test suite before it can merge. The secret scan covers both the tree and the diff, so a credential added and removed within one branch still fails the build.
• AI model calls are made server-side from edge functions. Model provider keys are held as server secrets and never reach the browser.

5. Data Protection

• Customer data is logically isolated. Multi-tenant architecture uses row-level security to enforce strict tenant boundaries.
• Residency— your account and its data live in the EU (Supabase eu-west-1). Research and messaging call third-party AI, enrichment and delivery providers, some of them outside the EU, under the safeguards in our DPA. Ask for the current sub-processor list before you sign; it changes as the stack does.
• Our database provider takes automated daily backups with a rolling retention window. Point-in-time recovery is not currently enabled.
• Retention— deleting your account removes it and its data from the production database. We do not operate a scheduled purge beyond that, and provider-side backups age out on their own retention schedules rather than ours.
• Account settings let you export your profile, settings and company record as JSON, and delete your account outright. For a full extract of everything held under your account, email us and we will produce it — see our Privacy Policy.

6. Incident Response

We do not have a formal, documented incident response plan, and we do not run automated anomaly detection or a 24/7 on-call rota. Saying otherwise would be the easiest sentence on this page to write and the first one to fall apart under a real review. What we commit to instead:

• Containment— isolating affected systems as the first action, ahead of diagnosis.
• Investigation— root cause analysis against database and platform audit trails.
• Notification— affected users and relevant authorities notified within 72 hours of a confirmed personal-data breach, as GDPR Article 33 requires of us.
• Remediation— corrective actions implemented and written up.

If a documented plan is a hard requirement for your review, tell us — that is a reasonable thing to need, and we would rather hear it than have you discover the gap after signing.

7. Compliance

• GDPR— we build against it: lawful basis for B2B outreach, suppression and deletion on request, and a DPA available on request. That compliance is our own assessment, not a third party's. No auditor has reviewed it.
• EU AI Act— we treat the systems we run as in scope and design for the transparency and human-oversight duties. No conformity assessment has been carried out.
• Our infrastructure providers — Supabase and Vercel — maintain SOC 2 Type II. We do not claim an ISO 27001 certification for them or for ourselves.
• Built and hosted in the EU. Enrichment draws on public business data and licensed B2B datasets under legitimate interest — no scraped private profiles, no gray-market databases.

8. Responsible Disclosure

We value the security research community and welcome responsible disclosure of vulnerabilities. If you discover a security issue, please report it to us privately:

We ask that you:

• Provide sufficient detail for us to reproduce and address the issue.
• Allow reasonable time for us to investigate and fix before public disclosure.
• Do not access or modify other users' data during your research.

We aim to acknowledge reports within 48 hours and to provide updates as we investigate. There is no paid bounty programme.

9. Contact

For security-related questions or concerns, contact: