Data Processing Agreement

between

(1) the account holder identified in the Steerd account and in the order confirmation (the "Controller" or "Customer"), and

(2) Unbogify GmbH, Zelterstr. 10, 10439 Berlin, Germany, registered at Amtsgericht Berlin-Charlottenburg under HRB 243027 B (the "Processor", "we", "us"), operating the service under the name Steerd,

each a "Party" and together the "Parties".

Preamble

The Parties have concluded a contract for the use of Steerd (the "Main Agreement", being the terms and conditions at steerd.io/terms and steerd.io/de/agb in the version the Customer accepted). In performing the Main Agreement the Processor processes personal data on behalf of the Customer. This agreement (the "DPA") sets out the terms required by Art. 28(3) GDPR and forms an integral part of the Main Agreement.

Where this DPA and the Main Agreement conflict on the processing of personal data, this DPA prevails.

1. Subject matter, duration, nature, purpose, data and data subjects

The subject matter, duration, nature and purpose of the processing, the types of personal data and the categories of data subjects are described in Annex 1, which forms part of this DPA.

The processing lasts for as long as the Main Agreement is in force, plus the periods in section 9.

2. Instructions (Art. 28(3)(a))

2.1 The Processor processes personal data only on the documented instructions of the Customer, including as regards transfers to a third country, unless required to do otherwise by Union or Member State law to which the Processor is subject; in that case the Processor informs the Customer of that legal requirement before processing, unless that law prohibits it on important grounds of public interest.

2.2 The Customer's use of Steerd is its instruction. The functions the Customer uses, the data it enters, imports or uploads, and the recipients it designates within the service constitute documented instructions for the purposes of Art. 28(3)(a). This DPA, the Main Agreement and the product documentation are the initial complete instruction.

2.3 Instructions beyond the use of the service require text form. The Processor may charge the reasonable cost of implementing an individual instruction that goes beyond the functions of the service, after telling the Customer the expected cost and obtaining its agreement.

2.4 The Processor informs the Customer without undue delay if, in its opinion, an instruction infringes the GDPR or other Union or Member State data protection provisions (Art. 28(3), second subparagraph). The Processor may suspend performance of that instruction until the Customer confirms it in text form.

2.5 The Processor does not use personal data processed under this DPA for its own purposes. In particular it does not sell that data, does not analyse it for its own commercial purposes, and does not use it to train artificial intelligence models, whether its own or a third party's.

3. Confidentiality (Art. 28(3)(b))

3.1 The Processor ensures that persons authorised to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality, and that the commitment survives the end of their engagement.

3.2 The Processor grants access to personal data processed under this DPA only to those persons who need it to perform the Main Agreement, and it maintains a record of who those persons are.

4. Security of processing (Art. 28(3)(c), Art. 32)

4.1 The Processor implements the technical and organisational measures set out in Annex 2, which forms part of this DPA and satisfies Art. 32.

4.2 The measures reflect the state of the art, the costs of implementation, and the nature, scope, context and purposes of the processing as well as the risk to data subjects, at the time of conclusion. The Processor reviews them at least annually and may change an individual measure provided the level of protection is not reduced. The Processor keeps a current version of Annex 2 available to the Customer.

4.3 Annex 2 states its known gaps rather than omitting them. The Customer acknowledges that it has been given the opportunity to review Annex 2, including that section, before concluding this DPA, and that the measures described there are appropriate for the processing it instructs.

5. Subprocessors (Art. 28(2) and 28(4))

5.1 The Customer grants the Processor general written authorisation to engage subprocessors. The subprocessors engaged at the date of this DPA are listed in Annex 3, and the Customer authorises each of them.

5.2 The Processor informs the Customer of any intended addition or replacement of a subprocessor at least 30 days in advance, stating the provider, the purpose, the location of processing, the intended start date and how to object. The notice is given to the addresses in section 11.4, and the 30-day period runs as section 11.4 provides.

5.3 The Customer may object within that period on reasonable grounds relating to data protection, in text form, to the Processor at legal@nightlybuildgroup.com or to any address the Processor has given for that purpose in the notice. If the Parties cannot agree on a solution within a further 30 days, the Customer may terminate the Main Agreement and this DPA with effect from the date the subprocessor is to start processing, and the Processor refunds the fee for the unused part of any period already paid for on a pro rata basis. The Processor does not offer a right to prevent the change while the Customer continues to use the service; for a service of this size that would be a promise it could not keep.

5.4 The Processor imposes on each subprocessor, by way of a contract, data protection obligations at least equivalent to those in this DPA, in particular sufficient guarantees under Art. 28(1). Where a subprocessor fails to fulfil those obligations, the Processor remains fully liable to the Customer for the performance of that subprocessor's obligations (Art. 28(4)).

5.5 Providers that process personal data for which the Processor is itself the controller, in particular the payment, website analytics and bot-protection providers of the Processor's own business relationship with the Customer, are not subprocessors under this DPA and are not listed in Annex 3. They are named in the Processor's privacy notice.

6. Transfers to third countries (Chapter V)

6.1 The processing takes place within the European Union. The Processor transfers personal data to a country outside the European Economic Area, or to an international organisation, only where a recipient listed in Annex 3 is identified there and only on the transfer basis stated for that recipient in Annex 3.

6.2 The transfer basis is stated per recipient in Annex 3 and is either an adequacy decision, the recipient's current certification under an applicable adequacy framework, or the standard contractual clauses adopted by the European Commission. The Processor does not rely on a basis stated generically.

6.3 On request the Processor provides the Customer with a copy of the relevant transfer instrument and with the transfer impact assessment it has carried out for that recipient, redacted only as necessary to protect the confidentiality of third parties.

6.4 The Processor informs the Customer without undue delay if a transfer basis it relies on ceases to be valid, and either establishes an alternative basis or ends the transfer.

6.5 The Processor publishes and keeps current, on steerd.io, the countries in which the infrastructure on which Steerd runs is located, the subprocessors it uses, and the measures it has taken against unlawful access by authorities of third countries.

7. Assistance with data subject rights (Art. 28(3)(e))

7.1 Taking into account the nature of the processing, the Processor assists the Customer by appropriate technical and organisational measures, insofar as this is possible, in fulfilling the Customer's obligation to respond to requests under Arts. 15 to 22 GDPR.

7.2 The Processor provides functions in the service by which the Customer can satisfy the most common requests itself, without involving the Processor. Those functions are described in Annex 1.

7.3 Where a data subject addresses a request under Arts. 15 to 22 to the Processor, the Processor does not answer it on its own behalf. It forwards the request to the Customer without undue delay and refers the data subject to the Customer.

7.4 Assistance under this section is provided at no charge, except where a request is manifestly unfounded or excessive, in particular because of its repetitive character, or where it requires the Processor to develop functionality that does not exist. In those cases the Processor may charge its reasonable costs, after telling the Customer the expected cost and obtaining its agreement.

8. Assistance with Arts. 32 to 36 (Art. 28(3)(f)), and personal data breaches

8.1 The Processor assists the Customer in ensuring compliance with Arts. 32 to 36 GDPR, taking into account the nature of the processing and the information available to it. Annex 2 and the Processor's breach response procedure are the principal means of that assistance.

8.2 The Processor notifies the Customer of a personal data breach affecting personal data processed under this DPA without undue delay and in any event within 48 hours of becoming aware of it, so that the Customer can meet its own 72-hour obligation under Art. 33(1).

8.3 The notification describes, as far as known at the time: the nature of the breach including the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point. Where the information cannot be provided at once, it is provided in phases without undue further delay. The Processor does not delay the initial notification in order to complete its investigation.

8.4 The Processor does not notify a supervisory authority or a data subject of a breach on the Customer's behalf unless the Customer instructs it to in text form.

8.5 The Processor supports the Customer's data protection impact assessments and prior consultations under Arts. 35 and 36 by providing the information about the processing that is available to it.

9. Deletion or return of the data (Art. 28(3)(g))

9.1 The Customer chooses whether the Processor returns the personal data processed on its behalf or deletes it. The Customer's declaration under the switching and exit provision of the Main Agreement is also the exercise of that choice.

9.2 This section carries out the choice made under 9.1. It is not a separate default that overrides it. The retrieval period the Customer has at the end of the Main Agreement, and the process for it, are those of the switching and exit provision of the Main Agreement, which the Parties have deliberately made the single exit process rather than operating a second one here. A Customer that has chosen return takes it through that process. At the end of that period the Processor deletes the personal data processed on the Customer's behalf, and existing copies of it, unless Union or Member State law requires it to be stored.

A Customer that has chosen deletion may have it carried out sooner, by deleting its account in the service; section 9.3 describes what that does. Where the Customer makes no choice, the Processor deletes at the end of that period. That is the outcome Art. 28(3)(g) treats as the default, and it is the one that leaves the Processor holding nothing.

9.3 Deletion by the Customer during the term. Where the Customer deletes its account in the service, the Processor produces and verifies a complete export before the deletion, then destroys the key with which the Customer's files are encrypted and removes the records from live operation. That deletion is immediate and irreversible, and the Customer is told so before it confirms.

9.4 Backups. Deletion propagates to backup copies as the backup retention window rolls forward and not before. Backups are not restored selectively in order to give effect to an individual deletion. The outer bound is therefore 90 days from deletion, which is the production backup retention period. Personal data present in a backup during that period is not processed for any purpose other than restoring the service.

9.5 Export archives. An export archive, whether produced under 9.3 or on the Customer's request during the term, is stored for 30 days from its creation and is then deleted by an automated task. A deletion of the account does not shorten that period, which is why the archive is the one artifact that outlives the deletion in 9.3. The period is deliberately fixed and short at both ends: it is long enough to leave the Customer's choice under 9.1 a real one, and no longer than that, because the archive is held unencrypted at rest and contains personal data of the Customer's own data subjects, who are third parties to the Processor. The Processor does not undertake that a download link issued for an archive remains valid for the whole of the period; links are short-lived by design. A fresh link for an archive still within its period, or a new export, is obtained through the Customer's account, which is available for as long as the account exists.

9.6 The Processor confirms deletion to the Customer in text form on request.

10. Information and audits (Art. 28(3)(h))

10.1 The Processor makes available to the Customer all information necessary to demonstrate compliance with Art. 28, and allows for and contributes to audits, including inspections, conducted by the Customer or an auditor mandated by it.

10.2 First instance. The Processor discharges this obligation in the first instance by providing Annex 2, the record of processing activities relating to the processing carried out for the Customer, the subprocessor list with its transfer bases, and written answers to the Customer's security questionnaire, within a reasonable period.

10.3 On-site and remote inspections. Where that is not sufficient for the Customer to demonstrate compliance, the Customer may carry out an inspection: on 30 days' notice in text form, during normal business hours, no more than once in any twelve-month period unless there has been a personal data breach or a supervisory authority requires it, subject to a confidentiality undertaking, and without access to data of other customers. The Customer bears its own costs and the Processor's reasonable costs of supporting an inspection beyond the first day.

10.4 An auditor mandated by the Customer must not be a competitor of the Processor. The Processor may refuse a particular auditor on that ground, in which case the Customer may nominate another.

10.5 The Processor may postpone an inspection while it is responding to a personal data breach or other security incident, and carries it out without undue delay afterwards.

10.6 The Processor holds no ISO 27001 or SOC 2 certification and does not represent that it does. It states this here rather than leaving the Customer to discover it during a security review.

11. Obligations of the Customer

11.1 The Customer is the controller. It is responsible for the lawfulness of the processing it instructs, in particular for having a legal basis, for informing data subjects, and for the accuracy of the data it enters.

11.2 The Customer is responsible for the personal data it chooses to enter, import or upload into the service, and for the recipients it designates within it.

11.3 Special categories. Steerd provides no field intended for personal data of the categories in Art. 9(1) GDPR and asks for none. The Customer shall not process such data, nor personal data relating to criminal convictions and offences (Art. 10), through the service unless it has notified the Processor in text form and the Parties have agreed the additional measures required. This imposes no obligation on the Processor to monitor or inspect the Customer's content, and the Processor does not do so.

11.4 Addresses for notices, and the one rule that governs them. The Customer names a contact for data protection matters in its account and keeps it current. The Processor gives notices under sections 5.2 and 8.2 to that contact and to the email address held for the account owner. Where the two differ, the notice is validly given once it has been sent to either, and any period the notice starts runs from the later of the two dispatch dates. Where the Customer has named no contact for data protection matters, the address held for the account owner is the address for those notices and is sufficient.

This is deliberately one rule rather than a rule per clause. The period section 5.2 starts is the Customer's 30 days to object to a subprocessor, and a Customer whose objection is late because the agreement named two addresses and the Processor used the other one would have lost a right through the drafting rather than through anything it did.

12. Liability

12.1 The liability of the Parties to each other under this DPA is governed by the liability provision of the Main Agreement, which applies to this DPA as it applies to the Main Agreement. The Parties have deliberately not created a second and different liability regime here.

12.2 Art. 82 GDPR is unaffected. Nothing in this DPA or in the Main Agreement limits either Party's statutory liability to a data subject under Art. 82 GDPR, which is owed to persons who are not parties to this DPA and cannot be limited by it. The apportionment between the Parties under Art. 82(5) is likewise unaffected.

12.3 Liability for intent and gross negligence, for injury to life, body or health, and under the Produkthaftungsgesetz, is unlimited.

13. Term and termination

13.1 This DPA begins when the Main Agreement begins and ends when it ends, subject to the obligations in section 9 which survive until performed, and to section 3 which survives indefinitely.

13.2 This DPA cannot be terminated separately from the Main Agreement, except under section 5.3.

14. Language

This DPA exists in German and in English. The version in the language in which the Parties conclude it is the version that binds them, and that language is the language of this DPA. Both versions are of equal standing and are amended together. This matches the language rule of the Main Agreement and is deliberate: a customer who concludes in one language should not be bound by a text in the other.

15. Final provisions

15.1 German law applies, excluding the UN Convention on Contracts for the International Sale of Goods.

15.2 The place of jurisdiction is that of the Main Agreement.

15.3 Amendments and additions to this DPA require text form, including any waiver of this form requirement. Individual agreements between the Parties take precedence (§ 305b BGB).

15.4 If a provision of this DPA is or becomes invalid, the remaining provisions stay in force. The Parties will replace an invalid provision with a valid one that comes closest to its data protection purpose.

16. Terms for particular jurisdictions

16.1 California. Where the Customer is a "business" and the Processor a "service provider" within the meaning of the California Consumer Privacy Act, Annex 4 applies to the personal information covered by that Act, in addition to the rest of this DPA.

16.2 United Kingdom. Where the Customer is subject to the UK GDPR in respect of the processing, Annex 5 applies to that processing, in addition to the rest of this DPA.

16.3 Each of those annexes applies only to the processing it describes and only for as long as the law it implements applies to that processing. Where an annex and the body of this DPA conflict on processing the annex covers, the annex prevails for that processing and the body continues to govern everything else. Neither annex reduces any obligation the GDPR imposes on the Processor.

16.4 The Processor does not sell or share personal data under any of these laws, and does nothing under this DPA on any basis other than the Customer's instructions. Sections 2.1 and 2.5 say so for the agreement as a whole: 2.1 confines the Processor to documented instructions and 2.5 rules out its own purposes, sale and AI training. The annexes restate it in the terms each statute requires, because a statute that requires specific words is not satisfied by a clause that means the same thing.

Annex 1: description of the processing

1.1 Subject matter, nature and purpose

Subject matter. Provision of Steerd, an all-in-one business platform for freelancers and small businesses. In one product: contacts and the client pipeline, projects and tasks, CVs, time tracking, travel expenses and per-diem records, files and attachments, imported email correspondence and the conversations built on it, and invoicing including e-invoicing. Managing client relationships is one module of it and not the whole product.

The subject matter is what scopes the processing under this DPA, which is why this description names every module that holds personal data rather than the ones the product started as. A description narrower than the product would be an agreement that arguably does not cover what is in fact processed, and Annex 1.2 below lists the data of every module named here.

Nature of the processing. Collection, including import from a mailbox the Customer connects and from the Customer's own browser; storage; structuring; retrieval; alteration; transmission to recipients the Customer designates; disclosure to the subprocessors listed in Annex 3, on the basis stated there; and erasure.

Purpose. Solely to provide the service under the Main Agreement and on the Customer's instructions.

Duration. For as long as the Customer holds an account, plus the periods in section 9.

1.2 Types of personal data

This list is factual and is the part of the document a customer's own lawyer will actually read.

1.3 Categories of data subjects

• The Customer's own clients and prospective clients, and their staff.
• Recruiters and agencies the Customer deals with.
• The Customer's own employees, contractors and team members.
• Candidates and freelancers whose CVs the Customer stores.
• Anyone who writes to a mailbox the Customer connects and whose message the Customer imports.
• The Customer's own users of Steerd.

1.4 Self-service functions for data subject rights (section 7.2)

What the export contains. The archive carries two halves through one manifest, so every entry has a SHA-256 and is verified the same way:

• Files: attachments and files, decrypted, under attachments/ and files/.
• Records: records/<table>.json for every table holding the team's data, including contacts

and all their child tables, organizations, projects, stages, assignments, tasks, activities, employees, time entries, invoices and their line items, billing profiles, trips, expenses and their child rows, CVs and presets, email ingestions, extension imports, connection metadata, team membership, permissions, invitations, subscriptions, notifications, the audit log, and the file metadata rows that make the exported bytes meaningful.

• An empty table still produces a file containing [], so "you had no invoices" is distinguishable

from "invoices were not in this export".

What is deliberately withheld. Secret material never leaves the encrypted store even for its owner, because a ZIP behind a signed URL is a wider blast radius than the encrypted column it came from: API key and CardDAV password hashes, encrypted mailbox and integration credentials, wrapped data encryption keys, and short-lived OAuth codes. Operational bookkeeping that is the Processor's rather than the Customer's is also withheld: the idempotency replay cache, dormancy notice markers, CardDAV sync tombstones, sync run telemetry, raw Stripe webhook payloads, invitation send records and internal counters. Each exclusion carries a stated reason, and an automated check enumerates every table the service holds and fails where one is classified in neither bucket, so the list cannot silently rot.

1.5 Retention within the term

Where the Customer copies an imported email excerpt into a project description or an activity note, that text becomes part of the Customer's own business records and is retained with them. It is not removed when the originating imported message reaches the end of its own retention window, because removing text from inside the Customer's records would be an alteration of the Customer's data that the Customer has not instructed.

Annex 2: technical and organisational measures (Art. 32)

Annex 2 is published at https://www.steerd.io/dpa/annex-2 and is not duplicated here, so the annex and the document cannot drift apart. It is written as a description of what the system does, not as an assurance of what it achieves, and it states its gaps in a Known gaps section rather than omitting them. Section 4.3 of this DPA refers to that section deliberately.

Annex 3: subprocessors

Annex 3 is published at https://www.steerd.io/dpa/annex-3, likewise not duplicated so the two cannot drift apart. It carries the same list, with the purpose and the transfer basis stated per recipient. As at 13.08.2026 the subprocessors engaged are:

Not subprocessors, per section 5.5. Stripe, Cloudflare and Google Ireland process personal data for which the Processor is itself the controller: the payment relationship, bot protection on the marketing forms, and consent-gated website analytics. They are named in the Processor's privacy notice and are not listed here, because listing them would misstate their role and give the Customer an objection right over processing that is not its data.

Why section 6.1 holds without qualification for the last row. The Processor's counterparty is OpenAI Ireland Ltd, which is established in the European Union, so the processing the Processor instructs takes place within the Union and Chapter V does not engage at the Processor's layer. The onward transfer to the United States is OpenAI Ireland's own, made under its data processing addendum. The transfer impact assessment section 6.3 offers on request has been carried out and is available on request.

Section 2.5 and this row are read together. The Processor does not use personal data to train artificial intelligence models, whether its own or a third party's. Content sent to OpenAI's API is not used to train its models, and the Processor does not opt in to any data-sharing or feedback mechanism by which that would change. The Processor reads the same commitment against any further model provider before engaging one.

Annex 4: California Consumer Privacy Act

This annex applies where section 16.1 says it does. Terms defined in the California Consumer Privacy Act of 2018 as amended by the California Privacy Rights Act, and in its implementing regulations (together the "CCPA"), have those meanings here. In this annex the Customer is the Business and the Processor is the Service Provider.

A4.1 The limited and specified purposes

The Business discloses personal information to the Service Provider only for the business purpose of providing Steerd under the Main Agreement, as described in Annex 1. That is the limited and specified purpose for which the personal information is disclosed, and the Service Provider processes it for no other.

The disclosure is not a sale and not a sharing. The Service Provider provides no monetary or other valuable consideration for the personal information, and receives it solely to perform the services.

A4.2 The Service Provider's prohibitions

The Service Provider shall not:

• Sell or share the personal information, as those terms are defined in the CCPA.
• Retain, use or disclose the personal information for any purpose other than the business

purpose in A4.1, including retaining, using or disclosing it for a commercial purpose other than that business purpose, and including outside the direct business relationship between the Service Provider and the Business.

• Combine the personal information with personal information it receives from, or on behalf of,

another person, or collects from its own interaction with a consumer, except where the CCPA expressly permits a service provider to do so.

The prohibition on retaining, using and disclosing outside the direct business relationship covers the Service Provider's own commercial purposes without exception, and the Parties record that section 2.5 of this DPA already says the same thing for the agreement as a whole: no use for the Service Provider's own purposes, no sale, no analysis for its own commercial purposes, and no use to train artificial intelligence models, whether its own or a third party's.

A4.3 Certification

The Service Provider certifies that it understands the restrictions in A4.1 and A4.2 and will comply with them.

A4.4 Level of protection, assistance and remediation

A4.4.1 The Service Provider shall comply with the obligations applicable to it under the CCPA and shall provide the same level of privacy protection as the CCPA requires of the Business.

A4.4.2 The Business may take reasonable and appropriate steps to ensure that the Service Provider uses the personal information in a manner consistent with the Business's obligations under the CCPA. Section 10 of this DPA is the mechanism by which it does so, and applies here.

A4.4.3 The Service Provider shall notify the Business without undue delay if it determines that it can no longer meet its obligations under the CCPA.

A4.4.4 Upon notice, including a notice given by the Service Provider under A4.4.3, the Business has the right to take reasonable and appropriate steps to stop and remediate any unauthorised use of personal information, and the Service Provider shall cooperate with those steps. The right does not depend on the Business having been the one to identify the unauthorised use.

A4.5 Subcontractors, consumer requests and deidentified data

A4.5.1 The Service Provider engages the subcontractors listed in Annex 3 and imposes on each, by written contract, obligations no less protective than those in this annex. Section 5 of this DPA governs how the list changes and how the Business objects.

A4.5.2 The Service Provider assists the Business in responding to verifiable consumer requests under the CCPA. Section 7 of this DPA, and the self-service functions in Annex 1.4, are the means of that assistance. Where a consumer addresses a request to the Service Provider, it does not answer on its own behalf; it forwards the request to the Business and refers the consumer to it.

A4.5.3 Where the Service Provider holds deidentified information it shall not attempt to reidentify it, and shall maintain the measures and commitments the CCPA requires of a recipient of deidentified information.

Annex 5: United Kingdom

This annex applies where section 16.2 says it does. "UK GDPR" and "UK Data Protection Act" mean the retained EU General Data Protection Regulation as it forms part of the law of England and Wales, Scotland and Northern Ireland, and the Data Protection Act 2018.

A5.1 How this DPA is read

Where the processing is subject to the UK GDPR, a reference in this DPA to the GDPR, to an Article of it, or to a supervisory authority is read as a reference to the corresponding provision of the UK GDPR and to the Information Commissioner. Every obligation the body of this DPA places on the Processor applies unchanged, and nothing in this annex reduces one.

A5.2 The transfer to the Processor needs no transfer tool, and here is why

The Processor processes in Germany, and its subprocessors process within the European Economic Area, as Annex 3 states per recipient.

A transfer of personal data from the Customer in the United Kingdom to the Processor in Germany is a restricted transfer, and the UK adequacy regulations cover it: under those regulations the EEA states are treated as providing an adequate level of protection. It therefore requires no safeguard under Article 46 UK GDPR, and none is engaged.

The distinction in that sentence is deliberate and is not pedantry. Adequacy does not put a transfer outside Chapter V of the UK GDPR; it is the ground on which a restricted transfer may be made without a further transfer tool. A clause saying the transfer is not restricted at all would be wrong in the vocabulary a UK buyer's counsel uses, and wrong in the direction that looks like we did not know.

The Parties record this expressly because the usual expectation is the opposite. A UK buyer's procurement will ask for the International Data Transfer Agreement or the UK Addendum by name, and the correct answer is that neither is required for this transfer rather than that neither was considered. Section A5.3 covers the case where that stops being true.

A5.3 The UK Addendum, for the transfers it would actually govern

Where the Processor relies on the standard contractual clauses adopted by the European Commission for an onward transfer of personal data subject to the UK GDPR to a country not covered by the UK adequacy regulations, the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses, issued by the Information Commissioner under section 119A of the Data Protection Act 2018 (the "UK Addendum"), applies to those clauses and forms part of this DPA for that transfer.

That Addendum is concluded between the Processor and the subprocessor, not here. The transfer it would govern is one the Processor makes as exporter to a subprocessor as importer, which is Module Three. Neither the Customer nor this agreement is a party to it: the importer is not a party to this DPA at all, so the parties block at the head of this document cannot complete the Addendum's Table 1, and its Table 2 selections, including the version of the standard contractual clauses and the optional clauses taken, are properties of that other contract rather than of this one.

So what this section obliges the Processor to do is concrete rather than declaratory. Before making any such onward transfer the Processor shall:

• conclude a UK Addendum with that subprocessor, with Tables 1 to 3 completed for that transfer

and Table 4 recording that neither party to it may end it as set out in its section 19;

• not begin the transfer until that Addendum is in force; and
• provide a copy to the Customer on request, under section 6.3, redacted only as necessary to

protect the confidentiality of third parties.

As at the date of this DPA no such onward transfer is made: every recipient in Annex 3 processes within the EEA, and the one onward transfer to the United States that occurs anywhere in the chain is made by OpenAI Ireland Ltd under its own agreement rather than by the Processor. Section 6.4 requires the Processor to tell the Customer if a transfer basis it relies on ceases to be valid, and section 5.2 gives the Customer 30 days' notice, and a right to object, before any new subprocessor is engaged at all.

A5.4 Reporting

The Customer's own obligation to report a personal data breach to the Information Commissioner runs 72 hours from its awareness, as it does under Art. 33(1) GDPR. Section 8.2 of this DPA applies to UK processing without change, and the period it sets is stated there rather than restated here: a binding deadline written in two places is a deadline that can come to say two things.