Data processing agreement

Draft status and acceptance

Draft for review — 3 November 2026. Not an executed agreement. This document is a proposed data processing agreement (DPA) under Article 28 of Regulation (EU) 2016/679 (GDPR). Publication, visiting a website, or using the platform does not by itself establish acceptance of this draft.

Before it takes effect, both parties must identify themselves, complete and approve the schedules below, and sign the agreement or record its express incorporation into an accepted service agreement. The accepted record must identify the version, customer, authorized representatives and effective date. This draft does not claim that any existing customer, including Pan i Bulka, has already accepted a DPA.

1. Parties and scope

The processor is Mykhailo Paliukh, trading as Aystra, registered as self-employed in Spain, VAT/NIF-IVA ESZ2013340V. Contract and data protection contact: hello@aystra.co. The processor’s business address must be completed in Schedule 1 before acceptance.

The controller is the customer identified in the accepted service agreement and Schedule 1. The controller determines the purposes and essential means of processing its customer information. Aystra acts as processor only for personal data it processes on that controller’s behalf to deliver the agreed service.

The DPA covers the agreed website, ordering or booking platform, customer management, hosting and support services. It does not convert processing for Aystra’s own business administration, billing or legal obligations into processing on a customer’s instructions. Any such independent-controller processing requires a separate lawful basis and privacy notice. A customer acting as processor for another controller must identify that relationship and its authority in Schedule 1.

2. Processing description and duration

Subject matter: operation and support of the customer’s agreed website and platform features. Processing may include collection, recording, organization, hosting, retrieval, display to authorized users, notifications, export, correction, restriction and deletion.

Purposes: fulfilment and management of customer requests, orders or appointments; communication selected by the controller; platform operation and authorized technical support. Exact services, data categories, people affected, processing locations and duration must be completed in Schedule 1. Processing lasts for the accepted service term and the agreed return/deletion period, subject to applicable legal retention.

Only the enabled and authorized services are covered. There is no general authorization to collect health information, other special-category data, criminal-offence data or children’s data. If these are necessary, the parties must first document the relevant instructions, lawful conditions, risks and additional safeguards.

3. Controller responsibilities and instructions

The controller is responsible for lawful purposes, an appropriate legal basis, information to data subjects, required consents, accuracy, data minimization, authorized users and its own statutory record retention.

Aystra shall process personal data only on the controller’s documented instructions, including instructions about transfers, unless EU or Member State law requires otherwise. Where legally permitted, Aystra shall inform the controller of that requirement before processing. Instructions comprise the accepted service agreement, completed schedules and subsequent documented requests from authorized contacts.

Aystra shall immediately inform the controller if, in its opinion, an instruction infringes the GDPR or other EU or Member State data protection law. The parties shall resolve the issue before carrying out the disputed processing. Aystra shall not sell controller data, use it for its own advertising or train general-purpose AI models on it under this agreement.

4. Confidentiality and security

Aystra shall ensure that personnel authorized to process personal data are bound by confidentiality obligations or an appropriate statutory duty. Access shall be limited to people who need it to perform the agreed service.

Aystra shall implement and maintain appropriate technical and organizational measures under GDPR Article 32, taking account of the state of the art, implementation costs, processing characteristics and risks to individuals. The specific measures and evidence must be recorded in Schedule 3 before acceptance, reviewed as risks change and not materially weakened without an appropriate lawful basis and notice.

The schedule must address access control, tenant separation, authentication and credential management, encryption as appropriate, vulnerability management, logging, incident response, backup and recovery, secure deletion and periodic testing. This draft is not evidence of a certification, completed audit or implementation of every listed measure.

5. Subprocessors

Aystra shall not appoint a subprocessor without the controller’s prior specific or general written authorization. The chosen authorization method and initially approved providers must be documented in Schedule 2. An uncompleted schedule is not authorization.

Where general authorization is agreed, Aystra shall give advance written notice of intended additions or replacements, with the provider’s identity, function, locations and relevant safeguards, allowing a meaningful opportunity to object before the new processing begins. The notice period and objection contact must be agreed in Schedule 2. Aystra shall not proceed with disputed processing until the objection is resolved through suitable safeguards, an alternative service or cessation of the affected processing.

Aystra shall impose equivalent applicable data protection obligations on each subprocessor by a binding agreement and remains fully liable to the controller for the subprocessor’s performance of its data protection obligations, as required by Article 28(4).

A provider’s role must be assessed for the particular use. A customer-selected messaging channel is not automatically an approved subprocessor or an EEA-only service. Independent-controller disclosures and safeguards must be addressed separately where applicable.

6. International transfers

Aystra shall process data in the locations approved in the completed schedules. Transfers outside the European Economic Area require documented controller instructions and a valid GDPR Chapter V mechanism before they take place.

The parties shall record the relevant adequacy decision or other applicable mechanism, such as appropriate standard contractual clauses, the correct parties/modules, transfer assessment and any necessary supplementary measures. Aystra shall assist with the information necessary for that assessment and notify the controller of relevant changes or legally permitted government-access requests.

An EU API hostname, EU database region or statement that a product is hosted in Europe does not establish that all support, telemetry, messaging or other processing remains in the EEA. This DPA alone is not a Chapter V transfer mechanism.

7. Assistance and requests from individuals

Taking account of the nature of processing, Aystra shall assist the controller through appropriate measures, insofar as possible, to respond to requests to exercise GDPR Chapter III rights. Aystra shall promptly forward requests concerning controller data and shall not respond on the controller’s behalf except on documented instructions or where legally required.

Taking account of the processing and information available, Aystra shall assist the controller with security obligations, personal data breach assessment and notifications, data protection impact assessments and prior consultation with supervisory authorities under Articles 32–36. The parties shall coordinate quickly enough for the controller to meet its statutory deadlines.

8. Personal data breaches

Aystra shall notify the controller without undue delay after becoming aware of a personal data breach affecting controller data. The notification shall include, as available, the nature of the breach, affected categories and approximate numbers of people and records, a contact for further information, likely consequences and measures taken or proposed to address it.

Information may be provided in phases without undue further delay where it cannot all be supplied at once. Aystra shall preserve relevant evidence, investigate, mitigate the breach and assist the controller. The controller remains responsible for deciding and making its own regulatory and individual notifications, unless another law directly requires Aystra to act. Incident contacts must be completed in Schedule 1.

9. Retention, return and deletion

The controller shall instruct the retention period for each data category in Schedule 1, consistent with its legal duties. This draft does not promise automatic deletion after 12 months. Applicable accounting obligations must not be confused with a blanket justification to retain all customer data indefinitely.

At the controller’s choice, Aystra shall return or delete personal data after the end of the relevant services and delete existing copies unless EU or Member State law requires storage. Return format, deadlines, active-system deletion, backup rotation, notification copies and subprocessor deletion must be agreed in Schedule 1 before acceptance. No unverified deadline is represented as an existing platform capability.

Any legally required retained data shall be limited to the required scope, protected, used only for the applicable legal purpose and deleted when the obligation ends. Any agreed temporary backup retention shall identify the period, access restrictions and restoration procedure, including reapplying valid deletions after restoration. Aystra shall provide written confirmation of completed return/deletion on request.

10. Demonstrating compliance and audits

Aystra shall make available to the controller all information necessary to demonstrate compliance with its Article 28 obligations and shall allow and contribute to audits, including inspections, by the controller or an auditor it mandates.

Reasonable coordination may protect other customers’ confidentiality and service security but must not prevent an effective audit or unlawfully limit supervisory-authority powers. Aystra shall cooperate with competent supervisory authorities as required by law. Neither party may use confidentiality or service terms to obstruct legally required disclosure.

11. Relationship to other agreements

For processing within its scope, the accepted DPA prevails over conflicting service terms on data protection. It does not restrict data subjects’ rights, regulatory powers or liability that cannot lawfully be excluded. If binding standard contractual clauses apply, those clauses take precedence in the event of a conflict.

The applicable service agreement may set the governing law and forum, subject to mandatory EU and national law. Neither this draft nor a link to it replaces the controller’s own privacy notice, cookie choices, legal notice or assessment of its business-specific obligations.

Schedule 1 — Customer-specific processing record

Complete and expressly approve this schedule before acceptance:

Schedule 2 — Provider authorization register

No provider is authorized merely by being named on this page. The completed register must identify the legal provider entity, specific service, data categories, processing/access countries, role, agreement, transfer mechanism and authorization date. Record the notice period and objection process for general authorization.

Repository configuration and deployment documentation identify the following candidates to verify, not a representation of a customer’s active or approved provider list:

Customer analytics and additional integrations must be assessed separately; they are not authorized by omission from this table.

Schedule 3 — Security measures and evidence

Before acceptance, document the actual controls, responsible person, review date and supporting evidence for: authorized access and offboarding; tenant isolation; authentication and secret management; transport and storage protection; secure development and patching; audit logging; monitoring and incident handling; backup/recovery tests; retention/deletion; subprocessor due diligence; and staff confidentiality/training. Identify any gaps and required remediation before processing starts.

Legal basis and review sources

• GDPR, including Articles 28, 32–36 and Chapter V.
• AEPD guidance on the required content of processor contracts.

The completed agreement and the processing it describes require review against actual operations. Contact hello@aystra.co to request completion and acceptance; this page does not certify compliance.