Event Horizon — Data Processing Agreement

This Data Processing Agreement (the "DPA") is entered into between:

(i) the Customer identified in the Event Horizon account, acting as controller; and

(ii) Ricardo Miguel Andorinha Rodrigues, sole trader (empresário em nome individual), tax number 220585571 ("Event Horizon"), acting as processor,

together the "Parties".

It forms part of the Terms of Service and is accepted at registration by the same affirmative act. Article 28(9) GDPR expressly permits a data processing contract to be concluded in electronic form; no signature is required for it to bind both Parties.

What this document is, exactly

Clauses 1 to 10 below are the standard contractual clauses set out in the Annex to Commission Implementing Decision (EU) 2021/915 of 4 June 2021, reproduced without modification. Clause 2 requires that. Only two things have been done to them, both of which the Decision itself provides for:

1. The options offered by the text have been selected. They are listed immediately below.
2. Information has been added to the Annexes, which is what Clause 2(a) permits and what Annexes I to IV exist for.

Anything in this document under a heading beginning "Practical note" is not part of the Clauses. It is additional information and additional undertakings, permitted by Clause 2(b), which do not directly or indirectly contradict the Clauses and do not detract from the rights or freedoms of data subjects. Where a practical note commits the processor to more than a Clause requires, the note binds the processor in addition to the Clause; where the two could ever be read as conflicting, the Clause prevails.

The options selected

Terms used here have the meaning given to them in the GDPR.

SECTION I

Clause 1 — Purpose and scope

(a) The purpose of these Standard Contractual Clauses (the Clauses) is to ensure compliance with Article 28(3) and (4) of Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation).

(b) The controllers and processors listed in Annex I have agreed to these Clauses in order to ensure compliance with Article 28(3) and (4) of Regulation (EU) 2016/679 and/or Article 29(3) and (4) of Regulation (EU) 2018/1725.

(c) These Clauses apply to the processing of personal data as specified in Annex II.

(d) Annexes I to IV are an integral part of the Clauses.

(e) These Clauses are without prejudice to obligations to which the controller is subject by virtue of Regulation (EU) 2016/679 and/or Regulation (EU) 2018/1725.

(f) These Clauses do not by themselves ensure compliance with obligations related to international transfers in accordance with Chapter V of Regulation (EU) 2016/679 and/or Regulation (EU) 2018/1725.

Practical note — what Clause 1(f) means for a European customer. These Clauses are the Article 28 contract. They are not a transfer tool. The Service is hosted in the United States, so a transfer under Chapter V does take place, and the instrument relied on for each sub-processor is stated — named, not gestured at — in Annex IV.

Clause 2 — Invariability of the Clauses

(a) The Parties undertake not to modify the Clauses, except for adding information to the Annexes or updating information in them.

(b) This does not prevent the Parties from including the standard contractual clauses laid down in these Clauses in a broader contract, or from adding other clauses or additional safeguards provided that they do not directly or indirectly contradict the Clauses or detract from the fundamental rights or freedoms of data subjects.

Clause 3 — Interpretation

(a) Where these Clauses use the terms defined in Regulation (EU) 2016/679 or Regulation (EU) 2018/1725 respectively, those terms shall have the same meaning as in that Regulation.

(b) These Clauses shall be read and interpreted in the light of the provisions of Regulation (EU) 2016/679 or Regulation (EU) 2018/1725 respectively.

(c) These Clauses shall not be interpreted in a way that runs counter to the rights and obligations provided for in Regulation (EU) 2016/679 / Regulation (EU) 2018/1725 or in a way that prejudices the fundamental rights or freedoms of the data subjects.

Clause 4 — Hierarchy

In the event of a contradiction between these Clauses and the provisions of related agreements between the Parties existing at the time when these Clauses are agreed or entered into thereafter, these Clauses shall prevail.

Practical note — the related agreement is the Terms of Service, and Clause 4 means these Clauses beat it on any matter of data protection, including anything agreed later.

Practical note — Clause 5 (Docking) is omitted, and what that does not change. The Customer is frequently a processor for its own clients, which makes Event Horizon a sub-processor in that chain. That is a matter of fact and of the Customer's own contracts; it does not require an entity to accede to this contract. The Customer may name Event Horizon as a sub-processor in its own disclosures and rely on these Clauses in doing so, and the processor will complete a customer's own sub-processor documentation on request.

SECTION II — OBLIGATIONS OF THE PARTIES

Clause 6 — Description of the processing(s)

The details of the processing operations, in particular the categories of personal data and the purposes of processing for which the personal data is processed on behalf of the controller, are specified in Annex II.

Clause 7 — Obligations of the Parties

7.1. Instructions

(a) The processor shall process personal data only on documented instructions from the controller, unless required to do so by Union or Member State law to which the processor is subject. In this case, the processor shall inform the controller of that legal requirement before processing, unless the law prohibits this on important grounds of public interest. Subsequent instructions may also be given by the controller throughout the duration of the processing of personal data. These instructions shall always be documented.

(b) The processor shall immediately inform the controller if, in the processor's opinion, instructions given by the controller infringe Regulation (EU) 2016/679 / Regulation (EU) 2018/1725 or the applicable Union or Member State data protection provisions.

Practical note — how instructions are given here. The controller's documented instructions are: these Clauses, the Terms of Service, and the configuration the controller creates in the Service — the pipelines it builds, the tables it defines, the retention periods it sets, the dashboards it publishes, the access and row-level restrictions it grants, and the exports and deletions it requests. Additional or different instructions are given in writing to privacy@eventhorizondata.com, and the processor may charge for instructions that require work outside the Service's normal functionality.

7.2. Purpose limitation

The processor shall process the personal data only for the specific purpose(s) of the processing, as set out in Annex II, unless it receives further instructions from the controller.

Practical note — the processor does not process the personal data for any purpose of its own. In particular, it does not use it to train machine-learning models, to produce benchmarks or statistics — aggregated or otherwise — for its own or a third party's use, or to develop products. The Parties record their shared understanding that doing so would determine the purposes and means of that processing and would, under Article 28(10) GDPR, make the processor a controller in respect of it.

7.3. Duration of the processing of personal data

Processing by the processor shall only take place for the duration specified in Annex II.

7.4. Security of processing

(a) The processor shall at least implement the technical and organisational measures specified in Annex III to ensure the security of the personal data. This includes protecting the data against a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure or access to the data (personal data breach). In assessing the appropriate level of security, the Parties shall take due account of the state of the art, the costs of implementation, the nature, scope, context and purposes of processing and the risks involved for the data subjects.

(b) The processor shall grant access to the personal data undergoing processing to members of its personnel only to the extent strictly necessary for implementing, managing and monitoring of the contract. The processor shall ensure that persons authorised to process the personal data received have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality.

Practical note — Annex III may be updated by the processor from time to time, provided the updates do not result in a decrease of the overall security of the processing. The current version is always the one published at /dpa.

7.5. Sensitive data

If the processing involves personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, genetic data or biometric data for the purpose of uniquely identifying a natural person, data concerning health or a person's sex life or sexual orientation, or data relating to criminal convictions and offences ("sensitive data"), the processor shall apply specific restrictions and/or additional safeguards.

Practical note — the specific restriction applied is a prohibition. The Service is not designed for sensitive data, and clause 5.3 of the Terms of Service prohibits the submission of special categories of personal data within the meaning of Article 9(1) GDPR, of personal data relating to criminal convictions and offences under Article 10 GDPR, and of cardholder data. That prohibition forms part of the controller's instructions.

The Parties record the following, plainly, because it decides who does what when the prohibition is broken:

• The processor does not inspect the content of the controller's data. Not inspecting is normal for a service of this kind and is not a failure of diligence; it is also the reason the processor cannot detect prohibited data by itself.
• A pipeline is a general-purpose mechanism. A change-data-capture connector pointed at the controller's own database will transfer whatever that database contains. The processor can prohibit, delete promptly once it knows, and demonstrate diligence — it cannot prevent.
• If either Party becomes aware that prohibited data has reached the Service, it tells the other without undue delay. The controller removes it. The processor may suspend the affected pipeline or the account under clause 13.4 of the Terms of Service, and may delete the data.
• Where prohibited data is nevertheless present, the measures in Annex III apply to it in the same way as to any other personal data. Nothing in this note reduces the processor's obligations under Articles 28 and 32 GDPR in respect of data actually in its systems.

7.6. Documentation and compliance

(a) The Parties shall be able to demonstrate compliance with these Clauses.

(b) The processor shall deal promptly and adequately with inquiries from the controller about the processing of data in accordance with these Clauses.

(c) The processor shall make available to the controller all information necessary to demonstrate compliance with the obligations that are set out in these Clauses and stem directly from Regulation (EU) 2016/679 and/or Regulation (EU) 2018/1725. At the controller's request, the processor shall also permit and contribute to audits of the processing activities covered by these Clauses, at reasonable intervals or if there are indications of non-compliance. In deciding on a review or an audit, the controller may take into account relevant certifications held by the processor.

(d) The controller may choose to conduct the audit by itself or mandate an independent auditor. Audits may also include inspections at the premises or physical facilities of the processor and shall, where appropriate, be carried out with reasonable notice.

(e) The Parties shall make the information referred to in this Clause, including the results of any audits, available to the competent supervisory authority/ies on request.

Practical note — how this is satisfied in practice. The processor holds no SOC 2 or ISO 27001 certification and does not claim one. In its place it provides, on request and under the confidentiality obligation in the Terms of Service:

• Annex III of this DPA, which is maintained against the system as built;
• the reports of its recurring authorised adversarial security reviews, dated, with the findings and the fixes;
• a completed security questionnaire (CAIQ or SIG Lite);
• its written commitments on availability, data export and business continuity.

An on-site inspection is available on reasonable notice. Because the infrastructure is operated by the sub-processors listed in Annex IV, an inspection of a datacentre facility is subject to that provider's own audit arrangements, and the processor will pass on the certifications and reports it receives from them.

7.7. Use of sub-processors

(a) GENERAL WRITTEN AUTHORISATION: The processor has the controller's general authorisation for the engagement of sub-processors from an agreed list. The processor shall specifically inform in writing the controller of any intended changes of that list through the addition or replacement of sub-processors at least 30 days in advance, thereby giving the controller sufficient time to be able to object to such changes prior to the engagement of the concerned sub-processor(s). The processor shall provide the controller with the information necessary to enable the controller to exercise the right to object.

(b) Where the processor engages a sub-processor for carrying out specific processing activities (on behalf of the controller), it shall do so by way of a contract which imposes on the sub-processor, in substance, the same data protection obligations as the ones imposed on the data processor in accordance with these Clauses. The processor shall ensure that the sub-processor complies with the obligations to which the processor is subject pursuant to these Clauses and to Regulation (EU) 2016/679 and/or Regulation (EU) 2018/1725.

(c) At the controller's request, the processor shall provide a copy of such a sub-processor agreement and any subsequent amendments to the controller. To the extent necessary to protect business secret or other confidential information, including personal data, the processor may redact the text of the agreement prior to sharing the copy.

(d) The processor shall remain fully responsible to the controller for the performance of the sub-processor's obligations in accordance with its contract with the processor. The processor shall notify the controller of any failure by the sub-processor to fulfil its contractual obligations.

(e) The processor shall agree a third party beneficiary clause with the sub-processor whereby — in the event the processor has factually disappeared, ceased to exist in law or has become insolvent — the controller shall have the right to terminate the sub-processor contract and to instruct the sub-processor to erase or return the personal data.

Practical note — the agreed list, the notice, and the objection. The agreed list is Annex IV. Notice of an intended change is given to the account's administrators by email and by publishing an updated Annex IV, at least 30 days before the sub-processor is engaged.

An objection is raised within the 30-day notice period, on reasonable data-protection grounds, in writing to privacy@eventhorizondata.com. The Parties will discuss it in good faith. If no solution is found, the controller may terminate the contract in respect of the affected processing without penalty, with a refund of prepaid fees for the unused period.

7.8. International transfers

(a) Any transfer of data to a third country or an international organisation by the processor shall be done only on the basis of documented instructions from the controller or in order to fulfil a specific requirement under Union or Member State law to which the processor is subject and shall take place in compliance with Chapter V of Regulation (EU) 2016/679 or Regulation (EU) 2018/1725.

(b) The controller agrees that where the processor engages a sub-processor in accordance with Clause 7.7. for carrying out specific processing activities (on behalf of the controller) and those processing activities involve a transfer of personal data within the meaning of Chapter V of Regulation (EU) 2016/679, the processor and the sub-processor can ensure compliance with Chapter V of Regulation (EU) 2016/679 by using standard contractual clauses adopted by the Commission in accordance with of Article 46(2) of Regulation (EU) 2016/679, provided the conditions for the use of those standard contractual clauses are met.

Practical note — the Service is hosted in the United States. Every controller established in the EEA or the United Kingdom should read this Clause as applying to all of its personal data, not to an edge case. The mechanism relied on for each sub-processor is stated in Annex IV, with the date it was verified.

Clause 8 — Assistance to the controller

(a) The processor shall promptly notify the controller of any request it has received from the data subject. It shall not respond to the request itself, unless authorised to do so by the controller.

(b) The processor shall assist the controller in fulfilling its obligations to respond to data subjects' requests to exercise their rights, taking into account the nature of the processing. In fulfilling its obligations in accordance with (a) and (b), the processor shall comply with the controller's instructions.

(c) In addition to the processor's obligation to assist the controller pursuant to Clause 8(b), the processor shall furthermore assist the controller in ensuring compliance with the following obligations, taking into account the nature of the data processing and the information available to the processor:

(1) the obligation to carry out an assessment of the impact of the envisaged processing operations on the protection of personal data (a 'data protection impact assessment') where a type of processing is likely to result in a high risk to the rights and freedoms of natural persons;

(2) the obligation to consult the competent supervisory authority/ies prior to processing where a data protection impact assessment indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk;

(3) the obligation to ensure that personal data is accurate and up to date, by informing the controller without delay if the processor becomes aware that the personal data it is processing is inaccurate or has become outdated;

(4) the obligations in Article 32 of Regulation (EU) 2016/679.

(d) The Parties shall set out in Annex III the appropriate technical and organisational measures by which the processor is required to assist the controller in the application of this Clause as well as the scope and the extent of the assistance required.

Practical note — the functionality of the Service is itself the primary assistance. The controller can search, export, correct and delete records, and set retention periods, without the processor's involvement. Where a request cannot be satisfied through the Service, the processor assists on request. The measures are set out in Annex III, section 7.

Clause 9 — Notification of personal data breach

In the event of a personal data breach, the processor shall cooperate with and assist the controller for the controller to comply with its obligations under Articles 33 and 34 of Regulation (EU) 2016/679, taking into account the nature of processing and the information available to the processor.

9.1 Data breach concerning data processed by the controller

In the event of a personal data breach concerning data processed by the controller, the processor shall assist the controller:

(a) in notifying the personal data breach to the competent supervisory authority/ies, without undue delay after the controller has become aware of it, where relevant (unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons);

(b) in obtaining the following information which, pursuant to Article 33(3) of Regulation (EU) 2016/679, shall be stated in the controller's notification, and must at least include:

(1) the nature of the personal data including where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned;

(2) the likely consequences of the personal data breach;

(3) the measures taken or proposed to be taken by the controller to address the personal data breach, including, where appropriate, measures to mitigate its possible adverse effects.

Where, and insofar as, it is not possible to provide all this information at the same time, the initial notification shall contain the information then available and further information shall, as it becomes available, subsequently be provided without undue delay.

(c) in complying, pursuant to Article 34 of Regulation (EU) 2016/679, with the obligation to communicate without undue delay the personal data breach to the data subject, when the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons.

9.2 Data breach concerning data processed by the processor

In the event of a personal data breach concerning data processed by the processor, the processor shall notify the controller without undue delay after the processor having become aware of the breach. Such notification shall contain, at least:

(a) a description of the nature of the breach (including, where possible, the categories and approximate number of data subjects and data records concerned);

(b) the details of a contact point where more information concerning the personal data breach can be obtained;

(c) its likely consequences and the measures taken or proposed to be taken to address the breach, including to mitigate its possible adverse effects.

Where, and insofar as, it is not possible to provide all this information at the same time, the initial notification shall contain the information then available and further information shall, as it becomes available, subsequently be provided without undue delay.

The Parties shall set out in Annex III all other elements to be provided by the processor when assisting the controller in the compliance with the controller's obligations under Articles 33 and 34 of Regulation (EU) 2016/679.

SECTION III — FINAL PROVISIONS

Clause 10 — Non-compliance with the Clauses and termination

(a) Without prejudice to any provisions of Regulation (EU) 2016/679 and/or Regulation (EU) 2018/1725, in the event that the processor is in breach of its obligations under these Clauses, the controller may instruct the processor to suspend the processing of personal data until the latter complies with these Clauses or the contract is terminated. The processor shall promptly inform the controller in case it is unable to comply with these Clauses, for whatever reason.

(b) The controller shall be entitled to terminate the contract insofar as it concerns processing of personal data in accordance with these Clauses if:

(1) the processing of personal data by the processor has been suspended by the controller pursuant to point (a) and if compliance with these Clauses is not restored within a reasonable time and in any event within one month following suspension;

(2) the processor is in substantial or persistent breach of these Clauses or its obligations under Regulation (EU) 2016/679 and/or Regulation (EU) 2018/1725;

(3) the processor fails to comply with a binding decision of a competent court or the competent supervisory authority/ies regarding its obligations pursuant to these Clauses or to Regulation (EU) 2016/679 and/or Regulation (EU) 2018/1725.

(c) The processor shall be entitled to terminate the contract insofar as it concerns processing of personal data under these Clauses where, after having informed the controller that its instructions infringe applicable legal requirements in accordance with Clause 7.1 (b), the controller insists on compliance with the instructions.

(d) Following termination of the contract, the processor shall, at the choice of the controller, delete all personal data processed on behalf of the controller and certify to the controller that it has done so, or, return all the personal data to the controller and delete existing copies unless Union or Member State law requires storage of the personal data. Until the data is deleted or returned, the processor shall continue to ensure compliance with these Clauses.

Practical note — how the choice under Clause 10(d) is exercised. The controller may export its data through the Service at any time. If the controller has not stated its choice within 30 days of termination, the processor deletes the data. Deletion from live systems is completed within 30 days; backups are not edited, and the data disappears from them as they rotate — within 14 days on the primary host and 7 days off-site. Deletion of a table in the Service drops the underlying physical storage before the metadata that describes it, so a partial failure can only ever leave a description with no data behind it, never data with no description.

Annex I — List of parties

Controller:

1. Name: the Customer, as identified by the organisation name held in its Event Horizon account. Address: the address held in that account. Contact person's name, position and contact details: the account's administrators, as designated by the Customer in the account. Accession date: the date on which the Customer accepted this DPA at registration, which the processor records together with the version accepted.

Processor:

1. Name: Ricardo Miguel Andorinha Rodrigues Tax number: 220585571 Contact person's name, position and contact details: Ricardo Miguel Andorinha Rodrigues, owner, privacy@eventhorizondata.com Accession date: the date of the version of this DPA in force at the time of acceptance.

Practical note — no signature, and why that is correct here. The Decision's Annex I provides for a signature. This DPA is concluded electronically under Article 28(9) GDPR, which expressly permits it. In place of a signature the processor records, for every acceptance and permanently: the accepting user, the organisation, the exact versions of the Terms, Privacy Policy and this DPA that were in force, a cryptographic hash of the text accepted, the timestamp, the IP address and the user agent. That record cannot be edited or deleted by any route in the application.

Practical note — the processor is identified by tax number, not by a street. Annex I of the Decision provides an address field, and this one gives a Portuguese tax number instead. That is a deliberate choice by the processor, recorded here rather than left as a blank somebody might read as an oversight.

The reason it is sound: Article 28 requires the contract to identify the parties and provide contact details, and it does not prescribe a postal address. A tax number identifies a person in Portugal more precisely than a street does — it is unique, it is verifiable, and it does not change when somebody moves. Contact is by the email address above, and notices under this DPA and under the Terms of Service are given by email, which is the channel both Parties actually read.

The honest limit, stated because a controller is entitled to weigh it: this deviates from the template's field, and a controller whose own policy requires a registered address from every processor will need one. The processor will provide it on request, and it appears in a future version of this document once the establishment is registered.

Practical note — the supervisory authority. The Decision's Annex I for these Article 28 Clauses does not have a supervisory-authority field (that is a feature of the transfer Clauses in Decision (EU) 2021/914). For information: the processor's own supervisory authority follows its place of establishment, which for a Portuguese establishment is the Comissão Nacional de Proteção de Dados (CNPD). The controller's supervisory authority is its own.

Annex II — Description of the processing

Categories of Data Subjects whose personal data is processed

Determined by the Controller. The Processor does not select them and does not inspect the data. Given the nature of the Service, they are typically:

• the Controller's customers, users and prospects;
• where the Controller is itself a Processor for its own clients, those clients' customers, users and prospects (the "End Clients'" Data Subjects);
• visitors to and users of websites and applications operated by the Controller or its End Clients;
• the Controller's own personnel, where the Controller ingests data about them.

Separately, and as Controller rather than Processor, Event Horizon holds account data about the Customer's own users — see the Privacy Policy.

Categories of personal data processed

Determined by the Controller, through the tables and pipelines it defines. Typically:

• identifiers and pseudonymous identifiers (customer IDs, account IDs, user IDs, cookie and device identifiers);
• contact details (name, email address, telephone number, postal address) where the Controller chooses to ingest them;
• online identifiers and technical data (IP address, user agent, referrer, session identifiers);
• behavioural and event data (page views, product events, timestamps, campaign attribution);
• commercial and transactional data (orders, order values, subscriptions, plan and status fields);
• any other field the Controller chooses to ingest.

Additionally, the Processor stores connection credentials that the Controller registers so that its pipelines can read from the Controller's own systems. These are encrypted at rest (Annex III).

Sensitive data processed

None is permitted. Clause 7.5 and clause 5.3 of the Terms of Service prohibit special categories of personal data under Article 9(1) GDPR, personal data relating to criminal convictions and offences under Article 10 GDPR, cardholder data, and health data. The Controller undertakes not to submit them.

Restrictions and safeguards applicable if such data reached the Service despite the prohibition: the measures in Annex III apply in full; the Parties notify each other without undue delay under clause 7.5; the Controller removes the data; and the Processor may suspend the affected pipeline or account and may delete the data.

Nature of the processing

Collection by ingestion from sources the Controller configures; transmission; structuring; storage; organisation and aggregation; retrieval; consultation and display in dashboards, exports and reports; disclosure by transmission to recipients the Controller designates, including through share links and embedded dashboards the Controller publishes; restriction; erasure.

Purpose(s) of the processing

To provide the Event Horizon analytics platform to the Controller in accordance with the Terms of Service and the Controller's configuration, and for no other purpose.

Duration of the processing

For the duration of the contract, plus the deletion periods set out in Clause 10(d). Within that period, data in the Controller's tables is retained for the retention window the Controller configures per table, after which it is deleted automatically.

For processing by Sub-processors, the subject matter, nature and duration of the processing

As set out in Annex IV.

Frequency of the transfer

Continuous, for as long as the Controller's pipelines are running.

Annex III — Technical and organisational measures, including technical and organisational measures to ensure the security of the data

These are the measures the Processor applies. They are maintained against the system as built, and they may be updated provided that the overall level of security is not decreased (the practical note to Clause 7.4).

1. Pseudonymisation and encryption of personal data

• In transit. All connections to the Service are over TLS, with certificates issued and renewed automatically. HTTP Strict Transport Security is enforced, with includeSubDomains. Certificates for customer-supplied hostnames are issued only after the platform has confirmed that the hostname belongs to a customer and that its owner published a verification record.
• At rest. User passwords are stored only as scrypt hashes with a memory-hard work factor, never in reversible form. The credentials a Controller registers for its own data sources are encrypted with AES-256-GCM under a key-encryption key held in the environment and never in the database; the key is versioned so it can be rotated without losing access to existing records. Two-factor secrets and recovery codes are stored in the same protected manner.
• Pseudonymisation. Dimension values are stored as surrogate identifiers in the fact tables and resolved to their labels through a per-tenant registry at read time.
• Storage-layer encryption, stated accurately. Off-site backup objects are encrypted at rest by the storage Sub-processor. The hosting Sub-processor does not provide encryption at rest by default -- it is documented as the customer's own responsibility -- and the volumes carrying the databases and the warehouse are not encrypted at the disk layer today. What protects that data at rest is the application-level encryption listed above, the access control in section 2, and the physical security of the facility. This is recorded as a declared limit in section 8 rather than described as a measure that exists.

2. Confidentiality: access control and tenant isolation

• Every warehouse read passes through a single point that asserts, fail-closed, that every object named in the query belongs to the authenticated tenant. The identity of the tenant is a required argument: code that cannot say whom it is working for does not compile.
• Physical separation by tenant. Each Controller's fact tables and its dimension registry are distinct database objects whose names carry the tenant's identifier. A missing tenant identifier raises rather than producing an unscoped name.
• Least-privilege database identities. Separate accounts for schema ownership, for reading and for writing. The read identity used by the query path holds SELECT and nothing else and is denied access to the database engine's introspection tables. The ingestion identity may write but may not change schemas.
• No user-supplied SQL. The query surface is a structured builder — filters, aggregations, drill-through. The free-text SQL mode was removed, which eliminated the class of risk rather than mitigating it.
• Role-based access control within a tenant, with per-user roles and permissions, and row-level scoping so that a user can be restricted to a subset of rows.
• Personnel access. Administrative access to production is limited to one named individual, by key-based authentication, with no shared accounts and no password authentication. Personnel are bound by confidentiality. The number is stated rather than rounded up: it is the strongest possible statement about the size of the group that can reach the data, and the weakest possible one about what happens if that person is unavailable. Both readings are correct, and the second is recorded as a declared limit in section 8.

3. Authentication and session security

• Two-factor authentication (TOTP) with recovery codes, available to every account.
• Session limits: an absolute maximum of 12 hours from sign-in, and an idle timeout of 2 hours measured on genuine user activity — background polling by the application does not count as activity, and the decision about what counts is made by the server, not by a header the client sends.
• Re-authentication ("step-up") for sensitive actions, valid for 15 minutes, applying to a declared list of operations rather than being sprinkled through the code.
• Global session revocation. Rotating a per-user security stamp invalidates every session of that user immediately; this happens automatically on password reset.
• Rate limiting on authentication endpoints, including the re-authentication endpoint, keyed on the client address.
• Session cookies are HttpOnly, Secure in production and SameSite=Lax; session state is held server-side, not in the cookie.
• CSRF protection on state-changing requests, X-Frame-Options: DENY, and X-Content-Type-Options: nosniff.

4. Integrity and availability

• Daily logical backups of the document store and of the analytical warehouse, retained 14 days on the primary host and 7 days off-site with a different provider, in a different account. The off-site access token is scoped to the objects of a single bucket and cannot describe or create buckets.
• A restore drill exists and passes. It restores into draft names beside the live data, counts what came out, and cleans up after itself.
• Retention. Each table carries a retention period set by the Controller, applied by the database engine, so old data is deleted without anyone having to remember.
• Data is not silently discarded. When a Controller exceeds a volume ceiling its pipelines are stopped and incoming batches are routed to a dead-letter store from which they can be replayed, rather than being dropped.
• Health endpoints verify a round trip to each datastore, and a deployment is not accepted until they answer.
• Container log volumes are capped and disk usage is reported by the daily backup with a warning threshold.

5. Testing, assessing and evaluating effectiveness

• Recurring authorised adversarial security reviews across all four repositories of the platform. Findings are fixed and each fix is held in place by a regression test. Reports are dated and reproducible and are available to the Controller under Clause 7.6.
• A tenancy audit verifying that no path exists from one tenant to another's data.
• Automated test suites — more than 850 in the application backend and 777 in the ingestion engine — together with type checking and linting, run inside the container build, so an image cannot be produced unless they have passed. There is no flag that skips them.
• Security-relevant behaviour is tested by asserting the refusal, not only the success path.

6. Logging and traceability

• Per-hop execution records for every pipeline run, retained in the analytical store.
• Query history per user.
• Sign-in and account-security events.
• An append-only record of each acceptance of these documents, holding the versions accepted, the time, the IP address, the user agent and a cryptographic hash of the accepted text. It has no update path and no delete path.

7. Measures for assisting the Controller

• Data subject rights (Clause 8): the Controller can search, export, correct and delete records itself through the Service, and can set retention per table. Where a request cannot be satisfied through the Service, the Processor assists on request.
• Breach notification (Clause 9): a named contact point, notification within 48 hours of becoming aware, and the information listed in Clause 9.2 as it becomes available.
• Impact assessments (Article 35): this DPA and its Annexes are drafted to be usable as the processor-side input to a DPIA; further information is provided on request.
• Return and deletion (Clause 10(d)): export through the Service at any time, and deletion on the schedule stated in Clause 10.

8. Limits of these measures, declared

Stating these is a contractual choice: a Controller is entitled to assess the risk on accurate information, and a measure claimed but not held is worse than one that was never claimed.

• Tenant isolation is enforced by the application, not by the database engine. The controls in section 2 are layered and fail closed, but the read identity holds SELECT across the warehouse; the final barrier is code, not a database grant. Per-tenant database roles were assessed and rejected as unworkable at the intended scale.
• The Processor holds no SOC 2 or ISO 27001 certification, and does not claim equivalence. What it offers instead is set out in Clause 7.6.
• Segregation of duties is limited. The Processor is a small organisation; the same personnel may write, review and deploy code. Compensating controls are the automated gates in section 5.
• Off-site backups are not encrypted by the Processor before upload. They rely on the storage Sub-processor's encryption at rest, and on an access token scoped to a single bucket.
• There is no 24/7 monitoring or paging. Health checks and logs exist and are reviewed; they are not an alerting system, and out-of-hours response is best-effort.
• The Processor cannot prevent prohibited data from being ingested — see Clause 7.5.
• No contractual uptime commitment is given at present; see clause 9 of the Terms of Service.
• The volumes carrying the databases and the warehouse are not encrypted at rest. The hosting Sub-processor does not provide disk encryption by default and documents it as the customer's own responsibility. The consequence is stated plainly: an attacker with physical possession of a disk, or the hosting Sub-processor itself, could read the data at rest without defeating any cryptography, save for the specific fields listed in section 1 as encrypted by the application. Closing this means encrypting the volumes at the operating-system layer, which is planned and not done.
• Key-person dependency. The single individual in section 2 is also the only person who can restore the Service from backups. There is no second operator today.

Annex IV — List of sub-processors

Clause 7.7(a) OPTION 2 was selected, so this Annex is the agreed list from which the processor is generally authorised to engage sub-processors. Changes to it follow Clause 7.7(a): 30 days' written notice, and a right to object.

The transfer mechanism column was verified against each provider's own published documentation on 23 August 2026. Where a mechanism requires an act by the processor that has not yet been performed, the cell says so instead of implying otherwise.

Onward sub-processing by these sub-processors

Stated because the controller is entitled to know where the chain ends, not only where it starts:

• Postmark hosts its primary data and servers at Deft (a datacentre outside Chicago) and at Amazon Web Services, both in the United States.
• Contabo and Cloudflare operate their own facilities for the services used here.
• Stripe publishes its own sub-processor list, which includes Amazon Web Services, Google and Twilio, and identity-verification providers such as LexisNexis and Ekata. That list is Stripe's to maintain and is not reproduced here; the controller is directed to it, and the processor is answerable under Clause 7.7(d) for Stripe's performance either way.

Not sub-processors, listed to avoid the question being asked

• Let's Encrypt (Internet Security Research Group) issues the TLS certificates. No personal data is transferred to it; certificate issuance discloses hostnames, which appear in public Certificate Transparency logs.
• Google, GitHub, Facebook and X, where a user chooses to sign in with an existing account. Each is an independent controller of its own account data; the choice is the user's, and Event Horizon receives only the identifier and email address needed to authenticate.
• The controller's own data sources. Event Horizon connects out to systems the controller configures. Those systems are the controller's, or its own suppliers', and are not Event Horizon's sub-processors.

Authorised from the outset, and why they are on the list before they process anything

The two below are on the agreed list from the first version of this Annex, and the controller's general authorisation under Clause 7.7(a) covers them from the moment it accepts this DPA.

That is deliberate and it is stated rather than left to be noticed. A sub-processor added after a controller has accepted requires 30 days' notice and carries a right to object — which is correct protection, and which would also mean the processor cannot begin charging for a month. Naming them now, before either processes anything, gives the controller the same information at a time when it can act on it, and costs the processor nothing. Nothing here is a commitment to engage them, and neither receives any personal data until the corresponding function goes live.

A note on the Data Privacy Framework, written down rather than assumed

Two of the three mechanisms above rest, wholly or partly, on the EU-U.S. Data Privacy Framework. Its standing on the date of this version: the European General Court dismissed the first annulment action against the adequacy decision on 3 September 2025 (Latombe v Commission), and that judgment is under appeal before the Court of Justice (Case C-703/25 P), with no hearing date announced as at July 2026. The Framework is therefore valid law today and is being litigated.

This is why the mechanism that matters most — the hosting sub-processor, which holds all Customer Data — is the SCC route rather than the DPF route, and why the two DPF-based entries above are with providers that also carry SCCs in their own DPAs. If the adequacy decision were annulled on appeal, the transfers described here would fall back on standard contractual clauses rather than having no basis at all.