Trust & data protection

Your data, protected

Security is built into every layer of ZYNQ — from data encryption, through strict isolation between companies, to redundant infrastructure in Europe. Below we show, concretely, how we look after what you entrust to us.

Data encryption

We protect the most sensitive information with encryption — at rest and in transit.

Sensitive data encrypted in the database (AES-256-GCM)

Integration API tokens and credentials for marketplaces, FTP, SMTP or couriers are stored encrypted. Even with access to the database itself, they remain unreadable.

All traffic over HTTPS/TLS with enforced HSTS

The connection to the app is always encrypted, and our HSTS policy (one-year, with preload) ensures your browser never connects to ZYNQ over an unencrypted channel.

Passwords are never stored in plain text

User passwords are protected with strong, one-way hashing (bcrypt) — they can't be read, even with access to the database.

KSeF invoices encrypted per Ministry of Finance rules

Documents sent to the National e-Invoicing System are secured according to the Ministry of Finance requirements (AES-256 + RSA-OAEP).

Access control & data isolation

Every company sees only its own data, and every user only what they're allowed to.

Full isolation between companies

ZYNQ runs as a multi-tenant system where each organization's data is separated. Every query is scoped to your organization — there's no way to view anyone else's data.

Roles and permissions (OWNER / ADMIN / MEMBER / VIEWER)

You decide precisely who sees and can do what. Permissions are checked server-side on every request — they can't be bypassed from the browser.

Secure sessions and automatic sign-out

Sessions are kept in secure, signed cookies (__Secure-, SameSite). After a period of inactivity (30 minutes by default) you're signed out automatically.

Strong password policy

We require sufficiently strong passwords (at least 8 characters, upper- and lower-case letters and digits), making account takeover harder.

Application protection

The application is designed to defend against common attacks by default.

Security headers and CSRF protection

We apply a set of headers (including a frame-embedding block — no clickjacking, a Content-Security-Policy, and content-type sniffing protection) together with CSRF protection.

Every input validated and sanitized

All data entering the system is validated and sanitized against code-injection (XSS) attempts before anything is stored or displayed.

Webhook verification and rate limiting

Notifications from external systems are verified with a signature (HMAC, using a timing-safe comparison), and rate limiting protects against abuse.

Full audit trail and secret protection

We keep an event log and a sign-in history (IP address, device). Sensitive fields are stripped from responses — secrets never reach the browser.

Reliable infrastructure

Redundancy, isolation and backups — so your data stays safe and available.

Daily, automatic backups

The production database is backed up automatically every day, with several days of retention. If something fails, data can be restored — nothing is lost.

Redundancy with automatic failover

Traffic is served by redundant application servers behind a health-checked load balancer. If one stops responding, another takes over automatically — with no downtime for you.

Private network and layered firewalls

Servers communicate over an isolated private network, and the database is reachable only from inside it — never directly from the internet.

Private file storage and encrypted secrets

User files live in private object storage with public access fully blocked, and environment secrets are encrypted — there are no plaintext credentials, even during deployment.

Data in the European Union — GDPR-aligned

The infrastructure sits in an EU data center (Germany). The application runs with least-privilege access and the system is continuously monitored.

Quality & process

Security isn't only technology — it's also discipline in how changes are made.

Over 950 automated tests

A suite of unit and end-to-end tests (over 950 in total) guards correctness on every change to the code.

Eight mandatory gates before production

Before any change reaches production it must pass a full set of checks: code analysis, type checking, unit and E2E tests, a dependency security audit, a database-migration guard, a test-coverage check and the build.

Deployments with vulnerabilities are blocked

An automatic security audit of third-party libraries stops a deployment if it finds known vulnerabilities. Test coverage cannot drop — new code must have tests.

Every change reviewed, reproducible deployments

No change reaches production without review (a Pull Request) — no shortcuts. Builds are deterministic and reproducible, and regression tests run on a regular schedule.

Questions about security or data processing?

We're happy to help. On request we also share detailed technical information, a Data Processing Agreement (DPA) and support for your team's security questionnaire.

or read our full data-processing details in the Privacy Policy.