Data Processing Agreement

Last updated: [effective date]

This Data Processing Agreement ("DPA") forms part of the Terms of Service or other written agreement (the "Agreement") between:

• Red Code Company, s.r.o., IČO 22385151, registered seat Děčínská 552/1, Střížkov, 180 00 Prague 8, Czech Republic ("Processor", "we", operating the service "daat.red"); and
• the customer identified in the Agreement ("Controller", "Client", "you"),

each a "party" and together the "parties".

This DPA reflects the parties' agreement on the processing of personal data in connection with the daat.red service (the "Service") and is entered into pursuant to Article 28(3) of Regulation (EU) 2016/679 ("GDPR").

1. Scope and roles

1.1 This DPA applies where, and to the extent that, the Processor processes Client Personal Data on behalf of the Controller in the course of providing the Service.

1.2 Client Personal Data means personal data contained in data that the Controller or its authorised users submit to the API, and in the Results derived from it, as further described in Annex I.

1.3 In respect of Client Personal Data, the Controller is the controller (or itself a processor acting on behalf of a third-party controller) and the Processor is a processor. Where the Controller is itself a processor, it warrants that it is authorised by the relevant controller to engage the Processor as a sub-processor on these terms, and that its instructions to the Processor reflect that controller's instructions.

1.4 This DPA does not apply to personal data for which the Processor is itself a controller, including data relating to account registration, authentication, billing, support and security of the Service. That data is processed in accordance with the Processor's Privacy Policy.

1.5 In the event of a conflict between this DPA and the rest of the Agreement, this DPA prevails on matters relating to the processing of Client Personal Data.

2. Processing instructions

2.1 The Processor shall process Client Personal Data only on documented instructions from the Controller, including with regard to transfers, unless required to do so by Union or member-state law to which the Processor is subject; in such a case, the Processor shall inform the Controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.

2.2 The Controller's documented instructions are constituted by: (a) this DPA and the Agreement; (b) the configuration options selected by the Controller in the operator console; and (c) each API call the Controller or its authorised users make, which instructs the Processor to perform the requested check on the submitted data. Additional or alternative instructions must be agreed in writing and may be subject to adjustment of fees or feasibility.

2.3 The Processor shall immediately inform the Controller if, in its opinion, an instruction infringes the GDPR or other applicable data-protection provisions. The Processor is not obliged to carry out a legal review of the Controller's instructions or of the lawfulness of the Controller's processing.

2.4 The Controller warrants that: (a) it has a valid legal basis for the processing and for disclosing Client Personal Data to the Processor; (b) it has provided all required information to data subjects and obtained any required consent; (c) its instructions comply with applicable law; and (d) it will not submit special categories of personal data (Article 9 GDPR) or personal data relating to criminal convictions and offences (Article 10 GDPR) through the API, except to the extent inherent in the ordinary data elements described in Annex I.

3. Nature, purpose and duration

3.1 Subject-matter: the provision of the Service, namely pre-authorization payment-data and identity-verification checks requested by the Controller.

3.2 Nature and purpose of processing: receiving API requests; performing the requested check (including, for the Card check method, forwarding a verification request to the relevant card network / payment system under the Processor's direct contractual relationships with those networks); deriving and returning the Result; metering usage; and retaining request metadata and Results as described in Annex I.

3.3 Duration: for the term of the Agreement, plus any period during which the Processor retains Client Personal Data as permitted or required under section 11 and Annex I.

3.4 The types of personal data and categories of data subjects are set out in Annex I.

4. Confidentiality of personnel

4.1 The Processor shall ensure that persons authorised to process Client Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality, and that access is limited to personnel who need it to provide the Service.

4.2 The Processor shall ensure that such persons are appropriately trained and are aware of their obligations.

5. Security of processing

5.1 The Processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing, as well as the risks to data subjects. These measures are described in Annex II.

5.2 The measures include, in particular: processing and hosting exclusively within the European Union on Hetzner infrastructure; not storing full card numbers, card expiry data or card security codes; encryption of personal data in transit; network segmentation; access control on a least-privilege basis with individual accounts and two-factor authentication for administrative access; logging and audit trails; and procedures for detecting and responding to personal data breaches.

5.3 The Processor may update the measures from time to time provided that the updates do not materially reduce the overall level of protection.

6. Sub-processing

6.1 The Controller grants the Processor a general authorisation to engage sub-processors to process Client Personal Data, subject to this section.

6.2 The Processor shall impose on each sub-processor, by way of a written contract, data-protection obligations that are no less protective than those in this DPA, in particular regarding sufficient guarantees to implement appropriate technical and organisational measures. The Processor remains fully liable to the Controller for the performance of each sub-processor's obligations.

6.3 A current list of approved sub-processors is maintained at daat.red/sub-processors and is referenced in Annex III.

6.4 The Processor shall give the Controller prior notice of the addition or replacement of a sub-processor, at least [sub-processor change notice period — suggested 30 days] before the change takes effect, by [notification mechanism — e.g. email to the Account's notification address and/or an update to the sub-processors page with subscription option].

6.5 The Controller may object to a new sub-processor on reasonable data-protection grounds by notifying the Processor in writing within the notice period. The parties shall discuss the objection in good faith. If the Processor is unable to accommodate the objection, the Controller may, as its sole remedy, terminate the affected part of the Service by written notice, and the Processor will refund any prepaid, unused fees for the terminated portion. [confirm refund position on termination for sub-processor objection, consistent with the Terms.]

6.6 The card networks / payment systems to which Card check requests are forwarded are engaged in reliance on the Processor's own direct contractual relationships with those networks and are treated as sub-processors and/or independent recipients as their role requires; they are listed at daat.red/sub-processors.

7. Assistance to the Controller

7.1 Data-subject requests. Taking into account the nature of the processing, the Processor shall assist the Controller by appropriate technical and organisational measures, insofar as possible, in fulfilling the Controller's obligation to respond to requests to exercise data-subject rights under Chapter III GDPR. If the Processor receives such a request directly from a data subject, it shall not respond to it substantively (except to acknowledge and redirect) and shall, without undue delay, forward it to the Controller.

7.2 Other assistance. The Processor shall assist the Controller in ensuring compliance with its obligations under Articles 32 to 36 GDPR (security, breach notification and communication, data protection impact assessments, and prior consultation), taking into account the nature of processing and the information available to the Processor.

7.3 Costs. Assistance that goes beyond the standard functionality of the Service, or that is required as a result of a change in law or the Controller's circumstances, may be provided against reimbursement of the Processor's reasonable costs, notified in advance.

8. Personal data breach

8.1 The Processor shall notify the Controller without undue delay, and in any event within 72 hours, after becoming aware of a personal data breach affecting Client Personal Data. [confirm 72-hour commitment and any shorter contractual target.]

8.2 The notification shall include, to the extent known and as it becomes available: a description of the nature of the breach including, where possible, the categories and approximate number of data subjects and records concerned; the likely consequences; the measures taken or proposed to address the breach and mitigate its effects; and a contact point for further information.

8.3 The Processor shall take reasonable steps to contain and remediate the breach and shall cooperate with the Controller. The Processor's notification is not an acknowledgement of fault or liability.

8.4 The Controller is responsible for any notification to supervisory authorities and to affected data subjects.

9. Audit

9.1 The Processor shall make available to the Controller all information necessary to demonstrate compliance with the obligations laid down in Article 28 GDPR and this DPA, and shall allow for and contribute to audits, including inspections, conducted by the Controller or an auditor mandated by the Controller.

9.2 Audits are subject to the following: (a) no more than once per 12 months, except where required by a supervisory authority or following a personal data breach affecting the Controller's data; (b) at least 30 days' prior written notice, save in an emergency; (c) conducted during business hours, in a manner that does not disrupt the Processor's operations, and subject to the Processor's security and confidentiality requirements; (d) the auditor must not be a competitor of the Processor and must sign a confidentiality undertaking; (e) the Controller bears its own costs and the Processor's reasonable costs of supporting the audit.

9.3 The Processor may satisfy an audit request by providing relevant third-party certifications, attestations or audit reports (where available) and responding to reasonable written questions, before an on-site inspection is undertaken.

10. International transfers

10.1 The Processor shall not transfer Client Personal Data to a country outside the EU/EEA in the course of processing it under this DPA, and processing shall take place exclusively within the European Union, unless the Controller instructs otherwise in writing or the transfer is required by Union or member-state law (in which case section 2.1 applies).

10.2 The parties acknowledge that a transfer of data outside the EEA may nevertheless arise where a card network or payment system inherently involved in the Controller's own transaction is located outside the EEA. Such a transfer results from the Controller's transaction and its verification requirements. Where it occurs, the parties shall rely on an adequacy decision, on appropriate safeguards under Article 46 GDPR (in particular the Standard Contractual Clauses), or on a derogation under Article 49 GDPR where applicable. The Processor shall, on request, provide available information about the safeguards in place with the relevant network. [confirm the transfer mechanism(s) applicable to the card networks and whether the Processor or the Controller is the data exporter for such transfers — obtain qualified legal review.]

10.3 If the Processor is required to introduce a transfer outside the EEA for its own provision of the Service in future, it shall give the Controller prior notice and shall put in place a valid transfer mechanism under Chapter V GDPR before any such transfer.

11. Return and deletion

11.1 On termination or expiry of the Agreement, the Processor shall, at the choice of the Controller, delete or return all Client Personal Data, and delete existing copies, unless Union or member-state law requires storage of the data.

11.2 The Processor shall in any event delete or anonymise Client Personal Data in accordance with the retention approach set out in Annex I and section 7 of the Privacy Policy: full card numbers, expiry data and security codes are never stored; request metadata and Results are retained for the minimum period required by applicable law and then deleted.

11.3 On request, the Processor shall certify in writing that it has complied with this section.

12. Liability

12.1 Each party's liability arising out of or in connection with this DPA is subject to the exclusions and limitations of liability set out in the Agreement. This DPA does not increase a party's aggregate liability beyond the cap agreed in the Agreement, except to the extent such a cap is not permitted by the GDPR or applicable law.

12.2 Nothing in this DPA or the Agreement limits a data subject's rights under the GDPR or a party's liability towards data subjects or supervisory authorities.

12.3 As between the parties, the Controller shall be responsible for losses, fines and claims to the extent they arise from the Controller's instructions, the absence of a lawful basis or required notice or consent, the Controller's breach of this DPA, or Client Data that is unlawful or inaccurate.

13. General

13.1 This DPA is governed by the laws of the Czech Republic, and the courts of the Czech Republic have exclusive jurisdiction, consistent with the Agreement.

13.2 If any provision of this DPA is invalid or unenforceable, the remainder is unaffected and the parties shall replace the invalid provision with a valid one that best reflects its purpose.

13.3 The Processor may amend this DPA on notice where required to comply with applicable law, guidance from a supervisory authority, or a court decision, or to reflect a change of sub-processor made in accordance with section 6.

Annex I — Details of processing

A. Categories of data subjects

• The Controller's customers and end-users (for example cardholders, applicants, account holders, payers) whose data the Controller submits to the API in order to screen a transaction or account.
• [any other categories the Controller submits, e.g. authorised representatives, beneficiaries.]

B. Types of personal data

• Cardholder name (submitted for the Card check method).
• Card number (PAN) — transmitted for the Card check and Card info methods; used only to perform the single requested lookup (including forwarding to the relevant card network for Card check) and then discarded. Not stored.
• Card expiry date and card security code — where transmitted, used only for the single lookup and not stored.
• Card BIN (leading 6–8 digits) — for BIN lookup and as retained metadata for card methods.
• Email address (for Email info and Email check).
• Public profile / name data associated with an email address and a match flag (Email info output).
• IP address (IPv4 or IPv6) and derived network/ASN and approximate geolocation data (for IP info).
• Request metadata and Results: the method called, timestamp, request status, credit cost, the non-card inputs described above, and the verification outputs (for example name-match indicator and check code, deliverability result and response code, reference data).

C. Nature and purpose of processing

Performing the pre-authorization checks that the Controller requests through the API, returning the Results, metering usage, and retaining request metadata and Results as described below.

D. Duration and retention

• Full card number, card expiry data, card security code: not retained; discarded immediately after the single lookup.
• Request metadata and Results (non-card): retained for the minimum period required by applicable law, then deleted. [confirm concrete retention periods per data category.]
• Processing continues for the term of the Agreement and the retention periods above.

E. Frequency of processing

Continuous / on-demand, each time the Controller or its authorised users call the API.

Annex II — Technical and organisational measures

The Processor implements and maintains at least the following measures:

1. Location and hosting

• Processing and hosting exclusively within the European Union, on Hetzner infrastructure.

2. Data minimisation and card data handling

• No storage of full card numbers, card expiry data or card security codes. Such data is used only for the single requested lookup and then discarded.
• Retained metadata is limited to non-card data elements and Results.

3. Encryption and transmission

• Encryption in transit using current transport-layer security for all API and console traffic.
• [confirm encryption at rest for stored metadata / databases / backups.]

4. Network security

• Network segmentation and minimised external exposure of processing systems.
• Firewalling and restriction of administrative interfaces.
• Rate limiting (default 20 requests/second per API key) and abuse detection.

5. Access control and identity

• Access on a least-privilege, need-to-know basis, with individual named accounts.
• Two-factor authentication (TOTP) for the operator console.
• API-key authentication with optional per-key source-IP allow-lists and key rotation.
• Role-based permissions and periodic access review. [confirm access-review cadence.]

6. Logging and monitoring

• Audit logging of administrative and security-relevant events.
• Operational monitoring of availability, latency and error rates.
• [confirm log retention period and protection against tampering.]

7. Resilience and continuity

• [backup approach, backup encryption, restoration testing.]
• [business continuity / disaster recovery arrangements and RPO/RTO.]

8. Organisational measures

• Confidentiality undertakings for all personnel with access to Client Personal Data.
• Security awareness training.
• Vendor/sub-processor due diligence and contractual flow-down of data-protection obligations.
• Personal data breach detection, escalation and notification procedures.
• [secure software development practices, change management, vulnerability management and penetration testing cadence.]

9. Deletion

• Procedures to delete or anonymise Client Personal Data at the end of the applicable retention period and on termination in accordance with the Controller's choice.

Annex III — Approved sub-processors

The current list of approved sub-processors for the Service is published and maintained at:

daat.red/sub-processors

That list identifies, for each sub-processor, its name, the processing activity/purpose, and the location of processing. As at the date of this DPA it includes at least:

Changes to this list are notified in accordance with section 6.