Data Processing Agreement

This Data Processing Agreement ("DPA") forms part of the agreement between the customer entity that accepts these terms ("Customer", "Controller") and WhiteCloud Project S.R.L., a company organised under the laws of Romania ("Orkestr", "Processor"), under which Orkestr provides the deployment platform available at orkestr.eu (the "Service"). The DPA governs Orkestr's processing of personal data on Customer's behalf.

Where the underlying Terms of Service conflict with this DPA, this DPA prevails for matters of data protection.

Capitalised terms not defined here have the meanings given in the GDPR (Regulation (EU) 2016/679). "Personal Data", "Processing", "Controller", "Processor", "Subprocessor", "Data Subject", and "Personal Data Breach" have the meanings given in Articles 4 and 28 GDPR. "Customer Personal Data" means personal data processed by Orkestr on Customer's behalf in connection with the Service.

For Customer Personal Data, Customer is the Controller and Orkestr is the Processor. Customer determines the purposes and means of processing; Orkestr processes Customer Personal Data only on Customer's documented instructions, which are deemed to include the Terms of Service, this DPA, and any reasonable configuration of the Service made by Customer through the dashboard or API.

For data Orkestr collects to operate its own business (account registration, billing, security logging), Orkestr acts as an independent Controller. That processing is governed by the Privacy Policy, not this DPA.

Subject-matter. Provision of the Service: building, deploying, and operating Customer's containerised applications, serverless functions, and managed add-ons (Postgres, Redis) on EU infrastructure.

Duration. The term of the Customer's subscription, plus the retention periods set out in Section 11.

Nature of processing. Storage, transmission, computation, logging, monitoring, backup, and deletion of Customer Personal Data necessary to host and operate Customer's applications. Orkestr does not analyse or access the content of Customer's running applications except where strictly necessary for security investigation or where Customer expressly requests support.

Purpose. To provide the Service as described in the Terms of Service.

Customer determines what personal data flows through its applications. Typical categories include (without limitation):

Data subjects: Customer's end users, employees, contractors, and any natural person whose data Customer chooses to process via applications hosted on the Service.

Personal data: contact details (name, email, phone), account identifiers and authentication data, profile information, content submitted by end users, IP addresses, device and browser metadata, transaction and order records, application logs, and any other personal data embedded in the requests, databases, or environment variables Customer processes through the Service.

Special categories of data. Customer should not use the Service to process special categories of personal data (Article 9 GDPR) or data relating to criminal convictions and offences (Article 10 GDPR) without taking the additional measures required by law and notifying Orkestr in writing in advance. Orkestr does not apply enhanced safeguards by default for such data and may decline to host applications that materially increase its compliance risk.

Orkestr undertakes that it shall:

• Documented instructions. Process Customer Personal Data only on Customer's documented instructions, including with regard to transfers to a third country, unless required to do so by Union or Member State law. In that case, Orkestr will inform Customer of the legal requirement before processing, unless the law prohibits such notice on important grounds of public interest.
• Confidentiality. Ensure that personnel authorised to process Customer Personal Data are bound by appropriate confidentiality obligations (whether by contract or statute) and are trained on data protection.
• Security (Article 32). Implement the technical and organisational measures set out in Section 9 and at orkestr.eu/security.
• Subprocessors. Engage Subprocessors only under the terms set out in Section 8.
• Assistance with data-subject rights. Taking into account the nature of the processing, assist Customer through appropriate technical and organisational measures, insofar as possible, in fulfilling Customer's obligation to respond to requests by Data Subjects exercising their rights under Chapter III GDPR (access, rectification, erasure, restriction, portability, objection). See Section 10.
• Assistance with security and breach obligations. Assist Customer in ensuring compliance with its obligations under Articles 32 to 36 GDPR, taking into account the nature of processing and the information available to Orkestr.
• Deletion or return. At Customer's choice, delete or return all Customer Personal Data to Customer after the end of the provision of services, as set out in Section 11.
• Compliance and audits. Make available to Customer all information necessary to demonstrate compliance with this DPA and allow for and contribute to audits, as set out in Section 12.
• Notice of unlawful instructions. Inform Customer immediately if, in Orkestr's opinion, an instruction infringes the GDPR or other Union or Member State data protection law.

Customer is responsible, as Controller, for:

• Establishing a valid lawful basis (Article 6, and where relevant Article 9) for the processing
• Providing appropriate privacy notices to its Data Subjects
• Responding to Data Subject requests directed at Customer (Orkestr may forward such requests; see Section 10)
• Ensuring its instructions to Orkestr - including configuration choices and content placed in environment variables, code, and databases - comply with applicable data protection law
• Not uploading content that contains malware, materially undermines Orkestr's security, or violates the Acceptable Use Policy
• Conducting any Data Protection Impact Assessment (Article 35) that may be required for its processing

Customer provides general authorisation for Orkestr to engage Subprocessors to assist in providing the Service. The current list of authorised Subprocessors is maintained at orkestr.eu/subprocessors.

Flow-down terms. Orkestr enters a written contract with each Subprocessor imposing data protection obligations equivalent to those in this DPA, in particular obligations to implement appropriate technical and organisational measures and to process personal data only as needed to perform the subprocessed service.

Liability. Where a Subprocessor fails to fulfil its data protection obligations, Orkestr remains fully liable to Customer for the performance of that Subprocessor's obligations, as required by Article 28(4) GDPR.

Notice of changes. Orkestr will notify Customer of intended additions or replacements of Subprocessors by email and by updating the public Subprocessors page at least 30 days before the change takes effect (or as soon as reasonably practicable in the case of an emergency replacement needed to maintain security or continuity of the Service).

Right to object. Customer may object to a new Subprocessor on reasonable data-protection grounds during the notice period by writing to legal@orkestr.eu. If the parties cannot agree a resolution, Customer may terminate the affected part of the Service and receive a pro-rata refund of any prepaid, unused fees.

Orkestr implements appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account the state of the art, the costs of implementation, and the nature, scope, context, and purposes of processing. Current measures include:

• Encryption in transit. TLS 1.2 or higher for all connections between Customers and the Service (web console, API, and Customer application URLs).
• Encryption at rest. Sensitive data is encrypted at rest using authenticated symmetric encryption (Fernet - AES-128-CBC with HMAC-SHA256, via the Python cryptography library). This applies to environment variables, OAuth access and refresh tokens, and managed add-on credentials. User passwords are hashed using bcrypt rather than encrypted. The encryption key is held in our control plane and is not shared with subprocessors.
• Container isolation. User application and serverless function containers are launched with --cap-drop=ALL, --security-opt=no-new-privileges, a process-limit, and per-plan CPU and memory caps. Auto-generated Dockerfiles run as non-root. Managed add-on containers (Postgres, Redis) run with default Docker capabilities and resource caps; they are isolated from user application containers by Docker network segmentation.
• Network segmentation. User application containers run on a dedicated Docker network that does not provide DNS resolution to, or network membership in, the platform's internal services (database, cache, registry, control plane). Platform services run on a separate Docker network.
• Build sandboxing. Builds run via Kaniko in a resource-limited container without Docker socket access and with --security-opt=no-new-privileges; the cloned source-code build context is discarded immediately after each build (whether the build succeeds, fails, or times out).
• Access controls. Multi-factor authentication is enforced on all administrative accounts upstream of the Service (cloud provider, registrar, payment processor, email provider, source-code hosts, object storage).
• Logging and abuse detection. Administrative actions are logged in the platform database (audit log); container and access logs are retained on the originating host with rotation; automated abuse detection runs continuously and notifies the operator on CPU anomaly (sustained >90% CPU), network egress anomaly (high egress with low CPU), and container restart loops.
• Patching. Base container images use pinned major versions and are rebuilt on a regular cadence; host operating systems are patched on a regular cadence.
• Backups. Daily backups of managed add-ons to EU object storage with retention per plan; restore procedures are documented internally.
• Personnel. Confidentiality obligations apply to all personnel with access to Customer Personal Data. A documented incident-response process is in place.

A more detailed description of current controls is published at orkestr.eu/security. Orkestr may update these measures from time to time, provided that the level of security is not materially reduced.

Customer is responsible for responding to Data Subject requests. Orkestr provides Customer with self-service tools through the dashboard and API to:

• Access, modify, and delete Customer Personal Data hosted in managed databases via the connection string Orkestr issues to Customer;
• Delete projects, environments, and managed add-ons, which permanently removes the underlying Customer Personal Data within the timelines set out in Section 11.

For data not directly addressable through these self-service tools (for example, audit log entries that mention the Data Subject, or copies of personal data Orkestr holds about Customer as an account-holder), Customer may submit a written request to privacy@orkestr.eu. Orkestr will respond within 30 days and, where applicable, provide the data in a structured, commonly used, machine-readable format (JSON).

If a Data Subject contacts Orkestr directly with a request relating to Customer Personal Data, Orkestr will not respond to the substance of the request and will, where it can identify the relevant Customer, forward the request to Customer without undue delay. Where Customer needs further assistance that is not available through self-service tooling, Orkestr will provide reasonable assistance taking into account the nature of the processing and the information available to Orkestr. Orkestr may charge a reasonable fee for assistance that is disproportionate to the level of assistance customarily included in the Service.

Customer may delete Customer Personal Data at any time through the dashboard or API. On account termination, expiry of the subscription, or earlier written instruction from Customer:

• Running containers and serverless functions are stopped and destroyed promptly (typically within minutes, in any event within 24 hours)
• Container images, deployment logs, environment variables, application logs, and configuration data are permanently deleted within 30 days
• Managed add-on data (Postgres, Redis) and all associated backups are permanently destroyed when the add-on is deleted
• Source code cloned during builds is deleted immediately at the end of each build

Orkestr is permitted to retain Customer Personal Data where required by applicable Union or Member State law (in particular billing records under Romanian tax law for a period of seven years) and may retain security and access logs containing IP addresses for up to 90 days for legitimate security purposes. Such retained data remains subject to the confidentiality and security obligations of this DPA for as long as it is retained.

On written request submitted before the end of the 30-day deletion window, Orkestr will instead return Customer Personal Data to Customer in a structured, commonly used, machine-readable format (and delete its copies subject to the legal-retention carve-out above).

Orkestr will make available to Customer all information reasonably necessary to demonstrate compliance with its obligations under this DPA. This information will, in the first instance, be provided through:

• This DPA and the published Privacy Policy, Subprocessors page, and Security page
• Responses to written questionnaires from Customer on reasonable due diligence and procurement-review topics
• Where applicable in the future, third-party audit reports (such as ISO 27001 or SOC 2 reports) made available under confidentiality

Where Customer can reasonably demonstrate that the information available is insufficient to demonstrate compliance, Customer (or an independent third-party auditor that is not a competitor of Orkestr and is bound by confidentiality) may conduct an on-site audit of Orkestr's data-processing facilities once per calendar year, at Customer's expense, on at least 30 days' prior written notice, during normal business hours, in a manner that does not unreasonably interfere with Orkestr's operations and that respects the confidentiality and security of other customers' data. The parties will agree the scope of the audit in advance. Audits arising from a regulator's binding order or a documented Personal Data Breach affecting Customer are not subject to the once-per-year limit or the notice period to the extent the regulator or the urgency of the situation requires otherwise.

Orkestr will notify Customer of any Personal Data Breach affecting Customer Personal Data without undue delay and in any event within 72 hours of becoming aware of it. The notification will, to the extent then known, describe:

• The nature of the breach, including where possible the categories and approximate number of Data Subjects and records concerned
• The name and contact details of Orkestr's data-protection contact (legal@orkestr.eu)
• The likely consequences of the breach
• The measures taken or proposed to address the breach and mitigate its possible adverse effects

Where the information cannot be provided at the same time, it will be provided in phases without undue further delay. Orkestr will reasonably cooperate with Customer in investigating and responding to the breach. Notification of a breach is not an acknowledgement of fault or liability by Orkestr.

Orkestr hosts and processes Customer Personal Data within the European Economic Area (EEA). All current Subprocessors are EU/EEA-established and process data within the EEA. If, in the future, Orkestr engages a Subprocessor that processes Customer Personal Data outside the EEA, Orkestr will put in place an appropriate transfer mechanism under Chapter V GDPR - an adequacy decision, the current EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), the EU-US Data Privacy Framework where applicable, or another lawful mechanism - and update the Subprocessors page accordingly.

To the extent the EU Standard Contractual Clauses apply between the parties (Module Two: Controller-to-Processor), they are deemed incorporated into this DPA by reference, with Customer as data exporter and Orkestr (or the relevant Subprocessor) as data importer. The optional docking clause is included; the optional independent dispute resolution by an independent body is not selected; supervisory authority is the Romanian ANSPDCP; governing law is Romanian law; jurisdiction is the courts of Romania. Annex I, II, and III to the Clauses are populated by Sections 4, 5, 9, and the Subprocessors page of this DPA.

Orkestr will not disclose Customer Personal Data to any government authority except as strictly required by binding legal process applicable to Orkestr. Where legally permitted, Orkestr will: (a) inform Customer of the request before disclosure so Customer may seek protective relief; (b) challenge any request that appears overbroad or unlawful; (c) disclose only the minimum data required to comply. Orkestr publishes summary information on government requests if and when it receives any.

Each party's liability arising out of or in connection with this DPA - whether in contract, tort, or under any other theory of liability - is subject to the limitations of liability and exclusions set out in the Terms of Service. Nothing in this DPA limits or excludes either party's liability under Article 82 GDPR (right to compensation for Data Subjects) or any other liability that cannot lawfully be limited or excluded under applicable law.

This DPA takes effect when Customer accepts the Terms of Service and continues until the later of: (a) termination of the underlying agreement; or (b) Orkestr's deletion or return of all Customer Personal Data in accordance with Section 11.

Orkestr may update this DPA from time to time, including to reflect changes in applicable law, new Subprocessors, or changes to the Service. Material changes will be notified to Customer by email at least 30 days before they take effect. If Customer reasonably objects to a material change on data-protection grounds and the parties cannot agree a resolution, Customer may terminate the affected part of the Service for cause and receive a pro-rata refund of any prepaid, unused fees.

This DPA is governed by the laws of Romania, without regard to its conflict-of-laws rules. The courts of Romania have exclusive jurisdiction over any dispute arising out of or in connection with this DPA, without prejudice to mandatory rules of jurisdiction that protect consumers or Data Subjects.

Data protection enquiries, audit requests, Subprocessor objections, and DPA-related correspondence should be sent to:

WhiteCloud Project S.R.L.
Email: legal@orkestr.eu (legal and DPA matters)
Email: privacy@orkestr.eu (privacy enquiries and Data Subject requests forwarded by Customer)
Country of establishment: Romania

Lead supervisory authority: Autoritatea Nationala de Supraveghere a Prelucrarii Datelor cu Caracter Personal (ANSPDCP), Blvd. G-ral. Gheorghe Magheru 28-30, Sector 1, Bucharest, Romania - www.dataprotection.ro.