merkleset
yasal belgeler

sürüm: 2026-08-12yürürlük: 2026-08-12bilgilendirme amaçlı

Bu belge yalnızca İngilizce yayımlanır. Esas alınacak metin İngilizce olanıdır: kabul, İngilizce kaynağın SHA-256 değerine karşılık kaydedilir; dolayısıyla bir çeviri, onay verdiğiniz metin olamaz.

Data Processing Agreement

Version 2026-08-12. Effective 2026-08-12.

This agreement is available for signature on request. Write to legal@merkleset.com with your entity details and we will return a counter-signed copy. It is published here so your legal and procurement teams can read it before asking.

0. Read this first — the honest structural point

Most vendor DPAs exist because the vendor processes personal data on the customer's instructions. That is largely not what happens here, and pretending otherwise would produce a document that misdescribes the service.

  1. For your account data we are a controller, not your processor. Your email address, login history, consent records and entitlements are processed for our own purposes — to run the account, prove what you accepted, and decide what you may download. We decide those purposes, so we are the controller and the Privacy Policy is the operative document, not this one. Article 28 does not apply to that processing.
  2. The datasets we sell are not intended to contain personal data. They are built from US federal government sources and screened in the pipeline before any published hash is computed. You are not sending us your customers' data to process, and we are not sending you personal data to process on your behalf. The screening scope, including its documented gaps, is in clause 7 of the Data License Agreement.
  3. For billing, Stripe acts as merchant of record in its own right. It invoices you, collects and remits taxes and handles disputes, determining its own purposes for that relationship. We are not its controller and it is not our processor for that layer. This agreement does not cover it; Stripe's own terms and privacy notice do.

So the subject matter of a classic controller-to-processor DPA is narrow here. It is not empty — clause 2 sets out the cases where we genuinely could process personal data for you — and the Article 28 obligations below apply in full to those cases. We would rather sign a short, true DPA than a long, wrong one.

1. Parties, definitions and precedence

1.1 This agreement is between:

  • Processor / Controller (as applicable): Andrii Sukhanov, a natural person trading as an independent professional (autónomo) registered in Spain, NIE Z2338955K, using merkleset as a trading name, of Av. Marítima 2, puerta 05c, {{POSTAL_CODE}} Los Silos, Santa Cruz de Tenerife, Spain ("we", "us"); and
  • Controller: the customer identified in Annex I ("you").

1.2 "GDPR" means Regulation (EU) 2016/679. "Personal data", "processing", "controller", "processor", "personal data breach", "data subject" and "supervisory authority" have the meanings given in Article 4 GDPR. "Customer Personal Data" means personal data you provide to us, or that we access on your behalf, for us to process under clause 2.

1.3 This agreement forms part of the Terms of Service. If it conflicts with the Terms of Service about the processing of Customer Personal Data, this agreement controls. If it conflicts with the Standard Contractual Clauses where those apply, the Clauses control.

1.4 English is the authoritative language. Governing law and venue are those in clause 15 of the Terms of Service: the laws of the Kingdom of Spain and the exclusive jurisdiction of the courts of Santa Cruz de Tenerife (Canary Islands, Spain).

2. Scope — when we act as your processor

2.1 We act as your processor only in these cases:

  1. Support material you send us. If, in a support request, you send us a file, a log, a sample of your own corpus or a screenshot that contains personal data, we process it to answer that request.
  2. Remote assistance. If you ask us to look at your configuration or your integration and that exposes personal data in your systems, we process it for the duration of that assistance.
  3. Any processing described in an Annex I we have both signed for a specific engagement, for example a custom connector built against a source you nominate.

2.2 In every other respect — your account, your entitlements, your consent records, our server logs and the datasets themselves — we act as a controller and the Privacy Policy applies.

2.3 We ask you not to send us personal data in support requests unless it is genuinely necessary. Redact it where you can. The cheapest processing to secure is the processing that never happens.

2.4 You are responsible for having a lawful basis for any Customer Personal Data you send us, and for the accuracy and lawfulness of the instructions you give.

3. Our obligations under Article 28(3)

For Customer Personal Data we process under clause 2, we will:

3.1 Process only on your instructions (Article 28(3)(a)) — the purpose in clause 2 and any written instruction you give under it. If we believe an instruction breaches data protection law we will tell you and may pause that processing.

3.2 Not process it for our own purposes. We do not use Customer Personal Data to train models, build datasets, or improve the service.

3.3 Keep it confidential (Article 28(3)(b)) — see clause 4.

3.4 Apply the security measures in Annex III (Article 28(3)(c) and Article 32).

3.5 Engage subprocessors only as clause 5 allows (Article 28(3)(d)).

3.6 Help you answer data subject requests (Article 28(3)(e)) — see clause 6.

3.7 Help you with your Article 32 to 36 obligations (Article 28(3)(f)) — security, breach notification, impact assessments and any prior consultation — by giving you the information we hold.

3.8 Delete or return the data at the end of the engagement (Article 28(3)(g)) — see clause 9.

3.9 Make available the information needed to show compliance, and allow audits (Article 28(3)(h)) — see clause 10.

3.10 Tell you without undue delay if we receive a legally binding request from an authority for Customer Personal Data, unless the law prohibits us from telling you. We will challenge a request that appears unlawful or overbroad.

4. Confidentiality

4.1 We treat Customer Personal Data as your confidential information and will not disclose it except as this agreement allows.

4.2 Access is restricted to people who need it to perform the processing. Today that means the individual who is merkleset. There are no employees, so there is no internal onward disclosure to control; if that changes, everyone with access will be bound by written confidentiality obligations that survive the end of their engagement.

5. Subprocessors

5.1 You give a general authorisation for us to use the subprocessors listed in the Subprocessor annex published alongside this agreement, which is incorporated here as Annex II.

5.2 Each subprocessor is engaged under a written contract imposing data protection obligations no less protective than this agreement, and we remain liable to you for their performance.

5.3 Change notice. We will publish any addition or replacement of a subprocessor in the Subprocessor annex, and give you at least 30 days' notice by email before the new subprocessor starts processing Customer Personal Data. If you reasonably object on data protection grounds within that period, we will work with you to find a solution; if we cannot, you may terminate the affected part of the service without penalty and receive a refund of the unused part of any prepaid fee.

5.4 We do not use subprocessors located outside the European Economic Area for support material under clause 2 beyond those in Annex II.

6. Data subject requests

6.1 If a data subject contacts us about Customer Personal Data, we will not respond substantively. We will refer them to you and tell you promptly.

6.2 We will help you respond, by providing the information and taking the technical steps we reasonably can within the scope of clause 2, at no charge for a reasonable volume of requests.

6.3 For personal data in datasets we sell — a different question — the route is in section 5 of the Copyright, Takedown and Complaints Policy, and we act on it as controller.

7. Personal data breach

7.1 We will notify you without undue delay, and in any case within 48 hours of becoming aware of a personal data breach affecting Customer Personal Data.

7.2 The notice will describe the nature of the breach, the categories and approximate number of data subjects and records affected so far as known, the likely consequences, the measures taken or proposed, and a contact point. Where we cannot provide all of it at once, we will provide it in stages without further undue delay.

7.3 We will not make a public statement identifying you without your consent unless the law requires it.

7.4 What limits our detection today. There is no automated monitoring or alerting on the service. Detection depends on our own inspection and on reports we receive. Our notification clock runs from becoming aware, so we are telling you honestly what "becoming aware" depends on rather than implying continuous detection we do not have.

8. Transfers

8.1 We are established in Spain. Processing under clause 2 takes place in the European Economic Area except to the extent our infrastructure and email providers operate elsewhere, as recorded in Annex II.

8.2 Where a transfer to a third country occurs, we rely on the provider's own data processing agreement together with the European Commission's Standard Contractual Clauses, module three (processor to processor) or module two (controller to processor) as applicable, and on a transfer impact assessment. The instrument in force for each provider is recorded in Annex II as {{TRANSFER_MECHANISM}} until confirmed and published.

8.3 If a transfer instrument we rely on is invalidated, we will work with you in good faith to put an alternative in place, and will suspend the affected transfer if no lawful alternative exists.

9. Deletion and return

9.1 We delete Customer Personal Data processed under clause 2 when the support request or engagement it relates to is closed, and in any case within 90 days, unless you ask for it earlier or the law requires us to keep it.

9.2 On your written request, we will return the data in a commonly used format, or confirm its deletion in writing.

9.3 This clause does not apply to your account data, your consent records or our billing records, which we hold as controller under the retention periods in section 5 of the Privacy Policy.

10. Audit

10.1 We will answer your reasonable written questions about the processing under clause 2, and provide the information in Annex III, once in any 12-month period and in addition after a personal data breach.

10.2 An on-site audit is available where a supervisory authority requires one or after a personal data breach affecting your data, at your cost, on 30 days' notice, during business hours, subject to confidentiality, and without access to other customers' data.

10.3 We hold no third-party security certification (no ISO 27001, no SOC 2). We will not imply otherwise, and clause 10.1 is the substitute we can actually deliver.

11. Liability

11.1 The liability limits in clause 10 of the Terms of Service apply to this agreement.

11.2 Nothing in this agreement limits either party's liability to a data subject or a supervisory authority under the GDPR.

12. Term

12.1 This agreement runs for as long as we may process Customer Personal Data under clause 2, and its confidentiality, deletion and audit obligations survive until performed.


Annex I — Parties and processing description

Data exporter (controller): the customer.

FieldValue
Legal name{{CUSTOMER_LEGAL_NAME}}
Address{{CUSTOMER_ADDRESS}}
Contact for data protection{{CUSTOMER_DP_CONTACT}}
RoleController

Data importer (processor): us.

FieldValue
NameAndrii Sukhanov, trading as merkleset
StatusNatural person, independent professional (autónomo) registered in Spain
Tax identificationNIE Z2338955K
AddressAv. Marítima 2, puerta 05c, {{POSTAL_CODE}} Los Silos, Santa Cruz de Tenerife, Spain
Contact for data protectionprivacy@merkleset.com
Data Protection OfficerNone designated; none required at this scale of processing
RoleProcessor for the processing in clause 2

Description of the processing.

ItemDetail
Subject matterSupport and assistance requests you send us, and any engagement described in a signed Annex I
DurationThe life of the support request or engagement, plus the deletion period in clause 9
Nature and purposeReading, reproducing and storing the material you sent, in order to diagnose a problem or answer a question; deletion afterwards
Categories of data subjectsWhoever appears in the material you choose to send. Typically your own staff
Categories of personal dataWhatever the material contains. Typically names, work email addresses and identifiers inside logs or sample records
Special category dataNot permitted. Do not send it. If you do, tell us immediately so we can delete it
FrequencyOccasional and event-driven, not continuous or systematic
RetentionDeleted on closure of the request, at the latest within 90 days
TransfersOnly through the providers in Annex II

Annex II — Subprocessors

The current list, with role, data categories, location and transfer mechanism, is the Subprocessor annex published alongside this agreement at the same effective date, and is incorporated here by reference. At this version it is: DigitalOcean, LLC (infrastructure hosting), Stripe (payments — acting as merchant of record in its own right, not as our processor), and Mailgun (Sinch) in its EU region (transactional email).

Change notice is governed by clause 5.3.

Annex III — Technical and organisational measures

These are the measures actually in place. Where something is not in place, it says so.

Access control and authentication

  1. Passwordless authentication: a one-time code emailed to the account address. No passwords exist, so none can be leaked or reused.
  2. One-time codes and refresh tokens are stored only as SHA-256 hashes and compared in constant time.
  3. Access tokens live 15 minutes; refresh tokens rotate on every use, and presenting an already-rotated token revokes the whole session family as suspected theft.
  4. Rate limits on the authentication endpoints (per email address) and on the public API (per client address).

Network and system security

  1. Only two services are exposed to the internet: the website and the public API. Authentication, the catalogue, the databases, the message broker and object storage publish no public port and are reachable only on an internal network.
  2. TLS on all public connections, with automated certificate renewal.
  3. Internal service-to-service calls are authenticated with a shared internal token compared in constant time.
  4. Object storage is exposed publicly only as a read-only path, and only so that time-limited signed download URLs can be opened by a browser.

Data minimisation and logging

  1. Application logs record method, path, status and duration only — never request bodies, query strings or headers.
  2. Consent records deliberately hold no IP address and no user agent.
  3. Card data never reaches our systems.
  4. In the ingestion pipeline, personal data is screened out before any published hash is computed, and where a source has a column boundary the contact fields are never read at all.

Segregation and integrity

  1. Buyer-facing release artifacts and unscreened internal raw evidence are stored in separate buckets with different lifecycles, precisely so the evidence tier stays deletable and is never delivered.
  2. Every release carries a Merkle root over the hashes of its data lines plus per-file hashes and byte counts, so tampering with delivered data is detectable by the recipient.
  3. Release artifacts are written atomically: a failed run leaves no partial artifact.

Organisational

  1. One person operates the service; access is inherently limited to that person.
  2. Documented internal collection rules: logged-out collection only, no accounts on source sites, robots.txt and text-and-data-mining reservations honoured, hard stop on a cease-and-desist.
  3. A published takedown and complaints procedure with named routes.

Not in place — stated rather than implied

  1. No automated backup of databases or release artifacts. A host loss would lose them.
  2. No monitoring or alerting, so incident detection depends on inspection and reports.
  3. Single-host deployment: no redundancy, no failover, no disaster recovery plan, and therefore no recovery time or recovery point objective.
  4. No third-party security certification (no ISO 27001, no SOC 2) and no penetration test.
  5. Evidence retention is configured at 90 days but not automatically enforced; expiry is manual today.
  6. Cryptographic signing of release manifests is planned but not implemented; integrity today rests on the published hashes and Merkle root.

If any of items 19 to 24 is a blocker for your procurement, tell us at legal@merkleset.com before you buy rather than after.

sha256 d1da12c2cc69…c084748ed7b7