Data processing agreement, Oretta by HEHE.studio (English)

Last updated 29 October 2026

Parties. The studio that opens an Oretta account (the "Controller") and Oretta by HEHE.studio, operated by HEHE.studio Marcin Michalak, a sole proprietorship registered in CEIDG, ul. Na Miasteczku 12C/255, 61-144 Poznań, Poland, VAT ID / NIP PL7773193269 (the "Processor"). Contact for data matters and notices under this agreement: contact@oretta.app. This agreement takes effect when the studio accepts the terms and forms part of them. On request we send the agreement signed with a qualified electronic signature.

1. Subject matter, nature and purpose

The Processor provides Oretta (time tracking, reports, budgets, export). In doing so it stores personal data on the Controller's behalf, shows it to the Controller's people by role, and builds reports from it. Processing covers: collection, storage, display, aggregation in reports, posting to the studio's Slack (when the Controller turns it on), backup, export and deletion. Purpose: only providing the service under this agreement and the Controller's documented instructions (the Controller's settings and actions in the app are such instructions).

2. Duration

For as long as the agreement to use Oretta lasts. After it ends, section 9.

3. Data and data subjects

Data subjects: the Controller's employees, collaborators and freelancers who have accounts in its studio; project data may also contain the Controller's client names (usually companies, sometimes individuals).

Categories of data: name, email, role, account state; time entries (project, task, tags, description, start and end); clients, projects, budgets; hourly rates; person costs: an hourly cost or, optionally, a monthly salary (entering person costs is optional; the Controller decides whether to enter an individual or a blended cost; visible only to studio admins; this is pay data, not an Art. 9 special category, but sensitive, so handled with extra care); studio logo; personal API tokens (only their SHA-256 hash is stored); the studio's Slack bot token (when connected); IP addresses and request logs. We do not process screenshots, recordings or computer-activity data. The Controller agrees not to enter special-category data (Art. 9) or criminal-conviction data in entry descriptions.

4. Processor's obligations

Process data only on the Controller's documented instructions, including on transfers outside the EEA, unless EU or Member State law requires otherwise (then it tells the Controller beforehand, if the law allows).
Ensure that people authorised to handle the data (today: the owner of HEHE.studio) are bound to confidentiality.
Apply the measures in section 6.
Follow the conditions for sub-processors in section 5.
Help the Controller, within reason, answer data-subject requests (access, rectification, erasure, portability): CSV export is available to the admin in the app; deletion on request per section 9. A request received directly from a person is passed to the Controller without undue delay.
Help with obligations under Arts. 32–36 GDPR (security, breach notification, DPIA, consultation) by providing the information it has.
Make available the information needed to show compliance and allow audits (section 8).
Tell the Controller at once if it thinks an instruction infringes the GDPR.

5. Sub-processors

The Controller gives general authorisation for the sub-processors on the subprocessor list (in the version dated on the list): Vercel (hosting, including the Vercel BotID check on the signup form), Supabase (database, sign-in, email sending), Cloudflare (backups in R2, encrypted), GitHub (running the backup job); Slack only once the Controller connects it, under the Controller's own contract with Slack.

Changes. We tell the studio admin by email of a new or replaced sub-processor at least 30 days before it starts processing, or, where the change comes from a decision of one of our providers that we learn of later, or is urgent for security reasons, without undue delay after we learn of it. In that time the Controller may object on reasonable grounds; if we cannot resolve it, it may terminate without penalty and with an export of its data.

We have, or will have, a contract with each sub-processor imposing obligations at least equivalent to this one. We remain liable to the Controller for sub-processors as Art. 28(4) GDPR provides.

Transfers outside the EEA: the database is in Ireland (Supabase) and the application functions run in Dublin (Vercel). Vercel's network and logs are global, and the backup job runs on GitHub machines with no pinned region. Each provider's data processing agreement (DPA) describes its transfer mechanism; the privacy policy gives the details and sources.

6. Security measures

What exists today:

Studio data separated in the database (Row Level Security, an organisation column on every table); automated tests check that separation.
Roles: admin, team lead, person. Rates and person costs are visible only to admins; a person sees their own entries, a team lead the team's.
API tokens stored as a SHA-256 hash; a token cannot create more tokens. Passwords are stored and hashed by Supabase's sign-in service. A deactivated account loses access, tokens included.
Transmission over HTTPS. Application functions pinned to an EU region (Dublin).
Backups: Supabase daily (7 days) and a weekly dump encrypted with age before it is uploaded to storage, newest 8; the private key is held offline, outside GitHub and the storage. The restore procedure is written down.
Access to the production database: the owner of HEHE.studio.
No monitoring of user activity.

What we do not have and do not promise: certifications (ISO 27001, SOC 2), two-factor authentication (not available), an audit log of changes, application-level field encryption in the database (Supabase provides disk encryption), an availability guarantee (SLA).

7. Personal data breaches

We tell the studio admin by email without undue delay, with a first notice, which may be incomplete, no later than 48 hours after we become aware of a breach affecting the Controller's data; we provide missing information in stages as we obtain it. The notice includes: a description, categories and approximate numbers of people and records, likely consequences, measures taken and planned, and a contact. Reporting to the authority (72 h) and informing individuals are the Controller's duty; we help.

8. Audits

The Processor makes available the information needed to show compliance with this agreement. Audits are carried out first by providing documentation and answering written questions. An on-site audit (by the Controller or an independent auditor bound by confidentiality) is possible once a year on 30 days' notice, where the documentation is insufficient or after a breach, at the Controller's cost. An audit does not cover other studios' data or vendors' systems (we pass on the vendors' documentation and reports instead).

9. End of agreement: return and deletion

Before the end and for 30 days after it, the studio admin can download all data as one ZIP of CSV files (UTF-8, semicolon separator): people (without password hashes or tokens), clients, projects, tasks, tags, rates, time entries, person costs. This is also the data retrieval period when switching provider (terms, section 8a). After that, on request or 30 days after the agreement ends, we delete the studio's data from the production database. Backups expire on their own within about 8 weeks of deletion and are not restored to production to bring deleted data back. We keep data the law requires (for example invoices) as a controller. We confirm deletion by email on request.

10. Final provisions

Polish law. Disputes go to the common court competent for the Processor's seat, unless the law gives the Controller the right to another court. Each party's liability under this agreement is subject to the limits in section 9 of the terms, except liability towards data subjects and fines imposed by a supervisory authority, which are borne by the party that caused them.