This Data Processing Agreement ("DPA") is entered into between the customer identified in the order or account registration for the Raysly service ("Customer") and Luxa Energy LTD, a Private company limited by shares registered under HE 482253 in Cyprus, registered office Chrysanthou Mylona 1, PANAYIDES BUILDING, 2nd floor, Flat/Office 1, 3030 Limassol, Cyprus ("Raysly"), and forms part of the agreement between Customer and Raysly governing Customer's use of the Raysly platform (the "Principal Agreement").
1. Roles
Customer is the controller for personal data of its own storefront visitors, leads and customers, its uploaded documents, and any other personal data it submits to or collects through the Raysly platform ("Customer Data"). Raysly is the processor, and processes Customer Data only on Customer's documented instructions as set out in this DPA and the Principal Agreement, except where Raysly is required to do otherwise by Union or Member State law, UK law or Swiss law to which Raysly is subject; in that case Raysly will inform Customer of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.
This DPA does not cover personal data for which Raysly is itself the controller (for example, Customer's own account-holder and billing-contact data) — that is described in the Raysly Privacy Notice.
Leads assigned from the Comparisun marketplace. Where the operator of Comparisun assigns a marketplace lead to Customer, that operator discloses the lead to Customer as a separate controller. From the moment the lead is placed in Customer's account, Customer is its controller and Raysly processes it under this DPA.
Two activities on storefronts fall outside this DPA, because Raysly determines them for its own purposes rather than on Customer's instructions: the shared end-customer login account (linked to the customer's email address across all storefronts and Comparisun), and Raysly's own platform-level analytics and error-monitoring telemetry (PostHog, Sentry, Vercel) captured on storefronts. These are disclosed as Raysly's own controller processing in the Privacy Notice (Section 3a), not under this DPA.
Analytics tags on storefronts — role
For storefront engagement analytics that Raysly runs on Customer's behalf and as Customer configures them (for example, the data shown in the Stats tab), Customer is the controller and Raysly is the processor, as an ordinary processing activity under Annex 1; no joint-controller arrangement applies. This is separate from Raysly's own platform-level analytics and telemetry described above, which Raysly runs as controller under its own Privacy Notice and only with consent given through the storefront's banner.
2. Subject matter, duration, nature and purpose
Subject matter. Raysly's processing of Customer Data as necessary to provide the Raysly platform to Customer, including its tenant storefront hosting, lead capture and CRM, checkout, document storage, communications (email/SMS), calendar/booking, accounting-integration, and (where enabled) content-blind encryption and engagement-analytics features.
Duration. For the term of the Principal Agreement, plus any period during which Raysly retains Customer Data under §8 (Return and deletion).
Nature and purpose of processing. Storing, transmitting, organising, structuring, retrieving, and where instructed, transferring Customer Data as necessary to operate the features Customer has enabled, described in Annex 1.
Categories of data subjects:
- storefront visitors and prospective customers;
- leads (people who submitted an enquiry or calculator result);
- customers with a placed order;
- Customer's own team members, to the extent their data is processed through Customer-configured integrations rather than under the Raysly Privacy Notice directly.
Categories of personal data:
- contact details (name, email, phone, address);
- enquiry and order content (monthly electricity bill, system size preferences, free-text notes);
- documents uploaded by customers to complete an order, which by default in Cyprus include a copy of a photo ID/passport and a copy of a title deed, alongside utility bills — these are sensitive documents and Customer, as controller, is responsible for the lawful basis and necessity of collecting them;
- payment-related metadata. End-customer storefront and marketplace payments run only through Customer's own connected payment provider (for example Mollie Connect) or Customer's own bank account (IBAN) that Customer configures — Luxa Energy LTD is not a party to that payment and does not receive or hold the funds. Raysly does not itself store card or payment-instrument numbers.
- device/browser data and, where Customer has enabled analytics, engagement metrics (pages viewed, time on page, scroll depth, form-step progress) and a daily-salted hash of IP address (not the raw IP);
- support-ticket content and attachments.
No special category data is intentionally solicited by Raysly's platform on Customer's behalf beyond what Customer chooses to collect through free-text fields or document uploads; Customer is responsible for assessing whether any special category data results and for its own lawful basis to collect it.
3. Instructions
Raysly will process Customer Data only on Customer's documented instructions, including with regard to transfers, as set out in this DPA, the Principal Agreement, and Customer's use of the platform's configurable features (which themselves constitute an instruction). If Raysly believes an instruction infringes applicable data protection law, it will inform Customer immediately, and may suspend performance of that instruction pending resolution. Raysly maintains a record of the processing activities it carries out on Customer's behalf, as required by Art. 30(2) GDPR and Art. 12 revFADP.
4. Confidentiality
Raysly ensures that persons authorised to process Customer Data are subject to an appropriate duty of confidentiality (whether contractual or statutory).
5. Technical and organisational measures (TOMs)
Raysly implements the technical and organisational measures described in Annex 2, taking into account the state of the art, costs of implementation, and the nature, scope, context and purposes of processing, as well as the risk to data subjects.
Annex 2 consists of the following measures:
- Hosting: the Raysly platform runs on Vercel, with serverless functions run in Vercel's Frankfurt, Germany (EU) region.
- Primary database: Turso (LibSQL).
- File storage: Cloudflare R2, partitioned per region (Cyprus/UK/Switzerland/global buckets), unless Customer has connected its own storage (Google Drive, OneDrive, Dropbox or Amazon S3), in which case files are stored in Customer's chosen location under Customer's own account.
- Encryption in transit: HTTPS/TLS is enforced (HTTP Strict Transport Security, including subdomains).
- Encryption at rest (server-held keys): Customer's integration OAuth tokens and cloud-storage keys are encrypted with AES-256-GCM under an internally managed key. TOTP two-factor secrets are separately encrypted. Other Customer Data in the primary database is not encrypted at application level; it relies on the hosting providers' storage-level controls.
- Password hashing: the partner portal uses passwordless sign-in (magic link, SMS one-time code, passkey, TOTP, social login). Where a legacy password credential exists in the marketplace login system, it is hashed and salted.
- Content-blind (zero-knowledge) encryption: available as an opt-in feature per tenant. Where enabled, specified fields (at minimum, order notes; lead details where Customer has enabled encryption for leads) are encrypted client-side before leaving Customer's browser, with a key derived from Customer's passphrase in Customer's browser, which Raysly does not receive. At activation Customer receives a recovery card that alone is sufficient to reconstruct the key. Raysly holds no recovery share. Raysly stores a salt, a passphrase verifier and Customer's key material wrapped under the passphrase-derived key (PBKDF2-SHA256, 600,000 iterations; minimum passphrase length 12 characters), so the confidentiality of encrypted content depends on the strength of Customer's passphrase and on Customer's safekeeping of the recovery card. Separately, Customer can give a named administrator access to a specific record through a Customer-initiated, time-boxed "break-glass" process that re-wraps that record's key. This is not Raysly's default configuration and does not apply to data outside the enabled scope.
- Access controls: role-based access (owner/admin/manager/staff/viewer) for Customer's own team. Where Raysly support staff impersonate a Customer account, the session is time-boxed (15 minutes absolute, 5 minutes idle), requires a stated reason, logs write actions, and triggers a summary email to Customer.
- Network/application security: A Content-Security-Policy is applied.
- Tenant data isolation: by default, Customer Data resides in a shared database alongside other partners' data, logically separated by tenant identifier. Physically dedicated infrastructure is available on Enterprise plans, or, on request, on other paid plans, but is not Raysly's default architecture.
- Backups: full database backups are produced automatically and stored in Cloudflare R2 on a rotating schedule (7 daily, 4 weekly, 6 monthly), so a deleted record may persist in backups for up to approximately 6 months. Backup files are protected by the storage provider's controls and are not additionally encrypted by Raysly.
6. Subprocessors
Customer authorises Raysly to engage the subprocessors listed in the Subprocessor Schedule as of the effective date of this DPA (general authorisation).
Change notice. Raysly will give Customer notice of any intended addition or replacement of a subprocessor at least 30 days before the change takes effect, by email to the account owner and by publishing an updated Subprocessor Schedule with a visible "last changed" date. Customer may object on reasonable data-protection grounds within that period; if Customer objects and the parties cannot agree on a resolution, Customer may terminate the affected service without penalty, and Raysly will refund any prepaid fees for the period after termination.
Raysly imposes on each subprocessor, by written agreement, the same data protection obligations as set out in this DPA, in particular sufficient guarantees to implement appropriate technical and organisational measures, and remains fully liable to Customer for the performance of each subprocessor's obligations.
7. Assistance with data subject rights and DPIAs
Taking into account the nature of the processing, Raysly will assist Customer, insofar as reasonably possible, in responding to requests from data subjects to exercise their rights, contacting Raysly at support@raysly.com with the request. Taking into account the nature of processing and the information available to it, Raysly will assist Customer in ensuring compliance with Customer's obligations on security of processing, personal data breach notification to supervisory authorities and communication to data subjects, data protection impact assessments and prior consultations with supervisory authorities (Arts. 32-36 GDPR and the equivalent revFADP and UK GDPR provisions).
8. Breach notification
Raysly will notify Customer without undue delay after becoming aware of a personal data breach affecting Customer Data, providing the information available to it at the time regarding the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed to address it. Where full information is not available immediately, Raysly will provide it in phases without further undue delay. Raysly will provide this notice within 48 hours of becoming aware of the breach — deliberately shorter than the 72-hour regulator-notification deadline that then applies to Customer as controller, so Customer has time to assess and notify.
9. Deletion and return
At Customer's election, made in writing within 30 days of termination of the Principal Agreement, Raysly will return Customer Data to Customer in a commonly used format (a self-service ZIP archive covering both structured data and uploaded file contents, or a JSON-only export), or delete it. If Customer makes no election within that window, Raysly will delete Customer Data within a further 30 days. In either case Raysly will delete existing copies unless Union or Member State law, UK law or Swiss law requires Raysly to retain it (for example, financial/tax records, retained for the statutory accounting period described in the Raysly Privacy Notice — 10 years in every country). Copies in backups are overwritten on the rotation described in Annex 2 (up to approximately 6 months) and are not restored into live systems except to recover from an incident.
10. Audits
Raysly will make available to Customer information reasonably necessary to demonstrate compliance with this DPA (for example, a current copy of the Subprocessor Schedule and, where available, third-party audit or certification summaries), and will allow for and contribute to audits, including inspections, conducted by Customer or an auditor mandated by Customer, subject to reasonable advance notice, confidentiality, scope limited to matters within this DPA, and no more than once per year absent cause, on 30 days' advance notice, preceded by a written questionnaire, and at Customer's cost unless the audit finds a material breach of this DPA, in which case Raysly bears its own reasonable costs. Raysly may satisfy an audit request by providing a recent third-party audit report addressing substantially the same controls, where one exists. Raysly does not currently hold such a report. Nothing in this section limits an audit or inspection by a competent supervisory authority.
11. International transfers
No transfer mechanism is needed for transfers within the EU/EEA, or to a country covered by an adequacy decision or finding under the applicable law. Any other transfer of Customer Data out of the EU/EEA, the UK or Switzerland is made only under an appropriate transfer mechanism:
- EU/EEA exports: the European Commission's Standard Contractual Clauses. Where Customer exports to Raysly and Raysly is established in a country without an adequacy decision, Module 2 (controller to processor) applies between Customer and Raysly and is incorporated by reference. Onward transfers from Raysly to subprocessors are covered by Module 3 (processor to processor) or another valid mechanism in Raysly's contracts with those subprocessors, as described in Annex 4.
- UK exports: the UK International Data Transfer Agreement or the UK Addendum to the EU SCCs.
- Swiss exports: the Swiss Federal Data Protection and Information Commissioner's recognised adaptation of the SCCs (the "Swiss addendum"), together with the Federal Council's list of countries recognised as providing adequate protection.
Annex 4 sets out how transfers to subprocessors are safeguarded.
12. Liability
Each party's liability under this DPA is subject to the liability provisions of the Business Terms of Service (Section 13), except that nothing in this DPA or the Business Terms of Service limits or excludes: (a) a party's liability for its own regulatory fines resulting from its own breach of data protection law; (b) either party's liability to a data subject under Art. 82 GDPR (each party remaining responsible for its own share of any joint liability, with a right of contribution between them); or (c) any other liability that cannot be limited or excluded under applicable law, including Art. 100(1) OR for Swiss-law agreements.
13. Precedence
In the event of a conflict between this DPA and the Principal Agreement concerning the processing of personal data, this DPA prevails. Where a Standard Contractual Clause or other statutory transfer instrument applies, that instrument prevails over any conflicting provision of this DPA or the Principal Agreement to the extent required by its own terms.
14. Term and changes
This DPA remains in effect for as long as Raysly processes Customer Data on Customer's behalf. Raysly may update this DPA to reflect a change in applicable law, a new subprocessor authorisation mechanism, or an operational change. Raysly will give Customer at least the notice required for changes to the Principal Agreement (and never less than 15 days) before a material change takes effect. No change may reduce the level of protection for Customer Data or Customer's rights under this DPA without Customer's agreement. If Customer objects to a material change, Customer may terminate the affected service before it takes effect, with a refund of prepaid fees for the period after termination. Acceptance of a new DPA version is recorded against Customer's account in the append-only acceptance evidence log, together with a hash of the exact text shown, a timestamp and the accepting user's identity, so a specific acceptance can always be matched to the exact terms accepted, not just a version label.
Annex 1 — Processing particulars
- Subject matter: provision of the Raysly platform (see §2).
- Duration: term of the Principal Agreement, plus retention under §9.
- Nature and purposes: see §2.
- Data subjects: storefront visitors, leads, customers, Customer's team members (where processed through Customer-configured integrations).
- Data categories: see §2, including uploaded ID/title-deed documents where Customer's default checkout configuration requests them.
- Customer instructions and authorised contacts: the account owner and any team member with the
adminrole, as recorded in Customer's account at the time an instruction is given.
Annex 2 — Technical and organisational measures
See §5 above.
Annex 3 — Authorised subprocessors
See the Subprocessor Schedule, incorporated by reference and updated per §6.
Annex 4 — Transfer mechanisms
Where a subprocessor listed in the Subprocessor Schedule processes Customer Data in a country that is not covered by an adequacy decision or finding under the applicable law, Raysly relies on the transfer mechanisms described in §11 for that transfer. On request, Raysly will tell Customer which mechanism applies to a specific subprocessor.
