Skip to main content

Security

Version 2026-06-30 · Last updated 2026-06-30

This page summarises the technical and organisational measures (the "TOMs" referred to in our Data Processing Agreement) that JobMistr applies to the Service. It is provided in good faith and reflects current practice; specific controls evolve as the threat landscape and our stack evolve.

1. Hosting and platform

  • Application: Vercel (EU region — Frankfurt primary).
  • Authentication and real-time data: Convex (EU region). Sessions handled server-side; tokens never exposed to JavaScript via document.cookie.
  • Primary database: managed PostgreSQL with automated daily snapshots and point-in-time recovery.
  • File storage: Cloudflare R2 with object-level access controls and presigned URLs for uploads.
  • Payments: Stripe Payments Europe, Ltd. (PCI-DSS Level 1). Card numbers never traverse JobMistr systems.

2. Encryption

  • TLS 1.3 in transit on all endpoints. HTTP-only, Secure-flagged session cookies. HSTS with preload for the apex domain.
  • Field-level AES-256-GCM encryption at rest for sensitive data — personal data such as email addresses, phone numbers, postal addresses, bank details, message content, and signature data, as well as OAuth refresh tokens, connected-mailbox credentials, TOTP secrets, and recovery codes. Encryption keys are held only in the hosting provider's encrypted secret store and never committed to source.
  • Provider-side AES-256 encryption at rest for the underlying database, object storage, and backups, per the sub-processors' own infrastructure controls.
  • User passwords are hashed with a modern memory-hard algorithm (scrypt) by our authentication layer. We never log or store plaintext passwords.

3. Authentication and account controls

  • Email + password sign-in with rate-limited attempts; OAuth sign-in available via Google, Microsoft (Entra ID), and Apple.
  • Two-factor authentication (TOTP) can be enrolled on any account; enforcing it at every sign-in is on our roadmap.
  • Recovery codes are generated with 128 bits of entropy.
  • Sign links for invoices, quotes, and contracts use long, unguessable tokens that carry a ninety (90)-day expiry by default and are rejected once expired.
  • Role-based access control (Owner / Admin / Member / Bookkeeper / Viewer) within each workspace. Tenant isolation by providerId on every data row.
  • Suspicious-activity protections including per-IP and per-route rate limiting on public endpoints, abuse detection on sign-up, and audit logging on privileged operations.

4. Network and application security

  • HTTP response headers: HSTS (1 year, includeSubDomains, preload), X-Content-Type-Options, X-Frame-Options: SAMEORIGIN, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy, Cross-Origin-Opener-Policy, Content Security Policy.
  • Input validated server-side with Zod schemas; rich-text content rendered through a strict HTML-sanitisation allowlist (DOMPurify).
  • Webhook integrations verify provider signatures (Stripe-Signature, etc.) and idempotency keys to defend against replay.
  • Open-redirect, XSS, and SSRF surfaces audited; redirects are restricted to same-origin or explicit allowlists.

5. Audit, logging, and monitoring

  • Sensitive operations (role changes, billing changes, data deletion, sign-token issuance, payment events) are written to an append-only audit log retained for seven hundred and thirty (730) days by default; longer where needed for legal-defence purposes.
  • The audit log captures a snapshot of the actor (user id when available, plus name and email) so that records remain useful even after the actor is later deleted under Art. 17.
  • Application errors and security events are forwarded to a monitoring pipeline. Our roadmap includes deeper Sentry / Datadog coverage of background paths.

6. Backups and disaster recovery

  • Daily automated database snapshots with point-in-time recovery retained on a rolling 30-day window.
  • R2 object storage uses provider-native durability; lifecycle rules retain historical versions of key files for thirty (30) days.
  • Recovery objective: RPO ≤ 24 hours; RTO ≤ 8 hours for a region failure. These objectives are commitments to ourselves, not contractual SLAs, until we exit beta.

7. Change management and secure development

  • All changes go through code review before deployment.
  • Static analysis: TypeScript strict mode plus targeted linting.
  • Dependencies tracked via package lockfiles; security advisories monitored.
  • Production access is restricted; secrets are managed via the hosting provider's encrypted environment variable store and never committed to source.

8. Incident response

We maintain an incident-response runbook. If we discover a personal-data breach within scope of GDPR Arts. 33-34 we will notify the relevant supervisory authority without undue delay and, where required, within seventy-two (72) hours. We will notify affected users without undue delay where the breach is likely to result in a high risk to rights and freedoms.

9. Vulnerability disclosure

We welcome responsible reports from security researchers. Please email security@jobmistr.com with sufficient detail to reproduce. We will acknowledge within three (3) business days. Please do not access or modify data that is not yours, do not perform attacks that degrade service for other users, and refrain from public disclosure until we have had a reasonable opportunity to remediate.

10. Penetration testing and third-party assurance

Independent penetration testing will be conducted annually once JobMistr exits beta. Sub-processor security is verified through their published certifications (e.g. Stripe's PCI-DSS Level 1 attestation, Cloudflare's ISO 27001 and SOC 2 reports) and through contractual obligations in our Data Processing Agreement.

11. Contact

Security reports: security@jobmistr.com. General questions: legal@jobmistr.com.