Trust centre
Security, privacy and compliance at HelpFalcon
What protects your support data, where it lives, who helps us process it, and where our compliance programme stands.
Last updated
Overview
HelpFalcon is in private beta. The whole platform runs on one server in Falkenstein, Germany, behind Cloudflare, with Docker Compose. That is enough for the first customers and it is honest about what it is not: there is no second server, no automatic failover and no availability commitment yet, the recovery point objective is 6 hours, and we hold no security certification. Everything on this page describes that setup, and says so where the production platform will do more. The legal documents below are drafts awaiting a lawyer.
Data location
Everything is in Germany: the server, database and search run in Hetzner's Falkenstein location, attachments and off-site database backups in DigitalOcean Spaces in Frankfurt. Support data does not leave the EU except for the subprocessors listed, under Standard Contractual Clauses.
Workspace isolation
Every row carries its workspace, and the database enforces it with row-level security. Search indexes, files, caches and realtime channels are scoped the same way. Cross-workspace tests run on every change.
Encryption
TLS 1.2 or newer with HSTS for every connection to us, and TLS inside the stack. Our hosting and storage providers encrypt their disks and object storage at rest. Integration secrets use a key that belongs to your workspace alone.
Secure development
Static analysis (Semgrep, PHPStan), dependency and secret scanning in CI, a ZAP baseline scan on staging, SSRF protection on every outbound call, and sanitised rich text and help-centre themes.
Audit and access
Append-only ticket history, admin and access audit logs you can export or stream. We see your workspace only when you grant support access, and every such session is in your audit log.
AI with privacy
AI features are switched off on the private beta: no AI provider is connected, so no ticket text has left our servers. When they are turned on, personal data is masked first, it is never used to train models, and admins can switch AI off completely.
In detail
Security measures
- Encryption in transit
- TLS 1.2+ (TLS 1.3 preferred) at the edge and to origin, HSTS (2 years, subdomains) on every app and API response, TLS inside the stack to the database, cache and queue.
- Encryption at rest
- Provider-side encryption of the server's disks and of the object storage that holds attachments and backups. Passwords are hashed with Argon2id; API tokens and portal sessions are stored as SHA-256 hashes. Per-workspace envelope keys (XChaCha20-Poly1305) protect integration, channel and SSO secrets; deleting the key makes them unreadable, backups included. LUKS2 volume encryption and client-side encrypted backups arrive with the production platform.
- Authentication
- Passwords hashed with Argon2id, MFA (authenticator app, passkeys, security keys), sign-in with Google or Microsoft, SSO with SAML and OpenID Connect, SCIM provisioning, session and password policies, IP allowlists (Enterprise).
- Backups and recovery
- Daily whole-disk server backups kept 7 days, a verified database dump every 6 hours and a nightly search dump to object storage at a second provider, kept 30 days. The recovery point objective on the beta is therefore 6 hours. Restore scripts are rehearsed on throwaway copies; the first drill on production hardware, continuous archiving for point-in-time recovery and an immutable off-site copy come with the production platform.
- Monitoring
- An independent status page checks the site, app, API, a workspace, the help centre and the realtime hub from Cloudflare's network every minute and alerts us by email and chat; errors go to Sentry (EU region). Audit logs record admin and staff actions. Metrics and alerting inside the stack, and a formal on-call rotation, come with the production platform.
- Vulnerability management
- Dependency audits (Composer and npm), secret scanning over the full history (gitleaks) and static analysis (Semgrep) on every change, a weekly scheduled run, a ZAP baseline scan on staging, a software bill of materials per release, and a responsible disclosure programme. Container image scanning and an external penetration test are planned before launch.
- Abuse prevention
- Sign-up screening with a Cloudflare Turnstile check, sending limits and reputation monitoring, look-alike workspace names blocked, report-abuse links on hosted pages, malware scanning of attachments (ClamAV), and a takedown process.
- People
- One small team. Staff accounts use MFA, access to the server is by SSH key only with the keys held by the founder, and support access to a workspace needs your approval and is logged. Managed and encrypted laptops, background checks, security training and a quarterly access review are written down in our employee baseline and are being adopted, not yet audited.
Compliance roadmap
Status, as it is today
Certifications take time. We list what is in place, what is in preparation and what is not planned yet.
| Topic | Status | Details |
|---|---|---|
| GDPR | In place | EU hosting, data processing agreement, tools to export and erase an end user's data, retention policies and redaction. |
| Data processing agreement | Draft, final before launch | Our standard DPA with the EU Standard Contractual Clauses where needed, breach notice within 48 hours. |
| Subprocessors | Published | The full list, with purpose and location. Changes are announced 30 days in advance. |
| External penetration test | Not done yet | Scoped for the app, API, help centre, messenger and workspace isolation, and planned before the public launch. No test has been carried out, so there is no summary letter to share yet. |
| SOC 2 Type I | In preparation | Policies drafted and awaiting adoption (access, incident response, encryption, vendor management, employee security). No auditor engaged and no audit window set. |
| SOC 2 Type II | Planned | Follows Type I after the observation period. |
| ISO 27001 | Not planned yet | We will reconsider when customers ask for it. |
| Accessibility (WCAG 2.1 AA) | In progress | Automated axe-core checks over the app, help centre, messenger and sign-in on every end-to-end run; a serious or critical finding fails the build. The manual keyboard and screen-reader audit is still to come, and our accessibility conformance report (VPAT) is a draft. |
Subprocessors
Seven providers help us run HelpFalcon today: Hetzner (hosting, Germany), Cloudflare (DNS, proxy, TLS, the sign-up check and this status page), DigitalOcean Spaces (attachments and off-site backups, Frankfurt), Resend (email, EU region), Google Workspace (our own mailbox), Sentry (error reports, EU region) and Paddle (payments, sandbox only during the beta). The subprocessor list names each one, what it does, where it processes data and what the transfer basis is. Workspace owners get 30 days' notice of changes.
IP addresses to allow
If your systems only accept traffic from known sources, the addresses our webhooks, apps proxy and customer data connector come from are on the IP addresses page. They are the private beta addresses today and change once at the public launch, with 30 days' notice, both sets answering during those 30 days, and an email to workspace administrators.
Status and availability
Live availability and incident history: status.helpfalcon.com. It runs on Cloudflare's network, not on our server, so it still answers when we are down. Every minute it checks this website, the application, the API with its database, queue, cache and search, a workspace host, the help centre and the realtime hub, marks a check down only after two failures in a row, and answers machine readably at /api/status on the same host.
We do not offer an availability commitment during the private beta: the whole stack runs on one server, so a restart or a provider incident is visible downtime. The availability figures named on the pricing page apply from the public launch, on the production platform, and the service level agreement that describes them is still to be written.
Incident response
We have a written incident response process with severity levels, a named lead and a post-incident review for every serious incident. If a security incident affects personal data in your workspace, we tell you without undue delay and within 48 hours of becoming aware of it, with the facts you need for your own 72-hour notice under GDPR Article 33, and keep you updated until it is closed.
Report a vulnerability
Email security@helpfalcon.com. We acknowledge within one business day and do not take legal action against good-faith research. Rules and scope: responsible disclosure, machine-readable contact: security.txt.
Report abuse
Phishing, spam or harmful content on a help centre, community or messenger hosted by HelpFalcon, or email sent through us: use the "Report abuse" link at the bottom of that page or email abuse@helpfalcon.com with the URL or the full email headers. We review phishing and malware reports within 24 hours and take down confirmed cases.
Security reviews
We answer security questionnaires (CAIQ, SIG Lite or your own) and can share our draft policies and our draft accessibility conformance report (VPAT) under NDA. There is no penetration test report or audit report to share yet; the table above says where each one stands. Write to security@helpfalcon.com or sales@helpfalcon.com.