Trust Center

How we handle your data — in plain terms.

Zonitix touches your identity and access data, so we hold ourselves to one rule: your data lives on a dedicated instance that’s yours alone, and everything the platform does is logged and verifiable. No claims we can’t back up.

Architecture

Your data stays inside one dedicated instance.

Your systems

Okta / Entra / Google
AWS · Azure · GCP
Slack

Your dedicated
single-tenant instance

Sensitive data encrypted · local AI · isolated from every other customer

You get

Provisioning & revocation
Tamper-evident audit trail
Readiness evidence (PDF/Excel)

Your directory data, credentials, and logs never leave your instance to be pooled with other customers. The one shared service is Apple MDM (preview), which only you opt into — see Subprocessors below. Each instance is deployed in the region we agree with you — an EU region when you need your data to stay in the EU, or one closer to your team when you do not.

Two ways to host this kind of software

Zonitix runs a separate instance for each customer. Most hosted software runs one shared application for everyone. These are different designs with different trade-offs; this is how ours is built.

Where it runs
A server that runs only your instance
Your data
In your instance's own database
Stored credentials
Encrypted field by field, on your instance
API keys
Held on your instance
Audit logs
In your instance's database, access-controlled
AI processing
Runs on your instance, no outside AI service
Employee lifecycle workflows
Included

The one shared service Zonitix runs is Apple device management (preview, and only if you turn it on); what it holds and the access we hold to your server are set out on this page.

Data protection

Single-tenant isolation
Every customer runs on their own dedicated VPS. The data in your instance is never co-mingled with another customer or placed on a shared, multi-tenant database. The one shared service is Apple MDM (preview): if you use it, your enrolled Macs’ management records sit in a Zonitix-operated MDM service, kept in a separate tenant per customer — see Subprocessors below.
Encryption at rest, scoped precisely
Sensitive fields — secrets, MFA data, integration credentials, selected HR fields such as compensation — are encrypted with AES-256-GCM at the data layer. Candidate résumés and offer documents are encrypted at rest as files, and everything shipped off-box for backup is AES-256-GCM ciphertext. The rest of the database is not application-encrypted, and we make no full-disk encryption claim for the VPS.
Encrypted in transit
All traffic is served over TLS.
Keys on your instance
Encryption keys live on your own instance. The platform refuses to boot in production if the encryption key is missing.
Passkeys and strong MFA
Admin sign-in supports WebAuthn passkeys (FaceID, TouchID, YubiKey) and TOTP multi-factor, so a stolen password on its own does not get an attacker in.
Trusted-device registration
A device you approve can skip the second factor for up to 30 days — per user, capped, and revocable for every device at once from the console. Network reach itself is gated separately by the gateway’s IP and geo allow-list.
Local, private AI
The AI features run on a local model on your instance. No resume, log line, or directory record is sent to an external cloud AI.
Tamper-evident audit trail
Every access grant and removal is logged with a correlation ID to a hash-chained audit trail, anchored daily to a checkpoint that is shipped off the server once your backup bucket is connected, so the chain can be corroborated independently. A one-click integrity check returns a green/red result and an auditor export. This is tamper-evidence — any change is detectable and provable, not a claim of un-hackability — and it is baseline on every tier. (Free-form evidence files you upload are not themselves hash-chained; the chain covers the system audit log.) How long entries stay in the live log is your administrator’s setting (Security Settings → Audit Log Retention: 90 days by default and at minimum, up to ten years); older entries are archived to your backup bucket first, and nothing is pruned until that archive is confirmed off the server.
Live health and telemetry
A system-health view watches every service on your instance, and centralized structured logs give you one place to review access, errors, and activity.

How your instance is run

We provision, host and monitor it
We stand up your dedicated instance and publish the releases for it, and there is nothing for you to install. Your administrator applies updates and runs backups and restores, and we do not log in to your server unless you ask us to. Day to day, both run one way. Monitoring: every five minutes your instance sends us one HMAC-signed check-in — the signature authenticates its identity (licence key, hostname); the same check-in also carries the IP address the instance reports, its customer and company identifiers, the version and release it is running, a user count, the state of its own updates (the update channel it follows, whether it updates automatically, and the result and time of its last maintenance window, with the release that window applied and the one before it), and, where you run our device agents, a count of how many managed devices are on each agent version. It also sends the number of active users, the server’s CPU count and memory, and a capacity figure derived from them; we discard those on receipt and do not store them. Those operational figures are the only thing we keep from it — the latest set, plus a per-check-in history (time, IP address, hostname, version, user count) deleted after 30 days — never the data inside your app. Updates: we publish a release; when your administrator applies it from System → Updates, an agent on your host fetches and applies it on a fixed, hardcoded sequence. We do not log in to do it.
Backups to a bucket you own
Database backups — a nightly dump, a weekly base backup and the continuously archived write-ahead log — upload to an S3-compatible bucket or an Azure Blob Storage container in your account, and so does a nightly archive of the files the database does not hold: signed documents, compliance evidence and candidate résumés. That file archive is only ever shipped encrypted. For AWS S3 you set only a region; for Azure you give the storage account and container; for Cloudflare R2, Backblaze B2, Wasabi, GCS or MinIO you paste your provider’s HTTPS endpoint into the admin panel — and only an HTTPS endpoint that resolves to a public address is accepted, so the backup destination can never be pointed at an internal service. On native AWS S3 we explicitly request server-side encryption (SSE-S3); the other destinations encrypt at rest by their own default, which we rely on rather than enforce — worth confirming against your provider’s settings. We recommend enabling object-lock/versioning so a snapshot can’t be silently wiped. A safety backup runs before every update, scheduled restore drills confirm those backups can actually be restored (a backup nobody has restored is only a hypothesis), and deleting backup history from the app takes a second person’s approval.
Updates applied when you choose
We publish each Zonitix release to your instance, and an administrator applies it from System → Updates; your data and configuration carry over untouched. Server security patches are applied from the same page, by hand or on a schedule you set — automatic patching is off until you turn it on, and it never applies an application release. No forced upgrades.
The access we hold, and how we use it
We keep one SSH deploy key with root access to your server, held in our deployment system. It is how we provision the server and, at the end, how we tear it down; routine updates do not use it. Having that key means we could reach your server, so we do not claim otherwise. What we commit to (Terms §5) is how we use that key: once your instance is deployed we do not use it to access your instance or your data unless you have asked us to, in writing — to help with an update or investigate something. We also hold the account with the hosting provider your server runs on; as the account holder we can reach your server’s provider console, rescue mode and snapshots without that key. Our deployment tooling has no connection to that account and does not use its console, rescue mode or snapshots. When you want our help inside the app, there is a narrower route than either: an administrator can grant a dedicated support sign-in from Security Settings → Support for 1 to 72 hours — read-only by default, with fresh credentials and MFA for each grant, every action audited, and revocable at any time.
If something goes wrong, you hear it from us
If we become aware of a security incident affecting your instance or your data, we tell you directly — an email to your registered admin contact — without undue delay, with what we know and what we are doing about it. We are not yet putting a specific contractual notification window in writing: that number is being finalised with counsel, and we would rather commit to telling you promptly and plainly than quote a deadline we cannot yet stand behind. Same “stated honestly” rule as the availability card.
Availability, stated honestly
Your instance runs on a dedicated VPS. Its database keeps periodic base backups plus a continuously-archived write-ahead log, which is what a point-in-time recovery needs; there is no in-product way to run a point-in-time recovery today, and the restore drills you schedule confirm those backups actually restore. We do commit a support response time — a first response within 12 business hours on Core and Team and 8 on Advanced. What we don’t promise yet is availability: there is no uptime percentage and no guaranteed recovery time. Backups run every night and, once you connect a storage bucket you own, are copied off the server — with a bucket connected, at most about a day of data is at risk. On every plan, restores are self-serve: the restore tooling is built into your instance (one administrator requests a restore and a second approves it), and it restores any backup that is still on your server. Zonitix does not perform restores for you on any plan. A backup that now exists only in your bucket, a point-in-time recovery and a restore after a lost server cannot be done from that screen today. We’d rather run the machinery and prove it than quote an availability figure we can’t yet stand behind; a formal uptime SLA is on our roadmap.
Compliance posture

Honest about where we are.

We’re an independent, early-stage company and we don’t claim certifications we don’t hold. What we do give you today is the architecture and the audit evidence that support your SOC 2, ISO 27001, and HITRUST CSF programs. Here’s exactly what’s in place and what’s next.

Today
  • Single-tenant isolation
  • Field-level AES-256-GCM for sensitive data, encrypted résumé files and backups, TLS in transit
  • Tamper-evident, hash-chained audit trail with one-click verification
  • Built-in Security Lab self-audit scanner (Advanced plan and up)
  • This Trust Center + disclosure policy
In progress
  • Documented data-flow & subprocessor register
  • Formal internal control mapping to SOC 2 criteria
  • Independent security review of the codebase
Planned
  • Third-party penetration test with published summary
  • SOC 2 Type I, then Type II
  • Customer-facing status page

Timelines firm up as we grow; we’ll report progress here rather than pre-announce dates we can’t commit to.

Report a vulnerability

Found a security issue? Email security@zonitix.com with details and steps to reproduce. We aim to acknowledge every report within 5 business days, then investigate and keep you posted. We won’t pursue good-faith researchers who follow this policy and avoid privacy violations or service disruption.

View security.txt

Subprocessors

Short, and we’d rather print it than make you ask:

Contabo GmbH
hosts your dedicated VPS, in the region agreed at provisioning. Listed because storing personal data is processing it, not because their staff read it.
Cloudflare, Inc.
carries traffic to this site and terminates TLS for it, so anything you type here — including a demo request — passes through their network. By default your instance is also reached through a Cloudflare tunnel, so its traffic is terminated at Cloudflare’s edge too; tell us if you need a different ingress.
Our account email (Google Workspace by default).
The mail we send you about your Zonitix account — account invitations, sign-in verification codes and password/MFA-reset messages, billing and subscription notices, instance set-up and decommission notices, and signature requests — goes over SMTP through the provider we configure for our own systems.
Your instance’s email provider (the one you configure).
Mail your instance sends — its sign-in and reset messages and the candidate and employee messages the product sends, such as application and rejection notices, offer letters, e-signature links, and onboarding and credential-delivery mail — goes through the SMTP provider your administrator sets up in Security Settings → Email / SMTP, under your own account with that provider. No relay is configured on a new instance and we do not choose one, so employee and candidate personal data in that mail passes through the provider you pick.
Google Calendar (only if you load it).
Our demo-booking calendar is not loaded until you click “Load Google calendar”. If you load it, Google receives the booking details you enter and may set its own cookies.
Zonitix Apple MDM service (only if you use Apple MDM).
Apple MDM is a preview feature run from one Zonitix-operated service (mdm.zonitix.com, hosted by Contabo and reached through Cloudflare) that is shared across customers, with each customer’s records in a separate tenant, rather than on your dedicated server. It holds the enrolled Macs’ identifiers (serial number, UDID), the device certificates and push and bootstrap tokens Apple’s MDM protocol keeps for each Mac, the local account names and inventory the Macs report (device information, security status, installed profiles), enrolment and check-in records, the commands sent to them — such as profile installs, lock and wipe — and their results, any FileVault recovery keys escrowed to it (stored encrypted), and the Apple push certificate you upload. Those records are erased from the live service when your instance is decommissioned; that service’s own backups are not rewritten, so copies can remain in them until those backups expire.
No third-party analytics or tracking.
We ship no third-party analytics, tag manager or tracking script on this site or in the product, and we sell no data to anyone. We count website visits ourselves, in aggregate and without cookies or stored IP addresses; the Privacy Policy lists exactly what is kept.

Other endpoints your instance contacts. Sealing a document with the built-in e-signature sends a hash of it — never the document — to a public timestamp authority (DigiCert by default). Security Lab discovery looks up your domain name in the public certificate-transparency search crt.sh. Vulnerability data comes from CISA and FIRST: the CISA list is a plain download, and FIRST is sent the CVE identifiers being scored, including any found in your Security Lab scans, and no personal data.

Those are the parties and endpoints we know of that handle or transmit your data, and we’ll give you notice before the sub-processors change. If you need it as a signed register for a vendor review, ask and we’ll confirm it in writing against our live configuration on the day — a page we maintain by hand is not the artefact your auditor should be relying on.

Private AI

AI help — without sending your data to the cloud.

Zonitix runs its AI on a local model on your dedicated, single-tenant instance. It helps screen anonymized résumés, refines interview feedback, drafts role competencies, summarizes a report’s findings in plain English, drafts workflow steps from a plain-English description, turns a plain-English question into a log or cloud-map search, and explains security findings — without a single résumé, log line, or directory record ever being sent to an external cloud AI. The model is deliberately small, sized to run on your instance’s CPU, so treat it as an assistant whose output a person reviews, not as a frontier model. An administrator can switch every AI feature off for the whole instance, or limit AI to people who hold a specific permission. Nothing is shipped off to the big cloud models. Which of these you get follows your plan: report analysis, log search and workflow drafting are on every plan; the candidate and interview features come with hiring, from Team; cloud-map search and explaining security findings come with those modules, from Advanced.

  • Screen & anonymize résumés
  • Screen candidates on skills
  • Refine interview feedback
  • Generate role competencies
  • Summarize report findings
  • Recruitment chat assistant
  • Draft workflow steps from a description
  • Search logs in plain English
  • Explain security findings

Your data is not sent to an outside AI service.

Technical Specifications

Built for high scalability, observability, and security following modern microservices standards.

  1. 01Microservices Architecture
  2. 02Modular API Gateway (http-proxy)
  3. 03Distributed Tracing (x-correlation-id)
  4. 04Stateful JWT Validation & Gatekeeper Pattern
  5. 05Centralized Engineering Standards (Shared Models)
  6. 06AES-256-GCM Secret Encryption

Questions your security team needs answered?

Bring your questionnaire. You’ll talk to the engineer who built the platform — not a sales script.