Data Processing Agreement (DPA)

Last updated: 07 October 2025

This Data Processing Agreement (“DPA”) describes how Amio processes personal data on behalf of customers in connection with our services. It is incorporated into and forms part of our Terms of Service and Privacy Policy. By using our services, you agree to this DPA.

Amio (the Processor):
Amio s.r.o., Bartoškova 1411/20, Nusle, 140 00 Praha 4, Czech Republic.
Company ID: 06177794,
VAT ID: CZ06177794.
Contact: privacy@amio.io,
Website: amio.io.

Customer (the Controller): The entity or individual that has contracted with Amio for the Services (referred to as “you”).

1. Definitions

Applicable Data Protection Law: All privacy and data protection laws and regulations relevant to the Processing of Personal Data under this DPA. This includes, as applicable, the EU General Data Protection Regulation (EU GDPR), the UK GDPR and UK Data Protection Act 2018, the Swiss Federal Act on Data Protection (rev. 2023), and U.S. state privacy laws (e.g., CCPA/CPRA, Colorado CPA, CTDPA, UCPA, VCDPA, etc.).
Customer Personal Data: Any Personal Data that you (the Customer) provide to Amio, submit via the Services, or otherwise make available for Processing on your behalf. In other words, it’s the personal data of others that you upload into our chatbot platform or that is collected through your use of our Services.
Data Subject: An identified or identifiable natural person to whom Personal Data relates. (For example, your end-users who interact with the chatbot are Data Subjects if their personal information is processed.)
Personal Data, Processing, Controller, Processor, and Supervisory Authority: These terms have the meanings given to them by the Applicable Data Protection Law. (Generally, Personal Data means any information about an individual, Processing means any operation performed on data, a Controller decides why and how data is processed, a Processor processes data on behalf of a Controller, and a Supervisory Authority is a data protection regulator.)
Security Incident: A breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Customer Personal Data processed by Amio. (In short, a security breach that affects your personal data.)
Services: The AI e‑commerce chatbot platform and related services provided by Amio under the Agreement.
Sub-processor: Any third party (company or contractor) that Amio engages to assist in Processing Customer Personal Data as part of providing the Services. For example, a cloud hosting provider or an AI service integrated into our chatbot could be a Sub-processor.

2. Roles of the Parties

2.1 Controller-Processor Relationship. When you use our Services and provide personal data for us to process, you are acting as the “Controller” of that data, and Amio is acting as the “Processor.” This means you retain overall control of the data and determine the purposes (“why”) and means (“how”) of the processing, and we process the data on your behalf according to your instructions. (If you are a Processor for a third-party Controller, then Amio is your sub-processor.)

2.2 Amio as an Independent Controller. In certain cases, Amio may also process personal data as an independent Controller for our own legitimate purposes. For example, we might keep records of your billing and payments, monitor usage for fraud prevention and security, or collect product usage data (telemetry) to improve core functionality. In these cases, we are not processing data on your behalf but for ourselves, in compliance with applicable laws. Such processing is not governed by this DPA and is instead described in our Privacy Policy (since we act as a Controller for that data).

3. Scope of Processing and Instructions

3.1 Documented Instructions. We will process Customer Personal Data only in accordance with your documented instructions. Your initial instructions to us are set out in this DPA and the Terms of Service – essentially, to process the data as necessary to provide, secure, and improve the Services. We will not deviate from your instructions unless required by law. If we believe an instruction from you violates the law or is not technically feasible, we will inform you promptly and we won’t execute that instruction without further agreement.

3.2 Nature and Purpose of Processing. We will process Customer Personal Data as needed to deliver the Services to you and your end-users. This includes operations such as: storing data, retrieving data on demand, transmitting data over networks, analyzing and classifying data (for example, understanding a user’s question), generating output (the chatbot’s answers) based on the data and AI models, and logging or monitoring interactions for troubleshooting and support. The purpose of all Processing under this DPA is to provide and support the Amio AI e-commerce chatbot services and any related technical support or improvements you have requested. (See Annex I for a more detailed description of the Processing activities.)

3.3 Types of Personal Data and Data Subjects. The types of personal data processed, and the categories of individuals (Data Subjects) involved, depend on how you use the Services. Generally, Customer Personal Data will include chatbot conversation data (e.g. the messages and queries that users input, which may incidentally contain personal information), any identifiers or contact details you choose to collect via the chatbot (for instance, a user’s name or email if your chatbot asks for it), and associated technical data (such as device or browser information, IP addresses, and timestamps) . The Data Subjects are typically individuals who interact with your chatbot (for example, your website visitors or customers using the chatbot on your e-commerce site). It may also include your staff or agents who configure or input information into the chatbot (to the extent any personal details of theirs are processed). A full description of the data and subjects is provided in Annex I. You confirm that you have provided any necessary notices to these individuals and have obtained any required permissions for us to process their data on your behalf.

3.4 Customer Responsibilities. You are responsible for ensuring that the personal data you submit to the Services can be lawfully processed by us for the purposes of the Agreement. In particular, you must: (a) lawfully obtain and share the data with Amio (e.g. ensure you have consent or another valid legal basis from the Data Subjects as needed); (b) provide appropriate privacy notices to your end-users (Data Subjects) explaining that their data will be processed by Amio on your behalf; (c) obtain any necessary consents or authorizations from Data Subjects, especially if you plan to collect sensitive information or use cookies/trackers in connection with the chatbot; and (d) configure and use the Services in a privacy-protective way, following our product documentation and security guidelines. This means using the tools we provide (like access controls, data retention settings, etc.) to limit access to personal data and avoid collecting more data than you need.

3.5 Prohibited Data. Please do not upload or submit any highly sensitive personal data to Amio’s Services unless we have expressly agreed in writing that we can handle such data. In particular, you should not provide:

Special Categories of Personal Data: This refers to sensitive data such as health information, biometric data, genetic data, information revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, or data concerning a person’s sex life or sexual orientation (as defined in GDPR Article 9).
Criminal Records Data: Information about criminal convictions or offenses (GDPR Article 10 data).

Amio does not need or require these types of data for the Services, and our platform is not intended to process them. If you nevertheless inadvertently send us any such data, we will treat it as data provided by mistake and not as intentional use of the Services for that purpose. (We will apply our security measures to protect it, but we may also flag or delete it to comply with this section.) If you think your use of the chatbot will legitimately require processing sensitive personal data, please contact us in advance to discuss whether an appropriate solution or additional agreement is possible.

4. Confidentiality and Personnel

We treat your Customer Personal Data as confidential. All Amio personnel and any contractors who are authorized to process Customer Personal Data are under strict obligations to maintain the confidentiality and security of the data. This is enforced through appropriate confidentiality agreements (for example, NDAs and contractual confidentiality clauses) and through regular training on privacy and data protection. In short, only people who need access to your data to provide the Services will have it, and they are legally and ethically bound to protect your data and keep it confidential.

5. Security Measures

5.1 Amio’s Security Obligations. We implement and maintain appropriate technical and organizational measures to safeguard Customer Personal Data. In determining these measures, we take into account the state of the art (current best practices and technologies), the costs of implementation, the nature and scope of the data and processing operations, and the potential risks to the rights and freedoms of Data Subjects. Annex II of this DPA describes our security measures in more detail. In summary, our protections include industry-standard techniques such as encryption of data (both at rest and in transit), access controls and authentication measures to ensure only authorized access, logical separation of each customer’s data within our systems, monitoring of systems for security events, regular data backups, and more . We also regularly evaluate and improve these measures to adapt to new security threats or changes in our Services. While no system can be guaranteed 100% secure, we are committed to protecting your data and will promptly address any security issues that arise.

5.2 Customer’s Security Responsibilities. You also play a crucial role in keeping data safe. You are responsible for managing the security of your accounts on our platform. This includes keeping your login credentials (usernames, passwords, API keys, etc.) confidential and using any available security features we offer (such as two-factor authentication, if applicable). You should also set appropriate access controls for your team members or any third parties you allow to access the Amio Services (for example, only give data access permissions to people who need them). Additionally, if you export or download any personal data from our Services, it is your responsibility to store and protect that data securely on your own systems. We recommend that you maintain your own backups or copies of data as needed (though we backup data on our side as part of our security measures), and that you promptly remove any Customer Personal Data from the platform that you no longer need. By following security best practices on your end, you help prevent unauthorized access to the data both within and outside of our platform.

6. Sub-Processors

6.1 Use of Sub-Processors – Your General Authorization. You authorize Amio to engage Sub-processors (other companies or subcontractors) to help us process Customer Personal Data and deliver the Services. In other words, we have your general permission to involve third-party service providers in our data processing operations as long as they live up to the data protection obligations in this DPA. Common examples of Sub-processors include the cloud infrastructure providers that host our servers, email service platforms, or providers of AI processing capabilities that our chatbot might use. We remain responsible to you for any actions of our Sub-processors regarding your personal data, as explained below.

6.2 List of Current Sub-Processors and Updates. We keep an up-to-date list of the companies we use as Sub-processors on our website. You can find this list here: Amio Sub-Processors. This page outlines who our Sub-processors are and what services they provide for us. We will notify you of any intended changes to our Sub-processor roster by updating that online list. If you subscribe to notifications (for example, by providing your email on that page or in your account settings for sub-processor updates), we will also send you an email alert for significant changes, such as adding a new Sub-processor or replacing an existing one with a different provider. We recommend monitoring the sub-processor page or subscribing to updates so you are aware of who is involved in processing your data.

6.3 Objections to New Sub-Processors. If we add or change a Sub-processor and you have a legitimate data protection concern with that Sub-processor (for example, you believe the new Sub-processor may not provide an adequate level of security or compliance), you have the right to object to our use of them. To object, you should notify us in writing within 10 days of us informing you about the new Sub-processor (e.g., within 10 days of the update on the sub-processor list or the email notice). Please include your specific reasons for the objection. We will then work with you in good faith to address your concerns. This could mean providing additional information about the Sub-processor’s security measures, or in some cases, discussing an alternative solution. If we are unable to reasonably accommodate your objection (for instance, if we cannot provide the Services without using that Sub-processor and no alternative is feasible), then you may choose to terminate the affected Services. If you decide to terminate due to a Sub-processor objection, we will allow you to do so without penalty. We will refund any prepaid fees covering the period after termination for the portion of services you can no longer use. Our goal is to be transparent about our data partners and ensure you are comfortable with everyone handling your data.

6.4 Sub-Processor Agreements and Responsibility. Whenever we engage a Sub-processor, we will have a written agreement in place with them that imposes data protection obligations at least as strict as those in this DPA. In practice, this means every Sub-processor must agree to protect Customer Personal Data to the same standard that you expect from Amio (including confidentiality, security measures, and assisting with rights requests, etc.). We carefully vet our Sub-processors for their security and privacy practices before working with them. Importantly, Amio remains fully responsible to you for what our Sub-processors do with your data. If a Sub-processor fails to meet its obligations, Amio will be liable to you just as if we had breached the DPA ourselves. In summary, we don’t pass the buck – using Sub-processors does not reduce our accountability for protecting your personal data.

7. Assistance with Data Subject Rights and Impact Assessments

We understand that as a Controller, you may need help fulfilling certain obligations under data protection laws. Amio will assist you in a reasonable manner, to the extent you cannot reasonably fulfill these needs through the self-service features of our platform, with the following:

Responding to Data Subject Requests: If an individual (Data Subject) whose personal data we process on your behalf exercises their rights (such as requesting access to their data, asking for correction or deletion, etc.), we will help you by providing relevant information or tools. For example, if one of your customers asks to delete their chat history, we can assist by deleting relevant data from our systems on your instruction. You are responsible for communicating with the Data Subject, but we will provide behind-the-scenes support as needed.
Data Protection Impact Assessments (DPIAs): If you conduct a privacy impact assessment regarding the use of Amio’s Services (for instance, because your use of AI or chatbots might be considered high-risk under GDPR), we will provide you with reasonable cooperation and information about our Services to facilitate your assessment. This might include details on our processing activities, security measures (see Annex II), and any third-party risk assessments we have.
Consultations with Regulators: If you need to consult with a data protection authority (Supervisory Authority) about the use of our Services (perhaps because a DPIA indicates high risk), we will support you with relevant information about our processing and security, as allowed by law.

These forms of assistance will be provided upon request to our privacy team (you can reach us at privacy@amio.io). We will respond as promptly as practicable. Please note: If the effort required on our part is significant (for example, extensive custom support, or developing new tools to help with a complex Data Subject request), we may charge a reasonable fee for our assistance, if applicable law allows us to do so. We would always discuss and agree on any such fees in advance. Our aim is to help you stay compliant while using Amio, within the reasonable bounds of our role as a Processor.

8. Security Incidents and Data Breach Notification

In the unfortunate event that we experience a Security Incident affecting your Customer Personal Data, we will inform you without undue delay after becoming aware of it. “Security Incident” means a confirmed breach of our security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data that we process for you. In plain terms, something like a data breach.

When we notify you, we will include all relevant information that we have at the time, such as:

The nature of the incident and the data concerned (e.g. what happened and what data was exposed or affected).
The likely consequences of the incident (e.g. potential risks or harm to Data Subjects, if known).
The measures we have already taken or plan to take to address the incident (for example, steps to contain the breach, fix vulnerabilities, and mitigate any damage).

We will send this notice to your designated contact (we recommend that you ensure your account contact information is up to date for this reason). After the initial notification, we will also keep you informed of any new developments regarding the Security Incident and our remediation efforts.

Additionally, we will take immediate action to mitigate the effects of the breach. This may include isolating affected systems, restoring data from backups, changing access credentials, or other emergency measures as appropriate. We will investigate the incident to understand what went wrong and to prevent a recurrence.

We will cooperate with your reasonable needs in responding to the incident. For example, if you need information from us to make a timely report to authorities or to notify affected individuals (as you may be legally required to do under GDPR’s 72-hour rule or other laws), we will do our best to provide you with the relevant facts as soon as possible. Our goal is to work together with you to manage the situation and minimize any harm.

(For clarity: Amio’s obligation to report a Security Incident to you is not an acknowledgment of fault or liability for the incident. Even if the breach resulted from circumstances outside our control, we will still notify you and assist. Conversely, if the incident was caused or exacerbated by your actions (e.g. your misuse of the Services), we will still cooperate in good faith, but that may be a factor in responsibility.)

9. Audits and Compliance Verification

9.1 Documentation and Transparency. We will make available to you the information necessary to demonstrate our compliance with this DPA. In practice, this means we can provide documents or reports about our data protection practices upon request. For example, we can share summary excerpts of our security policies or certifications, descriptions of our system architecture as it relates to data protection, results of independent security audits or penetration tests (typically provided under a non-disclosure agreement for sensitivity), and other relevant documentation. Our goal is to be transparent enough to give you confidence that we are meeting our obligations under this DPA and applicable law, without compromising security (we won’t, for instance, share details that could jeopardize our security or other customers’ data if disclosed publicly).

9.2 Right to Audit. You have the right to audit our compliance with this DPA, subject to the following conditions to ensure audits are reasonable and focused:

Frequency: You may conduct an audit once per year at most under ordinary circumstances. In addition, you may perform an extra audit if there has been a material Security Incident affecting your data, or if a Supervisory Authority (regulator) specifically requires or requests that an audit be conducted on your use of Amio’s Services.
Notice and Scheduling: You must provide us with at least 30 days’ advance notice of your requested audit. Audits should be conducted during normal business hours and in a manner that avoids disrupting our operations. We will work with you to agree on a start date and scope for the audit.
Scope: Audits can cover our facilities, systems, processes, and documentation directly involved in processing your Customer Personal Data. For example, this may include our data centers or hosting environment (likely via review of third-party attestations, since physical access is often managed by our cloud providers), security policies, and relevant records. However, audits must exclude any information that would compromise the security or confidentiality of other customers’ data. You also may not access our proprietary data unrelated to the Services or any sensitive employee information, etc. The audit should strictly focus on verifying compliance with data protection obligations concerning your data.
Auditors: The audit can be carried out by you (e.g. your internal or appointed auditor) or by an independent third-party auditor selected by you. If you use a third-party auditor, that auditor must sign a confidentiality agreement reasonably acceptable to Amio (to ensure they don’t disclose our sensitive information). We may object to a specific third-party auditor if we have a legitimate concern that the auditor is not independent, qualified, or is a competitor. In such case, you would need to select a different auditor.
Method: You may choose reasonable audit methods, which could include reviewing documentation we provide, interviewing our relevant staff (within reason), and/or conducting an on-site visit (if necessary). We reserve the right to charge a fee for support of an on-site audit if it requires significant resources; if so, we will discuss and agree on that fee in advance. For on-site audits, both parties will agree in advance on the logistics, timing, and safety protocols. Also, you agree to comply with any applicable facility security policies during a visit.
Results: Upon completion of the audit, we ask that you share the high-level results with us (at least any findings of non-compliance) so we can address them. We will work with you to promptly rectify any confirmed material weaknesses or instances of non-compliance identified by the audit. Any information gathered or reports generated through the audit must be kept confidential and used solely for purposes of meeting your audit requirements.

By providing the above cooperation, Amio fulfills its obligations to enable verification of our compliance. Note that many of our third-party Sub-processors (like major cloud providers) are regularly audited by independent firms and obtain certifications (e.g., ISO 27001, SOC 2). In many cases, providing you with those third-party audit reports or certifications can satisfy audit requirements without the need for you to conduct an on-site audit of those Sub-processors yourself. We will help facilitate such information sharing as part of our commitment to transparency.

10. Deletion or Return of Data

When your contract with us ends (for example, if you cancel your account or the Agreement expires or is terminated), you have a right to decide what happens to the Customer Personal Data you had us process. At that point, upon your request, we will either: (a) return the data to you, or (b) delete the data, at your choice. Return may be accomplished by providing you with export files or other accessible formats of the data we have, and deletion means we will securely erase or render unrecoverable the personal data from our systems. You should let us know which option you prefer at the end of the contract. If you don’t explicitly request one, the default is typically deletion of the data, since we no longer need to process it on your behalf once the Services are over.

There are a couple of important clarifications:

We may not immediately delete data that we are legally required to keep for a certain period. For instance, some transaction records or logs might need to be retained for financial reporting, audit, or compliance with legal obligations. Any such data will remain protected under this DPA until it is deleted. We will only retain the minimum necessary and only for the required duration.
If for some reason complete deletion is not technically feasible (for example, if the data is stored in long-term backups that are not easily isolated or if deletion from certain media is infeasible), then we will ensure that such data is put beyond further use. This means we will isolate it from any active system and maintain strict security and access controls, so it is not processed anymore for any purpose and will be overwritten or destroyed in accordance with our data retention and deletion schedules.

Amio’s general practice (as also noted in our Privacy Policy) is to erase Customer Personal Data within a reasonable time after termination of the Services, except for any data we must keep by law or which you have asked to be returned. We will certify deletion upon request. It’s a good idea for you to export any data you might need before your access to the Services ends. We’re happy to assist with any data export or migration if needed prior to deletion.

(Note: The choice to have data returned or deleted should be communicated to us preferably before the effective termination date or immediately after, to ensure a smooth process. If we don’t hear from you, we may delete the data in line with our standard procedures.)

11. International Data Transfers

We are based in the Czech Republic and also use infrastructure and Sub-processors in other countries. This section explains how we handle transfers of personal data across borders, especially from the European Economic Area (EEA), UK, or Switzerland to countries that may not have equivalent data protection laws.

11.1 Transfers from the EEA/Switzerland (EU Standard Contractual Clauses). If we process Customer Personal Data that originates from the EEA or Switzerland and transfer it to a country that the European Commission (or Swiss authorities) has not deemed to have an “adequate” level of data protection, we will ensure that such data transfer is protected by EU Standard Contractual Clauses (SCCs). The SCCs are legal contracts approved by the European Commission to safeguard personal data leaving the EEA/Switzerland. In particular, the SCCs issued under the European Commission’s Decision 2021/914 are incorporated by reference into this DPA. For the purposes of Article 46 of the GDPR, those SCCs will be considered executed between you (as “data exporter”) and Amio (as “data importer”). The SCCs we use are the modernized 2021 version, Module Two (Controller-to-Processor), since you are a Controller and we are a Processor in this context. We will apply the SCCs with the specific selections and details set out in Annex III of this DPA (Annex III lists the required information for the SCCs, such as the parties’ details, the data transfer description from Annex I, the security measures from Annex II, and certain options or boilerplate determinations under the SCC framework). Furthermore, if we engage any Sub-processor (another Processor) in such a transfer, we will also sign the appropriate Module Three (Processor-to-Processor) SCCs with them or use another valid transfer mechanism to ensure continuity of protection. In short, for data moving out of Europe to a country without an adequacy decision, we’ve got the SCCs in place to legally protect that data.

11.2 Transfers from the UK (UK Addendum). For personal data subject to UK data protection law (UK GDPR) that is transferred from the United Kingdom to a country not deemed adequate by the UK government, we will rely on the UK’s International Data Transfer Addendum to the EU SCCs (the template issued by the UK Information Commissioner’s Office, “ICO”). This UK Addendum is also incorporated by reference into this DPA. Essentially, the UK Addendum attaches to the EU SCCs and modifies them as needed for UK law. The specific details and selections for the UK Addendum are set out in Annex III. In general, the UK Addendum will be filled out using the information provided in the SCCs (as per Annex I and II of this DPA) and will indicate that neither party objects to the Addendum’s standard terms. By agreeing to this DPA, you (as data exporter) and Amio (as data importer) are deemed to have signed the UK Addendum as well, ensuring there is a lawful transfer mechanism in place for UK-to-non-UK transfers.

11.3 Supplementary Measures and Additional Safeguards. We monitor legal developments around international data transfers (such as the requirements from the Schrems II ruling by the EU Court of Justice and related guidance). Where necessary, we will implement supplementary measures to the SCCs or other transfer mechanisms to ensure that the transferred personal data receives an equivalent level of protection to that in the EU. These measures could be technical (for example, additional encryption or pseudonymization of data before transfer), organizational (strict policies limiting access to data and challenging any unlawful government requests), and/or contractual (adding commitments from the data importer regarding government access and individual rights). We also commit to not knowingly disclose European personal data to government authorities in a way that violates the SCCs without informing you, unless legally prohibited. In short, we will take all reasonable steps to secure the data in transit and in the destination country, so that Data Subjects’ rights remain protected.

11.4 Adaptation for Swiss Data Protection Law. For personal data transferred from Switzerland, the European SCCs and UK Addendum will be interpreted so as to comply with Swiss law requirements. In particular: references to the “GDPR” in the SCCs shall be understood to include the Swiss Federal Data Protection Act (FADP); references to “EU”, “Member State” or “Union law” shall be understood to include Swiss law where necessary; and references to a “Supervisory Authority” shall be understood to include the Swiss Federal Data Protection and Information Commissioner (FDPIC), and references to “courts” shall mean the relevant courts of Switzerland. These adaptations ensure that Data Subjects in Switzerland have equivalent rights and recourses under the SCCs framework. We treat transfers from Switzerland with the same high standard of care as EU data transfers.

(For completeness, if any other valid data transfer frameworks become available and applicable – such as a future EU–US Data Privacy Framework or another country-specific solution – we may use those as appropriate, but SCCs with necessary measures remain our primary tool for international transfers at this time.)

12. U.S. State Privacy Laws Compliance

Several U.S. states have enacted their own privacy laws which use terms like “service provider” or “processor” for entities like Amio that handle personal data on behalf of a “business” or “controller” (which would be you). If Customer Personal Data is subject to laws such as the California Consumer Privacy Act (CCPA) as amended by the CPRA, or similar laws in Colorado, Connecticut, Utah, Virginia, etc., then we make the following additional commitments to ensure compliance and enable you to meet your obligations under those laws:

No Sale or Sharing of Personal Information: We will not sell Customer Personal Data or share it for cross-context behavioral advertising, as those terms are defined under applicable state laws. In other words, we won’t disclose your end-users’ personal data to third parties for monetary or other valuable consideration, nor will we share it with third-party companies to target ads to those end-users. We only use and disclose the data to provide our Services to you, as described in this DPA.
No Use for Independent Purposes: We will not use Customer Personal Data for any purpose other than providing the Services and fulfilling our obligations to you under the Agreement. We won’t use the data for our own business purposes, except as allowed for a “service provider”/“processor” (for example, internal use to improve the quality and security of our service, in a manner consistent with this DPA and not outside the scope of your instructions). We also will not combine Customer Personal Data with personal information we collect from other sources, except as permitted by law and only to achieve the purposes of the Services (for instance, combining your data with our threat intelligence data purely to improve security would be allowed, but we wouldn’t combine it to build profiles for marketing).
Assistance with Consumer Requests: If you need to respond to consumer rights requests under these state laws (such as “Do Not Sell or Share” requests, deletion requests, etc.), we will assist as needed, similar to GDPR Data Subject Requests as described in Section 7. We will delete or return individual’s data from our systems upon valid request from you, and we will provide confirmation when completed.
Flow-Down of Obligations: We will ensure that any Sub-processors (subcontractors) we use to process Customer Personal Data also agree to the same restrictions and obligations that apply to us under these state privacy laws. This means any authorized Sub-processor will be contractually prohibited from selling or sharing the data, using it for purposes other than providing the Services to you, and will assist in honoring deletion or access requests, etc., just as we do.

By complying with the above, Amio qualifies as a “Service Provider” or “Processor” under applicable U.S. laws, which helps you (the “Business”/“Controller”) demonstrate that you’re handling your consumers’ personal data in a compliant manner when using our Services. If any term in this DPA or the Agreement would cause a conflict under U.S. state law requirements, we will work with you to address it, but generally this DPA is designed to meet or exceed those standards.

13. Liability and Precedence

All limitations on liability and exclusions of damages that are stated in the main Agreement (Terms of Service or other service contract between us) also apply to this DPA. This means Amio’s liability to you (and your liability to Amio) for any issues arising out of this DPA is subject to the same overall caps and restrictions as set forth in the Agreement. We are not agreeing to any additional liabilities by signing this DPA beyond what is in the main contract, except as required by law. For example, if the Terms of Service limit the amount of damages either party can claim, that same limit applies to claims under this DPA as well.

In the event of any conflict or inconsistency between the terms of this DPA and the terms of the rest of the Agreement, the terms of this DPA will prevail with respect to the processing of Customer Personal Data. In other words, regarding data protection and privacy matters, this DPA governs. For all other matters not specifically addressed by this DPA, the general terms of the Agreement remain in force. If something in the Agreement would contradict or undermine a provision in this DPA, parties should follow the DPA for anything related to data processing.

14. Governing Law and Jurisdiction

This DPA shall be governed by and construed in accordance with the same law that applies to the main Agreement, unless otherwise required by applicable data protection laws. The forum/venue for disputes under this DPA is also the same as that in the main Agreement, meaning any dispute will be resolved in the courts specified by that Agreement. (For reference, the Terms of Service specifies the governing law of the Czech Republic, and jurisdiction of Czech courts, unless another contract between us stipulates differently.)

However, for the purposes of the Standard Contractual Clauses (SCCs) incorporated in Section 11 and Annex III, we must designate a governing law and forum of an EU Member State. As detailed in Annex III, we have selected the law of the Czech Republic (an EU Member State) to govern the SCCs, and have submitted to the jurisdiction of the courts of the Czech Republic for any disputes arising from the SCCs. This SCC choice of law is made solely to meet the requirements of the SCC framework and does not change the overall governing law of the Agreement for other matters.

In summary, the DPA follows the same law and dispute resolution process as our main contract, except that for enforcement of European SCCs, an EU law/jurisdiction is adopted (Czech law, in our case, to align with our location).

15. Changes to this DPA

We may update or modify this DPA from time to time to reflect changes in our Services, changes in the law, or for other legitimate reasons. If we make an update, we will notify you in accordance with the notice provisions of the Agreement. If any change would materially reduce the protections or rights afforded to you under this DPA, we will provide at least 30 days’ advance notice (for example, via email or an in-app notification) so that you have the opportunity to review the changes and raise any concerns or objections before they become effective. Minor adjustments or clarifications that do not negatively impact your rights might take effect immediately or on shorter notice.

Your continued use of the Services after a DPA update becomes effective will be considered acceptance of those changes. However, if you object to a material change that adversely affects you, you may have the right to terminate the Services (as per the Agreement’s termination provisions). We encourage you to periodically check for the latest version of the DPA, which will have the “Last updated” date at the top. We will also maintain prior versions or change logs if required by law. Our aim is to be transparent and fair in how we handle any modifications to this DPA.

16. Acceptance and Execution

By entering into the Agreement with Amio and by using our Services, you are also agreeing to this DPA. In practice, this may happen electronically: for instance, when you click “Sign Up” or check a box agreeing to our Terms of Service, that action also signifies acceptance of the DPA (which is incorporated by reference). There is no need for a separate signature on this DPA when it is referenced in an online agreement – it is binding as part of our overall contract.

If required by your internal policies or by a counterparty (for example, if you are a processor to someone else), we can also arrange to execute a separate copy of this DPA (including Annexes and the Standard Contractual Clauses) upon request. The effective date of this DPA will align with the effective date of the Agreement, and it will remain in force as long as we are processing personal data on your behalf under the Agreement.

By agreeing to this DPA, both parties (you and Amio) acknowledge that the EU Standard Contractual Clauses and UK Addendum (as described in Section 11 and Annex III) are hereby incorporated and form part of this DPA, and that Annexes I, II, and III are an integral part of the DPA. The individuals signing up or accepting electronically on behalf of each party represent that they are authorized to legally bind that party to the terms of this DPA.

(In summary: you don’t need to physically sign this DPA for it to be effective. Your acceptance of the Terms of Service or continued use of Amio’s services is enough to “execute” this DPA, and it is as legally valid as a signed paper document.)

Annex I – Description of Processing

This Annex provides specific details about the Processing of Customer Personal Data as required by GDPR Article 28 and the Standard Contractual Clauses. It describes the “subject matter,” “duration,” “nature and purpose” of processing, the types of personal data, and categories of data subjects involved in our Service. This information applies to Module Two (Controller-to-Processor) of the SCCs (and Module Three for any sub-processors we use).

A. Subject Matter of Processing: The subject matter is the provision of the Amio AI e-commerce chatbot and related services to the Customer. In simpler terms, we process personal data in order to power the chatbot on your website or platform, enabling it to answer user inquiries and perform related tasks as you direct.

B. Duration of Processing: We will process Customer Personal Data for the duration of the Agreement between you and us, unless otherwise instructed by you. This means from the time you start using our Services until the time the Services end (for example, when your subscription or account is terminated or expires), plus any additional post-termination period during which we agree to continue storing or returning your data (as per Section 10 of the DPA). If data needs to be retained longer due to legal obligations, that will be done in accordance with applicable law and with the data safeguarded (no active processing beyond what is required). In summary, we don’t keep your data indefinitely – just for as long as we’re providing you the service, and then a short period thereafter for wrap-up or legal compliance, before deletion.

C. Nature and Purpose of Processing: Amio provides a conversational AI chatbot service, which involves various processing operations on the data you provide or that your end-users input. The nature of the processing includes collecting data (e.g., receiving a user’s question through the chatbot interface), recording and storing data (saving the conversation logs and any knowledge base content you’ve added), analyzing data (using algorithms and AI models to understand the query and find an answer), and generating responses (creating a reply to the user’s question, which might involve retrieving information from your knowledge base or performing an AI-driven formulation). We also transmit data to deliver responses back to the user, and possibly perform more operations like indexing, logging, and deleting data as per retention rules. The purpose of all this processing is to enable the chatbot to function and improve. Concretely, that means: providing instant automated answers to end-users on your behalf, using the data you’ve supplied (such as your product information, FAQs, or other knowledge base content) and learning from interactions to improve answer accuracy. We also process data for related purposes such as: maintaining and scaling the technical infrastructure (which might involve duplicating data across servers for reliability), monitoring performance and usage (to ensure the service works well and to detect fraud or misuse), and providing customer support to you (e.g., if you ask us to investigate a conversation where the bot had an issue, we might look at the log of that chat). All processing is limited to what is necessary to achieve these purposes. We do not process the data for any unrelated purposes (like marketing or profiling outside of the chatbot context) without your instructions.

D. Categories of Data Subjects: The personal data processed typically relates to the following categories of individuals:

End Users of the Customer: These are individuals who interact with the chatbot that you deploy on your website, application, or other channels. They could be your customers, website visitors, or other users seeking information or support via the chatbot. For example, if a visitor on your e-commerce site asks the chatbot a question about a product, that visitor is a data subject whose personal data (the content of their inquiry, any contact info they provide, etc.) might be processed.
Customers’ Personnel and Administrators: Individuals who are authorized by you to use the Amio platform in an administrative capacity. This includes your employees, contractors, or agents who may upload content to the chatbot’s knowledge base, configure chatbot settings, or view conversation logs in the dashboard. The personal data related to these individuals is minimal (typically business contact information like name, email, and any profile details they add, as well as their actions within the platform logged for security/audit purposes). Note that in many cases this kind of data may fall under Amio’s role as a Controller (for account management), but to the extent we are processing it on your behalf (like storing your team’s input into the knowledge base), it is within scope of this DPA.
Other Individuals Whose Data Appears in Chatbot Content: This is a less common category, but if your end-users mention or provide personal information about other people during a chat, or if your knowledge base content contains personal data about third parties, those individuals would also be data subjects. For instance, if a user types in someone else’s email address or name as part of a support query, or if your uploaded FAQs include a reference to a staff member’s contact info, that data concerns an identifiable person. We treat that data with the same care, though typically such data is incidental.

E. Categories of Personal Data Processed: The data we process on your behalf through the chatbot service can include a range of personal data, depending on what your end-users submit and what you configure. Broadly, the categories of personal data may include:

Chat Content: The text (or voice, if applicable) conversations between end-users and the chatbot. This often contains the user’s questions, which might range from general queries to specific information. The content could potentially include personal details if the user shares them (for example, “What’s the status of my order? My order number is 123 and my name is John Doe”). We do not require users to input personal data to use a typical chatbot query, but they might voluntarily do so. Any personal data embedded in the chat messages (names, addresses, order numbers that link to individuals, etc.) is processed as part of providing the response.
Identifiers and Contact Information: If you configure your chatbot to collect or use identifiers, we will process those. This can include things like a user’s name, email address, phone number, customer ID, or social media handle – typically collected if the chatbot asks for it to provide personalized assistance or to create a support ticket. Another example: you might integrate the chatbot with your e-commerce backend so it recognizes a logged-in user by an ID or cookie; in that case, we might process an identifier to retrieve that user’s order status.
Knowledge Base Content (Customer-Provided Data): This is the information you provide to Amio to “train” or inform the chatbot – for example, product information, answers to FAQs, documents, or any data that the chatbot uses to formulate answers. Generally, we expect this content to be about your products or services, not about individuals. Ideally, it contains no personal data. However, if any personal data is present in this content (e.g., a support contact list with names/email addresses, or testimonials from customers that include names), then those personal data elements are also processed (stored, possibly analyzed) by us as part of delivering answers.
Technical and Usage Data: We collect technical metadata generated by the use of the chatbot. This includes data like IP addresses of users interacting with the chatbot, browser type or device information, timestamps of interactions, and possibly location information (if IP or device data indicates general location). We also keep logs of how the chatbot was used (e.g., which knowledge base article was fetched to answer a question, any error logs for failed responses, etc.). This data is used for service functionality, analytics, security (like preventing abuse of the chatbot), and improving performance. Some of this might be considered personal data (IP addresses can be personal data under GDPR). We process this under your instructions to provide and monitor the service.
Special or Sensitive Data: As noted in Section 3.5 of the DPA, you should not intentionally use the Services to collect any sensitive personal data (such as health, credit card numbers, social security numbers, etc.). We do not design the chatbot to handle such data, and we do not ask for it. Therefore, the Services are not expected to process any special categories of personal data or highly sensitive info. If any appears in the data (due to user input outside our control, for example), it is considered inadvertent. We apply security to everything equally, but sensitive data is not part of the intended dataset. We do not have a separate processing purpose for it and will not use it other than to purge or ignore it as appropriate.

F. Processing Operations: To summarize the above in terms of the GDPR’s language: Amio’s processing operations on Customer Personal Data include collection (receiving data from you or directly from data subjects via the chatbot), recording and storing that data on our systems, organizing and structuring it (indexing knowledge base data, linking user queries to knowledge base entries), retrieval (pulling up relevant data to answer a query), analysis (like running the text of a query through an AI model to determine intent and relevant answer), consultation (allowing you to view the data via our dashboard or logs), use (using the data to generate a result for the user), disclosure by transmission (sending the answer back to the user, which inherently includes parts of their question or related data), combination (combining user query data with relevant knowledge base data to formulate answers), restriction (we can restrict processing if you instruct us to, such as “hold but don’t delete yet”), erasure or destruction (deleting data upon expiration or instruction). We do not sell or share the personal data for marketing; any transfers are strictly per your instructions (like sending a transcript to your support system if you’ve integrated one).

This Annex I is intended to satisfy the requirement to document the specifics of data processing. It can be used as the Appendix to the SCCs (Annex I of the SCCs) describing the transfer. It may be updated from time to time if you change how you use the Services (for example, if in the future our chatbot supports new data types). Any updates would require mutual agreement or appropriate notice as per the DPA terms.

Annex II – Security Measures

Amio understands the importance of security and has implemented a comprehensive security program. Below we outline the technical and organizational measures in place to protect Customer Personal Data, as required by GDPR Article 32 and referenced in the SCCs. These measures apply to all Customer Personal Data processed by Amio as your Processor. (This Annex II corresponds to Annex II of the SCCs, listing the security measures.)

1. Data Encryption: All Customer Personal Data is encrypted in transit and at rest. We use industry-standard encryption protocols. For data in transit, we enforce HTTPS/TLS (TLS 1.2 or higher) for all communication between the chatbot, end-users, and our servers, as well as between our internal services and any sub-processors. For data at rest, we utilize strong encryption (such as AES-256 or equivalent) for databases, backups, and storage systems that hold personal data. Encryption keys are managed securely and with restricted access.

2. Access Control and Authentication: We have strict controls to ensure only authorized personnel can access Customer Personal Data:

Access Control Policies: Access to systems storing personal data is limited based on the principle of least privilege. Team members are granted access solely on a need-to-know basis and only to the minimum extent necessary for their role.
User Authentication: Both our internal staff accounts and customer accounts are protected by authentication measures. We support strong passwords and encourage the use of multi-factor authentication (MFA) for our staff and, where applicable, for customer admin accounts. Internally, Amio requires multi-factor authentication for all employees accessing production systems.
Administrative Access Logging: We log and monitor administrative access to infrastructure and sensitive systems. Any access to production databases or servers containing personal data by Amio engineers (for troubleshooting or maintenance) is logged, reviewed, and only done through secure connection methods.
Separation of Environments: Development and testing environments are separated from the production environment. We do not use actual Customer Personal Data in testing environments without your permission; instead, we use anonymized or synthetic data for testing and development whenever possible.

3. Physical and Infrastructure Security: Amio’s services are hosted on secure cloud infrastructure (such as reputable cloud service providers with strong security track records). These data centers include robust physical security controls: security personnel, access badges, biometric scanners, CCTV, and other mechanisms to prevent unauthorized physical access to servers. The cloud providers maintain certifications like ISO 27001 and SOC 2, indicating adherence to high security standards. We rely on their infrastructure security (firewalls, DDoS protections, etc.) and add our own configurations:

Network Security: We use firewalls, network segmentation, and security groups to control access to systems. Only required network ports are open and only between necessary components. We regularly update and patch our servers and apply security updates to software and dependencies in a timely manner to mitigate vulnerabilities.
Monitoring and Threat Detection: Our systems are continuously monitored for security events. We employ intrusion detection and prevention systems, as well as anti-malware and integrity monitoring on servers. Unusual activities or anomalies trigger alerts to our security team. We also log relevant events (logins, administrative actions, errors) and retain those logs securely for analysis and audit.

4. Isolation of Customer Data: We utilize logical separation of data for each customer within our multi-tenant architecture. This means your data is tagged or segmented so that it is not intermixed with another customer’s data. Proper permission checks in software ensure that, for example, one customer’s chatbot cannot retrieve data from another customer’s knowledge base or chats. This tenant isolation is enforced at the application level, and in some cases at the database level, to prevent data leakage across customers.

5. Data Backup and Recovery: We perform regular backups of critical data (including Customer Personal Data such as chatbot logs and knowledge base content) to prevent data loss. Backups are encrypted and stored securely (often in a different geographic region or data center for redundancy). We periodically test our backups and restoration procedures to ensure data can be recovered in case of accidental deletion or disaster. We have disaster recovery plans and processes to restore services and data in a timely manner in the event of a significant outage or data loss incident.

6. Personnel Security & Training: All Amio employees and contractors with potential access to Customer Personal Data undergo background checks as allowed by law and role-appropriate screening. Every team member is required to sign confidentiality agreements. We provide regular training to our staff on data protection, privacy, and security practices, emphasizing their responsibilities when handling personal data. This includes training on phishing awareness, proper data handling procedures, and incident reporting. We also limit which personnel can access personal data; for example, customer support might access account information but not raw chatbot logs unless necessary for support, and even then under controlled circumstances.

7. Vendor and Sub-processor Management: We carefully select any third-party Sub-processors (as discussed in Section 6 of the DPA) and ensure they have robust security measures. We review their security documentation/certifications and include data protection requirements in contracts. We continue to monitor their compliance (e.g., by reviewing their SOC reports or security updates).

8. Operational Security and Procedures: We maintain internal policies and procedures to guide our day-to-day operations securely:

Change Management: We have a process for reviewing and testing changes to our infrastructure and software (including security impact assessment) before deploying to production. This helps prevent unintentional vulnerabilities.
Incident Response Plan: We have a defined procedure for handling security incidents. This includes steps for identification, containment, eradication, recovery, and communication (including the breach notification to customers as described in Section 8). We regularly review and practice this incident response plan.
Privacy by Design: We integrate privacy considerations into our product design and development processes. New features undergo privacy and security review, and we strive to minimize personal data usage and storage wherever possible (for example, we might hash or pseudonymize certain data if full plain-text is not needed).

9. Audits and Certifications: Where appropriate, we undergo independent audits or assessments of our security program. For instance, we may pursue relevant industry certifications or compliance audits (such as ISO 27001 or SOC 2 Type II). Results of these audits can be provided in summary as evidence of our controls. Additionally, we perform internal audits and risk assessments periodically to ensure continued effectiveness of our controls.

10. Continual Improvement: Security threats evolve, and so do our measures. We continuously evaluate new security tools and best practices. When necessary, we update our security measures to address emerging risks (e.g., adopting a new recommended encryption standard, or implementing a new monitoring system). We also maintain insurance and incident response partnerships to assist in case of major security events.

These measures collectively ensure a high level of security appropriate to the risk of the personal data we process. We commit to maintaining these measures and not reducing the security protections during the term of our Agreement. For any specific questions about security measures, you can contact us, and we will provide additional details as reasonably possible.

(This Annex II corresponds to the technical and organizational measures required by Annex II of the Standard Contractual Clauses. It may be updated as we enhance our security, but we will not materially weaken any measures listed without informing you.)

Annex III – International Transfer Mechanisms (SCC and UK Addendum Details)

This Annex provides the specific details and selections for the Standard Contractual Clauses (SCCs) and the UK International Data Transfer Addendum, as referenced in Section 11 of the DPA. Essentially, it fills in the blanks of the SCCs with information from this DPA and confirms the choices made where the SCCs or UK Addendum allow for options. This Annex III, together with Annex I and Annex II, will form the Appendix/Annexes to the SCCs.

1. Parties to the SCCs:

Data Exporter: The Customer (you).
- Role: Controller (as defined in GDPR) with respect to the personal data you submit to Amio. (If you are using Amio as a Processor for another Controller, then for the SCCs you will be the “data exporter” but acting as a Controller on behalf of a third-party Controller – essentially the SCCs Module Two still applies with you as exporter on behalf of that ultimate Controller).
- Address and Contact: The address and contact details you provided in the Agreement or your account with Amio shall be used. (We consider the Customer’s registered business address or principal place of business, and the email of your contact person/admin on the account as the contact point. You should ensure this info is up to date in our records.)
- Signature & Date: By entering the Agreement and this DPA, the data exporter is deemed to have signed the SCCs as of the effective date of the Agreement or whenever transfers of personal data subject to GDPR occur.
Data Importer: Amio s.r.o.
- Role: Processor (as defined in GDPR) providing AI chatbot services and processing personal data on behalf of the data exporter.
- Address: Bartoškova 1411/20, Nusle, 140 00 Praha 4, Czech Republic.
- Contact: privacy@amio.io (Data Protection Officer or privacy team contact).
- Company info: Company ID 06177794. Amio is subject to Czech and EU data protection laws.
- Signature & Date: By entering the Agreement and this DPA, Amio is deemed to have signed the SCCs as of the effective date of the Agreement or whenever transfers of personal data subject to GDPR occur.

(Both parties agree that the execution of the DPA constitutes execution of the SCCs. No separate signature is required, in line with Clause 7 (docking clause) of the SCCs, which by the way, we do include to allow additional parties if needed.)

2. Selected SCC Module: The parties have selected Module Two: Transfer Controller to Processor of the EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914 of 4 June 2021). If Amio ever acts as a sub-processor (Processor to Processor transfer) on your behalf for data from the EEA/Switzerland, we will also ensure Module Three (Processor to Processor) SCCs are in place down the chain, but that is handled through our sub-processor contracts (you are not directly party to Module Three in that case, but your data still gets the protection).

3. Optional Clauses: Under the SCCs Module Two, Clause 7 (the “docking clause” allowing new parties to be added) is accepted/included. This means the SCCs can be extended to new parties if, for example, you have affiliates that sign onto the DPA or if we agree to add another controller or processor later. Clause 11(a) (the optional transparency clause for the data importer to provide copies of sub-processor agreements to the data subject) is not included (this clause is optional and we typically do not include it because we instead provide information about sub-processors to you, the exporter, rather than directly to data subjects, which is consistent with Section 6 of the DPA).

4. Governing Law (Clause 17) of the SCCs: The parties agree that the law of the Czech Republic will govern the Standard Contractual Clauses. We chose Czech law because Amio is established in the Czech Republic, which is an EU Member State, and our Agreement’s governing law is also Czech. (If for some reason Czech law is not permissible, the fallback would be the law of another EU country that is valid, but as it stands Czech law is valid and covers GDPR enforcement.)

5. Choice of Forum and Jurisdiction (Clause 18): The parties submit to the jurisdiction of the courts of the Czech Republic for resolving disputes under the SCCs. In practice, this typically means the courts of Prague, Czech Republic, unless otherwise required by GDPR (which aligns with choosing Czech law above). This does not oust the jurisdiction of any supervisory authority or data subject rights to lodge complaints in their home country; it only pertains to how we as parties would resolve a dispute between us under the contract terms.

6. Description of the Transfer: The details about the data being transferred are laid out in Annex I of this DPA, which serves as Annex I.A and I.B of the SCCs (covering the list of parties and description of transfer). In summary: the data exporter is the Customer (controller), the data importer is Amio (processor); the data subjects, categories of data, purposes of processing, and duration are all described in Annex I above. There are no special categories of data intended (Annex I indicates we do not process special category data unless inadvertently provided, which we treat with special care but it’s not part of the intended transfer). The processing is continuous and on-demand as users interact with the chatbot, for the duration of the Agreement. The frequency of the transfer is continuous (as data flows with each interaction or periodically when you upload content). The retention period is until deletion as per the Agreement (again described in Annex I and Section 10). For transfers to sub-processors, the subject matter and nature are the same, just performed by those sub-processors under our instructions.

7. Security Measures: The technical and organizational measures implemented by the data importer (Amio) are set forth in Annex II of this DPA (which corresponds to Annex II of the SCCs). This includes encryption, access controls, etc., as detailed above. These measures are in place to protect the data during and after transfer.

8. Sub-Processors (for SCC Clause 9): The data exporter provides general authorisation to the data importer to use sub-processors, as per DPA Section 6. In terms of SCC Clause 9, the parties select the “General Written Authorisation” option. The data importer has listed its sub-processors online (as referenced in Section 6.2) and shall inform the data exporter of any intended addition or replacement of sub-processors at least 10 days in advance (as stated in Section 6.3 of the DPA). The exporter then has the right to object, etc. This aligns with Clause 9(a) Option 2 of the SCCs.

9. Competent Supervisory Authority: For the purposes of the SCCs, the lead or competent Supervisory Authority will typically be determined by the exporter’s established location in the EEA. If the exporter is not established in the EEA (for example, if you are a non-EU entity but still subject to GDPR via targeting individuals in the EU), then you should have appointed an EU representative or identified a main establishment. Generally, since we chose Czech law and jurisdiction, the Czech Data Protection Authority (ÚOOÚ) could be considered the relevant authority if needed. However, this does not preclude other EU authorities from involvement depending on the data subjects’ location. (This is a bit legalistic; essentially the SCCs require identifying who the regulator is. We consider it to be the regulator in the EU country where the exporter is located, or if none, Czech Republic’s regulator by default due to our presence.)

10. UK Addendum Specifics: For transfers from the UK, the International Data Transfer Addendum (version B1.0, in force 21 March 2022) is applied to the SCCs as follows:

Table 1 (Parties): The parties are the same as listed above for the SCCs (Customer as Exporter, Amio as Importer), and the key contact and company details are as in Annex I.
Table 2 (Selected SCCs): We are using the EU SCCs Module 2 as described, so that is the framework the UK Addendum applies to.
Table 3 (Appendix Information): The list of Annex information is taken from this DPA: Annex I (Sections A-F above) corresponds to “List of Processing/Transfer Details”, Annex II is “Security Measures”, and the information about sub-processors and technical measures is as given. Essentially, the content of the SCC Appendix is defined in our Annex I and II.
Table 4 (Ending of the Addendum): We select “Neither Party” will be able to terminate the UK Addendum when the ICO issues new standard clauses. (This means the Addendum will remain in force until it is replaced by an updated mechanism as required, but neither of us individually can just opt out upon new clauses being available, except as permitted by the Addendum’s terms.)
Governing Law for Addendum: By default, the UK Addendum inherits the governing law of the SCCs (which we set as Czech law) for interpretation. However, the UK Addendum itself is governed by the laws of England and Wales in terms of ensuring it’s enforceable under UK law. (This is generally implicit; we can clarify that any disputes under the UK Addendum would be heard in UK courts if required, but since the Addendum primarily ties into the SCCs, any major dispute likely falls under the SCC jurisdiction. We don’t anticipate issues, as we comply with the terms regardless of forum.)

By including the above in this Annex III, we ensure the SCCs and UK Addendum are properly anchored with the necessary details. If any conflicts arise between this Annex III (or the SCCs/Addendum) and the main body of the DPA, the SCCs and required terms will prevail to the extent needed to comply with international transfer law (as noted in Section 11 and the SCCs themselves).

Confirmation: Both you and Amio agree that the SCCs (and UK Addendum, if applicable) are hereby entered into and become effective as of the first transfer of Customer Personal Data from the EEA, Switzerland or UK to Amio (or its sub-processors) in a third country. There’s no need for a separate signing ceremony; this Annex and the DPA are sufficient evidence of the SCCs being in place.