Data processing agreement

Between:

Taliro Global Talent, S.L., trading as Yellowdesk, registered office at Rambla de Badal 62, 3-3, 08014 Barcelona, Spain, tax number B26780288 ("Yellowdesk"); and

the customer identified in the Agreement ("Customer", "you").

This Data Processing Agreement ("DPA") forms part of the Terms of Service or other written agreement between the parties (the "Agreement"). It takes effect when you accept the Agreement, and it ends when the Agreement ends.

Why this document is not shaped like the market's

Most agreements of this kind in this market say the customer is the controller and the vendor is a mere processor for everything. That is a comfortable position and, for a service that sources its own data, it is not a true one. A processor does not go out and decide which vendors supply a database, which people are surfaced, what is retained and for how long. Yellowdesk does all of that.

So this DPA splits the roles by category of data. Where you supply the data, we are your processor and Part 1 applies. Where we source the data and supply it to you, we are a controller in our own right, you become an independent controller when you receive it, and Part 2 applies.

The practical consequence for you is favourable: the transparency obligation towards the people in our contact database is ours, and we accept it in clause 2.4 and indemnify you for it in clause 18. A vendor claiming to be your processor is, whether it says so or not, leaving that obligation with you.

1. Definitions

Terms defined in GDPR have the same meaning here: "controller", "processor", "data subject", "personal data", "processing", "personal data breach", "supervisory authority".

Applicable Data Protection Law means Regulation (EU) 2016/679 (GDPR), Spanish Organic Law 3/2018 (LOPDGDD), Directive 2002/58/EC and its national implementations, and any other data protection law applying to a party's processing under the Agreement.

Contact Data means personal data relating to business contacts that Yellowdesk sources from its own data vendors and makes available through the Service, including a person's name, job title, employer, business e-mail address, business telephone number and professional profile URL.

Customer Personal Data means personal data that you or your Users submit to, or generate in, the Service, including account and user records, uploaded CVs, saved searches and the criteria derived from them, and support correspondence. It does not include Contact Data.

Restricted Transfer means a transfer of personal data to a country outside the European Economic Area that is not subject to an adequacy decision.

SCCs means the standard contractual clauses in Commission Implementing Decision (EU) 2021/914.

Service, User, Credits and Contact Details have the meanings given in the Agreement.

Sub-processor means a third party engaged by Yellowdesk to process Customer Personal Data.

2. Roles of the parties

2.1 Customer Personal Data. You are the controller. Yellowdesk is the processor. Part 1 applies.

2.2 Contact Data. Yellowdesk is the controller for the sourcing, storage and supply of Contact Data through the Service. When Contact Data is revealed to you, you become a separate and independent controller for everything you then do with it. The parties are not joint controllers and Article 26 GDPR does not apply. Part 2 applies.

2.3 Yellowdesk operational data. Yellowdesk is the controller for the personal data it processes for its own purposes, including billing, fraud prevention, security, service e-mail and product analytics. This is described in the Privacy Policy and is not governed by this DPA.

2.4 Transparency towards data subjects in the contact database. Yellowdesk accepts the controller obligations under Articles 13, 14, 15 to 22 and 30 GDPR in respect of its own processing of Contact Data, including the obligation to make information publicly available where it relies on the exemption in Article 14(5)(b). You accept the equivalent obligations in respect of your own processing after a reveal.

2.5 Order of precedence. Where this DPA conflicts with the Agreement on a data protection matter, this DPA prevails. Where this DPA conflicts with the SCCs, the SCCs prevail.

# Part 1. Yellowdesk as your processor

*This Part applies to Customer Personal Data. It is the Article 28(3) contract.*

3. Processing on your instructions

3.1 Yellowdesk processes Customer Personal Data only on your documented instructions, including for a Restricted Transfer, unless required otherwise by EU or Member State law. Where such a law applies, Yellowdesk will tell you before processing, unless the law prohibits it.

3.2 Your instructions are: the Agreement, this DPA, your use of the features of the Service, and any further written instruction you give that the parties agree.

3.3 Yellowdesk will tell you if, in its opinion, an instruction infringes Applicable Data Protection Law. It may suspend the affected processing until the instruction is withdrawn or amended.

3.4 You warrant that you have a lawful basis for the personal data you submit, that you have given the data subjects the information their law requires, and that your instructions comply with Applicable Data Protection Law. This matters most for CVs, where the data subject is a third party with no relationship to either party. See clause 6.

3.5 Yellowdesk does not sell Customer Personal Data and does not use it to train any machine learning model.

4. Confidentiality

Yellowdesk ensures that every person authorised to process Customer Personal Data is bound by an appropriate obligation of confidentiality, is trained on their responsibilities, and has access only where their role requires it.

5. Security

5.1 Yellowdesk implements the technical and organisational measures set out in Annex III, appropriate to the risk, as required by Article 32 GDPR.

5.2 Yellowdesk may update those measures, provided the level of protection is not reduced.

5.3 You are responsible for the security of your own systems, your Users' credentials, and any export you take out of the Service.

6. CVs and Candidate Match

6.1 Where you upload a CV, the document is read into memory, converted to text, and sent to a language model hosted in the European Union to derive search criteria. The document is never written to persistent storage, never logged, and is discarded when the request ends.

6.2 Where you save the resulting search, Yellowdesk retains the derived search criteria and a derived profile: titles, seniority, skills, years of experience and languages. No name, no employer, no dates and no free text from the document is retained. It is deleted when you delete the saved search or when the Agreement ends.

6.3 The criteria are derived once, at the time you save the search. Reruns and alerts operate on the stored criteria. The document is not re-read because it no longer exists.

6.4 You must not upload special category data (Article 9 GDPR) or criminal offence data (Article 10 GDPR). The Service is not designed to process it and Annex III does not describe measures appropriate to it.

7. Sub-processors

7.1 General authorisation. You give Yellowdesk general authorisation to engage the sub-processors listed in Annex II.

7.2 Changes. Yellowdesk will give you at least 10 days' notice before a new sub-processor starts processing Customer Personal Data, by updating the list at yellowdesk.ai/subprocessors and by e-mail to your account administrator.

7.3 Objection. You may object on reasonable data protection grounds within that notice period. The parties will discuss it in good faith. If it cannot be resolved, you may terminate the affected part of the Service, or the Agreement, without penalty, and Yellowdesk will refund fees paid for the unused period.

7.4 Yellowdesk imposes data protection obligations on each sub-processor that are no less protective than those in this Part, and remains fully liable to you for a sub-processor's performance.

8. Data subject requests

8.1 Where a data subject contacts Yellowdesk with a request concerning Customer Personal Data, Yellowdesk will not respond on the substance, and will refer them to you, unless you have instructed otherwise.

8.2 Yellowdesk will tell you about such a request without undue delay and in any event within 5 working days.

8.3 Yellowdesk will assist you, by appropriate technical and organisational measures and so far as reasonably possible, in meeting your obligations under Articles 12 to 22 GDPR.

9. Assistance with your obligations

Yellowdesk will provide reasonable assistance with your obligations under Articles 32 to 36 GDPR, taking into account the nature of the processing and the information available to it. This includes security, breach notification, data protection impact assessments and prior consultation with a supervisory authority.

10. Personal data breach

10.1 Yellowdesk will notify you of a personal data breach affecting Customer Personal Data without undue delay and in any event within 48 hours of becoming aware of it.

10.2 The notification will describe, so far as known: the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, the measures taken or proposed, and a contact point. Where the full picture is not available, Yellowdesk will provide information in phases rather than delay the first notification.

10.3 Yellowdesk will cooperate with you and take reasonable steps to contain and remediate.

10.4 Yellowdesk will not notify a supervisory authority or a data subject on your behalf in respect of Customer Personal Data, unless required by law or agreed by you in writing.

11. Audit

11.1 Yellowdesk will make available the information reasonably necessary to demonstrate compliance with this Part, which will normally be satisfied by the current version of Annex III, this DPA, the published sub-processor list, and Yellowdesk's answers to a reasonable written security questionnaire.

11.2 Where that is not sufficient, you may audit, or appoint an independent auditor who is not a competitor of Yellowdesk and who signs a confidentiality undertaking, on 30 days' written notice, no more than once in any 12 month period, during business hours, without unreasonable disruption.

11.3 The once-a-year limit does not apply following a personal data breach affecting your data, or where a supervisory authority requires an audit.

11.4 You bear the cost of an audit, unless it identifies a material breach by Yellowdesk of this Part, in which case Yellowdesk bears its own costs of cooperating.

12. Deletion and return

12.1 On termination of the Agreement, Yellowdesk will, at your choice, delete or return Customer Personal Data, and delete existing copies, unless EU or Member State law requires it to be kept.

12.2 Unless you tell us otherwise, we delete. You must export anything you want to keep before termination. Where an account is suspended for non-payment, deletion follows the timetable in the Agreement: a warning, then anonymisation 90 days later.

12.3 What survives, and why. Invoices, the credit ledger and the audit log are retained for at least 6 years under Article 30 of the Spanish Commercial Code and applicable tax law. These are accounting and integrity records. The credit ledger and audit log are append-only by design and cannot be edited, which is what makes them trustworthy and also what makes them undeletable.

13. Transfers

Clause 20 and Annex IV apply.

# Part 2. Yellowdesk and you as independent controllers of Contact Data

*This Part applies to Contact Data. It is not an Article 28 contract, because neither party is the other's processor for it.*

14. What Yellowdesk warrants about the data it supplies

Yellowdesk warrants that, in respect of Contact Data made available through the Service:

14.1 Lawful basis. It processes Contact Data on the basis of legitimate interests under Article 6(1)(f) GDPR, supported by Article 19 LOPDGDD, and has carried out and documented a Legitimate Interests Assessment, a summary of which is available on request.

14.2 Sourcing. Contact Data is obtained from third-party business contact data vendors under contract, and relates only to a person's professional capacity. Yellowdesk does not process special category data in the contact database.

14.3 Provenance. Every stored record carries the vendor it came from, the identifier it had there, and the date it was retrieved, and that provenance is disclosed to any data subject who exercises their right of access.

14.4 Transparency. Yellowdesk publishes a privacy notice addressed to the people in the contact database, without a login, and takes the appropriate measures required by Article 14(5)(b) GDPR. Yellowdesk bears the Article 14 obligation in respect of its own processing.

14.5 Objection and erasure. Yellowdesk operates a public suppression mechanism requiring no account, verifies requests, and actions them across all customer accounts within 30 days.

14.6 Retention. Contact Details revealed to you are retained for 180 days from retrieval and are then redacted from every account, including yours. Yellowdesk operates no indefinite retention of revealed contact details.

14.7 No warranty of accuracy. Yellowdesk does not warrant that any Contact Detail is accurate, current or complete. It is supplied as obtained from the vendor, with the retrieval date, and the Agreement's disclaimers apply.

15. What you warrant about what you do with it

You warrant that, in respect of Contact Data you receive:

15.1 Lawful basis. You have your own lawful basis for processing it and for contacting the individual, and you have carried out any assessment your basis requires.

15.2 Transparency. You are responsible for your own Article 13 and 14 obligations towards those individuals, including telling them where you obtained their details if asked. You may identify Yellowdesk as the source.

15.3 Purpose. You will use it only for business-to-business outreach relating to recruitment or staffing services, and not for any other purpose.

15.4 Marketing and canvassing rules. You will comply with the ePrivacy rules and national law on unsolicited communications, including screening telephone numbers against the applicable national registers, and you will not send unsolicited bulk messages.

15.5 Rights requests. You will handle any request an individual makes to you directly, promptly and on your own account, and you will not require them to go to Yellowdesk instead.

15.6 No onward supply. You will not sell, sublicense, publish, redistribute or otherwise make Contact Data available to any third party, and you will not incorporate it into a product, database or list supplied to a third party. Access is limited to your Users.

15.7 Security. You will apply appropriate technical and organisational measures to Contact Data in your systems, and you will retain it no longer than your purpose requires.

15.8 Special categories. You will not enrich, combine or infer special category data about an individual from Contact Data.

16. Suppression propagation: the clause that makes the right real

16.1 Where an individual objects to Yellowdesk or asks to be suppressed, Yellowdesk purges their details from every account, including yours. The record in your account will show as expired or purged.

16.2 You must then delete that individual's details from your own systems, including any CRM, applicant tracking system, mailing list, spreadsheet or export, without undue delay and in any event within 30 days, and you must not contact them further on the basis of what Yellowdesk supplied.

16.3 Yellowdesk marks a suppressed record in the Service and stops returning it. The Service does not currently notify you when a record you have already exported is suppressed, so your obligation under 16.2 does not depend on being told: it applies from the point the individual objects, and you are expected to re-check the Service before contacting anyone from an export you did not take today. We are building a suppression feed so that this stops depending on you remembering.

16.4 No refund of Credits is due in respect of a suppressed contact.

17. Mutual assistance

Each party will provide the other with reasonable assistance and information needed to respond to a data subject request, a supervisory authority enquiry, or a claim, in respect of Contact Data. Each party will tell the other without undue delay of any complaint, request or regulatory contact that concerns the other's processing.

18. Liability and indemnity for Contact Data

18.1 Each party is separately responsible for its own compliance and separately liable for its own processing. Article 82 GDPR applies to each party in its own right.

18.2 Yellowdesk indemnifies you against claims, fines and reasonable costs arising directly from Yellowdesk's own breach of clauses 14.1 to 14.6, that is, from how the Contact Data was sourced, stored, disclosed or retained by Yellowdesk before it reached you.

18.3 The indemnity in 18.2 does not apply to the extent the claim arises from your use of the data after a reveal, from a breach of clause 15 or 16, from your failure to meet your own transparency obligations, or from your outreach.

18.4 You indemnify Yellowdesk against claims, fines and reasonable costs arising from your breach of clause 15 or 16.

18.5 The indemnity in 18.2 is subject to the liability cap in the Agreement.

# Part 3. General

19. Term

This DPA takes effect with the Agreement and continues while Yellowdesk processes personal data under it. Clauses that by their nature should survive, including 12, 14, 15, 16 and 18, survive termination.

20. International transfers

20.1 All primary storage and processing of Customer Personal Data and Contact Data takes place in the European Union. See Annex II.

20.2 Where a Restricted Transfer occurs, the SCCs are incorporated into this DPA and apply, completed as set out in Annex IV.

20.3 For a Restricted Transfer of Customer Personal Data, Module Two (controller to processor) applies, with you as data exporter and Yellowdesk or its sub-processor as data importer. For a Restricted Transfer of Contact Data between the parties, Module One (controller to controller) applies.

20.4 Yellowdesk carries out a transfer risk assessment for each Restricted Transfer and makes it available on request.

21. Changes to this DPA

Yellowdesk may update this DPA where required by a change in law, in the Service, or in its sub-processors, on 30 days' notice, provided the change does not materially reduce the protection given to personal data. Where a change does materially reduce it, your agreement is required.

22. Governing law

This DPA is governed by Spanish law and the jurisdiction clause in the Agreement applies, except where the SCCs require otherwise, in which case the SCCs govern the transfer they cover.

23. Contact

Data protection contact: privacy@taliro.net Security contact: security@taliro.net

# Annex I. Description of the processing

Part A. Customer Personal Data (Yellowdesk as processor)

Categories of data subject

• Your personnel: account administrators and Users
• Candidates whose CVs your Users upload to Candidate Match
• Individuals who appear in support correspondence

Categories of personal data

• Identity and contact: name, business e-mail address, role
• Account and preference: language, country, date and time format, account membership
• Authentication and security: password hash, session records including IP address and browser user agent, sign-in timestamps, token hashes
• Billing: company name, billing address, tax number, invoices, card brand, last four digits and expiry. No card number.
• Usage: features used, searches saved, reveals made, credits spent, product analytics events
• Candidate data: the text of an uploaded CV in memory only, never stored, and the derived search criteria and derived profile (titles, seniority, skills, years of experience, languages)

Special categories: none. Prohibited by clause 6.4.

Nature and purpose: providing, securing, supporting and billing the Service. Collection, storage, structuring, retrieval, use, transmission, erasure.

Frequency: continuous, for the term of the Agreement.

Duration: for the term, then as set out in clause 12.

Sub-processors: Annex II.

Part B. Contact Data (independent controllers)

Categories of data subject: business decision makers at companies that hire, principally in recruitment, human resources, talent acquisition and hiring management roles, and individuals named as the poster of a job advertisement.

Categories of personal data: name, job title, employer, business e-mail address, business telephone number, professional profile URL, and the retrieval date and source of each.

Special categories: none.

Nature and purpose: Yellowdesk sources, stores and supplies the data so that a customer can approach the individual's employer about recruitment or staffing services. The customer then processes it for business-to-business outreach.

Duration: 180 days from retrieval, in every account, then redaction. Indefinite retention of a one-way hash where an individual has opted out, for the purpose of continuing to honour that objection.

# Annex II. Sub-processors

Current at the date of this DPA. The authoritative and current version is published at yellowdesk.ai/subprocessors.

The application

The website

# Annex III. Technical and organisational measures

*Article 32 GDPR. This annex is the customer-facing statement of the measures. The internal information security policy sits behind it.*

1. Pseudonymisation and encryption

• In transit: TLS on all connections, including to the database, where the provider's certificate is verified against its own certificate authority rather than merely encrypting the connection.
• At rest: encryption provided by the managed database, object storage and backup services.
• Passwords are hashed with Argon2id at parameters meeting the current OWASP minimum. Plaintext passwords are never stored or logged.
• Session and link tokens are 32 bytes of cryptographically secure random data, stored only as a SHA-256 hash. A leaked backup yields no usable session.
• Suppression records are stored as one-way hashes of the identifier, not as the identifier.
• Contact details are never sent to a language model. The pipeline that identifies hiring companies sends job advertisement text only.

2. Confidentiality

• Named individual accounts. No shared credentials.
• Access on a least-privilege basis, granted for a role and recorded.
• Multi-factor authentication required on administrative accounts with third-party providers.
• Server-side authorisation on every request that reaches account-scoped data, with every query filtered by account. Edge middleware is explicitly not treated as the security boundary.
• Personnel are bound by confidentiality obligations and are briefed on data handling.
• Restricted data (contact details, CVs, credentials) is never logged, never pasted into third-party tools, and never copied to personal devices.

3. Integrity

• Credit movements and administrative actions are written to append-only ledgers enforced by database triggers. Entries cannot be edited or deleted, only added to.
• Credit operations use row-level locking so that two simultaneous actions on one balance resolve deterministically.
• Single-use tokens are consumed atomically, so a double-clicked link cannot take effect twice.
• All input is validated against a schema at the boundary, including everything returned by a third-party vendor or a language model.
• Row-level security is enabled on every application table, denying by default.
• Database changes are applied from version-controlled migrations as part of an automated build. There is no manual production schema change.

4. Availability and resilience

• Managed, replicated infrastructure from established European providers.
• Automated database backups taken by the managed provider under its standard policy for our plan. No restore has been exercised by us to date. A backup nobody has restored is a belief rather than a control, so we state it plainly rather than implying otherwise.
• The application layer is stateless and can be redeployed from source.
• Recovery point and recovery time objectives have not yet been formally set. We would rather say so than publish a number we have never tested against.

5. Testing and evaluation

• Automated test suite of over 2.300 tests, run in continuous integration before every merge, together with type checking, linting and translation completeness checks. A failing build does not ship.
• Protective tests are verified by reintroducing the defect they guard against and confirming the test fails, before the test is relied upon.
• No automated test makes a network call. External vendors are served from recorded fixtures, enforced by a test rather than by convention.
• Annual review of this annex and of the underlying policy.
• No external penetration test has been performed to date. Nothing above should be read as implying that one has.

6. Data minimisation and retention

• The surname of a person in the contacts list is never received by Yellowdesk before a reveal: the vendor returns it obfuscated. What is never received cannot leak.
• No standing database of unrevealed contacts is held. The list a customer browses is fetched live and discarded.
• Revealed contact details are redacted 180 days after retrieval by a nightly scheduled job, in every account.
• A suppressed individual is purged across all accounts, including accounts that paid.
• An uploaded CV is processed in memory and never written to persistent storage.
• A suspended account is anonymised 90 days after warning.

7. Incident response

• Documented incident response process with severity levels and defined response times.
• Breach notification to the customer within 48 hours of awareness.
• Notification to the supervisory authority within 72 hours where required.
• A breach register is maintained, recording every incident whether or not it was notifiable.
• Written post-mortem for every serious incident.

8. Supplier management

• No supplier receives personal data before a data processing agreement is in place and the transfer mechanism is confirmed.
• EU processing is a selection criterion, not a preference.
• The public sub-processor list is kept current and customers are notified of changes in advance.

9. Payment data

Card data is captured directly by Stripe in the customer's browser and never reaches Yellowdesk's systems. Yellowdesk stores only the card brand, last four digits and expiry, returned by Stripe for display. PCI DSS scope is therefore Stripe's.

# Annex IV. International transfers

Default position: no Restricted Transfer occurs. All primary storage and processing takes place in the European Union.

Where a sub-processor established outside the EEA has access to personal data in the course of support or administration, the following applies.

Transfer risk assessments. These are being documented for each transfer named in Annex II. Until that is complete, clause 20.4 should be read as a commitment to produce them rather than as a statement that they are already on file.

United Kingdom. Where a transfer is subject to UK data protection law, the UK International Data Transfer Addendum to the SCCs applies.

Language

This document is published in English, German, French, Dutch and Spanish. The translations are provided for convenience. Where a translation and the English version differ, the English version governs.