Counsel Engagement Brief — Romanian Data-Protection Review

Drafted 2026-05-15 for the F11.0.5 pre-launch compliance pass. Sent to candidate Romanian data-protection firms to solicit a fixed-fee quote. See Production launch readiness, June launch plan, and F11.0.5 feature spec for full project context.

Fill-in-before-sending

This brief is a working draft. Before sending to a firm, the company side must fill in:

• Legal entity name, CUI, registered address ({{LEGAL_ENTITY}}, {{CUI}}, {{REGISTERED_ADDRESS}})
• Authorised signatory + contact email ({{SIGNATORY}}, {{CONTACT_EMAIL}})
• Project budget ceiling ({{BUDGET_CEILING}}) — see Budget section
• Engagement target date ({{ENGAGEMENT_TARGET}}) — current plan: 2026-05-22

Not sent — status 2026-09-04

This brief was written for an engagement that was to start in May 2026 and has not run. It is still the right brief, with two corrections a firm should be given up front:

• The launch already happened. Production has served real patients since 2026-06-05, and the platform is a CE-marked Class I medical device registered in May 2026. The engagement is no longer pre-launch advice; it is review of a system in operation.
• Add a question the brief does not ask. Live video consultations relay Art. 9 health data to a US sub-processor. The Art. 28 contract and the SCCs (Module 3) are in force by incorporation in the provider's terms, and the media is never recorded — but the provider account is shared with the legacy system, so the two are un-segregated and the entity on the contract is unconfirmed. Counsel should be asked whether that shared tenancy is curable by separation alone. See TIA T4 and the action plan.

§3.1's CNP question is narrower than the brief states. The field is in service — encrypted, masked, audited on read, and writable only on a patient-audience path — the conservative implementation of every likely answer. What remains open is whether it may be requested at sign-up.

1. About RestartiX

{{LEGAL_ENTITY}} (CUI {{CUI}}, registered at {{REGISTERED_ADDRESS}}) operates RestartiX, a multi-tenant SaaS platform for telerehabilitation and physical rehabilitation clinics. The platform is being launched to the public for the first time on 2026-06-10 ("the launch") with {{LEGAL_ENTITY}} itself acting as the first clinic on the platform ("RestartiX-the-clinic"). The launch program offers a free, guided exercise program to an expected 5,000+ self-serve patients in Romania.

Architecture summary

• Two parties, distinct roles. The platform ({{LEGAL_ENTITY}} qua platform operator) acts as data processor under GDPR Art. 28. The clinic on the platform acts as data controller. For launch, both parties are the same legal entity ({{LEGAL_ENTITY}}), but the roles and contractual boundary are real and will be formalised in an internal Data Processing Agreement. From launch +1 day, third-party clinics may onboard as additional controllers.
• Patient-facing app ("Portal") — public-facing web app. Patients sign up, provide profile information, give consent, follow guided exercise programs, watch videos, and submit per-session adherence and self-reported pain/exertion scores.
• Staff-facing app ("Clinic app") — clinic admins and specialists manage patients, treatment plans, and records.
• Console app — internal platform-admin app for {{LEGAL_ENTITY}} staff only. Access to cross-tenant patient data is gated by a "break-glass" pattern: scoped, time-bound, justified, audited, with always-on notification to the affected clinic.
• Sub-processors: Clerk (identity, US); Bunny (video CDN, EU); AWS (eu-central-1, hosting + SES email); Cloudflare (CDN + WAF, global); Sentry (error tracking, EU region); FGO (Romanian e-invoicing). Full list under Annex A of the eventual DPA.
• Data residency: primary stack in eu-central-1 (Frankfurt). Identity (Clerk) is the only systematic cross-border transfer at launch.

Data the platform processes at launch

• Identity & contact: name, email, phone (E.164), date of birth, locale.
• Health data (GDPR Art. 9): self-reported VAS pain score per session, self-reported RPE (rate of perceived exertion), adherence (sessions completed, video watch %, exercise drop-off).
• Telemetry: video playback events (buffering, watch %), session completion timestamps. Pose-tracking telemetry (biometric processing) is deferred to a post-launch phase; the tables exist in the schema but are not populated at launch.
• CNP (national ID number): open question — see §3 below.
• Cookies / tracking: to be inventoried; current scope = strictly necessary + product analytics (no marketing tracking at launch).
• Free-text from patients: profile notes, post-session comments.

What is NOT in scope at launch (so counsel can scope accordingly)

• Live video consultations / telemedicine in the live-clinical sense (no live appointment booking with specialists at launch — the program is fully guided/asynchronous).
• Prescriptions / clinical decisions driven by software output. The launch posture is EU MDR Class I: the platform displays informational data; the human specialist (post-launch) makes any clinical decisions.
• Biometric pose tracking (deferred; tables present, populated only after biometric consent surface ships).
• Payment processing (the launch program is free).
• Hospital / large-network deployments (the platform is permanently scoped to small-to-medium clinics, ≤ ~10 locations each).
• Patients outside the EU (launch is Romania-only).

2. What we need from counsel

A pre-launch Romanian data-protection review by 2026-06-08 that produces binding answers on the open questions in §3, marked-up versions of the platform's privacy notice template (EN + RO) and DPA template, a written findings memo for our architecture-decisions record, and any directly applicable ANSPDCP enforcement context from the last 12 months.

We are not asking counsel to draft these documents from scratch. We will provide v1 drafts of every artefact and ask counsel to red-pencil, correct, and confirm. This should reduce both the cost and the turnaround.

3. Open questions requiring binding answers

These are blocking the launch build. Each has a code-level and / or document-level consequence that we can implement immediately upon receiving counsel's answer.

3.1 Law 190/2018 — CNP processing at sign-up

The patient signs up on the portal with name + email + phone + DOB. The clinic (RestartiX-the-clinic at launch; third-party clinics later) may later need the CNP for invoicing, insurance reconciliation, or medical-record continuity under Law 95/2006.

Question: Under Law 190/2018 Art. 4, may the platform collect and store the CNP at portal sign-up, with appropriate safeguards (encryption at rest with KMS-managed keys, restricted access, defined retention, DPO oversight), or must CNP collection be deferred until the specific downstream purpose (invoice issuance, insurance claim) triggers a contractual or legal-obligation basis?

If permissible at sign-up, please specify the safeguard set the platform must demonstrate (DPO designation, training records, retention period, DPIA section, etc.).

3.2 Age of digital consent — under-16 flow

Romania's age of digital consent under Art. 8 GDPR + Law 190/2018 is 16. The launch program is open self-serve sign-up. Under-16 sign-ups must be handled — either blocked, or routed through a parental-consent path.

Question: What is the compliant flow for an under-16 sign-up? Options we are weighing:

1. Block at sign-up. Date-of-birth check refuses accounts under 16.
2. Parental consent path. Parental email captured, parental verification flow, parent gives consent on the minor's behalf.
3. Hybrid. Under-16 blocked from self-serve; on-boarded only via clinic-mediated invite with parental signature on paper / e-signature.

Please confirm which is required, and any specific technical/documentary requirements (parental-identity verification depth, evidentiary retention).

3.3 Telemedicine framework — applicability of Orders 1.589/2020 and 1.488/2020

The Ministry of Health orders set technical and procedural requirements for telemedicine consultations. The launch program is fully asynchronous: the patient watches videos and self-reports adherence; there is no live consultation, no live specialist interaction.

Question: Do Orders 1.589/2020 and 1.488/2020 (or other Ministry orders / Law 95/2006 provisions) apply to an asynchronous, guided-exercise program of this shape? If yes, which obligations attach at launch and which only when live consultations (planned post-launch) ship?

3.4 Medical records retention — Law 95/2006

The platform stores patient profiles, session adherence logs, self-reported clinical instruments (VAS, RPE), and (post-launch) clinical correspondence. GDPR Art. 17 erasure rights are partially displaced by medical-records retention obligations under Law 95/2006 (Art. 17(3)(c)).

Question: Please provide a retention table mapping each artefact type to the applicable retention period under Law 95/2006 and any successor norms. Specifically:

• Patient profile (name, contact, DOB)
• Self-reported clinical instruments (VAS pain, RPE, adherence per session)
• Asynchronous program completion records
• Future: synchronous consultation records, prescriptions, clinical correspondence
• Audit log of consent events

This will codify the platform's erasure flow ("anonymise per Art. 17(3)(c) where retention applies; full delete where it does not").

3.5 Biometric data — tablet signature and (deferred) pose tracking

The platform collects an electronic signature for consent acceptance (currently web-form click-through; tablet/touch signature surface planned). Pose-tracking telemetry (MediaPipe landmarks) is deferred but the schema is in place to allow controlled rollout.

Question: Under ANSPDCP guidance on biometric data:

• Does click-through consent acceptance qualify as biometric processing? Does a hand-drawn signature captured on a touch device?
• For deferred pose tracking, what consent surface, DPIA depth, and ANSPDCP-facing communication will be required before turning that telemetry on?

3.6 Cross-border transfer — Schrems II

Clerk (identity provider) is US-based. AWS regional fallback paths may at times route through non-EU regions for disaster recovery. The DPA's transfer-impact assessment (TIA) annex needs to address both.

Question: Are the EU Commission's 2021 Standard Contractual Clauses (Module 2 and Module 3 as applicable) plus a documented TIA sufficient under Romanian + ANSPDCP practice? Are there Romania-specific requirements beyond the EDPB six-step methodology?

3.7 Recent ANSPDCP enforcement focus

A scan of the last 12 months of ANSPDCP enforcement actions, with any fines or warnings relevant to: healthtech / telemedicine, large-scale consent / sign-up flows, CNP processing, retention failures, transfer-impact assessments.

Deliverable shape: short memo (1–3 pages) identifying the patterns and any specific risks we should harden against pre-launch.

3.8 MDR class confirmation

The platform's launch posture is Class I MDR for the guided-exercise program (informational data; human specialist makes clinical decisions). Future features (pose tracking driving treatment decisions, software-driven clinical recommendations) may require Class IIa.

Question: Confirm whether the Class I posture is defensible at the described launch scope, and identify the trigger conditions that would require uplift to Class IIa.

3.9 Marketing copy review

The public-facing landing page and onboarding copy must not make claims (efficacy, diagnosis, treatment outcomes, etc.) inconsistent with the Class I MDR posture. We will provide draft copy in EN and RO.

Deliverable: redlined copy with non-compliant claims removed or rephrased, plus a short list of permitted vs. forbidden claim patterns the marketing team can apply forward.

4. Documents we provide

The day the engagement letter is signed, counsel receives:

1. Privacy notice template (EN + RO) — current v1, seeded into the platform's clinic-facing template editor (1B.10). Markdown bodies with placeholders + toggleable sections (video_recording, biometric_capture, cross_border_transfer).
2. Terms-of-service template (EN + RO) — same machinery as #1.
3. DPA template v1 — controller ↔ processor agreement for tenant clinics. Drafted by us against GDPR Art. 28 + EDPB guidance + 2021 SCC modules.
4. Inner DPA v1 — same shape as #3 between RestartiX-the-clinic and RestartiX-the-platform.
5. Sub-processor list v1 — Clerk, Bunny, AWS (incl. SES), Cloudflare, Sentry, FGO. Names, purposes, locations, data categories transferred, transfer mechanisms.
6. TIA v1 — Transfer Impact Assessment per EDPB six-step methodology for non-EU sub-processors.
7. ROPA v1 — Records of Processing Activities under Art. 30, in two parts: {{LEGAL_ENTITY}} as controller (RestartiX-the-clinic), and {{LEGAL_ENTITY}} as processor (tenant clinics).
8. DPIA v1 — Data Protection Impact Assessment under Art. 35: overall + targeted sections for the guided-exercise program (F9) and adherence telemetry (F10 media half).
9. Marketing copy draft — public landing page + portal onboarding flow copy (EN + RO).
10. Architecture & decisions excerpts — relevant excerpts from the platform's technical documentation explaining the controller / processor split, the break-glass primitive, the consent purpose catalogue, the audit-log shape, the data-classification register, the patient-data isolation guarantees (RLS + tenant scoping), the encryption posture (column-level for CNP / credentials; layered defence for the rest).

We can provide additional excerpts on request; the platform documentation is extensive and we'd rather offer counsel a targeted reading list than a 200-page dump.

5. Deliverables we expect from counsel

#	Deliverable	Form
D1	Binding answers to §3.1–§3.9	Single memo, 5–10 pages, footnoted to specific statutes / orders / ANSPDCP decisions
D2	Red-lined privacy notice template (EN + RO)	Markdown returned with redlines; we apply to the seeded 1B.10 templates
D3	Red-lined DPA template + Inner DPA	Markdown or DOCX with redlines
D4	Red-lined ROPA, DPIA, TIA	Markdown or DOCX with redlines
D5	Red-lined marketing copy	Markdown or DOCX with redlines
D6	ANSPDCP enforcement scan memo	1–3 page memo per §3.7
D7	Engagement-close letter	Confirms the platform may launch on 2026-06-10 with the artefacts as finalised, listing any residual risks / open recommendations

D1 is the most important. Code and document changes flow directly from it.

6. Timeline

Date	Milestone
2026-05-22	Engagement letter signed (target)
2026-05-22	Materials pack delivered to counsel
2026-05-29	Mid-engagement check-in (D1 draft circulated)
2026-06-05	All deliverables (D1–D7) final
2026-06-08	Last possible D7 close letter for a 2026-06-10 launch
2026-06-10	Public launch

If counsel cannot meet 2026-06-05 final / 2026-06-08 absolute-last, we need to know before signing so we can plan a launch-delay contingency.

7. Budget and quote format

Fill before sending

Provide your internal ceiling as {{BUDGET_CEILING}}. Typical range for the scope above with a healthtech-specialist Romanian DP firm: €5,000 – €15,000 fixed fee. Confirm the ceiling before circulating to firms.

Please quote on a fixed-fee basis for D1–D7. If hourly rates are unavoidable, please provide a not-to-exceed estimate. Quote breakdown by deliverable preferred so we can scope-adjust if needed.

If a fixed-fee retainer for ongoing advice during the launch window (2026-06-10 to 2026-09-10) is available, please include it as a separate line item.

8. Firm profile we need

• Romanian-licensed (UNBR membership in Bucharest or another Romanian bar).
• Active data-protection practice with demonstrated healthtech experience (telemedicine, ehealth, hospital information systems, mhealth, clinical software).
• Familiarity with EU MDR / IEC 62304 boundaries (you do not need to be the medical-device-certification firm, but you must speak the language).
• Direct experience interacting with ANSPDCP (proceedings, opinions requests, enforcement responses).
• English working fluency for written deliverables. Final binding versions of the privacy notice / DPA will be in both EN and RO.

9. Selection process

We are soliciting quotes from 2–3 firms. Selection by 2026-05-21 based on:

1. Healthtech depth and ANSPDCP-facing experience (60%)
2. Ability to commit to the 2026-06-08 absolute-last deadline with confidence (30%)
3. Fixed-fee budget fit (10%)

We will share the engagement letter for signature with the selected firm by 2026-05-22.

10. Contact

{{SIGNATORY}} — {{CONTACT_EMAIL}} — for all engagement-process questions and to receive the materials pack.

---

Implementation note (internal — strip before sending)

After the engagement letter is signed, the following platform-side actions kick off in parallel and do not depend on counsel's deliverables:

• Sub-processor list v1 → publish as public transparency page (Art. 28) once counsel reviews wording
• ROPA v1 → kept in apps/docs/legal/ as a living document
• DPA + Inner DPA v1 → seeded as legal_document_templates of type dpa once 1B.10's document_type enum is extended, or held as a static markdown until a later sub-phase adds it
• TIA + DPIA v1 → live in apps/docs/legal/ as living documents; counsel-reviewed v1 becomes the auditable record
• DPO designation memo → resolves the open question of external DP service vs. internal hire (external recommended at current scale)
• Cookie / tracking inventory → drives the cookie banner across all three apps; new for-launch UI surface

Counsel's D1 answers drive direct code changes:

• §3.1 CNP at sign-up → Portal onboarding form keeps or drops CNP field; consent purpose catalogue (1B.9) may gain a cnp_processing entry; retention codified.
• §3.2 Under-16 → Portal sign-up DOB validation gains under-16 branch (block, parental flow, or hybrid).
• §3.4 Retention table → F11.1 erasure endpoint codifies Art. 17(3)(c) exemptions per artefact type.
• §3.5 Biometric → Tablet-signature design and deferred pose-tracking rollout each get the required consent surface.
• §3.6 Cross-border → DPA annex finalised; transparency page sub-processor entries gain TIA references.
• §3.8 MDR class → architecture decisions doc updated; marketing copy review feeds the launch landing page.