Devella One™ -Data Processing Agreement (DPA)

Näytä suomeksi

Version 2026-09-14 — effective from the date of acceptance

This DPA was originally drafted in Finnish. In case of any conflict between the Finnish and English versions, the Finnish version shall prevail.

1. Parties and scope

This data processing agreement (hereinafter the DPA) is entered into between Devella Oy(Business ID 3288286-1, Kokkola, Finland; hereinafter the Processor) and the customer using the Devella One™ service (hereinafter the Customer).

The Customer may be either an end customer of Devella One who uses the service on its own website to process visitor data, or a reseller/partner agency (hereinafter an Agency) that manages the websites of several of its own end customers through Devella One. If the Customer is an Agency, section 4.2 and its related terms apply to it in addition to this DPA. In all other respects this DPA applies equally to both types of Customer.

This DPA covers all processing of personal data that the Processor carries out on behalf of the Customerin providing the Devella One service and its associated administration.

2. Relationship to other agreements

This DPA forms part of the service agreement between Devella Oy and the Customer and supplements it withrespect to the processing of personal data in accordance with Article 28 GDPR.

• If there is a separate written service agreement between Devella Oy and the Customer, this DPA is an appendix to it. In matters concerning the processing of personal data, the terms of this DPA prevail over the other terms of the service agreement in the event of conflict.
• If there is no separate written service agreement between Devella Oy and the Customer, this DPA, together with the service's order confirmation and the administration's terms of use, constitutes the agreement between the Parties concerning the processing of personal data.

The acceptance of the terms of use requested from a user when logging in to the Devella One administration is a per-user acceptance and does not replace the organisation-level agreement, or its acceptance, referred to in this section. The organisation-level acceptance is carried out as an electronic acceptance in the administration in accordance with section 18.

3. Definitions

This DPA uses the definitions of personal data, processing, controller, processor, sub-processor, data subject and personal data breach set out in the General Data Protection Regulation (EU) 2016/679 (GDPR). In addition, in this DPA:

• Service: the Devella One™ website and content management service, including its administration.
• Site: a website published and maintained by the Customer using the Service.
• Admin: the Service's management interface used to administer a Site and to view the data it produces.
• Agency (reseller/partner agency): a Customer that manages the Sites of several of its own End Customers within the Service.
• End Customer: an Agency's own customer whose Site the Agency manages within the Service.
• Sub-processor: a party engaged by the Processor to assist in the processing of personal data on behalf of the Customer.

4. Roles of the Parties

4.1 Customer as controller, Devella as processor (default situation)

When the Customer collects personal data of visitors or other data subjects on its Site, for example through a form, a booking, or in connection with a payment, the Customer acts as controller and determines the purposes and means of the processing. The Processor processes such data on the Customer's documented instructions as a processor within the meaning of Article 28 GDPR.

4.2 Customer as an Agency

Devella One has technical capability for an Agency model, in which a reseller/partner agency manages theSites of several of its own End Customers under a single Agency account. This section applies only if the Customer has entered into an agreement with the Processor concerning an Agency arrangement.

When the Customer acts as an Agency, the Agency is a processor authorised by the controller in relation to its own End Customers, and Devella Oy acts as a sub-processor of the Agency. In this arrangement:

• The Agency warrants to the Processor that it has obtained sufficient authorisation from each of its EndCustomers (as controller) to give the Processor instructions concerning the processing of personal data andto approve the Processor's use as a sub-processor.
• The Agency has its own, separate data processing agreement with each of its End Customers. This DPA does not replace that agreement and is not a party to it.
• In accordance with the Service's access model, Agency members have access to the data of all the Sites they manage, including form submissions, bookings, AI conversations and media, unless a restrictive direct access right has been separately recorded for an individual Site or End Customer. The Agency is responsible for ensuring that its own members process End Customers' data only within the scope of their authorisation.
• Agency-level access does not grant the right to add content to a Site that is treated as trusted (such as scripts or iframe embeds); that right is reserved for the Processor's developer accounts.
• An Agency-level API token can be used to access the Sites the Agency manages. The token is not bound toa single Site; the target is selected per request via a separate header, and the server only accepts Sites whose End Customer belongs to that Agency. Every request verifies the validity of the token creator's account, the Agency's active status, the creator's membership in the Agency, and the Site's current Agency. The token expires after one year at the latest and can be revoked. The Agency is responsible for the careful safekeeping of its tokens, since a single token covers all of the Agency's Sites.
• An Agency's own template library is a shared resource within the Agency. Content saved to a template may therefore also be available on the Sites of the Agency's other End Customers. The Agency is responsible for ensuring that no personal data is saved to templates.
• Transferring an End Customer from one Agency to another, or out of Agency management, takes effect immediately: the former Agency's access to the Site's data ends and the new Agency's access begins at the same moment. The transfer is agreed with the controller in advance and is recorded in the Service's billing history.
• The Agency is responsible for forwarding to its own End Customers, without undue delay and within the time limits required by its own agreements, the sub-processor change notifications under section 8 and the personal data breach notifications under section 11 that it receives from the Processor. The Agency is responsible for ensuring that its agreements with its End Customers are compatible with the notice period under section 8.
• An End Customer's audit right under section 12 is exercised through the Agency: the End Customer submits its audit request to the Agency, which exercises the audit right under this DPA on the End Customer's behalf. The Processor has no direct contractual relationship with the End Customer.

If the End Customer is itself a direct contracting customer of Devella Oy and the Agency merely manages the Site on the End Customer's behalf, section 4.1 applies: the End Customer is the controller and the Processor is its processor. The Agency's users then act as users authorised by the Customer. The Customer is responsible for ensuring that the access granted to the Agency corresponds to the agreement between the Customerand the Agency, and that a separate data processing agreement exists between the Customer and the Agency where necessary.

4.3 Devella as controller for its own purposes

Devella Oy acts as an independent controller when processing data of the Customer and of the Service's users for its own purposes, such as managing user accounts and logins, billing, customer support, the Service's information security, and the development of the Service. The purposes, legal bases and rights of data subjects concerning this processing are described in Devella One's privacy notice (devella.fi/devella-one-tietosuoja). This DPA does not cover this processing carried out by Devella Oy in its own capacity as controller.

The Service's audit log contains both event data (the actor, the time, the action, the target and a protected IP hash) and, for each event, change data. Devella Oy is the controller of the audit log's event data for reasons of the Service's information security and traceability. However, the change data may contain personal data of data subjects whose information was collected on the Customer's Site (for example, data entered by the person who edited a form submission), and with respect to that change data DevellaOy acts as the Customer's processor, not as controller. The change data is deleted when the Site is physically deleted under section 13, even though the event row itself is retained for traceabilityuntil the end of the audit log's retention period described in section 13.

5. Processing only on documented instructions

The Processor processes personal data only in accordance with the documented instructions of the Customer (or, under the arrangement described in section 4.2, of the Agency), unless required otherwise by Union orMember State law applicable to the Processor. In such a case, the Processor shall inform the Customer of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest. The following are considered documented instructions:

• the service agreement between the Parties and this DPA;
• settings the Customer makes itself in the Admin that govern processing, such as a form's retention period, calendar integration settings, or the granting of access rights; and
• written support requests addressed by the Customer to the Processor.

If the Processor considers that an instruction given to it infringes applicable data protection law, theProcessor shall inform the Customer of this without delay before carrying out the instruction.

Special categories of personal data within the meaning of Article 9 GDPR, and other sensitive data (suchas national identity numbers, payment instrument data, health data, or confidential employment and financial data, for example salary, credit or performance appraisal data), must not be entered into the AI assistant. The Customer is responsible for compliance with this restriction by its own users and its End Customers.

6. Confidentiality and personnel

The Processor ensures that persons with access to personal data have committed to confidentiality eithercontractually or under a statutory duty of confidentiality. Access to personal data is granted only to the extent required by the task at hand. The Processor's developer accounts, which have access to all Customers'Sites, are required to use multi-factor authentication (MFA) at all times.

7. Security

The Processor implements appropriate technical and organisational measures for the protection of personal data in accordance with Article 32 GDPR. A description of these measures is set out in Appendix 2 to this DPA.

8. Sub-processors

The Customer gives the Processor a general written authorisation to use sub-processors in the processingof personal data. The sub-processors currently in use are listed in Appendix 3 to this DPA.

The Processor shall notify the Customer at least 30 days before engaging a new sub-processor that will process the Customer's personal data. The Customer has the right to object to the engagement of a new sub-processor on reasonable data protection grounds by notifying the Processor within the notice period. If the Parties are unable to reach agreement on the matter, either Party may, as a result of such objection, terminatethe service agreement or, if there is no separate service agreement, the subscription to the Service to theextent that the sub-processor in question is used.

The Processor is liable for the acts of its sub-processors to the same extent as for its own acts, and agrees with each sub-processor on data processing obligations equivalent to those set out in this DPA.

For the avoidance of doubt, the language model used in the AI feature may change via OpenRouter without a separate change notification as described above, provided the request is routed to an inference provider listed in Appendix 3: the sub-processor chain does not change in that case. Adding a new provider not listed in Appendix 3 to the routing restriction is, by contrast, a new sub-processor within the meaning of this Section 8 and requires the 30-day change notification described above.

Services that the Customer chooses and connects to a Site itself — such as the Customer's own SMTP server, analytics services the Customer enables, CAPTCHA services, embeds, or JavaScript injected into a Site — are not sub-processors of the Processor. They are the Customer's own service providers, for whose selection, use and lawfulness the Customer alone is responsible.

9. Rights of data subjects

The Processor assists the Customer in the exercise of data subjects' rights, taking into account the nature of the processing. For this purpose the Service provides, among other things, the following tools for the Customer's own use:

• export and management functions for a Site's content and media files;
• review and editing of form submissions, bookings and other collected data in the Admin; and
• a per-form retention period for form submissions, which the Customer can use to limit data retention also as a result of a data subject's request.

Since visitors to a Site, form respondents, bookers and payers typically submit requests concerning their rights without being aware of the Processor's role, such requests should primarily be addressed to the Customer as controller. If a data subject addresses a request directly to the Processor, the Processor shall notify the Customer of the request without undue delay and direct the data subject to the Customer.

10. Assistance with obligations under Articles 32–36 GDPR

The Processor assists the Customer, to a reasonable extent and taking into account the nature of the processing and the information available to the Processor, in fulfilling the following obligations of the Customer:

• ensuring security of processing (Article 32 GDPR);
• notification of a personal data breach to the supervisory authority and to data subjects (Articles 33–34 GDPR);
• carrying out a data protection impact assessment (DPIA) (Article 35 GDPR); and
• prior consultation with the supervisory authority (Article 36 GDPR).

Assistance is provided principally by giving the Customer the information on processing and safeguards described in the appendices to this DPA, and by responding to the Customer's written follow-up questions. Theduty to assist does not extend the Processor's liability for the Customer's own obligations as controller, nor does it require the Service's functionality to be expanded beyond what existed at the time this DPA was accepted.

11. Notification of personal data breaches

The Processor shall notify the Customer of a personal data breach without undue delay. For a breach detected in the Processor's own systems, the aim is to notify within 48 hours and in any case no later than 72 hours after the Processor becomes aware of the breach.

The notification shall include the following, to the extent known to the Processor at the time:

• a description of the nature of the personal data breach;
• an estimate of the categories and approximate number of data subjects concerned, and of the categories and approximate number of personal data records concerned;
• an estimate of the likely consequences of the breach; and
• a description of the measures already taken and proposed to address the breach and mitigate its possible adverse effects.

The notification and related communication take place via the contact persons identified in section 18, or via a contact person otherwise notified in writing by a Party.

12. Audit

The Processor demonstrates compliance with its obligations under this DPA primarily by providing the Customer with relevant documentation and by responding in writing to questions raised by the Customer.

If the Processor holds, at the relevant time, a valid audit report or information security certificationissued by an independent third party, the Processor may satisfy the Customer's request under this section by providing that report or certification.

The Customer additionally has the right to commission or carry out an on-site inspection no more than once per calendar year. The inspection must be notified to the Processor in writing at least 30 days in advance, and shall be carried out in a manner that does not unreasonably disrupt the Service for the Processor's other customers. The Customer is responsible for the costs of the inspection.

The following conditions also apply to the inspection:

• An external auditor mandated by the Customer may not be a competitor of the Processor. Persons taking part in the inspection shall be bound by written confidentiality obligations before the inspection begins.
• The inspection concerns whether the Processor complies with its obligations under this DPA in respect of the Customer's personal data. The inspection does not grant access to the personal data of the Processor'sother customers, to the contents of production systems, or to the source code of the Service, to the extentsuch access would compromise the security of the Service or the confidentiality of other customers' data. In such cases the Processor shall demonstrate those matters by other means, for example through documentationor a supervised demonstration.
• If the inspection identifies a deficiency that is contrary to this DPA, the Processor shall remedy it without undue delay at its own cost.

The Processor's ability to pass through the Customer's audit right to its own sub-processors is limited to what the agreement between the Processor and the sub-processor in question allows.

13. Duration of processing, return and deletion

The Processor processes personal data for as long as the service agreement or the subscription to the Service is in force, and thereafter for the duration of the deletion process described in this section.

Before the agreement ends, the Customer may export the content and media files of a Site for itself using an export function provided by the Processor (such as the Devella CLI).

Form submissions are permanently deleted (hard delete) from the database once the applicable retention period for each form expires, as part of the Service's ordinary scheduled cleanup, regardless of whether the agreement is still in force. If a form's retention period is set to 0, no automatic time-based deletion is carried out at all. At the Customer's request, the Processor will delete form submissions before the retention period expires, either by changing the retention setting or as a separate deletion action.

A file marked as deleted from the media library is permanently deleted from both the database and the storage service 30 days after the deletion marking, including any earlier versions of the file that may have been retained in the storage service. Within the 30 days, the deletion can be cancelled at the Customer's request, provided that permanent deletion has not yet been carried out.

An AI assistant conversation is permanently deleted 90 days after the conversation's most recent message, as part of the Service's ordinary scheduled cleanup.

When the agreement ends, the Site and the Customer relationship are marked as deleted immediately. This marking prevents further use and processing of the Site but does not mean the immediate physical deletion of data from the database or storage.

Physical deletion takes place within 60 days of the marking. Physical deletion permanently removes:

• the Site's content, media files and version history, including files in the storage service (object storage);
• form submissions, including their attachments;
• bookings;
• AI assistant conversations; and
• other Site-specific data.

Physical deletion does not apply to the following, which the Processor retains even after deletion:

• the audit log's event data, which the Processor retains for no more than 12 months from the recording of the event for reasons of traceability (Devella Oy is the controller of this event data inaccordance with section 4.3); however, the change data associated with an event is deleted immediately uponthe Site's physical deletion, because with respect to that change data Devella Oy acts as the Customer's processor (see section 4.3);
• billing records required under Finnish accounting law; and
• the acceptance record of this DPA (the accepted contract text, the accepting user account, the stated name and position, the authority confirmation and the timestamp), which the Processor retains in order to meet its accountability obligation as evidence that the contract was concluded.

Any copies that may remain of previously deleted or marked-for-deletion data are removed from backups nolater than within 90 days, through the normal backup rotation cycle, not through a separate action. Backups are encrypted at rest using the storage provider's (Google Cloud) default encryption.

Within the 60-day period, the Processor may, at the Customer's request, cancel the deletion and restore the Site to use, provided that physical deletion has not yet been carried out.

The above describes the technical implementation of the Service at the time this DPA takes effect. The Processor does not retain personal data for longer than the process described above, or applicable law, requires.

14. Transfers to third countries

Transfers of personal data outside the European Union and the European Economic Area, and the transfer mechanisms applied to them, are described in Appendix 4 to this DPA.

15. Liability and damages

The liability of each Party for a breach of this DPA is determined primarily in accordance with the liability and limitation-of-liability terms of the service agreement between the Parties, if such a separate written service agreement exists between Devella Oy and the Customer as referred to in section 2.

If there is no such separate service agreement between Devella Oy and the Customer, the Processor's total liability under this DPA is limited to an amount equal to the service fees paid by the Customer for the Service during the twelve (12) months preceding the event giving rise to liability.

The above limitation of liability does not apply to: a data subject's right to compensation under Article 82 GDPR; administrative fines imposed by a supervisory authority to the extent they result from a Party's own breach; or damage caused intentionally or through gross negligence. Neither Party is liable to the otherfor indirect damages, unless mandatory law provides otherwise.

When the Customer acts as an Agency within the meaning of section 4.2, the Agency is liable to the Processor for claims that End Customers or their data subjects bring against the Processor that result from the Agency's own breach or from the Agency lacking the End Customer authorisation required under section 4.2.

16. Term and amendments

This DPA remains in force for as long as the Processor processes personal data on behalf of the Customer, irrespective of the otherwise remaining term of the service agreement.

The Processor may update this DPA, for example due to changes in legislation, guidance from a supervisory authority, or the development of the Service. Changes are handled as follows:

• A material change — for example, a change to the Parties' rights or obligations, the allocation of liability, or the purpose of processing — requires the Customer's new acceptance in the Admin under section 18. Until the Customer has accepted the new version, the version of this DPA that the Customer most recently accepted, and whose text and checksum were recorded under section 18, applies between the Parties.
• A change that is not material, such as a technical clarification or an update to the sub-processor list referred to in section 8, takes effect 30 days after the Processor notifies the Customer of the change, unless the Customer objects to the change on reasonable data protection grounds before that time. If the Customer objects, the procedure under section 8 applies as appropriate, including the Parties' right of termination described there.
• A change required directly by a statutory obligation of the Processor takes effect within the timeframerequired by that legislation, regardless of the above.

Each version is identified by a version number and effective date at the beginning of this document.

17. Governing law and dispute resolution

This DPA is governed by the laws of Finland. Disputes arising from this DPA shall primarily be resolved through negotiations between the Parties. If no resolution is reached through negotiation, the dispute shallbe settled in the first instance by the District Court of Keski-Pohjanmaa (Keski-Pohjanmaan käräjäoikeus).

18. Parties and acceptance

This DPA is accepted through an organisation-level electronic acceptance carried out in the Admin. This is an organisation-level acceptance and is not replaced by the Admin's per-user acceptance of the terms of use referred to in section 2, nor does acceptance of the terms of use replace this acceptance.

Acceptance may be given by a person who represents to the Service that they hold signatory authority, oran equivalent authorisation, to bind the organisation they represent (the Customer) to this DPA. The Service records at least the following as evidence of acceptance: the accepting person's user account; the name and position they provided; the authorisation statement they gave; the timestamp of acceptance; the accepted version of the DPA; the contract text as it stood at the time of acceptance, verbatim; and its SHA-256 checksum.

This DPA takes effect for the Customer on the date of acceptance.

Detail	Processor
Name	Devella Oy
Business ID	3288286-1
Contact person	Panu Haaraniemi
E-mail	panu.haaraniemi@devella.fi

Appendix 1 — Description of processing

This appendix describes the processing in accordance with Article 28(3) GDPR.

Subject matter and duration of processing

The subject matter of the processing is the provision of the Devella One service to the Customer, including Site administration, forms, booking, payments, the AI assistant and calendar integrations. Processing lasts for the term of the service agreement and for the duration of the deletion process described in section 13 after it ends.

Nature and purpose of processing

The purpose of the processing is to enable the operation of a Site and the storage, display, editing andmanagement in the Admin of data collected by the Customer on the Site, in accordance with the features the Customer has chosen.

Categories of data subjects

• visitors to a Site, form respondents, bookers and payers;
• persons of the Customer, and where applicable the Agency, who use the Admin; and
• persons connecting a calendar integration to the Service.

Categories of personal data

• user and account data (for example name, e-mail, role, login and authentication data);
• Site content and media data;
• form submissions;
• bookings;
• payment transactions (excluding secret payment instrument identifiers);
• technical and security data (for example protected IP hashes, session and log data);
• AI assistant data (Admin users' conversations and related content);
• calendar integration data; and
• Agency memberships and related billing data, where section 4.2 applies.

Special categories of personal data

The Service is not designed or intended for the processing of special categories of personal data referred to in Article 9 GDPR. If the Customer collects such data through its own forms or other content, the Customer is responsible for ensuring that there is an appropriate legal basis for the processing and that the processing is otherwise lawful. For the AI assistant, entering such data and other sensitive data is entirely prohibited as described in section 5.

Processing operations

Processing includes the storage, retention, editing and display of personal data in the Admin and on a Site, its transfer to the sub-processors described in Appendix 3, and its deletion.

Retention periods

Data category	Retention period
Form submissions	365 days by default, selectable per form by the Customer from 0–3650 days
E-mail delivery log (email_log)	180 days
Admin session	30 days sliding, 90 days absolute maximum
Content autosave revisions	7 days
Public site cookie consent (dv:consent)	180 days, stored in the visitor's own browser
Site content and version history	for the duration of the customer relationship; physical deletion within 60 days of the deletion marking made when the agreement ends (see section 13)
Media files	for the duration of the customer relationship; a file removed from the media library is deleted from the database and the storage service, including earlier versions, 30 days after the deletion marking (see section 13)
AI assistant conversations	90 days after the conversation's most recent message (see section 13)
Audit log	event data for at most 12 months from the event; change data is deleted when the Site is physically deleted (see sections 4.3 and 13)
Agency memberships and Agency-level API tokens	for the duration of the membership or token validity; token valid for at most 365 days

Appendix 2 — Technical and organisational measures

This appendix describes the measures implemented by the Processor in the implementation of the Service in accordance with Article 32 GDPR.

Access control and authentication

• Passwords are stored as Argon2id hashes, and login comparison is performed in constant time even when the account does not exist, so that the existence of an account is not revealed.
• An Admin session is an opaque identifier stored in the database only as a one-way hash. The session cookie is HttpOnly, Secure and SameSite=Lax, and the __Host- prefix is used in production. A separate CSRF verification cookie is intentionally readable from the Admin front end, since its value is sent in a request header; it does not contain personal data and does not by itself grant access to the Service.
• Cross-site request forgery (CSRF) is mitigated by Origin/Referer verification and a separate verification token on every state-changing request.
• Multi-factor authentication (TOTP) is available and is mandatory for the Processor's developer accounts.
• Sensitive actions require a recent (less than 15 minutes old) re-authentication.
• API tokens are stored in the database only as a one-way hash; the full token is shown to the user only once, at the time of creation.
• Login attempts are rate-limited both by e-mail address and by source IP, and repeated failed attempts result in a time-limited account-level lockout.

Encryption

• Data in transit is protected with TLS.
• Sensitive secrets (such as the Customer's SMTP passwords, calendar integration OAuth tokens, and payment integration credentials) are encrypted at rest using strong, versioned key management, where the encryptedvalue is bound to the identifier of its subject and cannot be copied to another record.
• A form sender's IP address is not stored in raw form: a protected hash (HMAC) is derived from it.

Tenant isolation

Site-level data isolation (multi-tenant environment) is implemented through three complementary layers:

• database-level helper routines always require a valid site identifier and cannot form a query without one;
• an automated code review/quality rule prohibits direct database queries against tenant-scoped tables anywhere in the application other than in the helper routines reserved for that purpose; and
• an automated test suite runs the Admin's endpoints in an incorrect site context and verifies that no data is returned.

Input sanitisation and content security

• Site content is sanitised at save time, by default stripping scripts, iframes and other potentially harmful elements; broader rights are restricted to the Processor's developer accounts.
• Uploaded SVG files are always sanitised separately before storage.
• The Site's optional templating language (Liquid) is executed in a time-limited sandbox.
• Uploaded media files are checked against a list of permitted file types, file size is capped, and EXIF metadata (including location data) in raster images is always stripped during re-encoding.

Logging and traceability

• Admin actions are recorded in an audit log that includes the actor, any impersonator, the action, the target and the change data, along with a protected IP hash.
• Before storage, log entries are redacted to remove fields that appear, by name, to contain passwords, secrets or other identifying data.
• Impersonation carried out by the Processor's staff (logging in as a Customer's user for support purposes) requires a documented reason recorded in the audit log and a recent re-authentication, and is shown in the log separately with the identifier of the actual actor.

Availability and recovery

• The status of the Service and of customer domains is monitored by a scheduled technical check, and the publishing process waits for a passing health check before changes are made live.
• A regular backup (mysqldump) is taken of the database and transferred to separate storage. Object versioning is enabled in the media file storage, and the cache service's state is backed up by its own mechanism.Backups are retained for no more than 90 days, after which they are removed through the normal backup rotation cycle; copies of previously deleted or marked-for-deletion data are therefore removed from backups no later than within 90 days. Backups are encrypted at rest using the storage provider's (GoogleCloud) default encryption. No commitment is given in this DPA as to the frequency of restore drills.

Development and release practices

• An automated test suite, as well as code style and type checks, are maintained for the Service and run during development before changes are released.
• Development, testing and production environments are separated from one another.

Management of sub-processors

The Processor maintains a list of the sub-processors it uses (Appendix 3) and evaluates their use as part of the Service's development. Data passed to background service providers for the AI feature is restrictedby forcing, on every request, a setting that prohibits the use of the data to train models. In addition, OpenRouter has committed to a Zero Data Retention policy, under which API payloads are not permanently retained after a request and response have completed, except for momentary in-memory processing, short-term buffering, and data required by law. OpenRouter itself states that marking an inference provider as Zero Data Retention eligible does not constitute OpenRouter's guarantee of that inference provider's compliance; the Processor accordingly does not guarantee an individual inference provider's practices, but sets the requirement and routes requests accordingly.

Appendix 3 — Sub-processors

The sub-processors listed in this appendix take part in the processing of personal data to the extent that the functionality they represent is in use. This list is dated, and its current version is published on this page. List updated 14 September 2026.

The location column describes the provider's principal place of processing, and the transfer mechanism column states the basis on which processing outside the European Economic Area is carried out; see Appendix 4for details. Each provider's contracting party, processing locations and transfer mechanisms must be verified from that provider's current data processing agreement. OpenRouter's current list of sub-processors is published at trust.openrouter.ai, and the Processor monitors that list. The 30-day advance notice of new sub-processors under OpenRouter's own data processing agreement does not apply to inference providers; for those, the routing restriction describedbelow and the Processor's own, stricter commitment under section 8 apply instead.

Sub-processor	Service / purpose	Data processed	Location	Transfer mechanism	Mandatory or optional
Google Cloud	Server infrastructure (virtual machine) and storage of media files and backups	all data processed through the Service, insofar as server infrastructure is concerned; media files and database backups	europe-north1 (Finland, EU/EEA)	No transfer outside the EEA	Mandatory
Mailgun (EU region)	Delivery of system and form e-mails, if the Customer has not enabled its own SMTP server	message recipient (as a protected identifier), sender, subject, delivery status	EU	No transfer outside the EEA	Default (superseded by the Customer's own SMTP server, if enabled — see the Customer's own service providers)
OpenRouter	Routing of AI assistant requests to the selected inference provider; every request forces data_collection: 'deny'	the content of AI assistant conversations and relatedcontent entered or selected by the Admin user	United States	Standard contractual clauses, Module 2 (see Appendix 4)	Optional as a whole (AI feature); mandatory as the router while the AI feature is enabled
Stripe	Online payment processing, if enabled by the Customer	payment amount, currency, transaction and reference identifiers, payment status; no card numbers	Ireland and United States	Adequacy decision (EU–US Data Privacy Framework) or standard contractual clauses under that provider's data processing agreement	Optional
Paytrail	Online payment processing, if enabled by the Customer	payment amount, currency, transaction and reference identifiers, payment status; no card numbers	Finland	No transfer outside the EEA	Optional
Google (Google Calendar)	Calendar integration, if an Admin user connects their own account	the connected account's e-mail, calendar list, free/busy data, calendar events created by the Service, OAuth tokens (encrypted)	EU and United States	Adequacy decision (EU–US Data Privacy Framework) or standard contractual clauses under that provider's data processing agreement	Optional
Microsoft (Microsoft Entra ID / Graph)	Calendar integration, if an Admin user connects their own account	the connected account's e-mail, calendar list, free/busy data, calendar events createdby the Service, OAuth tokens (encrypted)	EU and United States	Adequacy decision (EU–US DataPrivacy Framework) or standard contractual clauses under that provider's data processing agreement	Optional
Cloudflare (Turnstile)	Form abuse prevention, if enabled by the Customer	technical data related to the form sender's verification request	United States	Adequacy decision (EU–US Data Privacy Framework) or standard contractual clauses under that provider's data processing agreement	Optional
hCaptcha	Form abuse prevention, if enabled by the Customer	technical data related to the form sender's verification request	United States	Adequacy decision (EU–US Data PrivacyFramework) or standard contractual clauses under that provider's data processing agreement	Optional

OpenRouter inference providers

The following inference providers run the language models used by the AI assistant, as routed by OpenRouter. They are OpenRouter's sub-processors, with each of which OpenRouter has entered into a written data processing agreement, and for whose conduct OpenRouter is answerable to the Processor under OpenRouter's own data processing agreement. The Processor has restricted the routing on its OpenRouter account to these providers and forces a Zero Data Retention requirement on every request, so that OpenRouter routes the request onlyto a provider that is marked as ZDR-eligible in OpenRouter's provider registry. Multiple providers are usedto ensure service availability. All listed providers are located in the United States and do not use the data to train models. The models' publishers (for example DeepSeek or Qwen) are not sub-processors, and requests are not routed to their own APIs; open-weight models are run exclusively by the providers listed here. Adding a new provider to the routing restriction is a new sub-processor within the meaning of section 8.

Provider	Location	ZDR-eligible	Transfer mechanism
Anthropic	United States	Yes	OpenRouter's sub-processor agreement (see Appendix 4)
Baseten	United States	Yes	OpenRouter's sub-processor agreement (see Appendix 4)
Crusoe	United States	Yes	OpenRouter's sub-processor agreement (see Appendix4)
DeepInfra	United States	Yes	OpenRouter's sub-processor agreement (see Appendix 4)
Fireworks	United States	Yes	OpenRouter's sub-processor agreement (see Appendix 4)
Google AI Studio	United States	Yes	OpenRouter's sub-processor agreement (see Appendix 4)
Google Vertex	United States	Yes	OpenRouter's sub-processor agreement (see Appendix 4)
Makora	United States	Yes	OpenRouter's sub-processor agreement (see Appendix4)
Modal	United States	Yes	OpenRouter's sub-processor agreement (see Appendix 4)
NovitaAI	United States	Yes	OpenRouter's sub-processor agreement (see Appendix 4)
OpenAI	United States	Yes	OpenRouter's sub-processor agreement (see Appendix4)
SpaceXAI	United States	Yes	OpenRouter's sub-processor agreement (see Appendix 4)
Venice	United States	Yes	OpenRouter's sub-processor agreement (see Appendix4)
Wafer	United States	Yes	OpenRouter's sub-processor agreement (see Appendix 4)

The Customer's own service providers

The following services are not sub-processors of the Processor, but are providers chosen and managed by the Customer itself, for which the Customer is responsible:

• the Customer's own SMTP server, if the Customer has enabled it instead of Mailgun;
• analytics and marketing services enabled by the Customer, such as Google Analytics (GA4), Google Tag Manager, Meta Pixel, LinkedIn Insight, Matomo, Hotjar and Microsoft Clarity;
• Google Fonts or other external font services chosen by the Customer;
• JavaScript injected into a Site by the Customer and third-party embeds added by the Customer.
• remote connections granted by an Admin user themselves, such as a ChatGPT or Claude mobile app connection to the Service. In such a case the user, by their consent, grants that application's provider access to the content of the Site they have chosen, within the scope of their own role. Such connections are visible inthe Admin and can be revoked.

Appendix 4 — Transfers outside the European Union and the European Economic Area

The Service's primary production infrastructure is located in the EU, and the Processor (Devella Oy) is established in Finland. No transfer to a third country within the meaning of this appendix takes place between the Customer and the Processor where the Customer is also established in the European Economic Area. Module 2 of the standard contractual clauses (controller as exporter, processor as importer) becomes applicable to the relationship between the Customer and the Processor only where the Customer itself is established outside the European Economic Area.

Transfers outside the European Economic Area instead take place between the Processor and its sub-processors listed in Appendix 3 — in particular in respect of AI model services and some payment and CAPTCHA services. For such transfers, the Processor relies, with each sub-processor, on one of the following grounds:

• an adequacy decision of the European Commission, for example the EU–US Data Privacy Framework, where the sub-processor in question is certified under it;
• for OpenRouter, Module 2 of the European Commission's standard contractual clauses (controller to processor), incorporated by reference into the data processing agreement between OpenRouter and its customers, including the Processor: under this arrangement the Processor is the data exporter and OpenRouter the data importer, the governing law is Ireland, the competent court is Dublin, and Annex I and Annex II of the clauses are OpenRouter's own Schedule 1 and Schedule 2; or
• for other sub-processors, the transfer mechanism specified in that sub-processor's own data processing agreement: an adequacy decision of the European Commission (the EU–US Data Privacy Framework) or standard contractual clauses in whichever module that agreement specifies, supplemented where necessary by additional safeguards. The transfer mechanism is recorded against each sub-processor in Appendix 3.

For OpenRouter's inference providers, the transfer mechanism consists of the standard contractual clauses between the Processor and OpenRouter, together with the sub-processor agreement between OpenRouter and each provider, for which OpenRouter is answerable to the Processor.

For the avoidance of doubt, the Processor acts as a processor towards its own Customers. OpenRouter's own contractual structure, however, makes Module 2 the mechanism applicable between OpenRouter and its customers — including the Processor. The Processor has, as part of its transfer impact assessment, determined that this constitutes an adequate safeguard for that transfer.

The Processor has carried out a transfer impact assessment for OpenRouter and the US-based inference providers used through it, and separately for the other sub-processors located outside the EEA that are listed in Appendix 3. For OpenRouter, Annex I and Annex II of the clauses are OpenRouter's own Schedule 1 and Schedule 2 under its data processing agreement, not the appendices to this DPA.