Security Policy
How we keep your data safe.
Security is the foundation of everything we build. This document is a living summary of the technical and organisational measures we use to protect your data. It complements Annex II of our Data Processing Addendum and supports the commitments in our Privacy Policy.
Last updated: 12 May 2026·Version 1.0.2
1. Principles
- Least privilege — minimum access by default, just-in-time elevation for sensitive actions.
- Defence in depth — multiple overlapping controls so no single failure breaks the system.
- Secure by default — TLS, strong password hashing, hardened cookies, 2FA available for everyone.
- Transparent — incident notifications within 72 hours, monthly status posts, public responsible-disclosure programme.
- Limit blast radius — tenancy isolation, encrypted backups, audit logs.
2. Encryption
- In transit: TLS 1.2+ for every connection — to our APIs, dashboard, and public vCards. HSTS enabled on all production domains with a 12-month max-age. Modern cipher suites only.
- At rest: AES-256 disk-level encryption for the primary database and object storage. Customer-managed encryption keys (CMEK) are on the Business plan roadmap.
- Passwords: Argon2id hashing with a per-password salt and a server-side pepper. Bcrypt is used for legacy compatibility where required.
- Secrets: sub-processor API keys and webhook secrets are stored in a dedicated secret manager, not in source code. Access is logged.
- Webhooks: outbound webhooks (when introduced) are signed with HMAC-SHA256 so receivers can verify origin and integrity.
3. Access controls
- Internal access: Debutap team access to production is role-based, granted on a need-to-know basis, with mandatory MFA. Just-in-time elevation (signed-off requests) for privileged actions.
- Customer accounts: 2FA available on all paid plans; required on Business plan accounts. Session management is HttpOnly + Secure + SameSite=Lax, with automatic expiry.
- Multi-tenancy: every database row is keyed by
workspace_id; query layer enforces tenancy at every read and write. - Anomaly detection: high-risk events (new device, new location, password change, mass deletes) trigger email notifications to the account owner.
4. Infrastructure security
- Production runs in private VPCs with firewall rules whitelisting only the ports needed by each service.
- Databases and queues are not reachable from the public internet. Engineers connect via a bastion host with audited sessions.
- Cloudflare WAF / DDoS protection sits in front of every public origin.
- Operating systems are patched within 7 days of a critical CVE being published, 30 days for high, 60 for medium.
- Containers are built from minimal base images and rebuilt at least weekly to pick up upstream fixes.
- Custom-domain TLS is automated via on-demand Let's Encrypt / Cloudflare-for-SaaS, so certificates never expire silently.
5. Application security
- Secure SDLC: mandatory code review on every change, automated dependency scanning, secret-scanning in CI, strict TypeScript types end-to-end.
- Input handling: server-side validation with Zod / class-validator schemas; output encoding via templating; CSP and SRI for the marketing site.
- Custom CSS/JS feature: sandboxed via iframe srcdoc with strict CSP — your custom code can't access the parent dashboard or other users' cards.
- Rate limiting: per-IP and per-account rate limits on auth, password reset, public APIs, and form submissions.
- CSRF: per-session anti-CSRF tokens on every state-changing request; double-submit cookie pattern for the dashboard.
- Pentesting: independent third-party penetration test at least annually; internal red-team exercises quarterly.
- Bug bounty: our responsible-disclosure programme is below.
6. Incident response
- Documented incident-response runbook with clearly assigned roles (Incident Commander, Comms Lead, Forensics Lead).
- Severity levels SEV-0 (data breach / total outage) through SEV-3 (cosmetic), each with target response and communication windows.
- Customer notification for confirmed personal-data breaches: within 72 hours (GDPR Art. 33) — usually within 24 hours.
- Post-incident review (PIR) within 14 days, published in summary to affected customers.
- We will not retaliate against any person reporting a suspected incident in good faith.
7. Backups & disaster recovery
- Daily encrypted backups of the production database, retained on a rolling 30-day window in a separate region.
- Backups are encrypted with keys distinct from the production database keys.
- Restore drills are performed quarterly and timing is recorded.
- Target Recovery Time Objective (RTO): 4 hours for full platform restore.
- Target Recovery Point Objective (RPO): 24 hours (worst case).
8. Logging & monitoring
- All authentication, API, and admin actions are logged with timestamp, user ID, IP, and outcome.
- Logs retained for 12 months; access is restricted and audited.
- Real-time alerts on anomalies: spikes in failed logins, geo-impossible logins, sudden mass exports, privileged actions outside business hours.
- Error and performance monitoring via Sentry with sampling; payloads are scrubbed for PII before storage.
9. Vendor risk management
- Every sub-processor is evaluated for security posture before onboarding (SOC 2 / ISO 27001 / equivalent attestation preferred).
- Contracts include data-protection obligations and breach-notification commitments back to us.
- Annual review of each sub-processor against our risk register.
- See the full list at /legal/sub-processors.
10. Responsible disclosure programme
We welcome reports from security researchers. If you find a vulnerability, please report it privately to [email protected].
Scope
- Production hosts owned by Debutap: debutap.com and its subdomains, the dashboard, and the public API.
- Out of scope: third-party services we use (report directly to them), customer-controlled custom domains, social engineering, physical attacks, denial-of-service testing without prior written agreement.
Rules of engagement
- Do not access, modify, or destroy data that doesn't belong to you.
- Do not run automated scanners that disrupt the Service.
- Give us a reasonable time to respond and fix before disclosing publicly — we aim for 90 days.
- Don't demand payment as a condition for the report.
What you can expect from us
- An acknowledgement within 2 business days.
- A triage update within 7 days.
- Credit on a public "Hall of Fame" page (planned), with your permission.
- A monetary reward for valid, original vulnerabilities — programme details and reward bands will be published on the Hall of Fame page once formalised.
Acting in good faith and within these rules, you will not be subject to legal action by Debutap. We commit to safe-harbour for good-faith security research.
11. Contact
- Vulnerability reports: [email protected] (PGP key on request)
- Incident inquiries: [email protected]
- General security questions: [email protected]
Questions about this document? Get in touch at [email protected].
See all legal documents