Security Statement — Zoravet (NIS2 / Cyberbeveiligingswet themes)

This statement describes Zoravet’s security posture in plain, non-technical terms, deliberately without naming specific infrastructure products, versions, or topology — detailed technical specifics are available to prospective and current customers under NDA or on request. It is written for clinics — our business customers — who increasingly ask their software suppliers to describe their security measures, including against the themes of the EU NIS2 Directive and its Dutch implementation, the Cyberbeveiligingswet. It is a transparency document, not a certification and not a contract; the binding data-protection commitments live in the Data Processing Agreement.

1. Scope and entity status (honest position)

What this covers: the Zoravet platform operated by Jensen Software — the pet-owner mobile app, the clinic web portal, the backend that serves them, and the cloud infrastructure that runs them.
NIS2 / Cyberbeveiligingswet applicability: Zoravet is a small SaaS provider. We align our practices with NIS2’s risk-management expectations proportionate to an organisation of our size and sector. We do not claim to be a designated “essential” or “important” entity under NIS2 / Cyberbeveiligingswet. Formal entity classification — including whether a clinic customer’s own NIS2 status flows any supplier obligations down to us contractually — is a determination we treat as one for legal counsel, not a legal conclusion we draw ourselves.
Why we publish this anyway: clinics that are themselves in scope (or that simply take supply-chain security seriously) reasonably ask suppliers to evidence sound security practice. This statement is our good-faith answer, aligned with NIS2’s risk-management themes (Art. 21): governance, access control, encryption, backup/continuity, incident handling, supply-chain security, and vulnerability handling.
Out of scope: clinic-side security (clinic devices, clinic networks, clinic staff behaviour) is the clinic’s responsibility. This statement covers Zoravet’s side.

2. Risk-management approach

Security is treated as a design constraint, not an afterthought. The platform is built multi-tenant with isolation between clinics enforced by the software mechanism itself (see section 3), so a configuration mistake fails closed rather than exposing another clinic’s data.
Infrastructure is defined as code and version-controlled, so the security configuration of the production environment is reviewable and reproducible rather than hand-built.
Changes are deployed via automated pipelines with automatic rollback; production deployments are additionally gated by a manual approval step. Changes go through a build process with review before merge, against an explicit backlog of hardening items.
Monitoring: the platform and its infrastructure are covered by continuous automated monitoring and alerting, notifying Zoravet’s operator of anomalies.
Data retention enforcement: the Dutch fiscal 7-year retention floor, and shorter operational-data windows (e.g. a 2-year window for the notification log), are enforced by an automated retention process.
Honestly stated gaps: load/scale testing is planned but not yet complete. We do not claim a 24/7 security operations centre or SOC 2 / ISO 27001 certification, and neither is on a committed roadmap today. An independent penetration test has not been performed, and we do not claim otherwise.

3. Access control, authentication and tenant isolation

Authentication is handled by a dedicated identity & access-management system, operated by Zoravet on our own EU infrastructure. Both the pet-owner app and the clinic portal authenticate through it; the backend validates signed tokens on every request.
Role-based access control (RBAC): users hold roles and fine-grained permissions (for example, separate permissions for finance, inventory, messaging). Staff see only the functions their role grants. Access follows least-privilege.
Tenant isolation between clinics is the platform’s central security property. Each clinic is a separate tenant; queries are automatically constrained to the caller’s clinic by a database-filter mechanism that is enforced centrally, applies on every execution path (web requests, background schedulers, event handlers), and fails closed when the tenant context or transaction is not established. Direct record loads are additionally verified on load and rejected if they belong to another clinic.
Independent isolation audit (July 2026): we ran a dedicated cross-tenant isolation audit with three independent reviewers as a release gate. Outcome: zero confirmed cross-tenant data leaks. The audit also drove targeted hardening (tightening bulk-update and role-assignment paths, and converting the last construction-only-safe entities to mechanism-enforced isolation). Test coverage of this property is being extended across remaining lower-risk endpoints; the behaviour is safe by mechanism, the additional tests are being backfilled.
Administrative access by Zoravet staff to the production environment is limited to what is needed to operate and support the service. Cloud secrets are held in a managed secrets store, encrypted, rather than in code or configuration files. Multi-factor authentication: our identity & access-management system supports MFA/TOTP; it is not enforced by policy for Zoravet operators or clinic staff today.
Audit logging: actions in the portal (for example, who edited a record and when) and authentication events are logged to support accountability.
Optional per-clinic network restriction (added July 2026): each clinic can restrict staff portal/API access to an allowlist of its own IP ranges (IPv4/IPv6 CIDR). Enforcement is server-side on staff endpoints only (pet-owner app traffic is unaffected), uses only the load-balancer-verified client address (client-supplied forwarding headers are not trusted), and fails closed for clinics that enable it. Individual staff members can be explicitly exempted by a clinic administrator (“access from anywhere”); everyone else remains bound to the allowlist. A safeguard prevents administrators from locking themselves out when saving the allowlist or removing their own exemption.

4. Encryption

In transit: all external traffic is served over HTTPS/TLS; plain-HTTP requests are redirected to HTTPS. Outbound email uses an encrypted transport. A documented minimum-TLS / cipher policy is a roadmap item.
At rest: the production environment encrypts data at rest — the database, file storage, and secrets are all encrypted using the cloud provider’s managed encryption. Specific key-management detail is available to customers on request.
The local development environment uses non-production stand-ins and is not representative of production security; nothing in this statement refers to development.

5. Backup, recovery and continuity

Database backups: the production database has automated backups with point-in-time recovery, geo-redundant within the EU — backups are replicated to a second EU region for regional-failure cover. Deletion protection is enabled on the production database.
Monitoring: the platform is covered by continuous automated monitoring and alerting, notifying Zoravet’s operator of anomalies.
Recovery testing: a documented restore rehearsal procedure exists and recovery procedures are tested periodically against production, with schema-integrity and data-integrity verification. Specific recovery-time and recovery-point objectives are available to customers on request.
Data is hosted with a leading cloud provider in EU (EEA) data centres, with backups replicated to a second EU region — your data stays in the EU/EEA.

6. Incident handling and customer notification

We maintain an internal breach-response approach: detect and triage, contain (revoke access, rotate secrets, isolate), assess scope (which clinics, which data categories, how many data subjects, likely consequences), notify, record, and review. The detailed, executable procedure — severity ladder, per-incident-class triage checklists (data breach / outage / data-integrity anomaly), communication templates, and the post-incident review template — is documented internally.
Incident owner: Zoravet is currently a single-founder operation. Mart (Jensen Software) is the named incident owner and responder for every severity, notified via the automated monitoring and alerting described in section 5. This is stated plainly rather than implying a team or rotation that does not exist; the internal runbook documents the escalation path for when the owner is unavailable.
Notification to clinics: where a personal-data breach affects a clinic’s data, Zoravet notifies the affected clinic without undue delay and at the latest within 48 hours of becoming aware. This aligns our commitment with the clinic’s own GDPR/AVG breach duties: the clinic, as controller, is responsible for notifying the Autoriteit Persoonsgegevens (and data subjects where required); Zoravet supports the clinic with the information it needs but does not notify the AP on the clinic’s behalf. The precise contractual timing lives in the DPA and is identical to the 48-hour figure above.
Every breach — including non-notifiable ones — is recorded in an internal log, with a post-incident review.

7. Supply-chain security (sub-processors)

Zoravet keeps its supplier footprint small and EU-first. See the Subprocessors page for the full, current list with purpose, data categories and safeguards.

Sub-processor	Purpose	Location / transfer
Amazon Web Services EMEA SARL	Cloud infrastructure: compute, database, object storage, transactional email, secrets	EU regions (primary and backup) — data stays in the EU/EEA
Google LLC (Firebase Cloud Messaging)	Mobile push-notification delivery (app only)	US-based; covered by the EU–U.S. Data Privacy Framework, with EU Standard Contractual Clauses as fallback under Google’s Data Processing Terms

Our identity & access-management system is self-hosted by Zoravet in the EU and is part of our own platform — it is not a third-party sub-processor.
Planned: Mollie B.V. (Netherlands) is a planned future sub-processor for clinic-invoice payment processing (hosted checkout only — no card data touches our servers). It is not yet active. Clinics will be notified in advance before activation, per the DPA’s sub-processor notice mechanism.
We impose data-protection obligations on sub-processors equivalent to those we owe clinics, and we notify clinics in advance of adding or replacing a sub-processor so they can object on reasonable grounds. The mechanism and notice period are set in the DPA (30 days).
This list is kept consistent with the app and portal privacy policies and the DPA. If they ever diverge, the DPA’s maintained sub-processor annex is authoritative.

8. Vulnerability handling and how to report a problem

We apply security patches to platform components and dependencies as part of ongoing maintenance.
Responsible disclosure: if you (or your security team) believe you have found a vulnerability in the Zoravet platform, please report it to security@zoravet.nl (falls back to support@zoravet.nl). Please give us reasonable time to investigate and remediate before any public disclosure. We do not currently operate a paid bug-bounty programme.
We ask reporters not to access, modify, or delete data belonging to clinics or their clients, and to stop at the point a vulnerability is demonstrated.

9. Review and updates

This statement is reviewed at least annually, and additionally after any material change to the platform’s architecture, sub-processors, or security posture.
Material changes relevant to clinics are communicated to clinic administrators. See Updates for the change log of this trust center.

Contact

Zoravet: Jensen Software, KvK 96526181, Oanjelaan 32, 1421 AK Uithoorn, Netherlands
General / privacy: support@zoravet.nl
Security reports: security@zoravet.nl