> For the complete documentation index, see [llms.txt](https://docs.toolkit.equs.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.toolkit.equs.ai/docs/legal/dpa.md). # Data Processing Agreement Data Processing Agreement in accordance with Art. 28 GDPR for the EQUS Developer Toolkit Private Beta (Managed SaaS), with EU Standard Contractual Clauses. Version 1.1, 16 October 2026. {% file src="/files/9mPO6vwfzEvAz2m3NYxW" %} Executed PDF, including the full text of the EU Standard Contractual Clauses {% endfile %} > The executed version of this Agreement, including the full text of the EU Standard Contractual Clauses with the Parties' selected options marked, is the signed PDF provided to each Customer. This page reproduces the Agreement for reference. **between** EQUS, Inc.\ 50 W. Liberty Street, Suite 1040\ Reno, NV 89501\ United States\ *"Processor"* **and** the Customer named in the Contract\ *"Customer"* *Processor and Customer each a "Party" and together the "Parties"* #### Preamble The present Agreement specifies the obligations of the Parties on data protection resulting from the Data processing described in detail in the Contract between the Parties about the provision of the EQUS Developer Toolkit Platform ("Master Agreement"). It is applicable to all activities connected to the Master Agreement and in which employees of the Processor or sub processors of the Processor may come in contact with personal Data ("Data") provided by Customer. It applies to the managed SaaS model of the EQUS Developer Toolkit Platform only. ### 1. Subject matter, duration and specification of Data processing **1.1** The subject matter of Data processing is described in the Master Agreement. Substantially, the Processor's tasks comprise the following: * The Provision and operation of a SaaS platform (“EQUS Developer Toolkit”) for the issuance, management, and verification of digital credentials for Issuers and Verifiers. * Processing of personal attribute values (Credential Claims) within the scope of credential issuance; values are not retained by Processor. * Handling of presentations solely for technical verification; presentation contents are not stored by Processor. * Maintenance and provision of credential status/revocation information and related verifier query interfaces (e.g., signature, validity, and status checks). **1.2** The type and purpose of Data processing are described in the Master Agreement and specifically comprise: * Issuance: processing personal attribute values (credential claims) solely to create/sign a credential token and deliver it to the holder’s wallet; Processor retains only an issuance result (timestamp/status) and a token status bit, a pseudonymous subject identifier. * Verification: receiving a vp\_token that reveals only requested claims, performing signature/validity/status checks, and returning a verification result; vp\_token/claims are not stored. EQUS retains only the verification result and a token status bit. * Status/revocation interfaces: operating token status lists and related endpoints for verifiers; no credential content is stored. **1.3** Processing comprises the types of Data specified below: * Credential claims for issuance and verification: depending on the credential, this may include various Data, such as identification Data (e.g., name, date of birth, address), account identifiers (e.g., account number, account holder, opening date), KYC completion status, and sanctions screening result. The concrete claim sets are determined by the Customer’s credential designs and are communicated at least in text form to Processor. * Wallet authentication and contact Data: limited login identifiers and communication details (e.g., e-mail address or device-binding information) required to deliver credentials or initiate presentations. * Credential lifecycle metadata: issuance result (timestamp/status), verification result, and token status entries (e.g., token status bit/status list indices). * Technical verification artifacts handled transiently: vp\_token and the revealed claims (processed for verification and not stored by the Processor) **1.4** The following categories of individuals are affected by processing: * Natural persons who are the subjects of credentials (Holders), including in particular customers of Customer. **1.5** The term of the present Agreement is determined by the term of the Master Agreement unless obligations going beyond that date result from the provisions of the present Agreement. **1.6** Data in connection with the services of the Main Agreement is hosted in data centres within the European Union. Data can be accessed from a third-country outside the European Union, in particular the United States. The special requirements of Art. 44 et seqq. GDPR have been satisfied. An adequate level of protection in the third country is ensured by standard data protection clauses (Art. 46 (2) lit. c) and d) GDPR (“EU SCC”). The Parties agree to apply Module Two of the EU SCC, by way of referencing them in Appendix 3 of the present Agreement. ### 2. Scope of application and responsibility **2.1** The Processor processes Data at the instruction of the Customer. This comprises activities as described in detail in the Master Agreement and in the performance specification. With regard to Data processing, the Customer is responsible for compliance with the statutory regulations on Data protection and especially for the legitimacy of Data processing. **2.2** At the outset, the instructions will be set forth in a contract and may subsequently be modified, amended or substituted by the Customer in writing or in text form at the location designated by the Processor (single instruction). **2.3** Any oral instructions shall be confirmed by the Customer without delay, at least in text form, and are not valid until then. **2.4** The Processor shall inform the Customer forthwith if it is of the opinion that an instruction violates data protection rules. The Processor is entitled to suspend compliance with the instruction in question until it is either confirmed or changed by the Customer. ### 3. Obligations of the Processor **3.1** The Processor may process Data of data subjects only within the scope of the assignment and the documented instructions of the Customer. In the event that the Processor should be obliged to process Data differently as a result of national or European law, it shall point out the circumstance to the Customer before processing begins. **3.2** Only to the extent required under applicable law, the Processor shall (a) not process Data outside of the direct business relationship between the Parties; (b) not “Sell” or “Share” such Data for targeted advertising purposes, as such terms are defined under the California Consumer Privacy Act or other applicable data protection law; and (c) not combine Data with any other personal data received from or on behalf of other persons or entities. **3.3** The Processor shall set up the internal organisation of his area of responsibility in such a manner that it meets the specific requirements of data protection. The Processor shall take the technical and organisational measures described in Appendix 1 so as to ensure adequate protection of the Customer's personal Data. The purpose of these measures is to ensure long-term confidentiality, integrity, availability and stress resistance of the systems and services in connection with the processing of personal Data. The Customer is aware of these technical and organisational measures. It is the Customer's responsibility to ensure that these measures provide an adequate level of protection in connection with the risks of personal Data processing. **3.4** The Processor reserves the right to change the technical and organisational measures taken but must guarantee that the level of protection agreed in the contract does not diminish. **3.5** To the best of his ability and within the scope of the services or under the contract, the Processor shall assist the Customer in dealing with requests and claims of data subjects pursuant to chapter III of the GDPR and in discharging the obligation specified in Articles 33 to 36 GDPR. For these services, the Processor is entitled to adequate financial compensation. **3.6** The Processor warrants that its employees involved in the processing of the Customer's personal Data and other individuals working for the Processor are prohibited from processing such personal Data outside the scope of the Customer's instructions. The Processor further ensures that the individuals authorised to process personal Data have signed an agreement of confidentiality or are subject to an adequate confidentiality clause. This obligation of confidentiality and secrecy shall remain in effect even beyond completion of an assignment. **3.7** The Processor shall inform the Customer without delay as soon as it becomes aware of any violation of the protection of the Customer's personal Data. The Processor shall take the necessary measures to safeguard personal Data and to alleviate possible disadvantageous consequences for the data subject and shall consult with the Customer in that respect without delay. **3.8** The Processor is obliged to appoint a competent and reliable Data Protection Officer pursuant to Art. 37 GDPR to the extent and as long as the statutory prerequisites for such an obligatory appointment are in force. Furthermore, the Processor is obliged to appoint a competent and reliable EU representative pursuant to Art. 27 GDPR to the extent and as long as the statutory prerequisites for such an obligatory appointment are in force. If the Processor is not obliged to appoint a Data Protection Officer, it shall give the Customer the name of the contact for any questions in relation to data protection that may arise in connection with the agreement. **3.9** The Processor shall ensure that its obligations pursuant to Art. 32 (1) lit. d) GDPR are complied with and put in place a process for regular examination of the efficacy of the technical and organisational measures to ensure the safety of processing. **3.10** The Processor shall correct or erase personal Data if instructed accordingly by the Customer and if this is a part of the scope of instructions. The Customer is responsible for correction and erasure of personal Data. The same is true for the restriction of the processing of personal Data (blocking). **3.11** The personal Data shall be erased at the end of the respective Master Agreement with a transition period of up to 30 (thirty) days after termination date, during which the Processor undertakes to make available to the Customer all data processed on the Customer’s behalf via download link and the present Agreement continues to apply respectively. Within those 30 (thirty) days of termination of the Master Agreement, the Customer shall instruct Processor in text form to (a) archive, (b) deactivate, or (c) erase its issuer identity (“Issuer DID”). If the Customer gives no separate instruction, option (a) is deemed to be instructed by default. The Parties agree their understanding that neither the Issuer DID nor the remaining status list contain any personal Data and thus, are not subject to this agreement anymore. **3.12** It is up to the Customer to prepare backup copies of its personal Data and to move such personal Data before the end of the Master Agreement or the present Agreement. The Processor is not obliged to surrender personal Data to which the Customer has direct access. **3.13** The Processor undertakes to maintain a record of Data processing activities pursuant to Art. 30 (2) GDPR. ### 4. Obligations of the Customer **4.1** It is the Customer's responsibility to provide the Processor with the personal Data in good time so as to enable the latter to provide the services pursuant to the Master Agreement. The Customer is responsible for the quality of the personal Data. The Customer shall inform the Processor immediately and completely in the event that it should identify any errors or irregularities with regard to data protection rules or in the services when checking the work products of the Processor. **4.2** In the event that claims should be made by a data subject in connection with Art. 82 GDPR, the Customer and the Processor undertake to assist each other in the defence against such claims. The Customer shall provide the Processor with details of the contact for any data protection queries arising in connection with the agreement. ### 5. Queries from data subjects If a data subject contacts the Processor demanding correction, erasure, restriction of processing or information about the personal Data, the Processor shall refer that request to the Customer if allocation to the Customer is possible on the basis of the information provided by the data subject. ### 6. Ways of verification **6.1** If so requested, the Processor shall submit suitable proof to the Customer that the obligations set forth in Art. 28 GDPR and in the present Agreement have been complied with. For the purpose of proving compliance with the agreed obligations, the Processor may provide the Customer with certificates and third-party test results (e.g. pursuant to Art. 42 GDPR or ISO 27001) or with test reports of the internal Data Protection Officer or any individual to whom this task has been assigned by the Data Protection Officer. **6.2** In the event that spot checks by the Customer or an auditor appointed by the Customer should turn out to be necessary in individual cases, these shall be conducted during the regular business hours from Monday to Friday between 8 a.m. and 5 p.m. PT without disruption of operations and after an adequate notification period of at least 4 days. The Processor is entitled to make approval of such checks dependent on signing an adequate declaration of secrecy by the Customer or the auditor assigned by the Customer. If the auditor appointed by the Customer should be a competitor of the Processor, the Processor is entitled to object. Such objection shall be declared to the Customer in text form. **6.3** In the event that an audit should be carried out by the data protection supervisory agency or another state authority, Section 6.2 shall apply mutatis mutandis as a matter of principle. Signing an undertaking of confidentiality is not required if the supervisory authority is subject to professional or statutory confidentiality any breach of which shall be penalised in accordance with the German Criminal Code. **6.4** The Processor is entitled to request adequate compensation for carrying out such an audit pursuant to Sec. 6.2 or 6.3, unless the reason for such an audit is the strong suspicion that an event affecting data protection has taken place within the scope of responsibility of the Processor. In such a case, details of the suspicion must be submitted by the Customer with the notification of the examination. ### 7. Sub-Processors (additional Data Processors) **7.1** The Customer agrees to the Processor involving subprocessors. Before involving or replacing subprocessors, the Processor shall inform the Customer in text form with four (4) weeks' notice. The Customer may object to such a change only for good cause. Any objection must be lodged within 14 (fourteen) days, and all causes must be specified explicitly. If no objection is lodged within this time limit, consent to the change is deemed to have been given. If there is good cause which cannot be eliminated by the Processor by adjusting the assignment, the Customer is granted an extraordinary right of termination. No separate information will be provided regarding the subprocessors and their partial services as listed in Appendix 2 already in place when the agreement is signed. If the Processor gives assignments to subprocessors, it is up to the Processor to convey its obligations under the present Agreement regarding data protection to the subprocessor. **7.2** Upon written request of the Customer, the Processor shall provide information regarding the obligations of its subprocessors in terms of data protection at any time. **7.3** The provisions of this section 7 shall also be applicable if a subprocessor in a third country is involved, observing the principles of Chapter 5 of the GDPR. The Processor agrees to cooperate as required in meeting the prerequisites as set in Chapter 5 of the GDPR. ### 8. Liability **8.1** The limitations of liability under the Master Agreement are applicable. **8.2** The Customer shall indemnify the Processor against any claims lodged by third parties against the Processor as a result of the processing of personal Data according to the instructions of the Customer unless the claim of such third party is based on processing the personal Data by the Processor in violation of instructions. ### 9. Obligations of information, written form clause, choice of law **9.1** In the event that the Customer's personal Data should be placed at risk as a result of seizure or confiscation, insolvency or settlement proceedings or by other events or measures of a third party while being processed by the Processor, the Processor shall inform the Customer forthwith. In this connection, the Processor shall inform all third parties without delay that control and ownership of the personal Data exclusively lie with the Customer as the "controller" as defined in the GDPR. **9.2** Any changes to and amendments of the present Agreement and all its elements – including possible assurances of the Processor – must be in writing which may also take the text form and include an explicit reference that this is a change to or amendment of the present Agreement. This also applies to any waiver of the text form clause. **9.3** In the event of possible contradictions, the provisions in the present Agreement regarding data protection take precedence over the provisions of the Master Agreement. If individual provisions of the present Agreement should be or become invalid, the validity of the agreement as such shall not be affected. **9.4** The present Agreement is governed by the law and competent court as agreed in the Master Agreement. ### Appendix 1: Technical and Organisational Measures for Private Beta This Appendix 1 specifies the technical and organisational measures taken by EQUS for the Private Beta Version of the EQUS DEVELOPER TOOLKIT. In this regard, especially the current state of the art, the cost of implementation and the type, scope, circumstances and purposes of data processing are taken into account. In addition, the different likelihood of occurrence and the severity of the risks for the rights and freedom of data subjects will be observed to achieve a level of protection for personal data proportionate to the level of risk. #### 1. Hosting and data location Tenant data is hosted on Amazon Web Services. Customers established in the European Economic Area (EEA) are provisioned in the Frankfurt region (eu-central-1); US customers in the US West region (us-west-2). Authentication services, logging and backups are region-local. Tenant data at rest is not replicated between regions. #### 2. Encryption Credential claims held during issuance are encrypted at rest with a data key unique to each record, derived from a key encryption key unique to each Customer and managed in AWS Key Management Service under the Processor's control. Signed credentials are generated in memory at the point of delivery and are not persisted. Presentation data (vp\_token) held during verification is encrypted at rest in the same way as claims. All other stored data is protected by AWS volume-level encryption. All data in transit is protected by TLS 1.2 or higher. #### 3. Access control Decryption of Customer data in the ordinary course is performed only by the Platform's application service role. AWS account administration is restricted to named EQUS personnel. Use of Customer encryption keys is logged in AWS CloudTrail. The Processor's engineering contractor (DSR, Portugal) provides technical support and does not hold production data access. #### 4. Pseudonymisation and data minimisation The Processor does not store Holders' names, e-mail addresses or other contact details as identifiers. The record of issued credentials holds only the identifier supplied by the Customer for the Holder, together with issuance timestamp, credential type and status. Credentials are stored on the Holder's device under device-held keys; the Processor retains no copy after delivery. Status list entries contain no personal data. #### 5. Retention and deletion Credential claims are deleted from the Processor's systems within minutes of the credential being claimed by the Holder, or after five days if not claimed. Presentation data is deleted on completion of verification and in any event within five minutes. The record of issued credentials is retained for the period set out in the Master Agreement. On termination, Customer data is made available for 30 days and then deleted, subject to clause 4.7 of the Terms of Service regarding status list entries. #### 6. Operator Portal Access is by individual named user accounts with multi-factor authentication enforced. Passwords are stored hashed. Failed authentication attempts are logged. Each Customer's tenant is logically isolated from all others; keys for one Customer cannot decrypt another Customer's data. #### 7. Environments Each Customer receives a sandbox tenant for testing and a production tenant for live credentials. Both run on the same Platform infrastructure and are separated logically by tenant configuration. Production is enabled per Customer on request. #### 8. Personnel EQUS personnel with access to production systems are bound by confidentiality obligations. Access is granted on a least-privilege basis and reviewed quarterly. #### 9. Incident management Security events are monitored. Personal data breaches are notified to the Customer without undue delay in accordance with clause 3.6. #### 10. Sub-processors Amazon Web Services, Inc. as listed in Appendix 2. No other sub-processor has access to Customer personal data. #### 11. Review These measures are reviewed at least annually and on material change to the Platform and will be expanded at General Availability. ### Appendix 2: Pre-approved Sub-processors | Sub-processor | Service | Location of processing | Transfer mechanism | Access to personal Data | | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Amazon Web Services, Inc., 410 Terry Avenue North, Seattle, WA 98109, United States | Cloud infrastructure, including compute, managed database and key management services, for the hosting and operation of the Platform. | For Customers established in the EEA, the Frankfurt region (eu-central-1). For Customers established in the United States, the US West region. Data is not moved between regions. Data might be accessed from the US. | AWS acts as sub-processor under the AWS GDPR Data Processing Addendum, which incorporates the EU Standard Contractual Clauses and applies to all AWS regions and services. | None in the ordinary course. Credential claims are encrypted at rest with per-tenant keys managed in AWS Key Management Service under Processor's control; AWS does not hold the key material in a form that permits decryption of Customer Data. | ### Appendix 3: EU Standard Contractual Clauses *The text of this Appendix is taken from the official website of the EU Commission and adjusted only as far as permissible to be in line with the present Agreement. The EU SCCs may be agreed upon electronically and are valid without signature.* #### Agreed options The Parties agree that the following options / choices as provided in the EU SCC are agreed upon: 1. **Regarding Clause 7 EU SCC, optional Docking clause:** The Parties have chosen that only Parties to the Agreement are in scope of the EU SCC. 2. **Regarding Clause 9 (a) EU SCC, MODULE TWO: Transfer controller to processor:** The Parties have chosen Option 2 (GENERAL WRITTEN AUTHORISATION regarding sub-processors). 3. **Regarding Clause 9 (a) EU SCC, specify time period:** The specify time period regarding Module Two is four (4) weeks, unless agreed otherwise. 4. **Regarding Clause 11 EU SCC, Redress:** The Parties have chosen to delete this option. Therefore, this option is not applicable. 5. **Regarding Clause 13 EU SCC, competent supervisory authority/ies:** The competent supervisory authority in accordance with Clause 13 EU SCC is by default the competent supervisory authority where the data exporter is incorporated. 6. **Regarding Clause 17 EU SCC, Governing Law regarding MODULE TWO:** The Parties have chosen Option 1. Option 2 is not applicable. The Parties agree that laws of Germany apply. 7. **Regarding Clause 18 EU SCC, Choice of forum and jurisdiction regarding MODULE TWO:** Competent Courts of Munich, Germany. 8. **Regarding APPENDIX to the EU SCC, ANNEX I, B. DESCRIPTION OF TRANSFER, “Sensitive data transferred \[…]”:** The Parties agree that sensitive Data might be transferred / processed. 1 (last visited: September 09, 2026). #### Appendix to the EU SCCs: Annexes I and II **Annex I** **A. LIST OF PARTIES** *Module Two: Transfer controller to processor* **Data exporter** **Name:** The customer as named in the Order Form **Address:** The customer’s address as provided in the Order Form **Contact person’s name, position and contact details:** The customer’s contact person as provided in the Order Form. **Activities relevant to the data transferred under these Clauses:** Please see Section 1 of the DPA **Signature and date:** The EU SCCs may be agreed upon electronically and are valid without signature. The date arises from the Order Form. **Role (controller/processor):** Controller **Data importer** **Name:** EQUS, Inc. **Address:** 50 W. Liberty Street, Suite 1040, Reno, NV 89501, United States **Contact person’s name, position and contact details:** MLL EU-GDPR GmbH, Ganghoferstrasse 33, 80339 Munich, Germany, Email: **Activities relevant to the data transferred under these Clauses:** Please see Section 1 of the DPA **Signature and date:** The EU SCCs may be agreed upon electronically and are valid without signature. The date arises from the Order Form. **Role (controller/processor):** Processor **B. DESCRIPTION OF TRANSFER** *Module Two: Transfer controller to processor* **Categories of data subjects whose personal data is transferred:** Please see Section 1 of the DPA **Categories of personal data transferred:** Please see Section 1 of the DPA. **Sensitive data transferred (if applicable) and applied restrictions or safeguards that fully take into consideration the nature of the data and the risks involved, such as for instance strict purpose limitation, access restrictions (including access only for staff having followed specialised training), keeping a record of access to the data, restrictions for onward transfers or additional security measures.:** Please see Section 1 of the DPA **The frequency of the transfer (e.g. whether the data is transferred on a one-off or continuous basis):** Continuous and recurring processing **Nature of the processing:** Please see Section 1 of the DPA **Purpose(s) of the data transfer and further processing:** Please see Section 1 of the DPA **The period for which the personal data will be retained, or, if that is not possible, the criteria used to determine that period:** Please see Section 1 of the DPA as well as the Contract **For transfers to (sub-) processors, also specify subject matter, nature and duration of the processing:** Please see Appendix 2 to the DPA Agreement (if any) **C. COMPETENT SUPERVISORY AUTHORITY** *Module Two: Transfer controller to processor* **Competent supervisory authority:** The competent supervisory authority in accordance with Clause 13 EU SCC is by default the competent supervisory authority where the data exporter or if applicable its EU representative is incorporated. **Annex II: Technical and organisational measures** *Module Two: Transfer controller to processor* Please see Appendix 1 to the DPA Agreement #### Standard Contractual Clauses: full text The Parties have agreed Module Two (transfer controller to processor) of the Standard Contractual Clauses adopted by the European Commission in Implementing Decision (EU) 2021/914, with the options set out in section 1 above and the Appendix in section 2. The full clause text, with the Parties' selections marked, is reproduced in the executed PDF of this Agreement. The Commission's official text is available at . --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.toolkit.equs.ai/docs/legal/dpa.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.