Built with workplace data in mind. Here's exactly what protects it.

Sign-in methods that fit your team

Every account is protected by the controls below. Enterprise customers can layer single sign-on on top.

Password sign-in with scrypt hashing

Passwords are hashed with scrypt and a per-user salt, never stored in plaintext, and never logged. Sign-in attempts are rate-limited to slow brute-force probes.

Magic-link sign-in

Passwordless sign-in via a short-lived, single-use email link. Sent through our transactional provider on a verified sending domain so deliverability stays high.

TOTP MFA with backup codes

Time-based one-time passwords compatible with Google Authenticator, 1Password, Authy, and others. Backup codes are generated at setup and encrypted at rest with AES-256-GCM.

OAuth, SAML & LDAP SSO (Enterprise)

Google and Microsoft OAuth out of the box, generic SAML 2.0 for Okta, Entra ID, Ping, and JumpCloud, plus LDAP for on-prem directories. Per-company provider configuration with just-in-time user provisioning.

Hardened at the edge and in every request

Helmet, strict CSP, HSTS preload, CSRF protection, and per-route rate limits ship with the platform — no toggles required.

HTTPS everywhere with HSTS preload

All traffic is served over HTTPS with a one-year HSTS max-age, includeSubDomains, and preload — browsers refuse to talk to BellKeep over plain HTTP.

Strict Content Security Policy

A locked-down CSP allow-lists only the script, connect, and frame sources we actually use (Stripe, our analytics endpoints, and our consent widget). Frameguard is set to deny in production to block clickjacking.

CSRF protection on every mutation

State-changing requests require a custom X-Requested-With header that cross-origin attackers can't set without a CORS preflight, paired with a strict CORS allowlist that only accepts trusted origins.

Rate limiting & account lockout

Auth endpoints cap at 5 attempts per 15 minutes, password reset at 3 per 15 minutes, and accounts lock after 5 failed sign-ins. Lockouts are recorded to the audit log.

Encryption everywhere, tenant isolation by default

Data is encrypted in transit and at rest, with extra app-level encryption on the sensitive bits — and each customer's data is scoped at the query layer, not just the UI.

Encryption at rest

PostgreSQL on Railway with provider-managed disk encryption. Daily managed backups, retained per Railway's policies, with point-in-time recovery available on production tenants.

App-level AES-256-GCM for secrets

MFA seeds, SAML/OAuth tokens, calendar OAuth credentials, and visitor ID-document images are encrypted in the application layer with AES-256-GCM and PBKDF2-derived per-record keys before they ever hit the database.

Multi-tenant isolation

Every customer gets a dedicated subdomain and a companyId scope that's applied to every query. Cross-tenant access is blocked at the data-access layer, not just in the UI — and verified by automated tests.

Role-based access control

Admin, manager, staff, and read-only roles are enforced server-side on every protected route. Permissions are scoped per company, and admin actions write to the audit log.

Real GDPR tooling, not a privacy policy page

Visitor consent, data retention, export, and deletion are wired into the product — not promises in a footer. Admins manage all of it from the GDPR dashboard inside the app.

Data export on demand

Admins can export tenant and visitor data — bookings, visits, audit trails, and metadata — directly from the dashboard. No support ticket required.

Right-to-erasure workflow

Deletion requests are tracked end-to-end with a dedicated table (data_deletion_requests). Personal data is purged on schedule; what we keep for legal reasons is anonymised.

Consent capture & history

Visitor consent is captured at check-in and version-tracked in consentHistory. Withdrawals are recorded, and retention policies run on a schedule with automated photo cleanup.

Every sensitive action is logged

Authentication events, admin actions, SSO sign-ins, and visitor watchlist changes write to dedicated audit tables. Logs are scoped per company and queryable from the admin dashboard.

User & admin actions

The audit_logs table captures action, resource type, granted/denied result, userId, companyId, and timestamp for every protected operation.

MFA events

Setup, verification, backup-code use, and admin overrides are recorded in mfa_admin_actions and mfa_verification_attempts so incidents are reviewable after the fact.

SSO sign-ins

Every SAML, OAuth, and LDAP sign-in is logged to sso_audit_log with provider, identity, and outcome — useful for procurement reviews and access reconciliation.

Visitor watchlist changes

Adds, edits, and matches against the visitor watchlist are recorded in watchlist_audit_log. Sensitive operations need elevated privileges to run.

Honest about certifications

We'd rather be straight with you than slap a logo grid on this page. Here is exactly what's shipping, what's underway, and what we don't have today.

GDPR data-rights tooling

Built into the product: consent capture, retention scheduling, export, deletion, and breach-notification records. Available to every customer, every plan.

Encryption in transit & at rest

TLS for all traffic with HSTS preload. Provider-managed encryption at rest on PostgreSQL plus AES-256-GCM application-layer encryption for MFA, SSO, and calendar secrets.

Logging, audit, and access controls

Structured audit logs, per-route rate limits, account lockout, role-based access control, and Prometheus metrics for monitoring — all enabled by default.

SOC 2 Type II

Not certified. We've built the underlying controls (audit logging, access management, change tracking) and will pursue an audit when customer demand justifies it. We're happy to walk procurement teams through our current control set.

ISO/IEC 27001

Not certified. Internal references in our codebase (logging, encryption) align to specific Annex A controls, but we have not undergone a third-party certification audit.

HIPAA

Not in scope today. BellKeep is not marketed for protected health information — please don't store PHI in the product without an explicit conversation about your use case.

Third-party penetration testing

We run continuous dependency auditing and internal security reviews, and we're planning an external penetration test. Until that report exists, we won't claim one.

Talk to security

Security questionnaires, responsible disclosure, vendor reviews, or just a chat about how we'd fit into your stack — reach out directly.

Data location and subprocessors

BellKeep's application servers, PostgreSQL database and Redis cache run on Railway. Contact security@bellkeep.com for the hosting region and a data processing agreement.