Inner DPA — RestartiX-the-Clinic ↔ RestartiX-the-Platform

The same SRL plays both roles at launch. This DPA documents the controller / processor split internally so the architectural commitment is enforceable in auditable form. Mirrors the tenant clinic DPA structurally — same shape, same rights, same Annex C sub-processor list. v1 drafted 2026-05-15.

Counsel-review status

Developer-drafted v1. Counsel confirms whether an intra-entity DPA is the correct instrument under Romanian law (alternative: a documented internal data-processing policy with equivalent binding force on internal teams). Either way, the substance must hold. See counsel brief.

Why have an inner DPA when both sides are the same legal entity?

{{LEGAL_ENTITY}} operates both:

• RestartiX-the-clinic — the first clinic on the platform at launch. Provides telerehab to patients. Controller under GDPR Art. 24.
• RestartiX-the-platform — the SaaS operator providing the multi-tenant infrastructure. Processor under Art. 28.

Both sides are the same SRL, but the roles are real and the boundary is enforceable:

1. Architectural commitment. Every other clinic onboarded after launch enters into the tenant clinic DPA. RestartiX-the-clinic operating without the same boundary would be a precedent that erodes the processor-only commitment. The inner DPA is the durable mechanism that prevents drift.
2. Operational reality. The platform team (engineers, ops, support, finance) is not the same as the clinic team (eventual clinic admins, specialists). The break-glass primitive applies inside {{LEGAL_ENTITY}} exactly as it does for third-party clinics: platform staff do not see RestartiX-the-clinic's patient data outside elevation.
3. Future-proofing. When the first third-party clinic onboards, the inner DPA is already in effect — there is no "old way" to migrate from. The break-glass log, the audit-log shape, and the consent flow all behave identically.
4. Auditability. A regulator asking "show me how you maintain the processor boundary when you operate as your own clinic" expects a written instrument. This is that instrument.

A formal DPA is the most defensible form; an internal data-processing policy with equivalent binding force is the alternative if counsel recommends. The substance — same TOMs, same break-glass, same audit, same sub-processor authorisation, same retention, same breach response — does not change between the two forms.

Parties

Party	Role	Identifier
Controller ("RestartiX-the-Clinic")	The clinical operation of {{LEGAL_ENTITY}} providing telerehabilitation services to patients on its own subscription	{{LEGAL_ENTITY}}, CUI {{CUI}}, {{REGISTERED_ADDRESS}} (clinical business unit identified by internal cost-centre {{COST_CENTRE_CLINIC}})
Processor ("RestartiX-the-Platform")	The SaaS operation of {{LEGAL_ENTITY}} operating the RestartiX multi-tenant platform	{{LEGAL_ENTITY}}, CUI {{CUI}}, {{REGISTERED_ADDRESS}} (platform business unit identified by internal cost-centre {{COST_CENTRE_PLATFORM}})

The single legal entity acts in both capacities, distinguished by internal business unit and cost-centre. Signing is by the same authorised representative on both sides — see Signatures below. The signing of this DPA in dual capacity is recorded in the SRL's corporate records as a related-party arrangement.

Substantive terms

The substantive terms of this DPA are identical to the tenant clinic DPA sections 1–13, applied between RestartiX-the-Clinic (as Controller) and RestartiX-the-Platform (as Processor). The following clauses are reproduced verbatim from the tenant DPA and apply with identical force:

• §1 Definitions — applied to this DPA.
• §2 Scope, roles and instructions — RestartiX-the-Clinic's documented instructions are issued by {{CONTROLLER_REPRESENTATIVE}} (operating-clinic side) and recorded in the internal change-control system at {{INTERNAL_INSTRUCTION_LOG_LOCATION}}. Instructions outside this channel are not in scope.
• §3 Processor obligations — applied without modification. The Platform's tooling for Data Subject Requests, breach assistance, and audit support is available to the Clinic side via the same Console + Clinic-app surfaces every tenant clinic uses.
• §4 Personnel access — applied without modification. The break-glass primitive applies between business units inside {{LEGAL_ENTITY}} exactly as it does for third-party clinics. Platform-side staff access to RestartiX-the-Clinic's patient data requires an active break-glass session with scope, reason, time bound, and audit row.
• §5 International transfers — applied without modification. The SCCs entered into by the Processor with third-country Sub-processors cover this DPA's data flow too.
• §6 Sub-processors — applied with the modification that notice of Sub-processor changes is given concurrently with the public notice to other clinics. The Controller's objection right exists in principle but is exercised in practice by the same person who, on the Processor side, made the change — the existence of the objection right is preserved as a durable mechanism, not as a meaningful gate between aligned parties.
• §7 Personal Data Breaches — applied without modification. Breach notice flows from RestartiX-the-Platform (DPO contact) to RestartiX-the-Clinic (clinic admin contact) within 48 hours, even where both contacts belong to the same SRL. The notice is a real record, used for the Clinic's Art. 33 obligation to ANSPDCP.
• §8 Audit — applied without modification, with the practical note that the Controller's audit right is satisfied by {{LEGAL_ENTITY}}'s annual internal review process; on-site audits are not meaningful between business units.
• §9 Liability — apportioned between business units per the SRL's internal cost-allocation policy. External liability remains with {{LEGAL_ENTITY}}.
• §10 Term and termination — for the duration of RestartiX-the-Clinic's subscription on the platform. If RestartiX-the-Clinic ceases clinical operations while the platform continues (or vice versa), the surviving obligations apply.
• §11 Governing law and jurisdiction — Romania; courts of {{JURISDICTION_CITY}}.
• §12 Order of precedence — applied.
• §13 Modifications — applied. Updates to the tenant DPA flow into this inner DPA automatically unless this DPA is explicitly amended to diverge (no divergence is intended).

Annexes — incorporated by reference

• Annex A — Description of the processing — identical in scope to the tenant DPA Annex A. Categories of Data Subjects are RestartiX-the-Clinic's own patients (initially the ~5,000 self-serve launch patients) and the eventual RestartiX-the-Clinic staff.
• Annex B — TOMs — identical to the tenant DPA Annex B. The Platform applies the same TOMs to RestartiX-the-Clinic's data as it applies to every other clinic's.
• Annex C — Sub-processors — identical to the tenant DPA Annex C and the sub-processor list.

Operational reinforcement

The inner DPA is not a paper document. It is reinforced by code-level and operational mechanisms:

Mechanism	Where
RestartiX-the-Clinic has a real organizations row, with the same RLS scoping every other tenant has	Platform database — no exception for {{LEGAL_ENTITY}}'s own clinic
Platform staff have no static RBAC role that grants read access across RestartiX-the-Clinic's patient data; access requires a break-glass session	break-glass primitive
Audit log treats RestartiX-the-Clinic identically to any other org_id	Audit-log shape (P41)
Sub-processor authorisations are general, not org-specific	Sub-processor list
Breach notification testing includes a drill where Platform notifies RestartiX-the-Clinic	Breach playbook

Signatures

Party	Signature	Date
For RestartiX-the-Clinic (Controller) — {{LEGAL_ENTITY}}	__________________	__________________
Name / Title	{{SIGNATORY}} / {{CLINIC_BU_TITLE}}
For RestartiX-the-Platform (Processor) — {{LEGAL_ENTITY}}	__________________	__________________
Name / Title	{{SIGNATORY}} / {{PLATFORM_BU_TITLE}}

The dual signature by the same authorised representative is recorded as a related-party arrangement in the SRL's corporate records.

Change log

Date	Change
2026-05-15	Initial draft. Inherits structure and substance from the tenant DPA. Annexes incorporated by reference