Records of Processing Activities (ROPA)

Required under GDPR Art. 30. Two-part register: {{LEGAL_ENTITY}} as controller (Part A — RestartiX-the-clinic's own patient data) and {{LEGAL_ENTITY}} as processor (Part B — tenant clinics' patient data processed on the platform). Living document; updated whenever a new processing activity is introduced or the categories change. v1 drafted 2026-05-15.

Counsel-review status

Developer-drafted v1. Counsel reviews retention periods (especially Law 95/2006 medical-records overlay), confirms lawful-basis attribution, and verifies the activity scope against ANSPDCP enforcement patterns. See F11.0.5 brief.

Controller information (both parts)

Field	Value
Controller / processor name	{{LEGAL_ENTITY}}
Registration / CUI	{{CUI}}
Registered address	{{REGISTERED_ADDRESS}}
Authorised representative	{{SIGNATORY}}
DPO	{{DPO_NAME}} ({{DPO_EMAIL}}) — see DPO designation memo
Contact for data-protection matters	dpo@restartix.pro
Establishment in EU	Yes — Romania
ANSPDCP designation submitted	{{ANSPDCP_NOTIFICATION_REF}}

Part A — RestartiX SRL as controller

Applies to data RestartiX SRL collects and processes as the operator of RestartiX-the-clinic (the first clinic on the platform at launch).

A1. Patient sign-up & account management

Field	Value
Purpose	Onboard patients to RestartiX-the-clinic's guided exercise program; maintain the patient account for the duration of program access
Categories of data subjects	Self-serve patients (16+ at launch; under-16 flow TBD pending counsel — see counsel brief §3.2)
Categories of personal data	Email, name, phone (E.164), DOB, locale, language preference. CNP where the patient supplies it — writable only on a patient-audience path, never through a staff-authenticated route; stored AES-256-GCM-encrypted with an HMAC blind index for search; masked on the record and revealed only through a dedicated permission on a separate endpoint that writes an audit row per read. Whether it may be requested at sign-up remains a counsel question (§3.1); the built behaviour is optional and patient-controlled
Lawful basis	Contract performance (GDPR Art. 6(1)(b)) — account creation and program participation. CNP processing under Art. 6(1)(c) + Law 190/2018 Art. 4 safeguards
Categories of recipients	Internal — patient themselves (own account), RestartiX-the-clinic specialists (post-launch), platform operations staff under break-glass elevation only
Sub-processors	Clerk (identity), AWS (hosting + SES email), Sentry (error tracking) — see sub-processors
International transfers	Clerk to US (SCCs Module 2 + TIA — see TIA)
Retention	Active account: lifetime of patient's relationship with RestartiX-the-clinic + Law 95/2006 retention overlay for the medical-records subset (counsel-confirmed table per counsel brief §3.4). Post-erasure: anonymisation under Art. 17(3)(c) for clinically-relevant rows
Security measures	TLS in transit; AES-256-GCM column-level encryption for pii_regulated columns (KMS-managed key); RLS scoped to app.current_org_id; audit-log all writes; break-glass primitive for cross-tenant access

A2. Guided exercise program participation

Field	Value
Purpose	Deliver the guided exercise program; record adherence and self-reported clinical instruments to enable program follow-up and clinical decisions (post-launch, when specialist interaction ships)
Categories of data subjects	Patients enrolled in the program
Categories of personal data	Health data (Art. 9) — VAS pain score per session, RPE, adherence (session completion, exercise drop-off, video watch %), free-text post-session comments
Lawful basis	GDPR Art. 9(2)(h) — provision of health and social care + Art. 6(1)(b) contract performance. Explicit consent (Art. 9(2)(a)) captured per the consent purpose catalog at sign-up
Categories of recipients	Patient themselves; specialists at RestartiX-the-clinic (post-launch — for clinical follow-up); platform operations under break-glass elevation only
Sub-processors	AWS (database + telemetry blobs in S3), Bunny (video CDN delivering exercise videos), Sentry (error tracking)
International transfers	None for runtime data (EU primary). See AWS entry in TIA for the parent-company-access addressing
Retention	Clinical-instrument data: per Law 95/2006 medical-records retention (counsel-confirmed). Telemetry blobs: 13 months hot / 6 years archived / then purged. Audit log: 6+ years
Security measures	TLS; column-level encryption for pii_regulated (not VAS/RPE — see data classification); RLS; audit log; break-glass for cross-tenant access; algorithm version recorded on every metric row

A3. Communications

Field	Value
Purpose	Transactional email (welcome, password reset, consent renewals, session reminders, program milestones) and operational notifications
Categories of data subjects	Active patient accounts
Categories of personal data	Email address, name, locale, account state metadata (e.g. "patient_X completed session_5")
Lawful basis	Contract performance (Art. 6(1)(b)) for transactional and operational messages; consent (Art. 6(1)(a)) for marketing. The classification is enforced in code, not by policy: every notification carries a classification, and a marketing-classified send fails closed unless a marketing consent is on record for the recipient
Categories of recipients	The data subject only
Sub-processors	AWS SES (email delivery); Clerk (some auth-related transactional emails)
International transfers	Clerk to US (SCCs + TIA)
Retention	Delivery logs 90 days; suppression list (bounce / complaint) indefinite per CAN-SPAM / GDPR opt-out integrity (see production launch readiness § SES bounce/complaint handler)
Security measures	DKIM + SPF + DMARC p=quarantine (currently p=none, hardening before launch); TLS for SES API; suppression list applied pre-send

A4. Consent management

Field	Value
Purpose	Record, evidence, and renew patient consent across purposes (program participation, marketing — disabled at launch, biometric — deferred, analytics — reserved for future portal-side web analytics (e.g. Plausible / GA) per cookie-inventory.md; does not gate F10 playback-QoS telemetry which runs under Art. 6(1)(f) legitimate interest per decisions.md, etc.)
Categories of data subjects	Active patient accounts
Categories of personal data	Consent record: principal_id, consent purpose code, version, granted_at, withdrawn_at, IP, user-agent, evidence (signature when applicable)
Lawful basis	Legal obligation (Art. 6(1)(c)) — Art. 7 GDPR requires demonstrability of consent
Categories of recipients	The data subject (own consent record); platform-internal under break-glass
Sub-processors	AWS only (database)
International transfers	None
Retention	For the lifetime of the patient relationship + 6 years after final withdrawal, per evidence-of-consent obligations
Security measures	Append-only consents table; supersession via withdrawal_reason='superseded_by_v{N}'; RLS scoped to principal + org; audit log

A5. Customer support

Field	Value
Purpose	Respond to patient support inquiries (support@restartix.pro)
Categories of data subjects	Patients (and third parties writing on their behalf, e.g. family members)
Categories of personal data	Email content + attachments, voluntarily-provided account context
Lawful basis	Legitimate interest (Art. 6(1)(f)) — providing requested support; data-subject expectations
Categories of recipients	Designated support staff
Sub-processors	TBD (email mailbox provider — to be selected from {{MAILBOX_PROVIDER}} candidates: Google Workspace / Fastmail / self-hosted). Mailbox provider must be EU-located or covered by SCCs
International transfers	Depends on mailbox provider (decision pending)
Retention	24 months from last interaction; sooner on request
Security measures	TLS; MFA on support inboxes; access restricted to support role

A6. Audit log

Field	Value
Purpose	Demonstrate accountability under GDPR Art. 5(2); investigate access; surface anomalous activity; support break-glass transparency
Categories of data subjects	All actors on the platform — patients (when they take actions), specialists, admins, platform operators
Categories of personal data	actor_id (principal), actor_type, action, entity_type, entity_id, IP, user-agent, status code, field-level changes, AI provenance fields (when applicable), break-glass session reference (when applicable)
Lawful basis	Legal obligation (Art. 6(1)(c)) + legitimate interest (Art. 6(1)(f)) — security and accountability
Categories of recipients	Platform compliance + security staff only; never the data subject directly (Art. 15 satisfied via DSAR mediated extract). Clinic admins see their own org's audit (audit_log.view_org permission)
Sub-processors	AWS only (database; S3 for archives)
International transfers	None
Retention	6+ years per data retention; never hard-deleted, partitioned monthly per P41
Security measures	Append-only RLS policies (no UPDATE or DELETE policy exists); INSERT-only via a SECURITY DEFINER function; monthly partitioning. Sensitive values masked in the JSONB payload by the platform's central redaction list. ⚠️ No S3 export or archival exists — the retention policy below is stated by policy, not yet enforced by a mechanism

A7. Marketing & website analytics

Field	Value
Purpose	Measure landing-page conversion and onboarding funnel performance
Categories of data subjects	Visitors to public landing pages + portal sign-up flow
Categories of personal data	Pseudonymised visit ID, page path, referrer, screen size, country (from IP, then dropped), timestamps. No cross-site tracking. No third-party ad pixels.
Lawful basis	Consent (Art. 6(1)(a)) for any tracking beyond strictly necessary cookies — captured via the cookie banner. See cookie inventory
Categories of recipients	Platform product team
Sub-processors	TBD — provider candidate: self-hosted Plausible or PostHog (EU-hosted). Final selection in launch operations
International transfers	None planned (EU-hosted candidates)
Retention	Aggregated indefinitely; raw events 12 months
Security measures	No cookies for first-party analytics (cookie-less analytics preferred); IP dropped after geocoding

A8. Live video consultations

Field	Value
Purpose	Conduct a remote consultation between a patient and a clinician (F5.5)
Categories of data subjects	Patients who book a video consultation; clinicians who conduct one
Categories of personal data	Live audio and video of the consultation — Art. 9 special-category health data. In-call display name; an opaque participant reference; room reference and token expiry; WebRTC connection metadata (IP, device, network quality)
Lawful basis	Art. 6(1)(b) contract performance + Art. 9(2)(h) provision of health care, with explicit consent captured through the telemedicine instrument, which must be adopted before a consultation can start
Categories of recipients	The two participants. No staff recipient beyond the clinician conducting the consultation
Sub-processors	Daily, Co. (media relay + room/token management) — see sub-processors §6
International transfers	Yes. Media servers are pinned to the EU (geo = eu-central-1) but the provider's control plane and corporate operations are in the United States. SCCs Module 3 are in force, incorporated by reference in the provider's terms. TIA T4
Retention	None. The consultation is not recorded, by us or by the provider; rooms and tokens expire. Only the consultation record (that it happened, when, with whom) persists in the platform database
Security measures	No recording enabled on any code path; EU media pinning enforced by an adapter that refuses to create a room without a region rather than defaulting; participants identified to the provider by an opaque reference, never a patient identifier; no clinical context in room name, token or webhook; private rooms with per-participant expiring tokens and eject_at_room_exp so expiry ends a call in progress; DTLS-SRTP on every media leg; webhook signatures verified

Part B — RestartiX SRL as processor

Applies to data third-party clinics (tenants on the platform) collect and process. At launch, there are no third-party clinics yet — but the platform is designed for them and the ROPA reflects that. Once the first third-party clinic onboards, the actual count of activities scales but the categories remain the ones below.

B1. Patient identity & clinical records on tenant clinics

Where a tenant clinic enables video consultations, the processing described at A8 applies identically with the clinic as controller — including the shared provider account, which should be separated before a tenant clinic is onboarded with that feature.

Field	Value
Purpose	Host the personal data of each tenant clinic's patients on the clinic's behalf — sign-up, account, consents, clinical records, treatment plans, scheduling, billing references
Categories of data subjects	Tenant-clinic patients
Categories of personal data	Identical to A1 + A2 in shape; in scope: identity, contact, DOB, locale, health data (Art. 9), CNP (where applicable), clinical correspondence, treatment plan, prescriptions, signed forms, audit log
Lawful basis	The tenant clinic determines lawful basis as controller. The platform processes on documented instructions per the DPA
Categories of recipients	The tenant clinic itself; the patient (their own records); platform operations under break-glass + always-on clinic notification only
Sub-processors	Same as Part A — Clerk, Bunny, AWS, Cloudflare, Sentry, FGO. Full list in sub-processors
International transfers	Clerk to US (SCCs + TIA); AWS parent-access addressing per TIA
Retention	Per the tenant clinic's instructions, with platform-enforced minimums for audit log + Law 95/2006 medical-records overlay
Security measures	RLS scoped to app.current_org_id; column-level encryption; cross-tenant isolation enforced at DB level; break-glass for any platform-side cross-tenant access; AWS BAA in place; KMS-managed encryption keys; backups in EU; restore drills tested per backup-disaster-recovery

B2. Tenant-clinic staff identity

Field	Value
Purpose	Authentication and authorisation of tenant-clinic staff (admins, specialists, support) into the Clinic app
Categories of data subjects	Tenant-clinic staff
Categories of personal data	Email, name, phone (optional), role membership, last-login metadata, MFA state, principal IDs
Lawful basis	Determined by tenant clinic; the platform processes on documented instructions
Categories of recipients	Tenant clinic; the staff member themselves; platform operations under break-glass
Sub-processors	Clerk, AWS, Sentry
International transfers	Clerk to US
Retention	While the staff member's seat is active + 6 years post-departure for audit-log continuity
Security measures	Same isolation guarantees as B1; per-org RBAC; impersonation requires break-glass session + always-on clinic notification

B3. Billing references for tenant clinics

Field	Value
Purpose	Issue invoices to tenant clinics for their platform subscription (when paid tiers ship — F12) and process usage metering
Categories of data subjects	Authorised billing contacts at tenant clinics
Categories of personal data	Contact name, email, billing address, fiscal ID (CUI for RO clinics), subscription state, usage records
Lawful basis	Contract performance (Art. 6(1)(b))
Categories of recipients	Tenant clinic; FGO (for RO invoicing); the platform's billing accounting
Sub-processors	AWS, FGO, future payment provider (Stripe) when F12 ships
International transfers	Stripe-hosted patient billing (Option B marketplace mediation) NOT in scope at launch — Stripe is a controller for that flow when it ships
Retention	10 years per Romanian fiscal record-keeping (Codul Fiscal Art. 78)
Security measures	TLS; access restricted to billing role

B4. Tenant-clinic audit log (subset of A6)

Field	Value
Purpose	Same as A6 — within each tenant clinic's org scope
Categories of data subjects	Tenant-clinic staff + patients
Categories of personal data	Same shape as A6
Lawful basis	Determined by tenant clinic; platform processes on instructions; the platform's own audit-log retention is the documented platform-side measure
Categories of recipients	Tenant clinic via audit_log.view_org permission; platform compliance under break-glass only
Sub-processors	AWS only
International transfers	None
Retention	6+ years
Security measures	Same as A6

Cross-cutting security measures (both parts)

These apply to every processing activity above and are documented in security/ and architecture/data-model.md:

• Tenant isolation: RLS at the database level, app.current_org_id GUC bound per request transaction. Cross-tenant queries impossible without break-glass elevation.
• Encryption at rest: RDS, S3, EBS, backups — all encrypted via KMS-managed keys. Column-level encryption (AES-256-GCM) for auth_secret and pii_regulated classes.
• Encryption in transit: TLS for browser↔app, app↔DB (verify-full), app↔sub-processors.
• Audit: every state-changing write logged; failed-auth logged; break-glass sessions log reads too.
• Access control: RBAC per-org with permission codes (not role-string compares); platform-side access via break-glass with scoped, time-bound, justified, audited sessions.
• Backups: automated database backups + 35-day PITR + a daily logical pg_dump into an Object-Locked (COMPLIANCE, 7-year) archive, published only on a byte-for-byte checksum match; an in-cloud restore drill exists and has been run against the archive. ⚠️ Cross-region replication is not configured. See backup-disaster-recovery.
• Pseudonymisation: telemetry pose data (when deferred pose half ships) keyed by principal_id, never name/email; Sentry user IDs hashed.
• Logging hygiene: PII never logged; redaction patterns enforced at the slog formatter level; Sentry beforeSend strips PII.
• DPO oversight: DPO designation memo carries the appointment and the reporting line.

Change log

Date	Change
2026-09-04	Added A8 live video consultations. CNP entries in A1 resolved to the implemented posture. A3 corrected: marketing classification is enforced in code and fails closed.
2026-05-15	Initial v1 register drafted (Parts A1–A7, B1–B4)