Where your data lives
- Application servers and the database run in Google Cloud's Belgium region (europe-west1), inside the European Union.
- Some of the providers we use for sign-in, email, error logging and AI are abroad (Firebase Authentication, Resend, Anthropic, Sentry, OpenStreetMap Nominatim, Stripe). Each one, what it's used for and which data it accesses is listed on the Subprocessors page.
- Transfers abroad are made with the appropriate safeguards in Article 9 of Law No. 6698.
Separation between companies
Zenoheld is a multi-tenant service: many companies use the same infrastructure, but none of them can see another's data.
- Every record is stamped with a company ID. Separation is enforced not in the application but in the database, with row-level security: even if the application has a bug, the database won't return another company's rows.
- This rule is mandatory for every table; a new table carrying a company ID can't be created without a separation decision.
- Within a group of companies, your own permission settings decide who sees which company's data.
Who can access what
- Permissions are granted by role and level: at screen, action and field level. Approval by amount threshold and visibility by department can be defined.
- National ID, SGK registration and passport numbers, IBANs, and salary and wage fields are shown masked to anyone without permission; you decide which roles see them in full.
- Segregation of duties rules are built in: whoever enters an invoice can't approve it, and whoever makes a payment can't close the reconciliation.
- IP address and network restrictions can be set per user.
- Sessions with no activity for 30 minutes are closed; the user is warned at minute 25.
- Managers periodically review and approve access; temporary permissions granted in an emergency are time-limited and approved, and every action taken with them is recorded.
Sign-in
- Users sign in with a Google account or with email and password. Passwords aren't stored in our database but in the authentication service (Firebase Authentication).
- Two-step verification: in addition to the password, the 6-digit code from the authenticator app on the phone (Google Authenticator, Microsoft Authenticator, 1Password…) is asked for. The code is checked on the server: someone who knows the password but doesn't have the code can't reach any data. Single-use recovery codes are issued against losing the phone; repeated wrong codes temporarily lock the account.
- Your company can make two-step verification mandatory for people who sign in with a password, or for everyone; an employee who hasn't set it up sees the setup screen at their next sign-in. You decide how many days a device is remembered (or that it's never remembered).
- For people who sign in with a Google account, Google's own two-step verification also applies; if you wish, you can make our code mandatory for them too.
- Administrators see active sessions, sign-in history and suspicious sign-ins, and can close a session remotely.
Audit trail
- Every change is recorded: old value, new value, who, when. The history is read from the record's own screen.
- Records aren't physically deleted, they're deactivated; they can be read back in an audit.
- Accounting vouchers can't be changed once posted; corrections are made with a reversing entry.
- Who accessed personal data and when is also kept separately in the KVKK access logs.
Our access
- Our support team enters your account only when support requires it: with a time-limited, justified session.
- Every support session is recorded with who, on whose behalf, for what reason and for how long; it's available to you on request.
- We don't sell your data, we don't use it for advertising, and we don't use it to train AI models.
Encryption
- All connections are encrypted (HTTPS / TLS).
- The database and files are stored with Google Cloud's default disk encryption.
- Entries in the Password Center (service passwords, two-step verification keys) are additionally encrypted at application level.
- Card details never reach our servers.
Backups and continuity
- The database runs on Google Cloud's managed database service (Cloud SQL).
- Planned maintenance is announced in advance inside the product.
- Because records aren't deleted, a record deactivated by mistake can be restored.
Payment security
- Subscription payments are taken through iyzico, a licensed payment institution; card details are entered only on its secure form and stored in its systems.
- We never see or store the card number.
AI
- AI features send content to the model provider only when they're used, and only what that task needs.
- Answers are produced from data within the user's permissions; AI can't see a record the user isn't allowed to see either.
- The model suggests, a person approves the record. Your content isn't used for model training.
KVKK
The product comes with tools to help you meet your own KVKK obligations:
- Data inventory, data subject request and KVKK access log screens.
- Retention policies and an approval queue for destroying personal data whose retention period has ended.
Our relationship with you is governed by the Data Processing Agreement. See also the KVKK Privacy Notice and the Privacy Policy.
Certificates
- Our infrastructure is on Google Cloud; Google Cloud's data centres are certified to ISO 27001, ISO 27017, ISO 27018 and SOC 2.
- Zenoheld itself doesn't yet hold an independently audited certification. Every item on this page is what the product does today.
Vulnerability disclosure
If you think you've found a security vulnerability, write to [Vulnerability disclosure email]. We'll acknowledge your report within 3 business days and keep you informed until it's fixed. We ask that you don't disclose it publicly before it's fixed and don't access other customers' data.