Skip to content
ARIVENOAll documents

DPA

Ariveno Data Processing Agreement

The Article 28(3) GDPR agreement concluded by a correctly identified and represented Controller.

Version 2026-09-07-beta.10 · effective from 2026-09-07

Download the immutable Markdown source.

Version: 2026-09-07-beta.10 Effective date: from the electronic acceptance of this version by a properly identified and represented Controller Processor: Brillnet Piotr Adamski, ul. Henryka Sienkiewicza 73/6, 90-057 Łódź, NIP 7321779060, REGON 101551294 Contact: privacy@ariveno.com

This English translation is provided for convenience. The binding text of this document is the Polish original of the same version (2026-09-07-beta.10), available at https://ariveno.pl/legal/dpa.

1. Parties and Conclusion of the Agreement

  1. The Agreement is concluded between:
    1. the entrepreneur or organisation identified in the Ariveno account by its business name/name, address, NIP or another identifier — hereinafter the Controller;
    2. Brillnet Piotr Adamski — hereinafter the Processor.
  2. The person accepting the Agreement on behalf of the Controller declares that they are authorised to conclude it.
  3. The Processor records at least: the account identity, the organisation, the representation data, the version, the UTC time, the source and the content of the statement of authorisation.
  4. If the Controller's data is completed after registration, the Agreement becomes effective only once that data has been linked to the organisation and the acceptance. Until then, the Controller should not enter the personal data of Salon Clients.
  5. The Agreement forms part of the agreement for the provision of Ariveno and constitutes an agreement under Article 28(3) GDPR.

2. Definitions

  1. GDPR — Regulation (EU) 2016/679.
  2. Entrusted Data — personal data processed by the Processor on behalf of the Controller in Ariveno.
  3. Processing, personal data, personal data breach, supervisory authority and data subject have the meanings given to them in the GDPR.
  4. Subprocessor — another processor engaged by the Processor to process the Entrusted Data.
  5. Service — Ariveno covered by the Terms of Service.
  6. Instruction — a documented instruction of the Controller arising from the Agreement, the configuration, the use of a feature, a support request or another recorded channel.

3. Subject Matter, Duration, Nature and Purpose

  1. The subject matter is the processing of the Entrusted Data for the purpose of providing, securing, maintaining and supporting Ariveno.
  2. The processing lasts from the effective conclusion of the Agreement until the deletion or return of the Entrusted Data after the end of the Service, taking into account technical copies and legal obligations.
  3. The nature of the operations includes: collection, recording, organisation, storage, retrieval, use, alignment, transmission according to Instructions, restriction, export, anonymisation and erasure.
  4. The purposes include:
    1. bookings, schedules, visits and the waiting list;
    2. management of the team, services, resources and stages;
    3. transactional e-mail messages and optional SMS;
    4. reports, exports, private ICS feeds and support;
    5. fulfilling data subject rights, audit and security;
    6. backups, continuity and deletion after termination.
  5. The Processor does not use the Entrusted Data for its own marketing, the sale of data, advertising profiling or the training of artificial intelligence models.

4. Categories of Data Subjects and Data

  1. Categories of data subjects:
    1. Salon Clients, persons making bookings and persons visiting the salon;
    2. members of the Controller's staff and its collaborators;
    3. the Controller's contact persons and representatives;
    4. persons appearing in booking data or transactional communication.
  2. Categories of data:
    1. identification and contact data, e.g. first name, last name, phone number, e-mail;
    2. booking and visit data, e.g. date and time, service, resource, attending staff member, status;
    3. organisational data of the team, schedule, permissions and location;
    4. transactional communication history and delivery metadata;
    5. preferences, consents and limited notes related to organising the service;
    6. identifiers, audit events and technical security metadata;
    7. files and photos provided by the Controller within the permitted scope.
  3. The Controller does not entrust health data or other special categories of data under Article 9 GDPR, data relating to convictions under Article 10, or data requiring features that Ariveno does not provide.
  4. If the Controller intends to change the categories of data or the purposes, it must first obtain the Processor's written confirmation and ensure compliance with the law.

5. Instructions and Lawfulness

  1. The Processor processes the Entrusted Data only on documented instructions from the Controller, including with regard to transfers outside the EEA, unless Union or Member State law requires otherwise.
  2. If the law requires processing without an Instruction, the Processor informs the Controller before commencing it, unless the law prohibits this on important grounds of public interest.
  3. The Terms of Service, the Service configuration, the actions of authorised Users and the Controller's requests constitute the complete set of initial Instructions.
  4. The Controller is responsible for the lawfulness of Instructions, the legal bases, transparency towards data subjects, the accuracy of the data and the scope of User access.
  5. The Processor immediately informs the Controller if, in its opinion, an Instruction infringes the GDPR or other data protection provisions. It may suspend its execution until the matter is clarified.
  6. An additional Instruction going beyond the standard Service may require agreeing on a cost and a timeline, insofar as this does not limit the Processor's obligations under the law.

6. Confidentiality and Authorisations

  1. The Processor grants access to the Entrusted Data only to persons for whom access is necessary.
  2. These persons are bound by a statutory or contractual obligation of confidentiality, trained in security and covered by access control.
  3. Administrative access is granted according to the principle of least privilege, logged and periodically reviewed.
  4. The obligation of confidentiality continues after the end of the cooperation.

7. Technical and Organisational Measures

  1. The Processor implements the measures under Article 32 GDPR appropriate to the risk, the state of the art, the cost and the nature of the processing.
  2. The minimum current set is described in Annex B. The Processor may change the measures provided this does not lower the overall level of protection.
  3. The Controller is responsible for the secure configuration of its own Users, devices, mailboxes, SMSAPI, exports and integration channels.

8. Assistance to the Controller

  1. Taking into account the nature of the processing, the Processor assists the Controller by appropriate technical and organisational measures in fulfilling data subject rights, in particular access, rectification, erasure, restriction and portability.
  2. A request concerning the Entrusted Data received directly from a data subject is forwarded by the Processor to the Controller without deciding on it independently, unless the law requires otherwise.
  3. The Processor assists the Controller in complying with the obligations under Articles 32–36 GDPR, including with:
    1. risk and security assessment;
    2. breaches and notifications;
    3. data protection impact assessments;
    4. prior consultations with the authority.
  4. Assistance is provided as standard through Service features and documentation. Non-standard work may be chargeable on previously agreed terms, unless the need for assistance results from the Processor's breach of the Agreement.

9. Personal Data Breaches

  1. The Processor notifies the Controller without undue delay after becoming aware of a breach concerning the Entrusted Data.
  2. The operational target is a first notification within 24 hours of confirming or reasonably qualifying the event. If a material risk exists earlier, the Processor provides a preliminary alert without waiting for full confirmation.
  3. To the extent available, the notification includes:
    1. the nature of the breach, the systems affected and the approximate categories and numbers of data subjects and records;
    2. the possible consequences;
    3. the measures taken or proposed;
    4. a contact point;
    5. the information the Controller needs to assess its obligations under Articles 33 and 34 GDPR.
  4. Information may be provided in phases.
  5. A notification does not constitute an admission of fault or liability.
  6. The Processor documents the breach and cooperates in mitigating its effects. The Controller is responsible for notifying the authority and the data subjects, if such an obligation exists.

10. Subprocessors

  1. The Controller gives a general authorisation for the use of the entities listed in the current Subprocessor List.
  2. The Processor gives notice of an intention to add or replace a direct Subprocessor at least 30 days in advance, by e-mail or in the Panel.
  3. Within that period, the Controller may raise a reasoned objection related to data protection at privacy@ariveno.com.
  4. The parties seek a solution in good faith, e.g. a configuration change. If one is not reasonably possible, the Controller may terminate the part of the Service affected by the change before the new Subprocessor is put into operation.
  5. The Processor concludes an agreement with the Subprocessor imposing substantially the same data protection obligations, in particular appropriate safeguards.
  6. The Processor remains liable to the Controller for the performance of data protection obligations by a direct Subprocessor to the extent required by Article 28(4) GDPR.
  7. The List distinguishes direct Subprocessors from providers acting as separate controllers or entities chosen directly by the Controller.

11. Transfers Outside the EEA

  1. The Processor uses primary resources configured for the EU jurisdiction, but global support, the network and emergency e-mail dispatch may result in a transfer outside the EEA.
  2. Such a transfer takes place on the Controller's Instruction expressed by concluding the Agreement and activating the relevant feature, and with the application of an appropriate mechanism under Chapter V GDPR.
  3. Depending on the recipient, the mechanism may be an adequacy decision, the EU–US Data Privacy Framework, or Standard Contractual Clauses together with supplementary measures.
  4. Upon a reasoned request, the Processor provides information about the mechanism, the transfer assessment and the supplementary measures, protecting secrets and security.
  5. If the Controller prohibits a transfer necessary for a specific feature, the Processor will disable that feature or, where that is not possible, the parties will agree on the termination of the Service.

12. Audits and Compliance Information

  1. The Processor makes available the information necessary to demonstrate compliance with Article 28 GDPR, including this Agreement, the Subprocessor List, a description of the measures and reasonably available evidence of controls.
  2. The Controller first evaluates the documents and answers provided.
  3. If they are insufficient, the Controller may conduct an audit itself or through an independent auditor:
    1. no more than once a year, unless a breach, a material change in risk or a request by an authority has occurred;
    2. upon at least 30 days' prior notice, unless urgency results from a breach or an authority;
    3. on Business Days, without unreasonably disrupting the Service;
    4. maintaining confidentiality and without access to other Clients' data or secrets that are not needed.
  4. The Controller covers the reasonable costs of the audit and its handling, unless the audit reveals a material breach of the Agreement by the Processor.
  5. The Processor cooperates with the competent supervisory authority in accordance with the law.

13. Retention, Return and Deletion

  1. During the term of the agreement, the Controller sets the retention of Salon Client data within the range of 30–3650 days; the default value is 180 days from the last completed visit. The active value indicated in the Panel is the configuration in force for the given Controller and may differ from the default value.
  2. The Controller may export the Entrusted Data during the term of the agreement and for 30 days of read-only access after its termination.
  3. After termination, the Controller may choose return through export and deletion, or deletion alone. If it gives no other Instruction, the Processor provides a standard export for 30 days and then deletes the data.
  4. Operational data and organisation resources are deleted no later than after 90 days. D1 Time Travel may allow technical restoration for up to 30 days, and R2 copies rotate for up to 35 days. Data in closed backups is not restored to normal use and is deleted in the rotation cycle.
  5. The Processor may retain data whose storage is required by law, only to the required extent, with processing restricted and the Controller informed, where this is permitted.
  6. An active legal or security hold requires a documented reason and a review date.
  7. Upon request, the Processor confirms the completion of deletion.

14. Liability

  1. The parties' liability under the GDPR is governed in particular by Article 82 GDPR and mandatory law.
  2. In the contractual relationship between the parties, the limitations set out in the Terms of Service apply to the extent the law permits their application to the given obligation.
  3. Each party is responsible for its own Instructions, decisions, breaches and the scope of its statutory obligations.

15. Term and Precedence

  1. The Agreement remains in force for the period during which the Processor processes the Entrusted Data.
  2. The provisions on confidentiality, audit, liability and deletion survive after termination to the extent necessary.
  3. In the event of a conflict in matters of data processing, the Agreement takes precedence over the Terms of Service.
  4. A change materially affecting the Controller's rights requires notification and, where necessary, renewed acceptance.
  5. The Agreement is governed by Polish law, without prejudice to directly applicable Union law.

Annex A — Processing Details

ElementDetermination
Controllerthe organisation identified in the Ariveno account
ProcessorBrillnet Piotr Adamski
Subject matterhosting and handling of the data needed to run a salon in Ariveno
Durationthe term of the Service plus the period of return, deletion and backup rotation
Purposeperformance of the functions indicated in point 3.4
Data subjectsSalon Clients, the Controller's staff, collaborators, representatives and contacts
Dataidentification, contact, bookings, visits, schedule, organisational preferences, consents, communication, audit, metadata and permitted files
Prohibited dataspecial categories under Article 9 GDPR, criminal data under Article 10 and medical data
Frequencycontinuous, depending on the use of the Service
Primary areaoperational resources configured for the EU jurisdiction, with possible technical transfers described in point 11
Retention180 days by default, active Controller configuration 30–3650 days; after termination in accordance with point 13

Annex B — Technical and Organisational Measures

1. Architecture and Isolation

  1. One private D1 database and one private R2 resource per organisation, plus booking coordination using Durable Objects.
  2. Operational resources configured for the EU jurisdiction.
  3. Logical isolation of organisations and explicit resource bindings.
  4. Separation of production and test environments through separate zones, tokens, prefixes, bindings and deployment safeguards. A separate Cloudflare account for each environment is not declared.

2. Access Control

  1. Individual accounts, authentication and roles.
  2. The principle of least privilege and revocation of unnecessary access.
  3. Logging of significant administrative operations.
  4. Secrets stored outside the code and not displayed to Users.

3. Encryption and Transmission

  1. TLS for transmission.
  2. Encryption of provider-managed resources at rest in accordance with the provider's standard.
  3. Short-lived tokens for exports; the token is not placed in the URL.
  4. Private file resources and object access control.

4. Minimisation

  1. Queues and asynchronous messages without PII content — they use organisation, job, record, idempotency and attempt identifiers.
  2. No tracking pixels in messages configured by Ariveno.
  3. No persistent storage of client, visit and schedule data in browser storage for offline purposes.
  4. No advertising providers, session recording or AI providers for the Entrusted Data.

5. Logging and Audit

  1. Audit of salon operations in D1 for 24 months.
  2. Workers logs for up to 7 days.
  3. Logs forwarded to a private R2 configured for the EU for up to 90 days.
  4. Correlation identifiers, alerting and an event analysis procedure.

6. Availability and Recovery

  1. Availability target of 99.5% monthly.
  2. RPO of up to 24 hours and a target RTO of up to 8 hours.
  3. D1 Time Travel of up to 30 days and R2 backup rotation of up to 35 days.
  4. Recovery tests and continuity procedures.
  5. Primary backups remain within the same provider and are not presented as full disaster recovery in a separate account.

7. Secure Development and Change Management

  1. Change reviews, controlled deployments and safeguards against environment mix-ups.
  2. Functional, privacy and isolation tests.
  3. Dependency updates and vulnerability response appropriate to the risk.
  4. Incident procedures and the security@ariveno.com contact.

8. Deletion and Data Subject Rights

  1. Configurable retention and deletion jobs.
  2. A privacy center handling access, rectification, restriction, erasure and portability.
  3. Irreversible anonymisation where full removal of identifiers while maintaining statistical consistency is appropriate.
  4. Status and proof of fulfillment without storing the full content of the request, if it is not needed.
Terms of ServicePrivacySubprocessorsBeta terms