Data Processing Agreement — Tenant Clinic Template
Controller ↔ Processor agreement under GDPR Art. 28(3). Signed between each tenant clinic (controller) and
{{LEGAL_ENTITY}}(processor). v1 drafted 2026-05-15 for counsel review under F11.0.5. The inner DPA uses the same shape with both parties ={{LEGAL_ENTITY}}.
Counsel-review status
Developer-drafted v1. Counsel reviews binding wording, confirms Romanian-law overlay (Law 190/2018, Law 95/2006 retention), redlines clauses against ANSPDCP practice. Not for execution until D2 + D7 from the counsel engagement are received.
Data Processing Agreement
This Data Processing Agreement ("DPA") forms part of the agreement between:
| Party | Role | Identifier |
|---|---|---|
| Controller ("the Clinic") | Tenant clinic operating on the RestartiX platform under its own subscription | {{CONTROLLER_LEGAL_ENTITY}}, {{CONTROLLER_REGISTRATION_NUMBER}}, {{CONTROLLER_REGISTERED_ADDRESS}} |
| Processor ("RestartiX") | {{LEGAL_ENTITY}} operating the RestartiX multi-tenant SaaS platform | {{LEGAL_ENTITY}}, CUI {{CUI}}, {{REGISTERED_ADDRESS}} |
This DPA is effective from {{EFFECTIVE_DATE}} and governs the Processor's processing of Personal Data on behalf of the Controller in connection with the Controller's use of the RestartiX platform under the underlying Subscription Agreement (the "Main Agreement").
This DPA prevails over any conflicting terms in the Main Agreement to the extent of the conflict. Where any term used herein is defined in GDPR (Regulation (EU) 2016/679), it has the meaning given in GDPR.
1. Definitions
| Term | Meaning |
|---|---|
| Applicable Data Protection Law | GDPR; Romanian Law 190/2018; Romanian Law 95/2006 (medical-records overlay); any other data-protection law applicable to the Controller's establishment or to the data subjects (each as amended). |
| ANSPDCP | Autoritatea Națională de Supraveghere a Prelucrării Datelor cu Caracter Personal (Romanian supervisory authority). |
| Annex | An annex to this DPA, each forming an integral part. |
| Authorised Sub-processor | A third party engaged by the Processor to process Personal Data under this DPA, as set out in Annex C and as updated per Section 6. |
| Data Subject Request | Any request from a Data Subject to exercise rights under Chapter III of GDPR. |
| Personal Data | Personal data (as defined in GDPR Art. 4(1)) processed by the Processor on behalf of the Controller in connection with the Main Agreement. The categories and types are set out in Annex A. |
| Personal Data Breach | A breach of security as defined in GDPR Art. 4(12). |
| Platform | The RestartiX multi-tenant SaaS platform comprising the Clinic app, Portal app, Console app, API, and supporting services. |
| Services | The services provided by the Processor to the Controller under the Main Agreement. |
| Sub-processor | Any processor engaged by the Processor under Section 6. |
| TOMs | The technical and organisational measures set out in Annex B. |
2. Scope, roles and instructions
2.1 Roles. The Controller is the controller in respect of the Personal Data; the Processor processes the Personal Data on behalf of the Controller. The categories of Personal Data, categories of Data Subjects, purpose, duration, and nature of processing are described in Annex A.
2.2 Documented instructions. The Processor shall process Personal Data only on documented instructions from the Controller. The Main Agreement, this DPA (including Annexes), and the configuration of the Services made by the Controller via the Platform (e.g. consent purposes published, RBAC role assignments, integrations enabled) together constitute the Controller's documented instructions. The Processor shall not process Personal Data for any other purpose unless required by EU or Member State law to which the Processor is subject; in such case the Processor shall inform the Controller of that legal requirement before processing unless that law prohibits such information on important grounds of public interest.
2.3 Unlawful instructions. The Processor shall promptly inform the Controller if, in its opinion, an instruction from the Controller infringes Applicable Data Protection Law.
2.4 Compliance. Each Party shall comply with its obligations under Applicable Data Protection Law applicable to its role.
2.5 Joint controllership. The Parties do not intend to act as joint controllers. The Platform's processor-boundary commitment — including the break-glass primitive for cross-tenant access — is the mechanism by which the Processor maintains the boundary in operations. Any Processor-side processing that would amount to controllership (e.g. the Processor determining purposes and means for cross-tenant patient analytics on identifiable data) is excluded; cross-tenant analytics are conducted on anonymised data only.
3. Processor obligations
3.1 Confidentiality. The Processor shall ensure that persons authorised to process Personal Data are bound by a duty of confidentiality (contractual or statutory) and have received training appropriate to the Personal Data they process.
3.2 Security. The Processor shall implement the TOMs set out in Annex B, taking into account the state of the art, costs of implementation, and the nature, scope, context, and purposes of processing, as well as the risk of varying likelihood and severity to the rights and freedoms of Data Subjects. The TOMs include encryption in transit and at rest, pseudonymisation where applicable, multi-tenant isolation enforced at the database level (Row-Level Security), restricted personnel access via documented RBAC + the break-glass pattern, immutable audit logging, and tested backup-and-restore procedures.
3.3 Assistance with Data Subject Requests. Taking into account the nature of the processing, the Processor shall, by appropriate technical and organisational measures, assist the Controller in fulfilling its obligation to respond to Data Subject Requests under Chapter III of GDPR. The Platform provides the Controller with self-service tooling to respond to:
- (a) Access requests (Art. 15) — via export of the Data Subject's records
- (b) Rectification (Art. 16) — via the staff-facing editing surfaces
- (c) Erasure (Art. 17) — via the anonymisation flow that preserves the audit trail per Art. 17(3)(c) and Law 95/2006 retention obligations
- (d) Restriction (Art. 18) — via consent-withdrawal per purpose and account state controls
- (e) Portability (Art. 20) — via structured JSON / CSV export
- (f) Objection (Art. 21) — via consent management
Where the Platform cannot self-service a request, the Processor shall provide reasonable assistance to the Controller without undue delay. The Processor shall not respond to a Data Subject Request directly except to acknowledge receipt and route the request to the relevant Controller; where the Data Subject's identity is associated with multiple Controllers on the Platform, the Processor shall route to each Controller in scope without disclosing the existence of other relationships.
3.4 Assistance with Art. 32–36 obligations. Taking into account the nature of processing and the information available to it, the Processor shall assist the Controller in ensuring compliance with Art. 32 (security), Art. 33–34 (breach), Art. 35 (DPIA), and Art. 36 (prior consultation), specifically by:
- providing the Controller with the TOMs documentation (Art. 32 assistance)
- notifying the Controller of Personal Data Breaches per Section 7 (Art. 33–34 assistance)
- providing on request the security and operational information necessary for the Controller to complete its DPIA (Art. 35 assistance) — including the Processor's own DPIA covering the Platform infrastructure
3.5 Return or deletion. On termination of the Main Agreement, the Processor shall, at the Controller's choice, return all Personal Data to the Controller or delete the Personal Data, except where storage is required by Union or Member State law. Where deletion is selected, the Processor shall confirm completion in writing within 90 days of termination, save for:
(a) Audit-log records, retained for the period specified in Annex A
(b) Data subject to Law 95/2006 medical-records retention, anonymised rather than deleted per Art. 17(3)(c)
(c) Backups, which are technically immutable. Layer-2 database backups are written to object storage under Object Lock in COMPLIANCE mode with a seven-year retention, which no administrator — including the Processor and the cloud provider — can shorten, alter or delete. Personal Data within a backup taken before termination therefore persists until that retention expires on its own.
The Processor's commitments in respect of that archive are: (i) it is used solely for disaster recovery, with no analytical, operational or support read path into it; (ii) a restore is an incident-response event, logged, and followed by re-application of every deletion, erasure and anonymisation recorded since the backup was taken, before the restored system serves traffic; and (iii) no step is taken to extend the retention.
The Controller is expected to reflect this position in its own privacy notice to Data Subjects. The Processor's deletion confirmation under this Section states it expressly.
3.6 Demonstrating compliance. The Processor shall make available to the Controller all information necessary to demonstrate compliance with this Section 3 and Art. 28 GDPR, including:
- the current version of this DPA
- the current version of the TOMs and ROPA
- the sub-processor list and any updates
- the breach playbook summary
- ANSPDCP DPO designation reference once notified
The Controller may exercise audit rights as set out in Section 8.
4. Personnel access
4.1 The Processor maintains a documented Role-Based Access Control system. Personnel access to Personal Data is granted on a least-privilege basis according to the role's documented duties; access is logged.
4.2 Platform personnel access to a Controller's identifiable Personal Data is gated by the break-glass pattern: scoped to the affected organisation, time-bound (≤ 4 hours), justified in writing, recorded in the immutable audit log, and notified to the Controller in real time via in-platform notification + email to the registered admin contact. Background reads of Personal Data outside this pattern are not technically possible.
4.3 Personnel access logs are retained for at least six (6) years (consistent with the audit-log retention in Annex A) and are available to the Controller for review on request.
5. International transfers
5.1 The Processor shall not transfer Personal Data outside the European Economic Area except as set out in Annex C (Sub-processors) and subject to one of the safeguards permitted by Chapter V of GDPR.
5.2 Where a sub-processor is located outside the EEA, the Processor enters into the Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914) Module 2 (controller-to-processor) or Module 3 (processor-to-processor as applicable). The Controller hereby authorises the Processor to enter into such Standard Contractual Clauses on the Controller's behalf, where the Processor is acting in the role required by the Module concerned.
5.3 The Processor shall conduct and document a Transfer Impact Assessment for each such transfer per the TIA and make it available to the Controller.
6. Sub-processors
6.1 General authorisation. The Controller grants the Processor general authorisation to engage Sub-processors for the processing of Personal Data, subject to this Section 6.
6.2 Current Sub-processors. The current list of Authorised Sub-processors is set out in Annex C and at sub-processors.
6.3 Notice of changes. The Processor shall notify the Controller of any intended addition or replacement of a Sub-processor at least thirty (30) days before the change takes effect. Notice is given via in-platform notification to the registered admin contact + email.
6.4 Objection right. The Controller may object to a new Sub-processor on reasonable data-protection grounds within twenty (20) days of notice. The Parties shall in good faith seek a resolution. If no resolution is reached within a further fifteen (15) days, the Controller may terminate the Main Agreement on thirty (30) days' notice, without penalty in respect of unconsumed prepaid Services.
6.5 Emergency sub-processor changes. For Sub-processor changes required to respond to a security incident, the Processor may make the change immediately and notify the Controller within seven (7) days, with rationale.
6.6 Sub-processor obligations. The Processor shall impose on each Sub-processor data-protection obligations substantially equivalent to those imposed on the Processor under this DPA. The Processor remains liable to the Controller for any failure by a Sub-processor to fulfil its data-protection obligations.
7. Personal Data Breaches
7.1 Notification to Controller. The Processor shall notify the Controller of any Personal Data Breach affecting the Controller's Personal Data without undue delay and in any event within forty-eight (48) hours of becoming aware of the breach. Notice shall include, to the extent then known and as it becomes known:
- (a) the nature of the breach (categories and approximate number of Data Subjects and records affected)
- (b) the name and contact details of the DPO or other contact point
- (c) the likely consequences of the breach
- (d) the measures taken or proposed to address the breach and mitigate its possible adverse effects
The Processor's breach playbook describes the operational procedure end-to-end.
7.2 Subsequent information. Where it is not possible to provide all of the information in 7.1 at once, the Processor shall provide it in phases as it becomes available, without further undue delay.
7.3 No direct regulator notification. The Processor shall not notify ANSPDCP or other supervisory authorities of a breach affecting the Controller's Personal Data on the Controller's behalf; the Controller remains responsible for Art. 33 notification to its supervisory authority. The Processor's notification under 7.1 is calibrated to enable the Controller to meet its 72-hour deadline under Art. 33(1).
7.4 Processor-level breaches. Where a breach affects the Processor's own personal data (its employees, contractors) the Processor handles notification to its own supervisory authority directly and is not within the scope of this Section 7.
8. Audit
8.1 The Processor shall make available to the Controller all information necessary to demonstrate compliance with Art. 28 GDPR and shall allow for and contribute to audits, including inspections, conducted by the Controller or another auditor mandated by the Controller, on the following terms:
- (a) The Controller's audit right may be exercised no more than once per twelve (12) months unless triggered by a Personal Data Breach affecting the Controller's data or by a documented regulatory inquiry concerning the Controller.
- (b) The Controller shall give the Processor at least thirty (30) days' written notice of an audit, save in the case of a triggering event under (a) above.
- (c) Audits shall be conducted during normal business hours, with reasonable measures to avoid disruption to the Services and other clinics on the Platform.
- (d) The auditor shall execute a non-disclosure agreement with the Processor on the Processor's standard terms before access is granted.
- (e) The auditor shall not access other clinics' Personal Data or any data not in scope of the audit.
8.2 In lieu of an on-site audit, the Processor may satisfy its obligations under 8.1 by providing the Controller with the Processor's most recent independent third-party security report (e.g. ISO 27001, SOC 2 Type II) once such reports are produced. At launch the Processor has not yet completed independent certification; the Processor commits to obtain ISO 27001 certification within twenty-four (24) months of launch and to make subsequent reports available to the Controller.
9. Liability
The Parties' liability for breach of this DPA shall be governed by the liability provisions of the Main Agreement, subject to the limitations and exclusions therein. Nothing in this DPA limits liability for Data Subject claims under Art. 82 GDPR; the Parties' apportionment of such liability between themselves shall follow Art. 82(4)–(5) GDPR.
10. Term and termination
This DPA continues for the term of the Main Agreement. Sections 3.5 (Return or deletion), 7 (Breaches) for breaches occurring during the term, 8 (Audit) for the audit periods covered, and 9 (Liability) survive termination of the Main Agreement to the extent necessary for their respective purposes.
11. Governing law and jurisdiction
This DPA is governed by the laws of Romania and disputes are subject to the exclusive jurisdiction of the courts of {{JURISDICTION_CITY}}, Romania, save where Applicable Data Protection Law requires otherwise (in which case the law and jurisdiction of the Data Subject's habitual residence prevails for matters concerning that Data Subject).
12. Order of precedence
In case of conflict, the order of precedence is:
- This DPA (excluding Annexes)
- The Annexes
- The Main Agreement
- Any other document referenced by the Parties
13. Modifications
This DPA may be modified only by a written instrument signed by both Parties, save that:
- (a) Annex C (Sub-processors) may be updated by the Processor in accordance with Section 6
- (b) Annex B (TOMs) may be updated by the Processor unilaterally to enhance the level of protection; downgrades require Controller consent
- (c) Where Applicable Data Protection Law changes (e.g. revised SCCs published by the European Commission), the Parties shall execute an updated DPA reflecting the change without undue delay
Signatures
| Party | Signature | Date |
|---|---|---|
For the Controller — {{CONTROLLER_LEGAL_ENTITY}} | __________________ | __________________ |
| Name / Title | __________________ | |
For the Processor — {{LEGAL_ENTITY}} | __________________ | __________________ |
| Name / Title | __________________ |
Annex A — Description of the processing
Subject matter
Hosting and operation of a multi-tenant telerehabilitation SaaS platform on behalf of the Controller, including patient identity management, consent management, treatment plan management, exercise-program delivery, adherence telemetry, audit logging, and supporting infrastructure.
Duration
For the term of the Main Agreement plus the retention periods specified below.
Nature and purpose of processing
| Activity | Purpose |
|---|---|
| Patient identity management | Onboard, authenticate, and maintain patient accounts on the Controller's behalf |
| Consent management | Record, evidence, and renew patient consents per the Controller's published purposes |
| Clinical records management | Store and serve the Controller's clinical records (treatment plans, session logs, instruments, signed forms) |
| Adherence telemetry | Capture and aggregate session-completion, video watch percentage, exercise drop-off, and self-reported clinical instruments |
| Communications | Deliver transactional email and in-platform notifications |
| Audit logging | Record all state-changing operations and personnel access for the purpose of demonstrating accountability |
| Backup and disaster recovery | Preserve the integrity and availability of Personal Data per the TOMs |
Categories of Data Subjects
- Patients of the Controller
- Staff of the Controller (admins, specialists, support)
- Third parties named in patient records (caregivers, emergency contacts, where collected)
Categories of Personal Data
- Identity and contact: name, email, phone, DOB, locale, postal address (where collected)
- Health data (Art. 9 GDPR): self-reported VAS pain, RPE, adherence, free-text comments, clinical correspondence, treatment plan content, prescriptions (where applicable), signed forms (including consent evidence)
- National identification number: CNP (Romania) where collected — subject to additional safeguards under Law 190/2018 Art. 4
- Consultation media: live audio and video of a video consultation, where the Controller uses that feature. Relayed in real time and not recorded; Art. 9 special-category data while in transit
- Authentication and operational metadata: session metadata, last-login, IP, user-agent, role assignments, audit-log records, encryption-key references
- Operational telemetry: application metrics, error stack traces (PII-redacted), request logs
Special categories (Art. 9 GDPR)
Health data, as listed above. Biometric data (deferred — pose-tracking telemetry tables exist but are not populated at launch; activation requires a separate consent surface and DPIA update).
Retention
| Category | Retention |
|---|---|
| Active patient account | Lifetime of the patient's relationship with the Controller + medical-records overlay (Law 95/2006) |
| Clinical records (notes, treatment plans, prescriptions) | Per Law 95/2006 retention schedule |
| Adherence telemetry (aggregate metrics) | 13 months hot / 6 years archived / then purged |
| Consent records | Lifetime of the patient relationship + 6 years post-withdrawal |
| Audit log | 6 years minimum, never hard-deleted, partitioned by month |
| Email delivery logs | 90 days |
| Suppression list (bounce/complaint) | Indefinite for opt-out integrity |
| Backups (Layer 1 — managed database) | 35-day automated backup window; 35-day point-in-time-recovery window; deleted on schedule |
Backups (Layer 2 — logical pg_dump archive) | 7 years, under Object Lock in COMPLIANCE mode with no expiration rule. Immutable and non-deletable by anyone, including the Processor. Disaster recovery only — see §3.5(c) |
Annex B — Technical and Organisational Measures (TOMs)
The Processor maintains the following measures. Detailed descriptions in /security/ and /architecture/.
| # | Measure | Description |
|---|---|---|
| B1 | Multi-tenant isolation | Row-Level Security in PostgreSQL bound to app.current_org_id per request transaction. No cross-tenant query path. |
| B2 | Encryption in transit | TLS 1.2+ for all browser↔app, app↔DB (verify-full), app↔sub-processor communications. |
| B3 | Encryption at rest | RDS, S3, EBS, backups — all encrypted via AWS KMS-managed keys. AES-256-GCM column-level encryption for auth_secret and pii_regulated classes (CNP, credentials, API keys, signing secrets), with KMS-managed envelope keys. |
| B4 | Pseudonymisation | Telemetry rows are keyed by opaque UUID (patient_id), never by name, email or CNP; re-identification requires access to the separately-controlled primary database. Error tracking runs with sendDefaultPii: false and attaches no user identifier at all. Video-provider participants are identified to the provider by a derived opaque reference. |
| B5 | Access control | Per-organisation Role-Based Access Control with permission codes; documented role templates; least-privilege defaults. |
| B6 | Personnel access to Controller data | Gated by break-glass primitive: scoped, ≤ 4-hour, justified, audit-logged, real-time-notified to the Controller. |
| B7 | Audit log | Append-only (no UPDATE or DELETE policy), partitioned monthly, RLS-protected. Failed requests (401/403/500) logged. State-changing operations logged with actor, action, entity, IP, user-agent, status and field-level changes, with sensitive values masked by the same redaction list as B8. ⚠️ Retention is 6+ years by policy, not yet by mechanism: no archival or purge job exists, so the table currently grows without bound. The scheduled task creates partitions forward only — it does not archive or drop them. |
| B8 | Logging hygiene | A central redaction list masks the values of sensitive keys (password, secret, token, apikey, authorization, cookie, session, nationalid, cnp; key names are normalised so api_key, api-key and X-API-KEY all match). It is installed on the API's structured-log handler and on the audit-log JSONB writer, so one list closes both surfaces. ⚠️ Scope: the API service. The telemetry and media services do not install it. Error tracking runs with sendDefaultPii: false (no IP, cookies, headers, bodies or user identifiers) plus a beforeSend hook that strips secrets carried in URLs and breadcrumbs; it is deployed on the Portal only. |
| B9 | Backups and DR | Multi-AZ database with automated backups + PITR; daily logical pg_dump of both the core and telemetry databases, encrypted under a dedicated envelope key, into an Object-Locked (COMPLIANCE, 7-year) bucket that neither an administrator nor the cloud provider can delete from — a ransomware and insider-deletion control. Restore drills are executed in-cloud from the archive itself, not simulated: the first such drill found and fixed a defect that would have prevented the production database from restoring from its own dump. |
| B10 | Disaster recovery | Target RTO 4 hours / RPO 1 hour for the platform tier; Controller-level recovery follows the same envelope. These are design objectives — they have not been measured against a full production-scale restore, and are stated as targets rather than as demonstrated figures. |
| B11 | Vulnerability management | Every direct dependency is inventoried with purpose and risk tier, enforced by a CI gate that fails the build when a manifest dependency has no inventory row or a row points at a removed dependency. ⚠️ Not yet in place: container image scanning on build, automated dependency-update alerting, and periodic penetration testing. |
| B12 | Personnel training | Data-protection training on engagement + annual refresher, with records kept by the DPO. ⚠️ Pending the DPO designation at B15; no training records are maintained today. |
| B13 | Confidentiality agreements | Personnel bound by NDA + data-protection clauses in employment / engagement contracts. |
| B14 | Sub-processor management | All Sub-processors subject to a written agreement imposing data-protection obligations substantially equivalent to this DPA. Sub-processors listed in Annex C. |
| B15 | DPO | ⚠️ Not yet designated. Two independent Art. 37 triggers apply and the designation memo is drafted — see DPO designation — but no DPO is appointed, the ANSPDCP filing is not made, and the dpo@restartix.pro mailbox is not provisioned. This must close before this DPA is issued to a Controller. |
| B16 | DPIA | DPIA conducted under Art. 35 — see DPIA. Updated on material change. |
| B17 | Breach response | Documented playbook with 48-hour Controller-notification SLA — see Section 7 + breach playbook. |
| B18 | Data classification | Every database column registered with class + permitted-egress-target — see data classification. CI gate enforces registry coverage. |
| B19 | Change control | All production deployments via reviewed pull request + CI checks + GitHub production environment approval. |
| B20 | Customer support data handling | Identifiable Controller patient data is not exported from the Platform for support purposes except under break-glass elevation (B6), which is scoped, time-bound, justified, audit-logged and notified to the Controller. ⚠️ No ticketing system with a documented categorisation scheme is in place yet. |
Annex C — Authorised Sub-processors
The current Authorised Sub-processors are listed at sub-processors and reproduced in the table below as of {{EFFECTIVE_DATE}}.
| # | Sub-processor | Role | Location | Transfer mechanism |
|---|---|---|---|---|
| 1 | Clerk | Identity provider | United States | SCCs Module 2 + TIA |
| 2 | Bunny.net | Video CDN | EU (Slovenia, EU edges) | EU-only |
| 3 | Amazon Web Services | Hosting, email, KMS, backups | EU (eu-central-1) | EU-only at runtime + SCCs Module 2 for parent-access surface |
| 4 | Cloudflare | CDN, WAF, DNS | Global edge | SCCs Module 2 + TIA |
| 5 | Sentry | Error tracking | EU (Frankfurt) | EU-only |
| 6 | Daily, Co. | Live video consultations (WebRTC media relay; not recorded) | Media servers pinned to EU (eu-central-1); control plane United States | SCCs Module 3, incorporated by reference in the provider's terms — TIA T4 |
Confirm the account holder before issuing this with row 6
Row 6's sub-processor agreement is in force — the provider's Terms of Service incorporate its DPA by reference and the DPA deems the Standard Contractual Clauses signed on entering the agreement, with Module 3 applying where the customer is itself a processor. Section 6.2 of this DPA is therefore satisfied.
What is not confirmed is which legal entity holds the provider account, because that account is currently shared with the legacy system this platform replaces. Confirm it, and move video onto a platform-owned account, before issuing this DPA to a Controller who will use video consultations.
Updates to this list are notified per Section 6. The current list at any time is the version published on the platform's sub-processor transparency page.