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 in two layers, in the application and inside the database 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: automated retention processes delete or anonymise data on fixed schedules: for example the notification log after 2 years, import source files 90 days after an import, and stored idempotency keys (which stop a payment or credit being booked twice) after 24 hours. Fiscal records are kept for at least the 7-year Dutch legal period and veterinary-medicine records for at least 5 years; the process enforces the 7-year minimum as a floor, and deleting these records after their legal periods is planned but not yet automated. Audit trails are kept for seven years; technical logs are deleted after 30 days and web-traffic logs after 90 days.
AI features: the AI summary of a pet’s medical history for clinic staff is off until a clinic switches it on. Inference runs in the EU only; inputs are not stored by the AI service and are not used to train models. AI output is a drafting aid for clinic staff, never an automated decision. Separately, when Zoravet migrates a clinic’s data from its previous system, the same EU-only service suggests which differently spelled breed names mean the same breed. It receives only the breed spellings and their species, has no clinic setting because it is part of every migration, and its suggestions are confirmed or changed by the person running the migration before they are applied.
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.
Database-level enforcement (since September 2026): in addition to the application-level mechanism, tenant isolation is enforced inside the database itself: clinic-owned records are protected by row-level, default-deny rules (a small number of child records that are only reachable through a protected parent record rely on the application-level layer), and the application connects with a restricted database role that does not own the tables and is bound by these rules. A missing or faulty filter in application code therefore does not by itself expose another clinic’s data. A small, inventoried set of platform-level and pre-login operations (for example subscription billing, or resolving an enrolment code before a clinic is known) switches to an elevated mode for a single database transaction instead of using a general bypass. Because the application itself sets the clinic context and makes that switch, this layer protects against mistakes in application code, not against a fully compromised application.
Cross-tenant isolation audit (July 2026): we ran a dedicated cross-tenant isolation audit 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. The database-level layer above was added afterwards as defence in depth.
Administrative access by Zoravet staff to the production environment is limited to what is needed to operate and support the service. Where Zoravet support staff need access to a clinic’s data inside the application (for example during onboarding), access is granted per clinic, limited to a defined role, can be time-limited, and every change they make (creating, editing or deleting a record) is recorded in that clinic’s audit trail. 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: changes in the platform (who created, edited or deleted a record, and when) and security events around sign-in on shared devices (for example PIN unlocks and lockouts) are logged to support accountability; viewing a record is not logged individually.
Error reporting: when something goes wrong in the clinic portal, an error report is sent only to our own servers. It is scrubbed of personal details (such as email addresses, quoted text, IDs, tokens and numbers) before it is logged, stays in the EU with our other technical logs, and is deleted after 30 days. No third-party error-tracking service is used.
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 (AWS)	Cloud infrastructure: compute, database, object storage, transactional email, secrets	EU regions (primary and backup): data stays in the EU/EEA
Amazon Web Services EMEA SARL (AWS): Amazon Bedrock	AI inference for the AI medical-history summary (off until a clinic switches it on) and for breed-name de-duplication during data migration	EU only; not retained by the AI service, not used for model training
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.
Already in use (our own billing): separately from that planned feature, Mollie already collects Zoravet’s own subscription fees from clinics by SEPA direct debit. That is Zoravet’s own billing data (legal entity name, billing contact, IBAN/mandate reference, invoice amounts) as controller, not clinic patient or client data.
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