Data processing agreement (DPA)

1. Summary

• Who is who. The practice is the controller of the data of its patients and staff. Sysqo Limited is the processor: it processes this data only to provide MedAdmin, on the practice's instructions (art. 28 GDPR).
• Where. On Hetzner servers in Germany (EU). Each practice has its own database.
• Who else has access. Only the sub-processors in Annex 2. Any change is announced 30 days in advance; the practice may object and may terminate without penalty.
• Incidents. We notify the practice within 48 hours of becoming aware, so that it can notify ANSPDCP (the Romanian supervisory authority) within the 72-hour deadline.
• At the end. 30 days for export, then deletion; backups are deleted by rotation. We confirm deletion in writing, on request.

The parties

1. [name of the practice], tax identification number (CUI) [tax ID of the practice], with its registered office at [registered office of the practice], email [email of the practice], telephone [phone of the practice], as controller (the "Controller");
2. Sysqo Limited (registered name SYSQO LIMITED), Company number 14417339, with its registered office at 18 Old Field Road, Pencoed, Bridgend, Wales, CF35 5LJ, United Kingdom, email gdpr@medadmin.ro, as processor (the "Processor").

This Agreement is concluded by electronic acceptance at sign-up or when a new version takes effect and forms part of the MedAdmin Terms and Conditions (the "Main Contract"). The version, date, time, IP address and the user who accepted are recorded.

2. Definitions

The terms "personal data", "processing", "controller", "processor", "data subject", "data concerning health" and "personal data breach" have the meaning given in Regulation (EU) 2016/679 ("GDPR"). "Sub-processor" means another processor engaged by the Processor in accordance with art. 28(2) and (4) GDPR. The "Service" is MedAdmin, as described in the Main Contract.

3. Subject matter and duration

3.1. The Processor processes personal data on behalf of the Controller, exclusively for the provision of the Service, as described in Annex 1.

3.2. This Agreement lasts as long as the Main Contract, plus the return and deletion period in section 12.

4. The Controller's instructions

4.1. The Processor processes the data only on documented instructions from the Controller, including with regard to transfers, unless required to do so by Union or Member State law; in that case it informs the Controller before processing, unless the law prohibits this.

4.2. The following constitute documented instructions: the Main Contract, this Agreement, the settings made by the Controller in the Service and written requests sent by ticket or email. Examples of settings that are instructions: activating SMS, e-Factura (Romanian e-invoicing), CNAS (National Health Insurance House) reporting, the patient portal, online payments, automated imaging analyses, the mobile and desktop applications, sending a document by email.

4.3. The patient portal. When it activates the patient portal, the Controller instructs the Processor: (a) to maintain a central index of cryptographic fingerprints (HMAC) of the patient's telephone number, the carer's telephone number and the personal numeric code (CNP), used only to link records to the patient's portal account; (b) to display to the patient and to persons linked to them as carers the data published by the Controller in the portal; (c) to record in the Controller's log the actions taken from the portal. The patient's portal account is a separate relationship, in which the Processor is the controller (see the Patient Portal Privacy Policy).

4.4. The Processor immediately informs the Controller if, in its opinion, an instruction infringes the GDPR or other data protection provisions.

4.5. The Controller is responsible for the lawfulness of the processing, for the existence of a lawful basis, for informing patients and for obtaining consents where required.

5. Confidentiality of personnel

5.1. The Processor ensures that persons authorised to process the data have committed themselves to confidentiality or are under a statutory obligation of confidentiality.

5.2. The Processor's personnel access the Controller's data only for support at the Controller's request or for incident management, through a support session which: is read-only by default; requires a reason; allows writing only with an additional reason and the two-factor authentication code of the support operator; is logged and is visible to the Controller.

6. Security of processing

The Processor applies the technical and organisational measures in Annex 3, in accordance with art. 32 GDPR. It may update them without reducing the overall level of protection.

7. Sub-processors

7.1. The Controller grants a general written authorisation for the sub-processors in Annex 2.

7.2. The Processor notifies the Controller by email and in the application at least 30 days before adding or replacing a sub-processor. The Controller may raise reasoned objections within this period. If the parties do not find a solution, the Controller may terminate the Main Contract without penalty, with a pro rata refund of the paid and unused period.

7.3. The Processor imposes on sub-processors, by contract, data protection obligations at least equivalent to those in this Agreement and remains fully liable to the Controller for their performance.

8. Transfers

8.1. The Controller's data is hosted in the European Economic Area (Germany).

8.2. The Processor has its registered office in the United Kingdom. Access to the data by its personnel from the United Kingdom (support, administration) is a transfer covered by the European Commission's adequacy decision in respect of the United Kingdom (art. 45 GDPR).

8.3. Sub-processors in groups with companies in the United States (Google, Stripe, GitHub) may transfer data to the United States only on the basis of the EU–US Data Privacy Framework (certified companies) or of the standard contractual clauses adopted by the European Commission (art. 46 GDPR).

8.4. Data concerning health is not transferred outside the EEA, with one exception under the Controller's control: documents that the Controller chooses to send to a patient by email pass through Google Workspace (Annex 2). The Controller can avoid this flow by sending documents through the patient portal.

[TO BE CONFIRMED (DE CONFIRMAT): the email flow with medical attachments. Recommendation: the "Europe" data region in Google Workspace, if the edition allows it, or replacing the attachment with a secure link; the exception in 8.4 would then disappear.]

9. Assistance with data subjects' rights

9.1. The Service provides the Controller with tools for patients' rights: export of the record (PDF and JSON), rectification, restriction, anonymisation and deletion, subject to archiving periods; the record access log; management of consents and their withdrawal.

9.2. If the Processor receives a request directly from a data subject concerning the Controller's data, it forwards it to the Controller within 5 working days and does not respond on the merits without instructions.

9.3. For requests that the Controller cannot resolve itself from the Service, the Processor assists it within 10 working days at most.

10. Assistance with arts. 32–36 GDPR

The Processor assists the Controller, taking into account the nature of the processing and the information available, in ensuring security, notifying breaches, carrying out data protection impact assessments (DPIA) and prior consultation with ANSPDCP, by providing the available technical documentation (description of the flows, of the measures in Annex 3 and of the sub-processors).

11. Personal data breaches

11.1. The Processor notifies the Controller without undue delay and within 48 hours at most of becoming aware of a personal data breach affecting the Controller's data, so that the Controller can meet the 72-hour deadline towards ANSPDCP (art. 33 GDPR).

11.2. The notification includes, to the extent known: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed and the contact person. Information not available at first is provided in phases, without undue delay.

11.3. The Processor immediately takes the measures necessary to limit the effects, preserves the evidence and documents the incident. It does not notify ANSPDCP or the data subjects on behalf of the Controller without the Controller's instruction, unless the law requires it.

12. Return and deletion of data

12.1. Upon termination of the Main Contract, the Controller may export the data for 30 days (PDF and JSON, plus uploaded files). On request, within the same period, the Processor provides a complete archive of the Controller's database.

12.2. After this period, the Processor deletes the Controller's database and the files in storage. Backups on the server are deleted by rotation within 30 days at most; those in external storage, if activated, in accordance with Annex 3. On request, the Processor confirms the deletion in writing.

12.3. The Processor may retain data only if the law requires it, and only to the extent of that obligation.

12.4. Local data on the Controller's workstations, phones and tablets (the desktop application, the agent, the mobile applications) is deleted when the device is disconnected or uninstalled; the Controller is responsible for disconnecting devices before termination.

13. Audit

13.1. The Processor makes available to the Controller the information necessary to demonstrate compliance with art. 28 GDPR: this Agreement, the description of the measures in Annex 3, the list of sub-processors and their audit reports or public certifications.

13.2. The Controller may carry out an audit, directly or through an independent auditor bound by confidentiality, at most once a year (and at any time after a security breach affecting it), with 30 days' notice, during working hours, without affecting the security or data of other clients. The audit is normally carried out remotely and on the basis of documents. The costs are borne by the Controller, unless the audit finds a significant breach attributable to the Processor.

14. Liability

The parties' liability is determined in accordance with art. 82 GDPR and the Main Contract. The limitation of liability in the Main Contract does not apply to intentional or grossly negligent breaches of this Agreement.

15. Final provisions

15.1. In the event of a conflict between this Agreement and the Main Contract, this Agreement prevails in matters of data protection.

15.2. This Agreement is governed by the same law as the Main Contract. [TO BE CONFIRMED (DE CONFIRMAT): the same decision as in the Terms, section 20; recommendation: Romanian law.]

Annex 1. Description of the processing

Annex 2. Authorised sub-processors

Updated public list: Sub-processors and hosting.

Recipients that are not sub-processors: ANAF (e-Factura) and the health insurance funds (SIUI, the health insurance IT system), to which the Service transmits data only on the Controller's instruction, as authorities towards which the Controller has its own obligations.

Providers inactive today, which will be added only with the 30-day notice in section 7.2: an error reporting service (Sentry, configured without personal data) and an invoicing service (SmartBill), which would process only the Controller's invoicing data.

Annex 3. Technical and organisational measures

Data isolation

• A separate database for each practice; on each request the application opens only the database of the authenticated practice.
• Each practice's files are kept in a dedicated, non-public directory; downloads are made only through the application, after checking permissions, or through short-lived signed links.
• Backups can be restored individually, per practice.
• Patient portal: the central database holds only the account, the links and the HMAC fingerprints; medical data is read from the practice's database on each request, only for active links.

Encryption

• In transit: HTTPS (TLS) for all traffic, with HSTS; the mobile and desktop applications communicate only over HTTPS.
• At rest, at field level: the CNP, allergies, chronic conditions, medication and integration secrets (for example ANAF tokens) are encrypted with the application key (AES-256), kept separately from the database; searches by CNP are made through an HMAC fingerprint per practice.
• Backups: archives encrypted with AES-256 using a passphrase kept separately from the server.
• Passwords: hash only (bcrypt); PINs: hash only.
• On devices: the mobile applications keep offline data in an AES-256 encrypted database (SQLCipher), with the key in the Keychain or Keystore, excluded from backup; the desktop agent's tokens are protected with DPAPI (Windows), and those of the desktop application in Windows Credential Manager or the Keychain.
• [TO BE CONFIRMED (DE CONFIRMAT): server disk encryption. Hetzner Cloud servers do not encrypt the volume by default; sensitive data is protected through field-level encryption and backup encryption. Recommendation: full disk encryption at the next server migration, or moving medical files to object storage with server-side encryption.]

Access control

• Roles and permissions per practice (account holder, administrator, doctor, nurse, reception, accountant), following the principle of least privilege; confidential notes (for example in psychology) are visible only to their author.
• Two-factor authentication (TOTP) mandatory for account holders, administrators and the Processor's team; the account holder may require it for the whole team; recovery codes; trusted device for at most 30 days.
• Attempt limiting: 5 failed attempts per account and IP address lock the account for 15 minutes, with an email alert to the account holders.
• Screen lock after inactivity (15 minutes by default), unlocked with a PIN or password; sessions with expiry, individual closing and "sign me out everywhere".
• Mobile devices and desktop workstations have individual tokens, revocable from the platform; revocation deletes local data at the next connection.
• Access by the Processor's personnel: read-only support session, with a reason, logged (section 5.2); access to servers only with named SSH keys and through the administration panel protected by two-factor authentication.

Logging and monitoring

• Patient record access log (who, what, when, from where), including downloads from the portal and the applications, available to the Controller.
• Log of authentications, lockouts, exports, deletions, permission changes and support sessions.
• Monitoring of availability and scheduled tasks (checked every minute), with alerts.
• Technical server logs are kept for 14 days; activity logs for 12 months.

Availability and resilience

• Daily full backups (at 03:00) of the central database, of all practice databases and of the files, encrypted, kept for 30 days.
• Optional external copy in object storage in the EU (Hetzner Object Storage), with a lifecycle rule. [TO BE CONFIRMED (DE CONFIRMAT): activation of the external copy. Today the backups are kept on the same server as the data; recommendation: activating the external copy in Hetzner Object Storage, in another data centre (for example Nuremberg), with 35 days' retention.]
• Restoration per practice, with prior saving of the current state; monthly restoration test recommended.
• Zero-downtime deployment and quick rollback to the previous version.

Minimisation and retention

• SMS messages and push notifications contain no medical data; links sent to patients are signed, expire and, where appropriate, require a verification code.
• The practices' public pages and the portal do not use tracking cookies; usage statistics contain no personal data.
• Automated imaging analyses run on the Processor's servers, without transmitting images to third parties; the Controller's data is not used to train models.
• Error reporting, if activated, does not send personal data.
• Development and demonstration environments use only fictitious data.

Organisational measures

• Confidentiality undertakings for staff and collaborators.
• Documented procedure for managing incidents and security breaches.
• Assessment of providers before contracting and annual review of the list of sub-processors.
• Secure development: code review, automated tests, up-to-date dependencies.
• [TO BE CONFIRMED (DE CONFIRMAT): annual staff training on data protection and the annual incident response exercise. Recommendation: carry them out and document them from the first year; until then, do not mention them as existing measures.]