Data processing agreement.

01Purpose

This data processing agreement (hereinafter « DPA ») sets out the conditions under which Neolia Sàrl (hereinafter the « Processor ») processes, on behalf of the controller (hereinafter the « Controller »), personal data relating to residents, visitors and users of buildings equipped with Neolia services.

The DPA is an inseparable annex to the Neolia GTS and to each operating agreement. In the event of divergence on data processing, it prevails. It continues to apply for as long as the Processor processes data for the Controller, including for the basic intercom service maintained free of charge after an operating agreement ends or during a suspension for non-payment.

02Roles and designations

Four separate roles. (1) The holder of the contract is its commercial party and its debtor. (2) The Controller determines the purposes and means of processing residents' data; in principle this is the owner, or the property management company according to its mandate. (3) The authorised persons are those whom the Controller authorises to manage occupants in the management interface. (4) The Processor and its sub-processors process the data on instruction.

• The holder is not the Controller merely because it signs or pays. A builder that funds the service, including through builder-funded months, does not thereby obtain any access to residents' data.
• The Controller and the authorised persons are designated in writing before processing begins, in particular before a building's first activation. The Processor creates no resident account and processes no resident data before this designation. This DPA creates no mandate between the owner and the property management company: they confirm their respective roles themselves.
• Change of holder or property management company. The transfer amendment confirms the Controller and the authorised persons. Current instructions remain valid until the Controller changes them. The outgoing property management company's access rights are revoked on the effective date.
• Basic service. After an operating agreement ends, the Controller remains the one last designated, and the property management company keeps limited administrative access to the operations needed for that service (Article 12 of the GTS).

For processing that falls within Neolia's own operations (client accounts, invoicing, aggregated usage statistics, product improvement), Neolia acts as a separate controller, governed by its privacy policy.

03Processing, by subscribed service

Processing depends on the services subscribed. The operating agreement or the subscription states which ones. Annex 1 describes each processing activity and its retention period, and Annex 2 the sub-processors for each group.

• Required for the connected building: routing door calls to the app, an ordinary telephone or a loaned screen; door opening and the door opening log; meter reading and individual billing; forwarding of technical alarms; residents' accounts and notifications; support.
• Property management platform, where subscribed: management of leases, documents and messages, including assisted document analysis.
• Optional integrations: connectors to third-party services, which receive nothing until the Controller or the resident has activated them.
• Services not activated: no data is processed for a service that is neither subscribed nor activated.

The duration of processing corresponds to the term of the contract, extended by the time the basic intercom service is running and by the retention periods in Annex 1.

04Controller instructions

The Processor processes the data only on documented instructions from the Controller. The GTS, the operating agreement, the DPA and the settings of the management interface constitute the standard instructions. Any additional instruction is given in writing by an authorised person of the Controller.

The Processor informs the Controller without delay if it considers that an instruction infringes the nLPD, the RGPD where applicable, or other applicable provisions.

05Staff confidentiality

The Processor gives access to personal data only to the persons who need it to perform the contract, under the principle of least privilege. Before gaining access, each of them is bound by a written confidentiality obligation and receives a written instruction describing what they may consult. The list of authorised persons at the Processor is kept up to date and provided to the Controller on request.

06Technical and organisational measures

The Processor implements technical and organisational measures appropriate to the risk, described as they exist on the date of this version, limits included, in Annex 3 and in the security charter. It does not promise any measure that is not in place. In particular, encryption is not applied throughout: Annex 3 states what is encrypted and what is not. Any improvement is announced by a new version of the DPA.

07Sub-processors

The Controller gives general authorisation for the use of the sub-processors listed in Annex 2, for the services subscribed or activated. The Processor:

• imposes on each sub-processor data protection obligations equivalent to those of this DPA;
• remains liable to the Controller for the performance of these obligations;
• informs the Controller of any addition or replacement with a notice period of 30 days, which gives a right to object on reasoned grounds;
• states for each one, in Annex 2, the status of its safeguards. A sub-processor marked « to be put in place » receives no data on a building's residents for a service put into service after this version, as long as its processing agreement and, where applicable, the transfer safeguard are not established. Where such a sub-processor already serves a service in operation, Annex 2 says so.

08International transfers

Management data (accounts, property management, buildings, dwellings, leases, uploaded documents, messages, call history and door opening log) is stored in Switzerland, in the Zurich region of the database host. Technical operating data is processed in Germany, in Nuremberg, a country that the Federal Council recognises as providing adequate protection: 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.

Data may be transferred to sub-processors established in the United States (Annex 2). The United States is recognised as adequate only for organisations certified under the Swiss-U.S. Data Privacy Framework (Annex 1 to the OPDo). For each provider, Annex 2 states whether this certification or another safeguard within the meaning of Art. 16 nLPD is established, to be confirmed or missing. The Processor does not claim that a safeguard exists until it has proof of it; it does not systematically pseudonymise before transfer: the email sending service receives a name and an address in clear text, and notifications carry a device identifier.

09Requests from data subjects

The Controller responds to requests to exercise rights (access, rectification, erasure, data portability, objection). The Processor assists it: a request received at contact@neolia.ch is forwarded to the Controller, and the Processor carries out its instructions within a time that allows the Controller to respond within the legal deadlines, and at the latest within 10 working days.

• What residents do themselves. In the app, a resident with an account exports their data and requests its erasure. The following are then erased: their profile, their account, their registered devices, their call history and images, their forwarding number, their messages and their documents.
• What is kept, and why. The dwelling and its intercom subscription, which belong to the Controller, and the consumption readings needed for statements, which are the Controller's records. The Controller decides what happens to them according to its own obligations.
• Persons without an account. An occupant without an account, or a person whose data appears only in the Controller's management records, exercises their rights with the Controller, which instructs the Processor.
• An erasure reaches backup copies as they rotate out, within the period set in Article 12.

10Personal data breach

In the event of a data breach affecting the processing covered by this DPA, the Processor notifies the Controller without undue delay after discovering it. The notification includes:

• the nature of the breach, the categories and approximate number of data subjects;
• the likely consequences of the breach;
• the measures taken or proposed to remedy it and limit its effects.

The Processor assists the Controller with its obligations to notify the FDPIC (Art. 24 nLPD) or the competent supervisory authority and, where applicable, the data subjects.

11Audit and proof of compliance

The information in this DPA and its annexes is based on a document review of the Processor's code, configuration and documentation. It does not result from an external technical audit, and no external audit report exists on the date of this version. On request, the Processor makes available to the Controller:

• the record of processing activities carried out for the Controller;
• the current security charter and, if any exist, external audit reports, subject to a confidentiality undertaking;
• the processing agreements and transfer safeguards of the sub-processors that it holds.

The Controller may, at its own cost and with 30 days notice, have an on-site or documentary audit carried out by an independent third party accepted by both parties, limited to one audit per year, except after a serious incident.

12End of the contract and what happens to the data

The deadlines below are counted in days from the end of the main contract:

1. From day 0 to day 90: the Controller's workspace stays available for reading. The Controller exports its data there itself, free of charge and as many times as it wishes, in a structured and readable format. On written request, the Processor provides that export within 30 days;
2. Day 75 and day 85: the Processor sends the Controller two written notices, fifteen days and then five days before the erasure;
3. Day 90: the Processor erases everything it processes on the Controller's behalf, data and files. Backup copies disappear as they rotate out: at most 90 days later for the Processor's backups, and 7 days for those of the database host;
4. After day 90: only the Processor's accounting records remain, that is its invoices to the Controller and their supporting documents, kept for ten years from the end of the financial year (Art. 958f para. 1 CO), together with the proof of erasure and the access log of this archive (Art. 8 Olico).

A dated deletion certificate is provided to the Controller on request.

Basic intercom service exception. When an operating agreement for a connected building ends, the basic intercom service provided for in Article 12 of the GTS remains active. As long as it is running, the Processor retains, by way of derogation from day 90, only the data needed for it to function: the list of units, the active occupants with their call names, their means of receiving calls and their access rights, and the property management company's accounts needed for the limited administrative access. This DPA continues to apply to that data, and the Processor erases it when the basic intercom service stops.

The Controller's own retention obligations remain its own. The leases, the statements and the supporting documents of its buildings are its accounting records under Art. 958f CO: it must keep them for ten years, and it is during those 90 days that it must take them away. After that, the Processor no longer has them.

AnnexesDPA annexes

Annex 1. Processing activities and retention periods

Periods applied by the Processor's code on the date of this version, unless stated otherwise. None of these periods results from a specific legal obligation, except for accounting records.

Annex 2. Sub-processors

a. Required for the connected building

b. Property management platform, where subscribed

Searching the uploaded documents is done on the Swiss servers: no document leaves them to be indexed.

c. Optional integrations, only when the Controller or the resident activates them

These services receive nothing as long as nobody has connected the corresponding account. When an account is connected, its credentials are sent to the service so that it can respond. For all of them, safeguards are to be put in place before they are offered in a new building.

d. One-off services and services not activated

e. Recipients that are not sub-processors

• The Controller's own system. Where the Controller connects its own software to Neolia, residents' messages and the links to their incident photographs are sent to the address it has entered. The country of destination is the one it has chosen, and it answers for it.
• The Controller's mailbox and calendar. Where the Controller connects its mailbox or its calendar (Microsoft 365, Google, iCloud, Yahoo, Infomaniak or another provider), Neolia retrieves and sends its e-mails and appointments with that provider, which the Controller has chosen and with which it has its own contract. To find the right server, Neolia also queries, with the domain name of the address only, two public name resolution services (Cloudflare and Google) and the configuration database of Mozilla Thunderbird: they receive neither the full address nor any content.
• Swiss public registers. The Federal Statistical Office (RBD), swisstopo and Zefix receive the address or company name entered in a search. Switzerland.
• esm.sh. Code library loaded at runtime by a few functions. Receives no personal data.

This page carries the up-to-date version of the list. Any addition or replacement is notified to the Controller with the 30 days notice set out in article 7.

Annex 3. Technical and organisational measures

Status established from the code and configuration on 16 September 2026, by document review. For details, see the security charter.

• Encryption in transit: the apps, the platform and the websites are served over HTTPS; device messages travel over TLS. The browser-based wall screen encrypts its audio and video. Call signalling and the audio and video streams of calls between the mobile app and the servers are not encrypted to date.
• Encryption at rest: the disks of the operating servers are not encrypted. The database hosted in Switzerland is encrypted by its operator according to that operator's own statements, which the Processor has not audited.
• Backups: daily, encrypted with a key whose private part is not on the servers, kept as 14 to 30 copies and for 90 days at most. They stay on the machine they protect, in the same data centre: no off-site copy to date. Missed-call images are not backed up.
• Server access: key only, password authentication disabled, two independent firewalls, control replayed every hour.
• Access management: least privilege, logging, review of authorised keys, audit log kept outside the database that produces it.
• Monitoring: intrusion detection every five minutes, hourly posture check and verified repair.
• Testing: dependency scans and continuous automated checks. No external penetration test and no external technical audit to date.
• Continuity: no recovery objective is stated in figures until a restore exercise has proven it.