Security and privacy
Secure because it is built that way – not because we say so.
Everything on this page is implemented and documented in the product. We promise nothing you could not verify in the installation.
Login and permissions
Who may do what – and how is that enforced?
- Login through a built-in identity service (Keycloak), invisible to users; protection against brute-force attacks
- Two-factor login (TOTP app) per user or mandatory for everyone; minimum password length and session timeout configurable
- Permissions per module and function (read, edit, bill, configure …), bundled into roles; roles can be limited to one location
- Permissions may only be granted where the grantor holds them
- Cashiers with their own PIN or card at the till; the till client only works with the configured server address
- Disabled modules are invisible: no apps, no routes, no jobs
Traceability and GoBD
Documents and register data stay the way they were created.
- Audit log across all modules: who changed what and when – stored in the same transaction; a database trigger prevents later changes or deletion
- Posted documents are immutable; corrections only via credit note or cancellation; archive as PDF/A
- Gapless number ranges per company or location; numbers of disabled modules continue after re-enabling
- Register: cloud TSE (fiskaly), DSFinV-K and TSE export, cash book, procedural documentation; aborts and cancellations signed correctly
- Handover, return and rental contracts as well as purchase documents as PDF/A-3 with embedded data and SHA-256 checksum, locked afterwards
- Archive mode: register, leasing, used bikes, rental, time tracking, insurance and assembly stay readable and exportable after module or licence end (§ 147 (6) AO)
- Retention periods with statutory minimums; deletion periods respect them
Data protection (GDPR)
Tools for access, erasure and documentation are part of the kernel.
- Record of processing activities (Art. 30) from the privacy declarations of all modules – including disabled ones
- Request register with deadlines; access and data portability (Art. 15, 20) across all modules
- Erasure (Art. 17) with holds from retention duties; pseudonymisation in the audit log instead of gaps
- Automatic deletion periods per data category, configurable within statutory limits
- Consents with wording, version, time and source; double opt-in for marketing, withdrawal stored as an objection
- ID checks at handovers only as a note – no copy, no number (§ 20 PAuswG)
- AI assistant: no data of natural persons sent to the model; contact details from inputs only as placeholders
- Public pages (booking, order status, digital receipt) with rate limits, hashed codes and automatic expiry
Technical hardening
What the server does to fend off attacks.
- Secrets (client secrets, API keys, tokens) stored encrypted only (AES-256-GCM); master key rotatable, the app reminds you after 12 months
- Content Security Policy with nonce and without unsafe-inline, strict security headers, no resources from third-party servers
- Rate limits per route: global per IP, public per IP, authenticated per user – tighter for writes
- SSRF protection: integrations only reach public addresses; private networks must be explicitly allowed
- Input validation with numeric limits against overload from absurd values in forms, e-invoices and import files
- Widgets can be embedded only by explicitly allowed origins (frame-ancestors); nothing else is embeddable
- Transfer logs to lessors and shops without secrets and tokens
Operations, backup, restore
An installation you can back up and restore.
- Every dealer gets their own installation with its own database – on your own Linux server or operated by us
- Scripted installation: random secrets, automatic HTTPS, one-time setup link for the administrator
- Scripted backup: both databases, file store and configuration with SHA-256 checksums; restore also onto a new server
- Updates with database and realm migrations at startup; “What’s new” in the desktop after every update
- Only the login pages are reachable from outside; admin consoles are blocked, internal services stay in the Docker network
- Operation behind Cloudflare optional, with firewall rules that only let Cloudflare addresses through
Where does the data run?
Servelta is not a multi-tenant cloud. You decide where your installation runs:
- On your own server (on-premises or with a hoster of your choice) – requirements are Linux, Docker, a domain and ports 80/443
- Operated by us as a dedicated instance just for you – location and data processing agreement are discussed in the demo meeting
- Third-party services only come into play when you set them up: fiskaly (TSE, legally required), Exchange 365 (mail), SMS providers, lessors, shops, 3CX, OpenAI (only with the AI assistant)
What we do not claim
Servelta carries no certification such as ISO 27001, and we quote no figures we cannot substantiate. The properties described here can be verified in the documentation and in the installation; notes for tax advisers and data protection officers ship with every module.
See Servelta in your own shop?
We walk you through Servelta using your workflows – point of sale, workshop, leasing or all of it. No obligation, at a time of your choosing.