Security charter.

01Guiding principles

Neolia operates infrastructure that touches sensitive parts of the home: who opens the door, who rings the intercom, how energy is consumed. We treat security as a characteristic of the product, not as a compliance layer added afterwards. Four principles guide our decisions:

• Verified rather than announced: every measure described here corresponds to a check we can re-run on our servers and whose result we can show. We do not announce any arrangement we would not be able to demonstrate.
• Minimal surface: nothing is reachable from the internet that need not be. Databases, caches and administration interfaces refuse any connection from outside: in production they answer only on the private network that links our three machines; in development and staging, where there is no private network, each machine's firewall closes them. The check can be replayed by opening a connection from anywhere: it is refused.
• Least privilege, everywhere: people, services and devices have only what their role requires.
• Controlled hosting: the database is in Switzerland, the operating servers are in Germany, in the European Union, with an encrypted backup copy of the Swiss database. Both jurisdictions offer a level of protection recognised as equivalent (FADP, GDPR). We would rather say it in full: some providers are US‑based, for sending emails, notifications on your phone, collections and the machine-assisted reading of uploaded documents. They are named one by one in annex 2 of the data processing agreement.

This document covers the operating infrastructure, the mobile applications and the deployment cycle. It does not replace a third-party security review, which we have not yet commissioned. No external penetration test, no certification audit and no bug bounty programme has taken place to date: the first one we commission will be announced here, with its date.

02Hosting and location

The database is hosted in Switzerland, in the Zurich region. The operating servers are in Germany, in the European Union. An encrypted backup copy of the Swiss database is made there every night and kept for 14 days. Application data and infrastructure therefore rest on two separate providers, and each environment has its own machines. We would rather say it in full: these five machines are in the same data centre, in Nuremberg. They protect against the failure of a machine, not against the failure of a building.

Database, authentication, documents filed and signed partner contracts

Supabase, Zurich region (Switzerland)

Operating servers (production, development and test)

Hetzner Online GmbH, Nuremberg data centre, Germany (European Union). It processes the routing of intercom calls and their voice and image (not recorded), dwellings' telephone accounts, the image taken by the door station, meter readings and the meters' radio network, the tokens used to send notifications to phones, installer accounts and photos, technical logs, and an encrypted backup copy of the Swiss database, made every night and kept for 14 days

Website, forms and sales follow-up

Cloudflare (worldwide content network, European points of presence). The sales follow-up and the attachments of partner messages are kept there, in a store whose region is not set. Signed partner contracts have been kept in Zurich since 24 September 2026

Assisted reading, platform assistant and dictation proofreading

Anthropic, United States. A lease, an invoice, a bank statement, the photograph of a meter or a message exchanged in the platform is sent there to be read. The search bar assistant sends the question asked, a numerical summary of the property manager's portfolio and the search results. Proofreading a dictation sends the transcribed text and the list of names of the property manager's buildings, streets, localities and tradespeople, never the voice. Transfers are covered by Anthropic's data processing addendum, incorporated into its commercial terms, and by the standard contractual clauses adapted to Swiss law

Online appointment booking

Cal.com, European instance cal.eu, data kept in the European Union. The publisher closes this instance on 1^st November 2026; the solution chosen afterwards will be shown here before that date

Data centres

One certificate out of three is on file, and we would rather say which. Hetzner's, the operator of our servers, is in our possession: ISO/IEC 27001:2022, no. ZN‑2025‑35, issued by SOCOTEC Certification Deutschland, valid until 26 September 2028, and our five machines are tied by a measurement to the site it covers, Nuremberg. Supabase and Cloudflare publicly declare the same certification, but they release their attestations only on their enterprise plans: we therefore do not hold them, and we do not present them as settled. This is not a matter of time, it is a matter of subscription. In every case this certification is that of the data centre operator, never that of Neolia: Neolia is not certified under any standard

Location of identifying data

Switzerland for the database; Germany for technical operations and for the encrypted backup copy of the database; United States for the providers listed in Annex 2 of the processing agreement, including email sending, notifications and machine-assisted analysis of documents

Apart from the booking calendar shown on /demo, in its own frame, the page you are reading loads no third-party resource: no typeface, no animation library, no audience measurement. Everything is served by the page's own domain, so your IP address is disclosed to no one but the site's host.

03Encryption

We do not encrypt the disks of our operating servers. Disk encryption protects against a machine being stolen from the data centre, not against access obtained over the network; we would rather write it down than let anyone believe otherwise.

04Server access

The checks below apply to all our servers and are automatically re-verified every hour.

• Key-only login: password authentication is disabled, the system administrator account cannot log in remotely, and empty passwords are refused.
• Three authentication attempts at most, then automatic blocking of addresses that keep trying.
• Two independent firewalls, one at the host and one on each server, closed by default: each machine exposes only what its role requires.
• Databases, caches and administration interfaces out of reach from the internet, reachable only over the private network.
• Review of authorised keys: every key present belongs to an identified person or component, and an unknown key raises an alert.
• No secret in a world-readable file nor in a command line, where any user of the machine could see it.
• Audit log kept outside the database that produces it, so that access to that database cannot erase the record of what was done in it.

On the Client and resident side

• Separate profiles by role, each account seeing only the buildings that concern it.
• Call credentials and the session token are held in the phone's encrypted vault and excluded from cloud backups, so that a backup restored onto another device does not give access to the intercom.

05Monitoring and automatic response

Our servers are monitored continuously by four independent loops, which fix on their own what they know how to fix and raise an alert for the rest.

Two safeguards frame these automatic repairs. They are limited to three attempts per problem per day, after which the machine is frozen and a human is alerted, with a daily reminder for as long as the problem lasts. And anything touching remote access, a password login switched back on or a new public port appearing, is never fixed automatically but reported: a failed correction on remote access would turn the repair into an outage.

06Development and deployment

• Infrastructure described as code and versioned: firewalls, server configuration and deployments are reviewed, version-controlled files, not manual steps.
• Verified deployment of sensitive configurations: validity check before applying, snapshot of the previous state, functional test after restart and automatic rollback if the test fails.
• Staged rollout: a change goes through the test environment before production, and production refuses a rollout that has not already run in test.
• No production data copied onto a workstation, and no secrets in the code repository.

07Backups and updates

• Daily backups of the database and of the operating servers, with rotation, encrypted before they leave the machine that produces them. There is no replication between two Swiss regions, and we publish no recovery objective or maximum data loss in figures until a restore exercise has proven them.
• Security patches applied automatically across all servers.
• Controlled restarts: when an update requires it, servers restart one at a time, never together, and the operation is postponed while an intercom call is in progress.

08Incident management

We handle an incident in the same order every time: detect, contain, fix, restore, understand. Each incident leads to a written analysis, and to a summary sent to those affected when the impact goes beyond an isolated case.

Notification

• Clients (property managers): notification as soon as the incident is confirmed, by email to the technical account.
• Data subjects: if the breach presents a high risk, individual notification with practical advice.
• PFPDT / authorities: notified within the deadlines of Art. 24 nLPD and Art. 33 RGPD.

09Responsible disclosure

If you have found a vulnerability in our services, please report it to us in a coordinated way.

Ground rules

• Test accounts: on request to contact@neolia.ch, we open a test space on our pre-production environment, staging.manager.neolia.ch. It includes a fictitious property management agency, two accounts (a manager in charge and a staff member limited to one building) and two fictitious buildings, with no customer data at all. The accounts close by themselves after 30 days. Work with these accounts rather than in production.
• On the same request, we also open, in pre-production, a fictitious installation company on Neolia Pro and two fictitious homes whose credentials open the residents' web portal. These accounts close by themselves after 30 days.
• No attacks on real data: do not use any resident, property management or electrician account that is not your own, and stop as soon as the vulnerability is demonstrated.
• No DoS, no social engineering aimed at our staff or our partners.
• No public disclosure before a fix, or before 90 days, unless the flaw is actively exposed.