Data Processing Agreement (art. 28 GDPR)

• Controller: the business or organisation that contracts the Jobchain ID business services ("the Controller").
• Processor: Jobchain ID, S.L.U., Tax ID B10734804, Calle Tarongers 3, 46680 Algemesí (Valencia), Spain ("the Processor").
• This agreement governs the processing of personal data that the Processor carries out on behalf of the Controller when providing the services described in the Business Terms, in accordance with article 28 of Regulation (EU) 2016/679 (GDPR) and Spanish Organic Law 3/2018 (LOPDGDD). It forms part of the services contract and is accepted together with the Business Terms when signing up the organisation, or by signing it separately.
• Annex I describes the processing: its nature and purpose, the types of data, the categories of data subjects and the duration.
• This agreement does not apply to the data that Jobchain ID processes as controller: each person's personal Jobchain ID account, the accounts of the people who manage the dashboard and billing data. Those are governed by the Privacy Policy.

This agreement lasts as long as the services contract and, afterwards, for the time needed to comply with the clause "End of the agreement".

• The Processor will process the data only on the documented instructions of the Controller. Documented instructions are this agreement, the Business Terms, the configuration the Controller sets in the dashboard or the API (for example, which data it requests, which credentials it issues or to whom) and the written instructions it sends to privacidad@jobchain.com.
• If Union or Spanish law requires the Processor to process the data otherwise, it will inform the Controller beforehand, unless that law prohibits it.
• If the Processor considers that an instruction infringes data protection law, it will inform the Controller immediately and may suspend its execution until it is clarified.
• The Processor will not use the data for its own purposes, sell it, or use it for advertising or to train artificial intelligence models.

The Processor ensures that the persons authorised to process the data have committed themselves to confidentiality or are under a statutory obligation of confidentiality, and that they only access it when necessary to provide the service.

• The Processor applies the technical and organisational measures in Annex II, appropriate to the risk (article 32 GDPR).
• By design, much of the data never reaches the Processor in clear: messages, mail and documents are end-to-end encrypted on people's devices, and face matching is done on the data subject's phone.
• The Processor may update the measures provided it does not lower the level of protection.

• The Controller gives a general authorisation for the Processor to engage the sub-processors in Annex III.
• Before adding or replacing a sub-processor, the Processor will notify the Controller at least 30 days in advance, by email to the administrators and on this page. The Controller may object on reasonable data protection grounds within that period; if no solution is found, it may terminate the contract without penalty and recover the unused part of fees paid in advance.
• The Processor will impose on each sub-processor, by contract, the same data protection obligations as in this agreement, and will remain liable to the Controller for their compliance.

The Processor will only transfer data outside the European Economic Area with a safeguard under Chapter V GDPR: an adequacy decision (including the EU-US Data Privacy Framework for participating companies) or the European Commission's standard contractual clauses (module 3, processor to sub-processor). Annex III states the safeguard for each sub-processor.

Taking into account the nature of the processing and the information available to it, the Processor will assist the Controller:

• in responding to data subjects' requests (access, rectification, erasure, restriction, portability and objection). If a data subject contacts the Processor, it will pass the request on to the Controller without delay and will not answer it on its own, unless the Controller asks it to;
• in complying with its obligations regarding security, breach notification, data protection impact assessment and prior consultation with the supervisory authority (articles 32 to 36 GDPR).

• The Processor will notify the Controller of any personal data breach affecting the data it processes on the Controller's behalf without undue delay and, in any case, within 48 hours at most of becoming aware of it, by email to the administrators.
• The notification will include, as far as known: what happened, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed and a contact point. If not everything is known at once, the information will be provided in phases.
• Notifying the supervisory authority and the data subjects is the Controller's responsibility; the Processor will give it the information it needs.

• When the contract ends, the Controller may export its data from the dashboard for 30 days, or ask the Processor to return it in a structured format.
• After that period, the Processor will delete the personal data processed on behalf of the Controller, including copies, unless Union or Spanish law requires it to keep it; in that case, it will keep it blocked and use it only to comply with that obligation.
• Encrypted backups are deleted 35 days after they are made.
• Credentials already delivered to data subjects are on their phones and do not depend on the Processor; the Controller can revoke them before the end.

• The Processor will make available to the Controller the information necessary to demonstrate compliance with this agreement.
• The Controller may carry out or commission audits, including inspections, with reasonable notice of at least 30 days, during business hours, without affecting the security of other customers and with a confidentiality undertaking from the auditor. Unless the audit reveals a breach, its cost is borne by the Controller.
• The parties will first try to resolve it with the documentation, reports and certifications available; on-site inspection is reserved for when that is not enough or an authority requires it.

The Controller warrants that it has a legal basis for each processing it entrusts, that it has informed the data subjects as required by articles 13 and 14 GDPR, that its instructions comply with the law and that, if it processes special categories of data or data of minors, it meets the additional requirements applicable to them.

Each party is liable towards data subjects and authorities under article 82 GDPR. Between the parties, the liability regime of the Business Terms applies, except where the GDPR does not allow it to be limited.

In everything relating to personal data, this agreement prevails over any other contract document. It is governed by Spanish law and disputes are submitted to the courts of the city of Valencia (Spain).

Nature and purpose. Depending on the services the Controller uses:

Categories of data subjects: the Controller's customers, users and contacts; its staff and collaborators; the people to whom it issues credentials or sends documents.

Types of data (only those the Controller requests and the person agrees to share):

• identifiers: DID, session identifier and organisation identifier;
• identity data taken from the document chip: name, surnames, date of birth, nationality, type, issuing country, number and expiry of the document and, if the Controller requests it, the document photo;
• verification result: level, method, date and results of the checks;
• verified contact data: email and phone;
• country of residence, if verified;
• content of the credentials the Controller issues;
• documents sent for signature and their signatures;
• technical logs: date, time, IP address and result of each operation.

Special categories. The Processor does not process biometric data on behalf of the Controller: face matching is done on the data subject's phone. The document photo is only delivered if the Controller requests it and the person shares it; the Controller decides whether it treats it as biometric data and on what basis.

Retention periods.

• Responses the person shares with the Controller: the Processor keeps them until the person deletes their account or the Controller asks for them to be deleted, to be able to resolve incidents. They are not currently deleted earlier automatically.
• Credentials issued: for as long as the Controller keeps them or until the person deletes their account.
• Dashboard activity log: the IP, 90 days; the log, 2 years.
• After the end of the contract: as stated in the clause "End of the agreement".

Product measures:

• people's private keys generated and kept only on their devices;
• end-to-end encryption of messages, mail and documents;
• face matching and liveness check on the data subject's device;
• chip data processed only during issuance, without keeping it; document-identity link by means of HMAC with a key kept separately;
• app integrity attestation (Apple App Attest and Google Play Integrity) in verifications;
• role-based access control to the dashboard, with verified identity and without passwords;
• organisation activity log, with the IP anonymised after 90 days;
• encryption in transit (TLS) in all communications;
• separation of test and production environments.

Infrastructure measures (Amazon Web Services, Frankfurt):

• database, file system, cache and backups encrypted at rest with our own AWS KMS keys, with automatic rotation; the database is not reachable from the internet;
• object stores (Amazon S3) encrypted at rest and with public access blocked;
• private key of the credential issuer in AWS KMS, non-exportable, which only the identity service can use to sign, and only from the private network;
• log of the account's activity in all regions (AWS CloudTrail), encrypted, with integrity validation and protected against deletion for 365 days;
• technical logs of the services encrypted and kept for 90 days;
• web application firewall (AWS WAF) in front of the API;
• threat detection and continuous configuration review (Amazon GuardDuty, AWS Security Hub, AWS Config and IAM Access Analyzer);
• daily backups of the database and the files, duplicated in a separate AWS account used only for backups, protected against early deletion and kept for 35 days;
• alarms on errors, latency, availability, firewall blocks, use of the root account and permission changes;
• no users with permanent access keys in the production account: access is through roles with temporary credentials.

Organisational measures:

• access to production data limited to the people who need it, with a confidentiality undertaking;
• security breach management procedure with notice to the Controller within 48 hours;
• security review of the code before each change in production.

The XMTP network is an open transport network run by third parties: the messages travel over it end-to-end encrypted on each person's device, and XMTP cannot read their content. It is described in the Privacy Policy.