Data Processing Agreement

This Data Processing Agreement (the "Agreement") governs the processing of personal data concerning children in therapy, their parents or guardians, and clinic staff, in the course of using the TempoApp platform. It is entered into between the clinic creating an account on the platform (the "Clinic") and DINCA DANIEL-STEFAN PERSOANA FIZICA AUTORIZATA, the operator of the TempoApp platform ("TempoApp"), and is accepted by ticking the dedicated box during signup.

This is a translation provided for convenience. The Romanian version of this document is the binding one, and in the event of any discrepancy between the two, the Romanian version prevails.

1. Roles of the parties

The Clinic is the data controller for the clinical records of children in therapy. The Clinic decides what data it enters into the platform, which of its own staff have access to it, and for which therapeutic or administrative purposes it is used.

TempoApp is the data processor. We process this data solely on the Clinic's documented instructions, given through the platform's features, in order to provide the service. We do not use the data of children in therapy for our own purposes, whether marketing or statistical, and we do not disclose it to third parties other than the sub-processors listed in section 7.

The distinction matters because it determines who can decide what happens to the data: decisions about the content, access to, and retention of clinical records belong to the Clinic, not to TempoApp.

2. What data is processed

On the Clinic's behalf, the platform stores: identifying details of children in therapy and of their parents or guardians, clinical records and session notes entered by therapy staff, appointments, and, if the Clinic chooses to use them, assessment documents uploaded to the platform. This data is entered, edited and deleted by the Clinic, through its own staff accounts.

3. TempoApp's obligations

TempoApp undertakes:

• to process the data solely on the Clinic's instructions, received through use of the platform;
• to limit its own staff's access to the Clinic's data to what is strictly necessary for maintenance, technical support and incident resolution;
• to inform the Clinic, without undue delay, of any personal data breach affecting its records;
• not to engage any sub-processor other than those listed in section 7 without updating that list.

4. Return or deletion of data when the service ends

On termination, the Clinic chooses between the return and the deletion of its data. This is not a choice TempoApp can refuse or defer: at any time while the account exists, the Clinic can download an export of its own data (client records, appointments, notes) in a usable format, and can request permanent deletion of the data remaining on the platform.

If the Clinic communicates no choice, the retention periods described in section 5 apply.

5. Retention periods

The clocks below start running from the day the Clinic's account becomes read-only, not from the day of initial signup. An account may become read-only because the trial period ended without a subscription, because the subscription was cancelled, or because a card payment failed, on different days and for different reasons, but the retention clock is the same either way, because from that moment the data is no longer being changed, only kept or deleted.

There are three situations, treated differently because they are, in legal terms, three different situations:

• An account nobody has ever signed in to: deleted 30 days after it becomes read-only.
• An account that was used but holds no client records: deleted 60 days after it becomes read-only.
• An account containing real client records: never deleted on TempoApp's initiative. The Clinic receives notifications 30, 60 and 80 days after the account became read-only, and the data is deleted at 90 days unless the Clinic instructs otherwise; deletion happens sooner if the Clinic asks for it.

6. Backups

Deletion, whether requested by the Clinic under section 4 or occurring automatically under section 5, removes the data from active systems (the databases and storage the platform uses day to day). Copies of that same data may continue to exist for a period in the backups of the infrastructure providers listed in section 7, and are removed from those automatically as they age out of each provider's own rotation cycle. Deletion from active systems is therefore not the same as instant deletion from every backup existing at that moment.

7. Sub-processors

TempoApp uses the following sub-processors to provide the platform. The list may be extended over time by adding a row, for example if the transactional email provider changes; that is precisely why data retention and security are described by reference to this list rather than by the name of a single provider.

Sub-processor	Role
Google Cloud (Firebase)	Hosting the platform and storing data
Vercel	Hosting the tempoapp.ro website
Stripe	Processing card payments
Resend	Sending transactional email (notifications)
SmartBill (S.C. Intelligent IT S.R.L., Romania)	Issuing fiscal invoices to the clinic's clients
Anthropic PBC	The AI assistant (Mira): interpreting assessment data

What SmartBill receives

When an invoice is issued from the platform, SmartBill receives the data needed to issue it: the name of the client being invoiced, the billing address, the tax identification code, the email address of the parent or guardian the invoice is sent to, and the description, quantity and price of each invoice line. The transmission happens only when a user with the Administrator or Coordinator role issues an invoice from the clinic's billing screen.

SmartBill is a Romanian company, so this data stays within the European Economic Area and does not fall under the Article 46 GDPR safeguards described in section 8.

What the AI assistant (Mira) receives

The assistant receives pseudonymised data: the child's initials (at most three characters), age in months, diagnosis and severity level, and assessment scores. The child's internal identifier is replaced with an opaque handle unrelated to their name.

The full name, date of birth, contact details and access code fields are not transmitted. The restrictions are enforced in the code that builds the request: the object sent is composed of explicitly named fields rather than by removing unwanted ones, so a new field added to a child's record cannot reach the model without a deliberate change.

One exception: free-text clinical notes are transmitted as written when the therapist requests that section. They may contain anything the therapist wrote, including a name.

8. Security measures

TempoApp applies the following technical and organisational measures:

• per-clinic data isolation: each clinic has its own database, separate from every other clinic's, so one clinic cannot reach another's data;
• role-based access control: a clinic's staff see and modify only the data their role on the platform permits;
• data stored in the European Union: clinic databases are hosted in the EU, with the sub-processors listed in section 7;
• processing outside the European Economic Area: processing of that data also takes place outside the EEA, at the sub-processors listed in section 7. Those transfers rely on the safeguards provided for by Article 46 GDPR. For Anthropic PBC, the safeguard is the European Commission's Standard Contractual Clauses, incorporated by reference into Anthropic's Data Processing Addendum.

These measures reflect how the platform currently works. We do not claim or promise certifications, external audits or compliance with security standards we do not hold.

9. Contact

For questions about this Agreement, or to exercise the choice described in section 4, the Clinic can write to us at contact@tempoapp.ro.