Data Processing Agreement

This DPA forms part of the Terms of Service between JJ Online GmbH and you (the customer) and is incorporated into the Terms of Service under § 17.2. Where this DPA and the Terms of Service diverge in respect of Personal Data processing on the customer's behalf, this DPA controls.

Last updated: 27 May 2026 — Version 1.1

Preamble

Parties

The Processor:

JJ Online GmbH Schönhauser Allee 163, 10435 Berlin, Germany HRB 235074 B (Amtsgericht Berlin-Charlottenburg) USt-IdNr. DE351060880 Represented by: Andrius Gecius, Managing Director Email: admin@uptimia.com (hereinafter "JJ Online", "we", "us", or "the Processor")

The Controller:

You — the natural or legal person identified as the account holder on the Uptimia subscription, processing Personal Data through the Uptimia service operated by JJ Online. (hereinafter "you", "the Customer", or "the Controller")

JJ Online and the Controller are collectively referred to as the "Parties" and individually as a "Party".

Recitals

(A) JJ Online operates Uptimia, a software-as-a-service observability platform that provides website availability monitoring, page-speed monitoring, real user monitoring (RUM), transaction monitoring, domain and SSL expiry monitoring, and alerting services (the "Service", as further defined in the Terms of Service at https://uptimia.com/terms).

(B) In the course of using the Service, the Controller causes JJ Online to process certain Personal Data on the Controller's behalf within the meaning of Art. 4 (8) and Art. 28 of Regulation (EU) 2016/679 (the "GDPR") and, where applicable, the United Kingdom General Data Protection Regulation as it forms part of the law of England and Wales, Scotland and Northern Ireland (the "UK GDPR") and the Swiss Federal Act on Data Protection (the "FADP").

(C) The Parties wish to establish their respective rights and obligations under Art. 28 GDPR (and equivalent provisions of the UK GDPR and the FADP) in respect of this processing.

(D) This DPA is incorporated by reference into the Terms of Service and applies automatically upon Controller's acceptance of the Terms of Service. No separate signature is required; in the event the Controller requires a counter-signed version, the Controller may request one at admin@uptimia.com.

Definitions

Unless otherwise defined in this DPA, terms used in this DPA have the meaning given to them in the GDPR. In addition:

"Data Protection Laws" means the GDPR, the UK GDPR, the FADP, the German Federal Data Protection Act (Bundesdatenschutzgesetz — BDSG), the German Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz (TDDDG), and any other applicable data protection or privacy law as in force from time to time. (The German Digitale-Dienste-Gesetz (DDG), which implements the EU Digital Services Act, is platform-regulation law and is not part of this Data Protection Laws definition; any DDG obligation referenced in this DPA is referenced specifically by section where it applies.)
"Customer Personal Data" means personal data processed by JJ Online on the Controller's behalf in connection with the Service.
"Sub-processor" means a third party that JJ Online engages to process Customer Personal Data on the Controller's behalf within the meaning of Art. 28 (4) GDPR. The current list of Sub-processors is set out in Annex C of this DPA; the Annex is the canonical source.
"Standard Contractual Clauses" or "SCCs" means the standard contractual clauses for the transfer of personal data to third countries adopted by the European Commission in Implementing Decision (EU) 2021/914 of 4 June 2021.
"EU-US Data Privacy Framework" or "DPF" means the data protection framework certified pursuant to Commission Implementing Decision (EU) 2023/1795 of 10 July 2023.
"UK Addendum" means the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses issued by the UK Information Commissioner's Office and laid before Parliament on 2 February 2022.
"IDTA" means the International Data Transfer Agreement issued by the UK Information Commissioner's Office and laid before Parliament on 2 February 2022, in standalone form (i.e., not as the Addendum to the Commission SCCs).

1. Subject matter and scope

1.1. This DPA governs JJ Online's processing of Customer Personal Data on the Controller's behalf in connection with the Service. The detailed subject matter, nature, purpose, duration, types of Customer Personal Data and categories of Data Subjects are set out in Annex A.

1.2. The Controller is the controller and JJ Online is the processor of Customer Personal Data within the meaning of Art. 4 GDPR. JJ Online remains an independent controller for Personal Data it processes for its own purposes (account management, billing, security, product analytics) — that processing is governed by the Uptimia Privacy Policy, not by this DPA.

1.3. This DPA does not apply to:

(a) JJ Online's processing of the Controller's own account-holder data (name, email, billing details), for which JJ Online is the controller;

(b) Personal data the Controller chooses to transmit to third-party services through the Service (for example, alert payloads routed to customer-configured channels such as Slack, Discord, Twilio SMS, Meta WhatsApp Cloud, PagerDuty, Microsoft Teams, Atlassian Statuspage, X/Twitter, Telegram, or generic webhooks) — for those onward transmissions JJ Online acts on the Controller's documented instruction, and the Controller is responsible for the lawfulness of the onward transfer under Arts. 6 and 44–49 GDPR.

Customer freedom of choice — alert channels. The Controller is free to choose any alert channel offered in Annex C.5. The act of configuring a channel in the Controller's account constitutes the Controller's documented instruction under Art. 28 (3)(a) GDPR for the routing of alert payloads to that channel. The Controller bears the Art. 6 and Art. 44–49 GDPR lawfulness analysis for the resulting transfer (including, where the channel destination is outside the EEA, the Art. 46 / 49 transfer-mechanism analysis disclosed for that channel in Annex C.5). JJ Online's role is limited to (i) offering the channel as an option in the Service, (ii) executing the configured routing on the Controller's instruction, and (iii) disclosing in Annex C.5 the transfer mechanism on which JJ Online relies, or on which the Controller must rely under § 10.5, for each channel. JJ Online does not pre-vet a Controller's particular legitimate-interest / consent / contract-necessity basis for using a given channel.

Restricted Channels — acknowledged activation. A subset of the channels in Annex C.5 is designated Restricted Channels (currently: Telegram and X Corp — see Annex C.5 for the current list and the per-channel reason for the designation). Restricted Channels are not part of the default alert-channel menu. Activation of a Restricted Channel requires the Controller (acting through an authorised user of the Controller's account) to confirm an in-product acknowledgement of the per-channel transfer posture disclosed in Annex C.5. JJ Online retains a timestamped record of each acknowledgement (account ID, user identifier, channel, Annex C.5 disclosure version, acknowledgement timestamp) as part of the Art. 28 (3)(a) instruction record under § 14.1 (e) and produces it on supervisory-authority or Controller request. The acknowledgement is required once per channel per account; deactivating and re-activating a Restricted Channel requires a fresh acknowledgement against the then-current Annex C.5 disclosure version.

Two-tier acknowledgement standard. Restricted Channels carry one of two acknowledgement tiers depending on the legal posture of the channel, set out in Annex C.5.2:

Tier 1 — Standard Restricted Channel acknowledgement (used where the channel has an operative Art. 46 GDPR transfer mechanism with elevated reliance on SCC + supplementary-measures fallback owing to volatility of any complementary mechanism — e.g. X Corp). The in-product acknowledgement text requires the Controller to confirm awareness of (i) the operative transfer mechanism, (ii) any volatility of complementary mechanisms, and (iii) the Controller's own Art. 44–49 GDPR analysis for the resulting transfer.

Tier 2 — Elevated-risk Restricted Channel acknowledgement (used where the channel has no available Art. 46 GDPR transfer mechanism applicable to the deployment, and the only candidate transfer basis is an Art. 49 GDPR derogation that does not comfortably fit the channel's actual use pattern — e.g. Telegram bot alerting under § 10.5 and Annex C.5.2). The in-product acknowledgement text requires the Controller to positively confirm each of the following on activation, in language no less explicit than:

"I understand that Telegram bot alerting [or the equivalent named channel] does not have an available Art. 46 GDPR transfer mechanism (no adequacy decision for the recipient country; no Commission Standard Contractual Clauses available from the channel operator to bot operators).

I understand that JJ Online does not itself assert any Art. 49 GDPR derogation for the transfer and that EDPB Guidelines 2/2018 on derogations of Art. 49 under Regulation 2016/679 read the Art. 49 derogations narrowly, in particular that:

— Art. 49 (1)(a) requires explicit consent of each affected Data Subject, informed of the specific risks (including absence of an Art. 46 mechanism and absence of an adequacy decision) — which is unlikely to be available for routine outage alerting routed to my operations team;

— Art. 49 (1)(b)–(c) require that the transfer is occasional and non-repetitive and that the transfer is necessary for performance of, or pre-contractual measures at the Data Subject's request relating to, a contract with the Data Subject — which routine recurring outage alerting is structurally unlikely to satisfy;

— Art. 49 (1)(d)–(g) (important reasons of public interest, legal claims, vital interests, public register) are not a comfortable fit for the use case.

I have independently evaluated the lawfulness of the resulting transfer under Arts. 44–49 GDPR for my own organisation's particular circumstances, including any cumulative-data-subject and frequency considerations. I accept that my evaluation, and not JJ Online's offering of the channel, is the basis on which the transfer is made.

I accept the supervisory-authority risk that a competent supervisory authority may find this transfer to be unlawful, and I accept any consequence of such a finding, including the obligation to discontinue the channel and to notify affected Data Subjects where applicable.

I am aware that Annex C.5.1 contains alternative alert channels with operative Art. 46 GDPR transfer mechanisms (DPF or SCCs with supplementary measures, as applicable) and that those channels are available to me as a substitute."

The Tier 2 acknowledgement text must be displayed in full on activation and cannot be collapsed or pre-checked. The Controller's authorised user must positively click through each of the bracketed elements above (or an interaction equivalent of equal substance). Where a Restricted Channel is moved from Tier 1 to Tier 2 in Annex C.5.2 — for example, because a previously available Art. 46 mechanism becomes unavailable — the move is a presumptive § 20.4 (ii) material change (lawful-transfer mechanism), and active acknowledgements collected against the previous Tier 1 text are treated as expired; a fresh Tier 2 acknowledgement is required to continue using the channel.

2. Duration

This DPA enters into force on the date the Controller accepts the Terms of Service and continues for the duration of the Controller's subscription to the Service plus, where applicable, the residual retention periods set out in § 15 (End-of-contract treatment of data).

3. Nature and purpose of processing

JJ Online processes Customer Personal Data on the Controller's behalf solely for the purpose of providing the Service and the related operational functions (alerting, dashboards, reports, exports, support). The detailed list of processing activities is set out in Annex A.

4. Type of Personal Data and categories of Data Subjects

The types of Customer Personal Data and the categories of Data Subjects are set out in Annex A. The Controller acknowledges that JJ Online cannot independently verify the categories of data that may appear in monitored resource responses (e.g., authenticated HTTP check response bodies, transaction monitoring screenshots) — the Controller is responsible for the lawfulness of the data they cause to be captured and processed by the Service.

5. Roles and responsibilities

5.1. Controller responsibilities. The Controller:

(a) is solely responsible for the lawfulness of the processing under Art. 6 GDPR and, where consent is required, for obtaining valid consent under Art. 7 GDPR — including consent from end users whose data is captured by the RUM script, any client-side SDK, or any equivalent in-browser component deployed by the Controller on the Controller's own websites or applications. The Controller further warrants that, where the RUM script, a client-side SDK, or any equivalent in-browser component stores information on, or accesses information already stored on, the terminal equipment of an end user (e.g., reads or writes cookies, localStorage, or comparable identifiers in the end user's browser), the Controller has obtained the consent required by § 25 Abs. 1 TDDDG (Germany), Art. 5 (3) of Directive 2002/58/EC (ePrivacy Directive) as transposed by the relevant Member State, and any equivalent national rule applicable to the end user (such as the UK PECR for UK end users), in addition to any GDPR Art. 6 lawful basis required for the underlying processing. JJ Online is not the controller in respect of those § 25 TDDDG / ePrivacy / PECR consents and has no operational visibility into the Controller's consent-management system; the parties' Art. 28 GDPR allocation in this DPA is concluded on the basis of this warranty;

(b) is solely responsible for providing transparent information to Data Subjects under Arts. 13 and 14 GDPR in respect of the processing carried out through the Service;

(c) is responsible for ensuring that the Service is used in accordance with all applicable Data Protection Laws and that any onward transfer of Personal Data through the Service (for example, by configuring alert delivery to a US-based notification channel) is itself lawful;

(d) warrants that the Controller has the legal right to provide JJ Online with the Customer Personal Data and to instruct JJ Online to process it as set out in this DPA.

5.2. Processor responsibilities. JJ Online:

(a) processes Customer Personal Data only on documented instructions from the Controller as set out in § 6;

(b) implements the technical and organisational measures set out in Annex B;

(d) assists the Controller as set out in § 8, § 9, § 11, and § 12;

(e) returns or deletes Customer Personal Data as set out in § 15.

5.3. Joint-controllership fallback for the collection phase (C-40/17 Fashion ID). The parties record the Art. 28 GDPR allocation in this DPA on the assessment that, in respect of the RUM script and any equivalent in-browser component deployed by the Controller on the Controller's own websites or applications, (i) the Controller alone determines the purposes of the collection (the Controller's monitoring of the Controller's own visitors) and (ii) JJ Online's role is limited to the non-essential (technical) means of collection within the meaning of EDPB Guidelines 07/2020 ¶ 38 and as further set out at § 6.2, with the Controller retaining authority over the essential means (the URLs on which the script is deployed, the visitors targeted, the retention period via the Service plan tier, and the lawful basis / § 25 TDDDG / ePrivacy / PECR consent under § 5.1 (a)).

The parties acknowledge the risk that a supervisory authority or court could nevertheless characterise the parties as joint controllers within the meaning of Art. 26 GDPR for the collection phase only, on the C-40/17 Fashion ID line of authority, on the ground that JJ Online's distribution of the RUM script materially co-determines the means of collection. If a competent supervisory authority issues a binding decision, or a court of competent jurisdiction issues a binding judgment, treating the parties as joint controllers for the collection phase in respect of the RUM script or an equivalent in-browser component (a "Joint-Controllership Determination"), then:

(a) the parties will, within thirty (30) calendar days of the Joint-Controllership Determination becoming binding on at least one of them, enter into an Art. 26 (1) GDPR arrangement that mirrors the substantive allocation in § 5.1 (a) and § 6.2 of this DPA — i.e., the Controller bears responsibility for the lawful basis, the Arts. 13 / 14 GDPR information of end users, and the § 25 TDDDG / ePrivacy / PECR consent under § 5.1 (a); JJ Online bears responsibility for the technical configuration of the script (event taxonomy, browser-information surface, /24 IPv4 and /48 IPv6 truncation prior to storage, aggregation logic, EU-located storage routing) as set out at § 6.2 and Annex B;

(b) JJ Online will publish, and keep current, an Art. 26 (2) GDPR "essence" notice describing the above allocation at https://uptimia.com/legal/joint-controllership; the Controller may, but is not required to, reproduce or link to this essence on the Controller's own end-user-facing privacy notice;

(c) Data Subjects retain the right under Art. 26 (3) GDPR to exercise their rights under the GDPR in respect of, and against, each of the parties — the parties will cooperate to route a Data Subject request received by one of them to the other where the request falls within the other's allocated responsibility under (a);

(d) the Joint-Controllership Determination affects only the collection phase in respect of the script; the storage, processing, retention, and disclosure of the collected RUM event payloads remain processor activity by JJ Online on the Controller's instruction under this DPA. § 6.1 instruction architecture, § 10 sub-processor governance, § 11 Data Subject assistance, § 12 breach notification, § 14 audit, and § 15 deletion-on-termination continue to apply to the post-collection phase.

This § 5.3 is a fallback allocation triggered only on a Joint-Controllership Determination as defined above. Until such a Determination, the § 5.1 (a) and § 6.2 allocations stand without recharacterisation, and the parties do not by entering into this DPA concede that joint controllership applies to the collection phase or to any other phase.

6. Processing on documented instructions

6.1. JJ Online processes Customer Personal Data only on documented instructions from the Controller. The Controller's instructions are set out in:

(a) this DPA, including its Annexes;

(b) the Terms of Service;

(c) the configuration settings the Controller selects in the Service — including, but not limited to, the deployment of the RUM script on URLs the Controller selects, the configuration of monitors and authenticated checks, the configuration of transaction-monitoring journeys, the operation of a public status page that accepts visitor subscriptions, the configuration of alert channels and recipients, and the Service plan tier selected by the Controller (which determines the retention period applicable under Annex A.9 of this DPA within the per-category ceilings set out there);

(d) any subsequent written instructions issued by the Controller to admin@uptimia.com that JJ Online expressly accepts in writing; and

(e) the Processing Instructions Summary the Controller may request at any time from privacy@uptimia.com. The Summary is generated by JJ Online from the Controller's account state at the time of the request and sets out, for the Controller's specific account: the active monitor types, the resources the Controller has chosen to monitor, the Service plan tier selected (and the retention periods applicable to the Controller under Annex A.9 of this DPA as a result), the alert channels the Controller has activated (and therefore the Sub-processors under Annex C.5 active on the Controller's account), the EU storage region applicable to the Controller's data, and any subsequent written instructions accepted under (d). JJ Online returns the Summary within five (5) business days of receipt. The Summary, read together with this DPA, constitutes the Controller's documented instructions under Art. 28 (3)(a) GDPR for the purposes of demonstrating compliance under Art. 5 (2). The structure of the Summary is set out in Annex A.8.

A counter-signed counterpart of this DPA with the Summary attached as Annex A.8 is available on request at no fee for any Controller whose procurement, audit, or regulatory process requires it. Request the counterpart at privacy@uptimia.com.

6.2. Essential / non-essential means split (EDPB Guidelines 07/2020 ¶ 38). The Controller determines the essential means of processing — the categories of data, the categories of Data Subjects, the duration of retention, and the recipients of the data — through the instructions enumerated at § 6.1 (a)–(d). JJ Online determines, in its capacity as processor, the non-essential (technical) means — including the algorithm used for the truncation of visitor IP addresses (/24 IPv4 and /48 IPv6) prior to storage, the aggregation logic that keeps RUM events out of per-beacon storage, the choice of EU-located storage infrastructure, the encryption scheme applied at the column level for Controller-supplied credentials, the automatic recipient-region routing logic for transactional email between the AWS SES eu-central-1 (Frankfurt) and us-east-1 (Virginia) endpoints (disclosed at § 10.2 (b) and Annex B.1), and the ephemeral-processing property of the probe layer. The non-essential means JJ Online determines constitute Art. 32 GDPR technical and organisational measures and do not displace the Controller's authority over the essential means.

6.3. JJ Online informs the Controller without undue delay if it believes that an instruction infringes Data Protection Laws.

6.4. No use of Customer Personal Data for JJ Online's own purposes or third-party commercial purposes. JJ Online does not process Customer Personal Data for any purpose other than the performance of the Service for the Controller. Without limiting the foregoing, JJ Online:

(a) does not use Customer Personal Data — whether in identified, pseudonymised, hashed, or aggregated form — to train, fine-tune, evaluate, benchmark, or otherwise develop any artificial-intelligence, machine-learning, or large-language model, including the construction of model weights, embeddings, retrieval-augmented-generation indexes, evaluation datasets, or any other derived dataset;

(b) does not use Customer Personal Data for advertising, profiling, look-alike audience-building, ad targeting, or audience-segment enrichment;

(c) does not sell, sub-license, syndicate, or otherwise make Customer Personal Data available to data brokers, analytics networks, advertising networks, or any other third party for that third party's own purposes;

(d) does not reuse Customer Personal Data for any other secondary purpose that is not strictly necessary to deliver the Service to the Controller.

JJ Online's Sub-processors are bound to equivalent prohibitions under their respective Art. 28 (4) GDPR contracts (see § 9 and Annex C); the prohibitions in this § 6.4 form part of those flow-down obligations.

6.5. JJ Online may process Customer Personal Data outside the scope of § 6.4 only where required to do so by Union or Member State law to which JJ Online is subject. In that case, JJ Online informs the Controller of that legal requirement before processing, unless the law prohibits such notification on important grounds of public interest.

6.6. AI-assisted features — EU AI Act forward-looking commitment. The Service does not currently include AI-assisted features within the meaning of Regulation (EU) 2024/1689 (the "EU AI Act"); the § 6.4 (a) prohibition on training, fine-tuning, evaluating, benchmarking, or otherwise developing artificial-intelligence or machine-learning models with Customer Personal Data continues to apply. Where JJ Online introduces an AI-assisted feature into the Service in the future (for example, anomaly detection, root-cause suggestions, alert summarisation, or incident-triage assistance), JJ Online will, in addition to the § 6.4 (a) prohibition continuing to apply:

(a) classify the feature under the EU AI Act risk-classification framework (prohibited practice / high-risk / limited-risk / minimal-risk) and disclose the classification to the Controller as part of the § 20.4 update;

(b) provide the transparency information required by Art. 50 EU AI Act for limited-risk systems (and any corresponding higher-risk regime where applicable), in a form that the Controller can pass through to its own Data Subjects where relevant;

(c) disclose any provider / deployer split between JJ Online and the Controller for the feature, taking into account that JJ Online is the deployer of any model embedded in the Service while the Controller is the deployer of any feature it activates in respect of its own Data Subjects; and

(d) update this DPA under § 20.4 to reflect any AI-Act-driven changes to the processing, including (where applicable) updates to Annex A, Annex B, Annex C, and the § 20.4 (i)–(xi) presumptive-materiality list.

This § 6.6 is forward-looking and does not authorise JJ Online to introduce AI-assisted features without the § 20.4 update process; it sets out the substance of that update so the Controller can anticipate the disclosures that will follow.

7. Confidentiality

7.1. JJ Online ensures that persons authorised to process Customer Personal Data are bound by an obligation of confidentiality, whether by contract or other appropriate means. The binding rests on the contractual obligations in their employment or contractor agreements, supplemented by training.

7.2. JJ Online restricts access to Customer Personal Data to personnel who require such access to perform their duties under the Service.

7.3. Personnel instruction binding (Art. 32 (4) GDPR). JJ Online takes steps to ensure that any natural person acting under JJ Online's authority who has access to Customer Personal Data does not process that data except on documented instructions from the Controller (as set out in § 6.1), unless that person is required to process the data otherwise by Union or Member State law. Where Union or Member State law requires such processing otherwise than on the Controller's instructions, JJ Online informs the person concerned of the obligation and, in the same circumstances, informs the Controller as set out at § 6.5, unless that law prohibits such notification on important grounds of public interest. The steps JJ Online takes to give effect to this § 7.3 include, without limitation, (a) the confidentiality binding at § 7.1, (b) the least-privilege access restriction at § 7.2 and Annex B.1, (c) the personnel measures at Annex B.7 (confidentiality obligations and background screening), and (d) ongoing data-protection training. This § 7.3 is set out separately from § 7.1 and § 7.2 in order to give explicit effect to Art. 32 (4) GDPR alongside the Art. 28 (3) (b) GDPR confidentiality duty at § 7.1.

8. Security of processing (Art. 32 GDPR)

8.1. JJ Online implements appropriate technical and organisational measures to ensure a level of security appropriate to the risk, as set out in Annex B. These measures include, in particular:

(a) pseudonymisation and encryption of Customer Personal Data where appropriate;

(b) measures to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;

(c) the ability to restore the availability of and access to Customer Personal Data in a timely manner in the event of a physical or technical incident;

(d) a process for regularly testing, assessing and evaluating the effectiveness of those measures.

8.2. JJ Online assesses the appropriate level of security taking account of the risks presented by processing — in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to Customer Personal Data.

8.3. JJ Online may update Annex B from time to time to reflect changes in the state of the art, the costs of implementation, the nature, scope, context and purposes of processing, or new identified risks. JJ Online notifies the Controller of any material reduction in the measures set out in Annex B before the change takes effect.

9. Sub-processor engagement (Art. 28 (2) GDPR)

9.1. General authorisation. The Controller grants JJ Online general written authorisation to engage Sub-processors for the processing of Customer Personal Data, subject to the conditions set out in this § 9.

9.2. Current Sub-processors. The current list of Sub-processors engaged by JJ Online is set out in Annex C, which is the canonical list maintained as part of this DPA. Updates to Annex C are republished as part of an updated version of this DPA and are notified to the Controller as set out at § 9.3.

9.3. Notification of changes. JJ Online notifies the Controller at least 30 calendar days in advance of any intended addition or replacement of a Sub-processor. The notification is delivered through two parallel channels:

(a) Primary channel — email to the address registered to the Controller's Uptimia account; and

(b) Secondary channel — in-product notification displayed in the Controller's Uptimia dashboard (e.g. a persistent banner, notification-centre entry, or equivalent in-product surface) which remains visible to administrator users of the Controller's account until acknowledged.

Both channels carry the same notification content and the same effective date. The 30 calendar day objection period under § 9.4 starts to run on the later of (i) the date the email was sent under (a) and (ii) the date the in-product notification first became visible to an administrator user of the Controller's account; if email delivery to the registered address fails (e.g. hard bounce, mailbox-full reject) and JJ Online cannot reach the Controller through a known alternative contact, the in-product surface controls. Annex C of the then-current version of this DPA is updated in parallel to reflect the change.

The notification obligation extends to changes in a Sub-processor's sub-sub-processing chain that introduce a new processing location (e.g. a new third country) or a new category of recipient (e.g. a new corporate group outside the existing Sub-processor's group); it does not extend to purely internal reassignments of processing within a Sub-processor's corporate group that do not introduce a new processing location or a new category of recipient and that do not materially change the lawful-transfer mechanism applied.

9.4. Right to object. The Controller has the right to object to the intended change on reasonable grounds related to the protection of Customer Personal Data within 14 days of receiving the notification under § 9.3 (with the 14-day clock anchored as set out in § 9.3). If the Controller raises a reasoned objection, the Parties cooperate in good faith to identify a solution. The Controller may, at its option, elect any of the following remedies:

(a) Termination with pro-rata refund. The Controller may terminate the affected portion of the Service in accordance with the Terms of Service § 23 before the change takes effect, with pro-rata refund of any pre-paid fees attributable to the unused portion of the affected period;

(b) Alternative Sub-processor. The Controller may require JJ Online to engage a different Sub-processor in place of the proposed Sub-processor. JJ Online will not refuse such a request where an alternative is available within the same functional category of service (Annex C category) at no more than 25 % incremental cost to JJ Online relative to the proposed Sub-processor and the swap can be completed within 90 calendar days of the request, taking into account reasonable engineering and migration effort on JJ Online's side. Refusal is permitted only where (i) no alternative meeting the 25 % incremental-cost ceiling is available within the same functional category, or (ii) the swap cannot be completed within 90 calendar days (or such longer period as the Parties agree in writing), or (iii) the alternative would itself give rise to a separate protection-of-Customer-Personal-Data concern reasonably comparable to the one underlying the Controller's objection. Where JJ Online refuses, JJ Online provides the Controller with a written reasoned statement identifying which of (i), (ii), or (iii) is engaged and the specific facts JJ Online relies on (e.g. the alternatives JJ Online surveyed and the cost or completion-time data that took each out of scope); the Controller may then elect remedy (a) or remedy (c). Any disagreement on whether the 25 % or 90-day thresholds are met is resolved in the Controller's favour where there is reasonable doubt; or

The Controller's failure to elect a remedy under (a), (b), or (c) within 30 calendar days of the parties acknowledging in writing that no good-faith solution under the second sentence of this § 9.4 has been reached is treated as election of remedy (c). The choice of remedies in this § 9.4 is without prejudice to any data-subject rights under Art. 26 (3), Art. 77, or Art. 79 GDPR, and without prejudice to any supervisory-authority action under Art. 58 GDPR.

9.5. Sub-processor obligations. JJ Online imposes data protection obligations on each Sub-processor that are no less protective than those imposed on JJ Online under this DPA, by way of a written contract. JJ Online remains fully liable to the Controller for any failure of a Sub-processor to fulfil its data protection obligations, except where the Sub-processor's failure is caused by the Controller's instructions or the Controller's own breach.

10. International data transfers (Art. 44–49 GDPR)

10.1. Primary processing location. Customer Personal Data is primarily processed within the European Economic Area:

(a) Main application infrastructure (dashboard, API, primary database, persistent storage for the application schema) is hosted on OVH SAS infrastructure in France.

(b) Time-series monitoring metrics are stored in a self-hosted time-series database operated by JJ Online itself on EU-located infrastructure (no third-party cloud database service for this storage).

(c) Transaction-monitoring screenshots and exported PDFs are stored as blobs on AWS S3 in the eu-central-1 (Frankfurt) region (Amazon Web Services EMEA SARL, Luxembourg, as the contracting entity). The S3 storage region is the same EU footprint as the main application; no transaction-monitoring screenshot leaves the EU on the JJ Online side. (Where the Controller chooses to download or forward a screenshot to a non-EU destination of their own, that onward transfer is the Controller's responsibility under § 1.3 (b).)

(d) Probe network infrastructure is geographically distributed across nine providers (OVH France, GCore Luxembourg / additional regions, EDIS Austria, Scaleway France (Paris / Amsterdam / Warsaw — all EU), and Contabo GmbH (Munich) as EU-headquartered probe sub-processors; plus DigitalOcean, Akamai/Linode, AWS, and Vultr for additional regions, some of which are non-EU). Importantly, the probe network performs ephemeral processing only: probes perform the check, forward the result to the main EU infrastructure, and immediately delete the local copy. No Customer Personal Data is persisted at rest on the probe layer. This ephemeral-processing property is the principal supplementary measure relied on for non-EEA probe locations and for probe Sub-processors without DPF certification (in particular Vultr). The technical detail of the ephemeral-processing property is set out in Annex B.6.

Customer freedom of choice — probe location selection. Where the Controller selects a specific probe region or set of probe regions for a given monitor, the selection is bounded by the JJ Online probe inventory set out in Annex C.2 and is covered by the lawful-transfer mechanisms applicable to each probe Sub-processor (DPF where the Sub-processor is DPF-certified; SCCs with supplementary measures where it is not). The ephemeral-processing property described in Annex B.6 ensures that no probe-location selection alters where Customer Personal Data is persisted at rest — that location remains the JJ Online EU footprint (OVH France application database; self-hosted time-series database on the same EU footprint; AWS S3 eu-central-1 Frankfurt for screenshot blobs) regardless of which probe ran the check. The Controller is therefore free to choose any probe region from the JJ Online inventory without altering the cross-border-transfer analysis for persistent storage.

10.2. Necessary transfers outside the EEA. Notwithstanding § 10.1, JJ Online transfers Customer Personal Data outside the EEA to the following categories of Sub-processors:

(a) Sub-processors that are themselves established outside the EEA (for example, the US-based Sub-processors set out in Annex C);

(b) Sub-processor regional infrastructure located outside the EEA (for example, AWS SES us-east-1 Virginia, operated by Amazon Web Services, Inc., for transactional email delivery to recipients outside the EU). The legal cover for this transfer is the transfer mechanism set out at § 10.3 and Annex C.2 — i.e., the EU-US Data Privacy Framework where Amazon Web Services, Inc. is DPF-certified at the time of the transfer, with SCC + supplementary measures as the operative fallback. Operational considerations such as delivery latency or deliverability characteristics may inform the routing decision but do not themselves constitute the legal basis for the transfer and are not relied on as a derogation under Art. 49 GDPR.

Routing logic — transactional email between the AWS SES EU and US endpoints. Routing of a given transactional email between the AWS SES eu-central-1 (Frankfurt) and us-east-1 (Virginia) endpoints is performed automatically by JJ Online's mail-dispatch layer on the basis of a deterministic classification of the recipient email address; the routing logic is a non-essential (technical) means determined by JJ Online under § 6.2 and EDPB Guidelines 07/2020 ¶ 38. The classification methodology is documented internally and is available to the Controller on audit-information request under § 14.1 (d). The Controller does not configure or override the routing on a per-email or per-account basis through the Service's current UI; where the Controller wishes to constrain the routing to the EU endpoint for any category of mail, the Controller may request that constraint in writing at privacy@uptimia.com, and JJ Online will engage with the request in good faith subject to the operational and deliverability impact of the constraint. A future configuration knob for Controller-elected EU-only routing is on the product roadmap; until shipped, the automatic-routing default applies;

(c) Customer-configured alert channels that route alert payloads to non-EEA destinations (for example, the customer's PagerDuty or Microsoft Teams workspace) — these onward transfers are made on the Controller's instruction under § 1.3 (b), and the Controller is responsible for the lawfulness of the onward transfer.

10.3. Transfer mechanism. For each transfer outside the EEA, JJ Online relies on one of the following mechanisms, layered as required by EDPB Recommendations 01/2020:

(a) EU-US Data Privacy Framework (Commission Implementing Decision (EU) 2023/1795) for Sub-processors that are self-certified under the DPF;

(b) Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), Module 3 (processor-to-processor), for any transfer where the DPF does not apply, supplemented by technical and organisational measures appropriate to the destination country;

(c) For transfers under UK GDPR, the UK Addendum to the SCCs as the default mechanism, or — at the Controller's election — the International Data Transfer Agreement (IDTA) issued by the UK Information Commissioner's Office and laid before Parliament on 2 February 2022, in standalone form. The default election is the UK Addendum (which preserves the Commission SCCs as the underlying instrument and reduces drafting fragmentation across the EEA and UK transfer chains); a Controller who prefers the standalone IDTA may notify JJ Online in writing at privacy@uptimia.com, in which case the Parties incorporate the IDTA in place of the UK Addendum for transfers under UK GDPR;

(d) For transfers under the Swiss FADP, the SCCs read with the Swiss-specific amendments published by the Federal Data Protection and Information Commissioner.

10.4. Sub-processor list — canonical source. The canonical Sub-processor list is Annex C of the then-current version of this DPA. Changes to the list are notified by email to the Controller under § 9.3 and reflected in an updated version of this DPA published on uptimia.com.

10.5. Onward transfers by Customer-instructed channels. Where the Controller configures an alert channel that itself transfers data outside the EEA (for example, Slack, Discord, X Corp in the United States, or Telegram FZ-LLC in the UAE — for which JJ Online does not itself assert an Art. 46 or Art. 49 GDPR transfer mechanism, as noted in Annex C.5), JJ Online is acting on the Controller's instruction under § 1.3 (b). The Controller is solely responsible for ensuring that the chosen alert channel is lawful under Arts. 44–49 GDPR for the Controller's particular use case. JJ Online identifies in Annex C which of the available alert channels are non-EEA destinations and on what transfer mechanism, to assist the Controller's assessment.

Restricted Channels. Annex C.5 designates a subset of channels as Restricted Channels (currently: Telegram and X Corp). Restricted Channels are not offered on the default alert-channel menu and require the per-channel in-product acknowledgement described in § 1.3 (b) before they can be activated on a Controller's account. The Restricted Channels designation reflects either (i) the absence of a Commission-approved Art. 46 GDPR transfer mechanism applicable to the channel as deployed (Telegram FZ-LLC bot alerting), or (ii) the historical volatility of the channel operator's DPF certification status and the elevated reliance on SCC + supplementary-measures fallback that follows (X Corp). JJ Online may move additional channels into, or out of, the Restricted Channels list as the underlying legal posture changes; such changes are notified to active Controllers under the Annex C update mechanism in § 9.3.

11. Assistance with Data Subject requests (Art. 12–22 GDPR)

11.1. JJ Online provides reasonable assistance to the Controller, by appropriate technical and organisational measures, insofar as possible, to fulfil the Controller's obligation to respond to requests from Data Subjects exercising their rights under the GDPR, including the rights of access, rectification, restriction, erasure, portability, and objection.

11.2. Direct Data Subject contacts. If a Data Subject contacts JJ Online directly with a request relating to Customer Personal Data, JJ Online forwards the request to the Controller without undue delay and does not otherwise respond to the Data Subject, except to acknowledge receipt and inform the Data Subject that the request has been forwarded to the Controller.

11.3. In-product self-service. Where the Service provides built-in tooling for the Controller to satisfy Data Subject requests directly (for example, data export, account deletion, IP truncation / pseudonymisation for RUM events — consistent with the Annex B characterisation of /24 IPv4 and /48 IPv6 truncation as pseudonymisation, not anonymisation, in line with Art. 29 WP Opinion 05/2014 on Anonymisation Techniques), the Controller is expected to use those tools as the first-line response. JJ Online's manual assistance is available where the in-product tooling is insufficient.

11.4. Cost. Manual assistance beyond what is reasonably available through the in-product tooling may be charged at JJ Online's reasonable cost, except where the Service's documented capabilities should have been sufficient to satisfy the request.

12. Personal Data breaches (Art. 33–34 GDPR)

12.1. JJ Online notifies the Controller without undue delay, and in any event within 24 hours, after becoming aware of a personal data breach affecting Customer Personal Data. This processor-side window is deliberately set inside the Controller's own Art. 33 (1) GDPR 72-hour notification window so that the Controller has meaningful time to assess and to notify the competent supervisory authority on the Controller's own clock. JJ Online treats this 24-hour ceiling as a firm operational commitment, not a target.

12.2. The notification at least:

(a) describes the nature of the breach, including, where possible, the categories and approximate number of Data Subjects and data records concerned;

(b) communicates the name and contact details of JJ Online's point of contact for the breach (the email admin@uptimia.com is the default; for severe incidents JJ Online may direct the Controller to a specific incident contact);

(d) describes the measures JJ Online has taken or proposes to take to address the breach, including, where appropriate, measures to mitigate its possible adverse effects.

12.3. Where the information cannot be provided at the same time, the information may be provided in phases without undue further delay.

12.4. JJ Online does not notify supervisory authorities or Data Subjects on behalf of the Controller — that obligation under Arts. 33 (1) and 34 GDPR rests with the Controller. JJ Online provides the Controller with the information needed to make those notifications.

13. DPIA and prior consultation (Art. 35–36 GDPR)

JJ Online does not charge for assistance under Art. 28 (3) (f) GDPR. JJ Online provides reasonable assistance to the Controller in carrying out data protection impact assessments and prior consultations with supervisory authorities, where required under Arts. 35 and 36 GDPR. The Art. 28 (3) (f) GDPR duty to provide such assistance — taking into account the nature of processing and the information available to JJ Online — is treated as a mandatory and unqualified processor obligation and is performed at no charge to the Controller. This no-charge rule applies to the full scope of Art. 28 (3) (f) assistance, regardless of how the Controller's request is framed or how many iterations of clarification it requires.

Standard documentary assistance (no charge). JJ Online provides as standard, on Controller request: (a) this DPA, (b) Annex B (TOMs), (c) Annex C (Sub-processor list), (d) the Uptimia Privacy Policy and Cookie Policy, (e) the per-account Processing Instructions Summary under § 6.1 (e) and Annex A.8, and (f) the per-recipient Transfer Impact Assessment summaries referenced in § 10. These documents together are designed to cover the typical Art. 35 (7) DPIA elements (description of processing, necessity-and-proportionality assessment inputs, risk assessment inputs, safeguards).

Reasonable additional assistance (no charge). Where the Controller's DPIA or Art. 36 prior-consultation reasonably requires assistance specifically directed at the Controller's deployment of the Service that goes beyond the standard documentation — for example, written responses to a finite set of clarification questions, a walk-through of a specific TOM, or a written confirmation of a specific configuration fact — JJ Online provides that assistance at no charge, as part of its Art. 28 (3) (f) GDPR obligation.

Engagements outside the scope of Art. 28 (3) (f). Charges may be applied only for engagements that are not Art. 28 (3) (f) GDPR assistance — that is, for work the Controller commissions from JJ Online that goes beyond the processor's statutory DPIA-assistance duty.

The Art. 28 (3) (f) duty is anchored on the underlying factual disclosure, not on the output framework. The factual disclosure of what Customer Personal Data JJ Online processes, where, under what TOMs, through which Sub-processors, and with which transfer mechanisms is the same disclosure whether the Controller is producing the output for a GDPR DPIA, a UK GDPR DPIA, a Swiss FADP impact assessment, an ISO 27001 control narrative, a SOC 2 / HITRUST attestation, or a non-GDPR regime such as HIPAA, CCPA, LGPD, or PIPL. JJ Online does not charge for that underlying factual disclosure, regardless of the regulatory frame the Controller intends to use it in — to the extent the substance of the assistance is the § 14.1 (a)–(e) audit-information set, the Annex A / Annex B / Annex C content of this DPA, the § 10 transfer analysis, the § 6.1 (e) Processing Instructions Summary, or any reasonable clarification of those, it is Art. 28 (3) (f) assistance and is provided at no charge.

Charges may be applied only for the incremental value-add that is genuinely outside the § 14.1 (a)–(e) factual-disclosure surface — namely:

(a) bespoke security audits commissioned by the Controller that go beyond the § 14.2 audit cooperation already provided at no incremental charge;

(b) custom written attestation / control narrative work that JJ Online produces for the Controller's framework filing (for example, ghost-writing a SOC 2 sub-processor control narrative or an ISO 27001 Annex A.15 control statement), as opposed to the underlying factual disclosure;

(c) legal-regime mapping work that goes beyond stating the factual position — e.g., a written legal opinion that the JJ Online TOMs satisfy a specific HIPAA Security Rule administrative safeguard, a CCPA "service provider" warranty, an LGPD "operator" warranty, or a PIPL "entrusted processing" warranty, as opposed to merely disclosing the underlying TOM facts. (The Controller's own counsel is the right party to draw the legal conclusion; JJ Online's chargeable engagement on this point is opinion-writing assistance, not factual disclosure.)

Whether a particular request falls inside or outside Art. 28 (3) (f) is decided in the Controller's favour where there is reasonable doubt — in particular, where a Controller is itself subject to a regulatory regime outside the GDPR / UK GDPR / FADP scope and the request can be satisfied by the factual disclosure surface above, it is Art. 28 (3) (f) assistance and is provided at no charge regardless of the framework the Controller is producing the output for. Any chargeable outside-scope engagement is quoted in writing before work begins, is at JJ Online's reasonable cost, and the Controller has the option to decline. Declining a chargeable outside-scope engagement does not waive or reduce JJ Online's Art. 28 (3) (f) obligation in respect of the underlying DPIA, prior consultation, or factual disclosure.

14. Audit rights (Art. 28 (3) (h) GDPR)

14.1. Audit information. JJ Online makes available to the Controller, upon written request, the information necessary to demonstrate compliance with the obligations set out in Art. 28 GDPR and in this DPA. The standard form of audit information is:

(a) this DPA, including its current Annexes;

(b) the Uptimia Privacy Policy and Cookie Policy;

(d) summaries of any independent third-party audit reports JJ Online holds in respect of the Service infrastructure (where available — the Service is not currently SOC 2 / ISO 27001 certified; JJ Online provides equivalent self-assessment summaries on request);

(e) Art. 28 (3)(a) instruction record — for the Controller's account, the timestamped record of (i) the Processing Instructions Summary versions previously issued under § 6.1 (e) and Annex A.8, and (ii) the Restricted Channel acknowledgements collected under § 1.3 (b), § 10.5 and Annex C.5.2. JJ Online produces this record on Controller or supervisory-authority request as the Art. 5 (2) accountability evidence for the Controller's documented instructions.

14.2. On-site audit. Where the standard audit information set out in § 14.1 is insufficient to demonstrate compliance, the Controller (or an independent auditor mandated by the Controller and acceptable to JJ Online, acting reasonably) may carry out audits, including inspections, at JJ Online's premises, on the following conditions:

(a) audits take place no more than once in any rolling twelve-month period as a default (this default does not curtail the Controller's Art. 28 (3) (h) GDPR right and is subject to (i)–(iii) below). Additional audits within the same rolling twelve months may be conducted where the Controller demonstrates a reasoned need related to the protection of Customer Personal Data — without limitation, where (i) a material personal data breach affecting Customer Personal Data has occurred, (ii) a competent supervisory authority has issued an instruction, request, or order to the Controller or to JJ Online that reasonably requires a further audit, or (iii) the Controller has identified a specific finding (whether from a prior audit, from the standard audit information under § 14.1, from a sub-processor disclosure, from a supervisory-authority action against JJ Online or another customer, or from an external source) the verification of which reasonably requires a recurrent audit. JJ Online will not refuse a recurrent audit request supported by such a reasoned need, and any disagreement on whether the threshold is met is resolved in the Controller's favour where there is reasonable doubt;

(b) the Controller gives at least 30 calendar days' written notice of the audit;

(c) audits are conducted during JJ Online's normal business hours and in a manner that does not unreasonably interfere with JJ Online's business operations;

(d) the auditor is bound by appropriate confidentiality obligations covering the audit process and findings;

(e) the Controller bears its own audit costs; JJ Online bears its own internal costs of cooperating with the audit;

(f) the audit does not extend to information concerning other JJ Online customers, infrastructure or commercial information not relevant to the audit's stated purpose, or any data not relating to the Controller. Where JJ Online proposes to withhold a particular piece of information on the basis of this paragraph, JJ Online identifies the withheld item with sufficient specificity for the Controller to assess the withholding, and any disagreement on whether the item is relevant to the audit's stated purpose is resolved in the Controller's favour where there is reasonable doubt.

14.3. Sub-processor audits. Where the Controller's audit right reasonably extends to a Sub-processor, JJ Online either (a) provides the relevant Sub-processor audit information from its own records, or (b) on reasonable request assists the Controller in exercising any audit rights the Sub-processor's own DPA with JJ Online provides.

14.4. Cooperation with supervisory authorities — including the Controller's lead authority under Art. 56 GDPR. JJ Online cooperates, on request, with any competent supervisory authority in relation to JJ Online's processing of Customer Personal Data under this DPA. The competent supervisory authority is not limited to the Berliner Beauftragte für Datenschutz und Informationsfreiheit (BlnBDI) as JJ Online's own lead under Art. 56 (1) GDPR (and as designated for Annex I to the SCCs at Annex D.2). In particular, where the Controller has cross-border processing within the meaning of Art. 4 (23) GDPR and a lead supervisory authority of its own designated under Art. 56 (1) GDPR, JJ Online:

(a) cooperates with that Controller-lead authority, and with any concerned supervisory authority within the meaning of Art. 4 (22) GDPR acting through the Art. 60 GDPR one-stop-shop mechanism, on requests reasonably related to JJ Online's processing of that Controller's Customer Personal Data — without requiring the request to be routed first through BlnBDI;

(b) provides to that authority, on reasonable request and subject to applicable confidentiality obligations, the same categories of audit information set out in § 14.1 (a)–(e), and the same on-site-audit cooperation as at § 14.2, that would be available to the Controller itself; and

(c) notifies the Controller in writing without undue delay of any direct contact, request, instruction, or order that JJ Online receives from a supervisory authority concerning the processing of that Controller's Customer Personal Data, unless the authority's instruction or applicable law prohibits such notification on important grounds of public interest. Where JJ Online is so prohibited, JJ Online challenges the prohibition through legally available channels and notifies the Controller as soon as the prohibition is lifted.

This § 14.4 does not displace BlnBDI's role as JJ Online's lead supervisory authority for SCC-Annex-I purposes under Annex D.2, and does not displace the Controller's own duty to engage directly with its lead authority. It is a parallel cooperation channel intended to give effect to the one-stop-shop mechanism of Arts. 56 and 60 GDPR in respect of JJ Online's processor-side cooperation duty under Art. 28 GDPR.

15. End-of-contract treatment of data (Art. 28 (3) (g) GDPR)

15.1. Upon termination of the Controller's subscription, JJ Online, at the Controller's choice exercised within 30 calendar days of termination:

(a) returns Customer Personal Data to the Controller in a structured, commonly used and machine-readable format through the Service's export tooling. The Controller exercises the return option by initiating, and completing, the export via the Service's export tooling within the 30-calendar-day window. After the 30-calendar-day window has elapsed, the return option is extinguished and JJ Online proceeds with deletion under (b); or

(b) deletes Customer Personal Data in the production systems.

Extension on reasoned request. Where the Controller has notified JJ Online in writing within the 30-calendar-day window that the Controller has elected the return option but reasonably requires additional time to complete the export (for example, because of dataset size or an integration constraint on the Controller's side), JJ Online and the Controller agree in good faith on a reasonable extension, not exceeding a further 30 calendar days save in exceptional circumstances. Until the extension expires, the return option is not extinguished and deletion under (b) is suspended.

15.2. Default behaviour. If the Controller does not exercise the return option within the 30-calendar-day window in § 15.1 (or within any extension agreed under § 15.1), JJ Online proceeds with deletion under § 15.1 (b) without further notice or instruction from the Controller.

15.3. Backups. Customer Personal Data may remain in JJ Online's encrypted backups for the rolling 14-day backup-rotation window before being overwritten by the rotation cycle. During that residual period, the data is not actively processed and exists only as a frozen disaster-recovery snapshot. The combination of a short rolling window, the absence of active processing during that window, and the re-erasure-on-restore step described below is consistent with established supervisory-authority practice on backups under Art. 17 (1) / (3) GDPR. JJ Online maintains an internal backup register documenting the in-scope systems (application database on OVH France, time-series database on OVH France, AWS S3 Frankfurt blobs), the rotation policy, the storage location, the access controls, and the re-erasure runbook described below. If JJ Online restores from a backup that pre-dates an erasure request received from the Controller or a Data Subject, the original erasure is re-applied to the restored data within 72 hours of the restore completing — and, where the restore brings the system back online for active processing, before the restored system is opened to user or Controller traffic — so that erased Customer Personal Data is not reintroduced into active processing. The 72-hour ceiling is the outer audit commitment; in normal operation the re-erasure replay runs as the first scripted step after the restore and completes in minutes, not hours. The backup register records, for each production restore, (i) the timestamp the restore completed, (ii) the timestamp the erasure-log replay completed, and (iii) confirmation that no user or Controller traffic was admitted to the restored system between (i) and (ii). The re-erasure runbook itself, the backup register, and the per-restore records (i)–(iii) are subject to the audit right under § 14 — JJ Online produces them on Controller or supervisory-authority request as part of the standard audit-information set under § 14.1, and they fall within the on-site-audit scope at § 14.2 where the standard set is insufficient to demonstrate compliance.

15.4. Statutory retention. Notwithstanding § 15.1–15.3, JJ Online may retain Customer Personal Data where retention is required by Union or Member State law, in particular under German tax and accounting law (§ 147 AO and § 257 HGB, each as amended from time to time, and the corresponding VAT-invoice retention rules under § 14b UStG). The retention periods applicable under those provisions at the version date of this DPA are eight years for invoices and accounting documents and ten years for books, annual statements and consolidated accounts (anchored at the end of the calendar year). Such retained data is not actively processed beyond what is necessary for the statutory retention purpose.

16. Records of processing (Art. 30 (2) GDPR)

JJ Online maintains a written record of all categories of processing activities carried out on the Controller's behalf and makes that record available to the Controller and to supervisory authorities on request, as required by Art. 30 (2) GDPR. The record contains the Art. 30 (2) (a)–(d) elements as follows:

(a) Name and contact details of the processor and of each controller on whose behalf the processor is acting, and where applicable of any processor's representative and the data protection officer — JJ Online's identity and contact are in the Preamble and Annex E; the Controller is identified by the account record held on the Controller's behalf; JJ Online has no representative under Art. 27 GDPR (controller and processor both established in the EEA); JJ Online has not appointed a DPO under § 38 Abs. 1 BDSG (see Annex E). (b) Categories of processing carried out on behalf of each controller — set out in Annex A (in particular Annex A.3 nature/purpose and Annex A.4 data categories). (c) Where applicable, transfers of personal data to a third country or international organisation, including the identification of that third country or international organisation and, in the case of transfers referred to in the second subparagraph of Art. 49 (1), the documentation of suitable safeguards — set out in § 10 and Annex C (Sub-processor location and transfer mechanism per Sub-processor) and Annex D (SCC incorporation and supplementary measures). (d) Where possible, a general description of the technical and organisational security measures referred to in Art. 32 (1) — set out in Annex B.

The Annexes A, B, C and D are therefore the constitutive content of the Art. 30 (2) record for the Service.

17. Liability

17.1. The liability of each Party under this DPA is subject to the liability provisions of the Terms of Service § 19–20.

17.2. Mandatory non-excludable liability. Nothing in this DPA limits or excludes liability that cannot be limited or excluded under applicable law. This includes, without limitation:

(a) Art. 82 GDPR (right to compensation of the Data Subject) — the cap and any limitation in this § 17 does not apply to JJ Online's liability under Art. 82 GDPR for damage caused to Data Subjects by JJ Online's own processing in breach of the GDPR, to the extent the cap would impair the effet utile of Art. 82;

(b) § 309 Nr. 7 BGB and the Kardinalpflichten line of case law — under the standards of § 309 Nr. 7 Buchst. a und b BGB read with § 307 Abs. 1 und Abs. 2 Nr. 1 und Nr. 2 BGB (which the BGH applies to B2B AGB through the Indizwirkung of §§ 308 / 309 BGB), the cap and any limitation in this § 17 does not apply to (i) injury to life, body or health (Körper- und Gesundheitsschäden), (ii) damage caused by intent (Vorsatz) or gross negligence (grobe Fahrlässigkeit) on the part of JJ Online or its legal representatives or vicarious agents (Erfüllungsgehilfen), or (iii) breach of a cardinal contractual duty (Kardinalpflicht / vertragswesentliche Pflicht — a duty whose fulfilment is essential to the proper performance of this DPA and on whose fulfilment the Controller may regularly rely); in the cardinal-duty case where the breach is by simple negligence, JJ Online's liability is not unlimited but is capped at the foreseeable damage typical for this type of contract (der vorhersehbare, vertragstypische Schaden) under the standard BGH formulation;

(d) any other liability that cannot be limited or excluded under mandatory Union or Member State law applicable to the Parties or to the processing.

17.3. Liability cap (subject to § 17.2). To the extent permitted by applicable law and subject to the carve-outs in § 17.2, JJ Online's aggregate liability under this DPA in any rolling twelve-month period is limited to the fees actually paid by the Controller to JJ Online for the Service in that rolling twelve-month period. This cap is set out in this DPA on a self-contained basis and does not depend on the existence, content, or continued effectiveness of any provision of the Terms of Service. To the extent the Terms of Service § 19 contains a parallel liability cap, the cap in this § 17.3 applies independently to claims under this DPA; in the unlikely event of any divergence between the two, the cap in this § 17.3 (i.e., fees actually paid in the relevant rolling twelve-month period) applies to claims under this DPA.

Reference period when no full twelve months of fees have accrued. Where the Controller's subscription has been in force for less than twelve months at the time of the claim, the reference period for the cap is the period between the start of the subscription and the date of the claim, and the cap is the fees actually paid by the Controller in that shorter period. Where no fees have been paid (e.g. during a free trial), the cap is set at the fees that would have accrued under the Controller's then-prevailing plan tier over a twelve-month period at the list price applicable on the date of the claim, so that the cap remains a determinate figure under § 17.2's close-case scrutiny rather than collapsing to zero.

Cap survival. This § 17.3 survives any termination, amendment, or invalidity of the Terms of Service to the extent § 18.2 of this DPA preserves the operation of § 17.

Carve-out re-statement. Where, in respect of a particular claim, the cap as so applied would be invalid under § 17.2 (a) (Art. 82 GDPR effet utile) or § 17.2 (b) (Körper-/Gesundheitsschäden / Vorsatz / grobe Fahrlässigkeit / Kardinalpflichten), the cap does not apply to that claim and JJ Online's liability for that claim is determined under the applicable statutory regime (Art. 82 GDPR, §§ 280, 241, 249 ff. BGB, ProdHaftG, or other applicable mandatory rule), subject — in the cardinal-duty / simple-negligence case under § 17.2 (b)(iii) — to the foreseeable-typical-damage ceiling stated there.

18. Term and termination

18.1. This DPA enters into force on the date the Controller accepts the Terms of Service and continues for the duration of the Controller's Uptimia subscription, plus the residual periods set out in § 15.

18.2. Sections 14 (Audit rights), 15 (End-of-contract treatment of data), 16 (Records of processing) and 17 (Liability) survive termination for as long as is necessary to give effect to the obligations they contain.

19. Order of precedence

In the event of any conflict between this DPA, the Terms of Service, and any other document referenced from either, the order of precedence (highest to lowest) is:

Any data-protection-specific term required by a supervisory authority order or by Data Protection Laws;
The Standard Contractual Clauses, where incorporated by reference under § 10.3 and Annex D, in respect of any transfer governed by them;
This DPA, including its Annexes;
The Terms of Service;
The Uptimia Privacy Policy.

For the avoidance of doubt, the precedence rule above reflects Clause 5 of the Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), under which the SCCs prevail over conflicting provisions of related agreements as between the Parties to that SCC transfer. To the extent any provision of this DPA conflicts with the SCCs in respect of an SCC-governed transfer, the SCCs prevail.

20. Miscellaneous

20.1. Governing law and jurisdiction. This DPA is governed by the laws of the Federal Republic of Germany, excluding the UN Convention on Contracts for the International Sale of Goods (UN-Kaufrecht). Disputes are subject to the jurisdiction provisions of the Terms of Service § 25, with the proviso that, for matters falling under the GDPR / UK GDPR / FADP, the Data Subject's mandatory statutory venue under Art. 79 GDPR is preserved.

20.2. Controlling language. This DPA is published in English as the controlling language. Translations are informational; in case of conflict the English version controls.

20.3. Severability. If any provision of this DPA is held to be invalid, illegal or unenforceable, the remaining provisions remain in full force, and the Parties replace the invalid provision with one that achieves the same purpose to the extent permitted.

20.4. Updates. JJ Online may update this DPA to reflect (a) changes in Data Protection Laws, (b) changes in the Service infrastructure or Sub-processor list, (c) supervisory authority guidance, or (d) operational requirements that do not materially reduce the protections afforded to the Controller. Material changes are notified to the Controller at least 30 calendar days in advance.

Presumptively material changes. The following categories of change are presumptively material under this § 20.4 — i.e., JJ Online does not retain discretion to classify them as non-material, and the 30-day notice, the 14-day objection window, and the objection-and-termination remedy below apply automatically:

(i) change in Sub-processor location — any change in the country or region from which a Sub-processor (Annex C) processes Customer Personal Data, including a change in the sub-sub-processing chain that introduces a new third country or new processing region as set out at § 9.3;

(ii) change in the lawful-transfer mechanism applied to any transfer of Customer Personal Data outside the EEA (e.g. transition from EU-US DPF to SCC + supplementary measures, addition of an Art. 49 GDPR derogation as the operative mechanism for any category of transfer, restructuring of an SCC Module assignment under Annex D);

(iii) change in the categories of Sub-processor engaged (e.g. introduction of a new functional category in Annex C, or addition of a Sub-processor in a country or under a corporate group not previously represented in Annex C);

(iv) addition or replacement of a Sub-processor, as already provided for at § 9.3 (this § 20.4 (iv) is for the avoidance of doubt — the § 9.3 dedicated mechanism applies, with the § 9.4 three-remedy menu);

(v) reduction in the technical and organisational measures set out in Annex B — including a downgrade of any encryption-at-rest or in-transit posture, a reduction in the access-control regime, a relaxation of the § 10.1 EU primary-processing-location property, a reduction in the §B.6 ephemeral-processing property of the probe layer, or a loosening of any other TOM relied on in the Annex B description;

(vi) change in the retention period for any category of Customer Personal Data set out in Annex A.9 that lengthens the period, expands the categories subject to retention, or changes the storage location (parallel to § 20.5);

(vii) change in the breach-notification window under § 12 from the 24-hour commitment, or any equivalent loosening of the § 12 assistance regime;

(viii) change in the categories of Customer Personal Data processed beyond what is set out in Annex A.4, or change in the categories of Data Subjects beyond what is set out in Annex A.5;

(ix) restriction of any Controller right under this DPA — including any narrowing of the audit right under § 14, the DPIA-assistance regime under § 13, the data-subject-rights-assistance regime under § 11, the deletion-on-termination regime under § 15, or the SCC / Art. 26 fallback regimes under § 5.3 and Annex D;

(x) change in JJ Online's controller of record under Art. 4 (7) GDPR (e.g. a corporate restructuring within the JJ Online group that changes the contracting entity for Customer Personal Data); and

(xi) any other category of change that a competent supervisory authority indicates should be treated as material for the purposes of Art. 28 GDPR.

This list is presumptively material but non-exhaustive — other changes may also be material on the general standard set out below.

Controller right of objection and termination for material changes. Where a notified change is presumptively material under (i)–(xi) above, or is otherwise material — that is, where it reasonably affects the protection of Customer Personal Data, the rights of Data Subjects, the location of processing, the categories of Sub-processors, the lawful-transfer mechanism applied, or the technical or organisational measures relied on — the Controller may object on reasonable grounds related to the protection of Customer Personal Data within 14 calendar days of receiving the notification. If the Controller raises a reasoned objection, the Parties cooperate in good faith to identify a solution. Where no solution acceptable to both Parties can be reached, the Controller may terminate the affected portion of the Service in accordance with the Terms of Service § 23, with pro-rata refund of any pre-paid fees attributable to the unused portion of the affected period, before the change takes effect. Non-material updates — for example, drafting corrections, restatements of existing law, or changes that strictly improve the protections — do not give rise to a termination right.

Close-case rule on materiality. Where there is reasonable doubt about whether a particular change is material, the change is treated as material and the § 20.4 notice, objection, and termination remedy apply. The Controller may at any time, on notification of a change JJ Online has classified as non-material, request that JJ Online reconsider the classification on stated grounds; JJ Online responds to such a request in writing within ten (10) business days, and any disagreement on materiality is resolved in the Controller's favour where reasonable doubt remains.

20.5. Retention schedule — flow-through of privacy-policy changes. A change to § 11 of the Uptimia Privacy Policy (privacy.en.md) that, in respect of any category of Customer Personal Data within the meaning of this DPA, lengthens the retention period, expands the categories subject to retention, or changes the storage location, is treated as a material change to this DPA under § 20.4 and is notified to active Controllers on the § 20.4 timeline with the § 20.4 objection and termination remedy. JJ Online will, in the same notification, publish the corresponding Annex A.9 amendment. Privacy-policy changes that strictly shorten retention or strictly improve the protections for the categories listed in Annex A.9 are non-material under § 20.4 and may take effect on publication; they are nevertheless reflected in the next revision of this DPA and Annex A.9 for transparency.

Annex A — Subject matter, nature, purpose, data categories, Data Subjects

A.1 Subject matter of processing

The processing of Personal Data by JJ Online on the Controller's behalf in the course of providing the Uptimia observability service.

A.2 Duration of processing

The duration of the Controller's subscription to the Service plus the residual periods set out in § 15.

A.3 Nature and purpose of processing

Processing activity	Purpose
Availability monitoring (HTTP/HTTPS, ICMP, TCP checks)	Detection of availability incidents on Controller-monitored resources
Page-speed monitoring (Real Chrome on Controller URLs)	Performance measurement and trend analysis
Real user monitoring (RUM) via Controller-deployed script	Page-load metrics and JavaScript error visibility from Controller's visitors
Transaction monitoring (synthetic multi-step browser flows)	Functional health checks for Controller workflows
Domain and SSL expiry monitoring	Lifecycle alerts
Mixed-content and content-change monitoring	Detection of configuration drift
Alert delivery to Controller-configured channels	Operational notification of incidents
Status page publication	Public-facing incident communication
API access	Programmatic retrieval of Controller's monitoring data

A.4 Types of Customer Personal Data

The following categories of Customer Personal Data may be processed, depending on the Controller's use of the Service:

(a) Authenticated HTTP check response payloads. Where the Controller configures a monitor with authentication credentials against an endpoint that returns Personal Data in its response body, that response data is captured for the duration necessary to perform availability evaluation, then truncated or hashed for the persistent record.

(b) Transaction monitoring screenshots. Each step of a Controller-configured transaction is captured as a screenshot. Screenshots may contain Personal Data visible on the screen (e.g., usernames, email addresses, account details visible in the application UI).

(c) RUM event payloads. Page-load metrics, browser/device information, geographic origin, JavaScript error context, and visitor IP addresses (truncated to /24 IPv4 and /48 IPv6 prior to storage). The visitor whose data is captured is the Controller's website visitor, not a JJ Online subscriber.

(d) Status-page incident subscription email addresses. Where the Controller's status page allows visitors to subscribe to incident notifications, the subscriber's email address is processed for the duration of the subscription.

(e) Alert payload metadata. Monitor name, check timestamp, response status, and (where the Controller has enabled it) excerpts of the response body, transmitted to the Controller-configured alert channels.

The Controller acknowledges that JJ Online cannot independently determine whether a monitored response or a transaction screenshot contains Personal Data, Special Categories of Personal Data (Art. 9 GDPR), or data of children (Art. 8 GDPR). The Controller is responsible for the lawfulness of what they cause to be captured.

A.5 Categories of Data Subjects

(a) The Controller's website visitors — where RUM is deployed by the Controller on their own websites.

(b) The Controller's authenticated end-users — where authenticated HTTP checks capture data about users of the Controller's application.

(c) The Controller's customers / users visible in transaction screenshots — where transaction monitoring scripts traverse authenticated areas of the Controller's application.

(d) The Controller's status-page subscribers — where the Controller operates a public status page with incident-subscription functionality.

(e) The Controller's own employees and operators — where alert delivery channels reach Controller staff and the alert payload contains operational data about that staff member's environment.

A.6 Special Categories of Personal Data (Art. 9 GDPR)

JJ Online does not require or solicit Special Categories of Personal Data. The Controller is responsible for not configuring the Service in a way that captures Special Categories of Personal Data (e.g., not monitoring an authenticated health-record endpoint without appropriate Art. 9 (2) legal basis).

A.7 Data of children (Art. 8 GDPR / national thresholds)

JJ Online does not knowingly process the data of children below the applicable national threshold under Art. 8 (1) GDPR or its UK GDPR / FADP equivalents. The applicable threshold varies by jurisdiction: 16 under Art. 8 (1) GDPR in Germany (Germany did not exercise the Art. 8 (1) Satz 2 GDPR option to derogate below the 16-year default, so the GDPR default applies directly; this is the floor JJ Online applies by default to its own controller-side processing); other EU Member States have exercised the Art. 8 (1) Satz 2 GDPR option to set their threshold in the range 13–16 (e.g. 13 in some, 14 in others, 16 in the Netherlands like Germany's GDPR default); 13 under section 9 of the UK Data Protection Act 2018; comparable rules under the Swiss FADP. The Controller is responsible for identifying the applicable threshold for the Controller's own Data Subjects (in particular the Controller's own website visitors targeted by RUM, the Controller's authenticated end-users, and the Controller's status-page subscribers) and for satisfying Art. 8 (1) / (2) GDPR (or the UK / Swiss equivalent) in respect of them. The Controller's use of RUM on websites directed at children below the applicable threshold is the Controller's responsibility and is not contemplated by this DPA.

A.8 Per-account Processing Instructions Summary

This Annex specifies the structure of the Processing Instructions Summary referenced at § 6.1(e). The Summary is the per-account documented-instructions artifact contemplated by EDPB Guidelines 07/2020 on the concepts of controller and processor ¶ 39 and is generated on Controller request to support the Controller's Art. 5 (2) accountability and Art. 30 (1) records-of-processing obligations.

The Summary is generated by JJ Online from the Controller's account state at the time of the request and contains, at a minimum:

(a) Account identification. The Controller's account identifier, the email address on record, and the date the Summary was generated.

(b) Active monitor inventory. The number and type of monitors the Controller has configured under the account (HTTP/HTTPS, ICMP, TCP, page-speed, RUM, transaction monitoring, domain/SSL expiry, mixed-content / content-change), with the corresponding processing activity from Annex A.3.

(c) Resources monitored. The hostnames and URL patterns the Controller has chosen to monitor, including any URLs on which the Controller has deployed the RUM script.

(d) Service plan tier and retention. The plan tier the Controller has selected at the time of the request, with the corresponding retention period per data category drawn from Annex A.9 of this DPA and § 15.3 of this DPA.

(e) Alert channels activated (Sub-processor surface). The Controller-configured alert channels currently active on the account, drawn from the list at Annex C.5. Sub-processors in Annex C.5 not activated by the Controller are listed as inactive.

(f) Storage region. The EU storage region or regions applicable to the Controller's data (currently OVH France for the application database; AWS Frankfurt eu-central-1 for screenshot blobs in S3; self-hosted time-series database on the same EU footprint).

(g) Subsequent written instructions. Any § 6.1(d) written instructions JJ Online has accepted in writing from the Controller since the last Summary, identified by date and reference.

(h) Sub-processor list. A copy of, or reference to, the current Annex C list at the date of generation.

(i) Term acknowledgement. A statement that the Summary is documentary in nature, does not vary this DPA, and is read subject to it.

A Controller may request the Summary as often as is reasonably necessary; JJ Online will not unreasonably refuse repeat requests. JJ Online does not currently provide self-service generation of the Summary in the Controller's dashboard — that feature is on the product roadmap. Until self-service is available, the Summary is generated and returned manually within the five-business-day window stated at § 6.1(e).

A.9 Retention schedule (Customer Personal Data — DPA scope)

This Annex sets out the retention schedule applicable to Customer Personal Data within the meaning of this DPA — i.e., Personal Data JJ Online processes as processor on the Controller's behalf under Art. 28 GDPR. It is the operative retention reference for the purposes of § 6.1 (c), § 6.1 (e), § 15.3, and Annex A.8 (d). The corresponding schedule published in § 11 of the Uptimia Privacy Policy (privacy.en.md) covers a broader set of data categories (including Personal Data for which JJ Online is the controller, e.g. account, billing, and security-audit data) and remains the user-facing source of truth for those broader categories; this A.9 snapshot is restricted to the DPA-scoped subset and prevails over the broader privacy-policy schedule in case of conflict for the categories listed below.

Category (Customer Personal Data, DPA-scope)	Retention period	Legal basis / authority
Monitor result data — uptime, SSL, domain/WHOIS, speed, transaction, RUM aggregates, virus/malware, server-agent metrics	Up to 13 months, plan-tiered (the active plan-tier ceiling is the binding figure; the current plan-tier matrix is published on uptimia.com)	Art. 6 (1)(b) GDPR (provision of Service); customer-utility ceiling under Art. 5 (1)(e) GDPR
Uptime HTTP response bodies	7 calendar days, auto-expired	Art. 6 (1)(b) GDPR; operational only
Transaction monitoring screenshots and exported PDFs (stored on AWS S3 `eu-central-1` Frankfurt under § 10.1 (c))	30 calendar days	Art. 6 (1)(f) GDPR; data minimisation under Art. 5 (1)(c) (Personal Data may be visible on authenticated screens)
Status-page incident subscription email addresses	Duration of the subscription, immediate deletion on unsubscribe	Art. 6 (1)(b) GDPR
Backups of the above (application database, time-series database, AWS S3 Frankfurt)	Rolling 14-day window; re-erasure-on-restore as set out at § 15.3	Art. 6 (1)(f) GDPR (disaster recovery)

Retention periods for Customer Personal Data are bounded by (i) the Service plan tier the Controller has selected at § 6.1 (c) (which determines the active ceiling within the "up to 13 months" range for monitor result data), and (ii) the deletion-on-termination flow at § 15. The Controller may at any time request earlier deletion of Customer Personal Data under Art. 17 GDPR (subject to § 11 and § 15.4); plan-downgrade-driven shortening of retention is applied prospectively to data collected after the downgrade and not retroactively to previously-collected data unless the Controller requests it.

Changes to this A.9 retention schedule that lengthen any retention period, expand the categories of Customer Personal Data subject to retention, or change the storage location for any category are material changes within the meaning of § 20.4 and are notified to active Controllers on the § 20.4 timeline. Changes that strictly shorten retention or strictly improve the protections are non-material under § 20.4 but are nevertheless notified for transparency in the next DPA revision.

Annex B — Technical and organisational measures (TOMs) per Art. 32 GDPR

The technical and organisational measures listed in this Annex are JJ Online's current measures. They may be updated in accordance with § 8.3.

B.1 Confidentiality

Measure	Implementation
Access control to systems	Multi-factor authentication required for all JJ Online operational staff accessing production infrastructure; least-privilege access; access reviewed quarterly
Access control to data	Per-customer logical isolation in the application layer; database-level encryption at rest; least-privilege query access for support staff
Pseudonymisation	RUM visitor IPs are truncated to /24 IPv4 and /48 IPv6 prior to storage (rationale set out at B.1.1 below); database-resident PII in transaction screenshots is not separately pseudonymised by JJ Online (the Controller is responsible for what their transaction script traverses)
Encryption in transit	TLS 1.2+ enforced for all customer-facing interfaces and all sub-processor communications; certificate management automated with renewal alerts
Encryption at rest	Application database and time-series database use disk-level encryption on EU infrastructure; backups encrypted under a separately-managed key
Column-level encryption of customer-entrusted credentials	Credentials and secrets the Controller supplies for the Service to authenticate against the Controller's own resources (HTTP authentication credentials, custom request headers, alert-channel integration credentials, transaction-step literal values) are held under column-level envelope encryption layered on top of disk-level encryption; keys are managed separately from the database, so operational staff with database access cannot read the cleartext; decryption occurs at probe execution time only, with the cleartext held in memory for the duration of a single check. Personal API keys issued for programmatic access to the Service are stored as one-way hashes (no recoverable cleartext)
Transactional email regional routing (non-essential means under § 6.2)	Routing of transactional email between the AWS SES `eu-central-1` (Frankfurt) and `us-east-1` (Virginia) endpoints is performed automatically by JJ Online's mail-dispatch layer on the basis of a deterministic classification of the recipient email address. The classification is designed so that mail to EU recipients is routed to the EU endpoint and mail to non-EU recipients is routed to the US endpoint, subject to deliverability fallbacks. The methodology is documented internally and disclosable on audit-information request under § 14.1 (d). No Controller knob is currently exposed; a Controller-elected EU-only override is available on written request to privacy@uptimia.com pending the roadmap item described at § 10.2 (b)

B.1.1 Rationale for the /24 IPv4 and /48 IPv6 truncation thresholds

The truncation thresholds applied to RUM visitor IP addresses are JJ Online's TOM choice for the non-essential means of processing under § 6.2 and EDPB Guidelines 07/2020 ¶ 38, and are documented here in concrete terms so that the Art. 32 GDPR sufficiency analysis rests on a verifiable engineering claim rather than aspirational wording.

(a) /24 IPv4 truncation. The trailing eight bits (the host portion within a typical residential or commercial /24 allocation) are removed; the remaining /24 prefix is what is persisted. This is the long-established supervisory-authority baseline for IP anonymisation in web analytics — the EDPB and several Member State authorities (e.g. CNIL, DSK in the German Orientierungshilfe der Aufsichtsbehörden für Anbieter von Telemedien line) have treated /24 IPv4 truncation as sufficient pseudonymisation in the analytics context, on the analysis that the /24 prefix retains country-and-region geographic resolution but no longer permits singling-out of an individual household terminal within that /24.

(b) /48 IPv6 truncation. The trailing 80 bits — the subnet (16 bits) and the interface identifier (64 bits) — are removed; the remaining /48 routing prefix is what is persisted. /48 is the prefix length that, in standard RIR/ISP IPv6 allocation practice (RIPE-690 / RIPE BCP for residential ISP customers; ARIN / APNIC similarly), corresponds to an aggregate routing block above the per-customer allocation. Truncating to /48 retains country-and-region geographic resolution comparable to the /24 IPv4 case but removes (i) the customer-side subnet allocation (the IPv6 /56 or /64 a residential ISP typically delegates per subscriber) and (ii) the interface identifier within that subnet (the host-level identifier).

(c) Why not /64 IPv6. /64 truncation drops only the interface identifier, retaining the subnet identifier. In residential IPv6 deployments the /64 typically corresponds to a single LAN segment within a single subscriber's home network and remains, in combination with the browser-fingerprint surface JJ Online does process for RUM purposes (browser/device information, geographic origin, error context), capable of singling-out a single household terminal under the Art. 29 Working Party Opinion 05/2014 on Anonymisation Techniques three-test framework. /48 was selected over /64 on this analysis.

(d) Why not /56 IPv6. /56 is the standard ISP allocation to a single residential customer under RIPE-690 — i.e., truncating to /56 retains the per-customer allocation. /56 was not selected for the same singling-out reason as /64.

(e) Why not full IP discard. A small but non-zero amount of network-level identifier is retained because (i) RUM utility for the Controller requires country-and-region geographic resolution of visitor sessions, which the truncated prefix supports; and (ii) the truncated prefix supports basic abuse-protection signal at the analytics layer (detection of malformed-script bot traffic) without re-introducing host-level identification.

(f) BfDI orientation papers — variance noted. JJ Online is aware that BfDI orientation has at different times referenced /64 IPv6 (in some contexts) and full anonymisation (in others) as targets, and that there is no single binding figure across all use cases. The /48 choice is JJ Online's TOM determination on the analysis above, with the understanding that a competent supervisory authority may, on the specific use case, require a different threshold; in that event the threshold is adjusted as a § 20.4 update.

The truncation is globally enforced at the RUM ingestion layer — i.e., it is applied to every RUM beacon at the EU-located ingestion endpoint before any downstream persistence — and is not configurable per monitor or per Controller. A Controller cannot opt to retain full visitor IPs.

B.2 Integrity

Measure	Implementation
Input validation	Application-layer input validation and parameterised database queries
Anti-malware	Server-side antivirus on application infrastructure; Customer-monitored URLs are checked against Google Web Risk API (security service, not data export to Google for advertising purposes)
Logging and audit trails	Application and access logs retained for at least 90 days; security-relevant log events monitored

B.3 Availability

Measure	Implementation
Backup and restore	Daily encrypted backups of the application database and time-series database; recovery time objective (RTO) and recovery point objective (RPO) documented internally; backups tested periodically
Geographic redundancy	Primary application infrastructure in OVH France; backup replication to a separate failure domain
Probe-network resilience	Multi-region probe deployment across nine providers (OVH, GCore, DigitalOcean, Akamai/Linode, EDIS, Scaleway, AWS, Contabo, Vultr) spanning EU and non-EU regions; transient (no at-rest) data storage at probe layer prevents data accumulation on probe infrastructure
DDoS mitigation	Provider-level DDoS protection at OVH France

B.4 Resilience and recovery

Measure	Implementation
Incident response	Defined incident response procedure with named roles; post-incident review for material incidents
Disaster recovery	Documented disaster recovery plan; backup restoration tested at least annually

B.5 Regular testing, assessing and evaluating

Measure	Implementation
Vulnerability scanning	Periodic automated scanning of customer-facing surfaces
Dependency monitoring	Automated monitoring of third-party library vulnerabilities (composer + npm); critical updates applied within 14 days
Code review	All production changes reviewed before merge
Penetration testing	Independent third-party penetration testing at least annually. Scope covers the customer-facing application surfaces — the Uptimia dashboard, the public API, and the Controller-facing status pages. The test is commissioned from a qualified external provider; a summary of the test scope, the test date, and the remediation status of any material findings is available to the Controller on audit-information request under § 14.1 (d). A material finding is remediated, mitigated, or formally accepted (with documented risk rationale) before the next testing cycle, and any remediation gap that crosses the next-cycle boundary is itself disclosed in the summary. Where a Controller's contractual obligations require a broader scope than the customer-facing surfaces — for example, a scope that explicitly includes admin / privileged surfaces or the probe network — the Controller may commission that additional scope under § 14.2 on the Controller's own audit-cost basis.

B.6 Specific measure — ephemeral probe processing

A specific design property of the Uptimia probe network is that no Customer Personal Data is persisted to non-volatile storage on the probe infrastructure. The technical property is described in concrete terms below so that the supplementary-measure analysis for non-EU probe Sub-processors (in particular Vultr, which is not DPF-certified) rests on a verifiable engineering claim and not on aspirational wording.

(a) In-memory only on the probe host. The probe binary holds the check inputs (the URL, request headers, body, authentication credentials decrypted at check-execution time) and the check outputs (response status, response headers, response body or its truncated/hashed form, transaction screenshots in transit) in process memory only. There is no write of check inputs or outputs to any file on the probe host's local disk during normal operation.

(b) Result forwarded to EU infrastructure, then discarded. Once the check is complete, the probe forwards the result over an authenticated TLS channel to the JJ Online-operated EU infrastructure (OVH France for the application database, self-hosted time-series database for time-series metrics, AWS S3 eu-central-1 Frankfurt for screenshot blobs). The probe-side in-memory copy is then discarded as the probe process terminates or returns to its idle state.

(c) Process restart between checks. The probe process is restarted on a short cycle between checks, so that no in-memory state persists across checks.

(d) No probe-side log retention of response payloads. Probe-side logs (where they exist for operational diagnostics) record only check-id, timestamp, target hostname, and a result code. They do not retain response bodies, response headers other than non-personal metadata, transaction screenshot contents, or decrypted credentials.

(e) No use of the probe host's persistent storage for Customer Personal Data. Where the probe host provides persistent disk volumes, they are used only for the probe binary itself, the OS, and operational telemetry that contains no Customer Personal Data.

(f) Periodic verification of the ephemeral-processing property. JJ Online verifies the engineering claims in (a)–(e) above at least annually, and additionally after any change to the probe binary, the probe host operating-system image, or the probe deployment runbook that could materially affect those claims. The verification is performed against a representative sample of probe hosts drawn from across the probe Sub-processors listed at Annex C.2 (including at least one non-EEA Vultr probe host and at least one host from each other probe Sub-processor in active use) and expressly includes kernel-level configuration checks designed to prevent persistent storage of any volatile-state-to-disk artefact (including, without limitation, crash dumps, core dumps, kernel panics, memory snapshots, hibernation images, swap-file writes, and hypervisor / cloud-provider snapshot facilities) that would defeat the ephemeral-processing property. The specific kernel-level controls verified at each cycle are recorded in the internal verification runbook and are disclosable to the Controller on audit-information request under § 14.1 (d) under appropriate confidentiality protections.

A summary of the most recent verification — the date, the sample of probe hosts checked, the outcome of the kernel-level configuration checks, and the remediation status of any deficiency identified — is available to the Controller on audit-information request under § 14.1 (d). A material deficiency identified by the verification is remediated, mitigated, or formally accepted (with documented risk rationale) before the next verification cycle, and any deficiency that crosses the next-cycle boundary is itself disclosed in the next summary. Where remediation requires a change to the supplementary-measures analysis for a non-EEA probe Sub-processor (in particular Vultr), the change is notified to active Controllers as a presumptive § 20.4 (v) TOM-reduction.

This is the principal supplementary measure relied on for non-EEA probe Sub-processors, in particular Vultr Holdings, LLC. The measure is implemented and controlled at the JJ Online deployment layer — it is a JJ Online TOM rather than a contractual property of the underlying IaaS Sub-processor — and is documented in the internal runbook that governs probe deployment. A description of the runbook step is available to the Controller on audit request under § 14.

B.7 Personnel

Measure	Implementation
Confidentiality obligations	All operational personnel bound by written confidentiality obligations; ongoing training on data protection requirements
Background screening	Standard for personnel with production access

B.8 Sub-processor due diligence

Measure	Implementation
Sub-processor selection	Sub-processors selected with consideration of their data protection practices, DPF certification status (where relevant), and DPA/DPA availability
Sub-processor monitoring	Sub-processor list reviewed at least annually; material changes notified per § 9.3

Annex C — Approved Sub-processors

The current list of Sub-processors engaged by JJ Online for the processing of Customer Personal Data on the Controller's behalf in connection with the Uptimia Service is set out below. Annex C is itself the canonical Sub-processor list — updates are notified to the Controller by email under § 9.3 and reflected in an updated version of this DPA.

Note for the Controller: Sub-processors marked as "Controller-configured" in the Function column only process Customer Personal Data where the Controller chooses to enable that particular channel or feature. Sub-processors marked "Default" or "Required" process Customer Personal Data for every Controller using the Service.

C.1 Payments and billing

Sub-processor	Legal entity	Location	Function	Transfer mechanism
Stripe	Stripe Payments Europe Ltd.	Ireland (+ US sub-processing)	Required — subscription billing, fraud detection	DPF + SCC fallback
PayPal	PayPal (Europe) S.à r.l. et Cie, S.C.A.	Luxembourg (+ US sub-processing)	Default — alternative checkout option	DPF + SCC fallback
easybill	easybill GmbH	Germany	Required — invoice generation, statutory archiving	n/a (EU-only)

C.2 Hosting and infrastructure

Sub-processor	Legal entity	Location	Function	Transfer mechanism
OVH	OVH SAS	France	Required — main application hosting (dashboard, API, database) + probe network EU region	n/a (EU)
AWS EU	Amazon Web Services EMEA SARL	Luxembourg (eu-central-1 Frankfurt + S3)	Required — transactional email SES to EU recipients + transaction-monitoring screenshot blob storage on S3 + invoice PDF / export storage on S3 + probe network (EU regions)	n/a (Frankfurt EU region)
AWS US	Amazon Web Services, Inc.	USA (us-east-1 Virginia)	Default — transactional email SES to non-EU recipients as determined by the automatic recipient-region routing logic disclosed at § 10.2 (b) and Annex B.1 (routing is a non-essential means under § 6.2; no Controller knob currently exposed) + probe network (non-EU regions)	DPF + SCC fallback
GCore	G-Core Labs S.A.	Luxembourg + global regions	Default — probe network	n/a EU regions; SCC for non-EU regions if used
DigitalOcean	DigitalOcean, LLC	USA + regions	Default — probe network	DPF + SCC fallback
Linode / Akamai	Akamai Technologies, Inc.	USA + regions	Default — probe network	DPF + SCC fallback
EDIS	EDIS Telekommunikation GmbH (operating as EDIS.at)	Klagenfurt, Austria	Default — probe network EU region	n/a (EU)
Scaleway	Scaleway SAS (Iliad Group)	France (Paris HQ) — probe regions in France (Paris), the Netherlands (Amsterdam), and Poland (Warsaw); all EU	Default — probe network EU regions	n/a (EU)
Contabo	Contabo GmbH	Germany (Munich HQ) — probe regions across EU (Germany — Nuremberg / Düsseldorf, Austria, Spain, Portugal) and non-EU (USA — St. Louis, United Kingdom, Singapore, Australia — Sydney, Japan — Tokyo, India — Chennai)	Default — probe network	EU regions: n/a (Contabo GmbH is the EU contracting entity). Non-EU regions: SCC (Commission Implementing Decision (EU) 2021/914, Module 3) for the physical-processing leg at non-EU Contabo infrastructure, with the ephemeral-processing property described in Annex B.6 (verified at least annually per B.6 (f), including the explicit check against crash-dump, core-dump, memory-snapshot, and swap-write persistence) as the principal supplementary measure relied on — the probe layer holds no Customer Personal Data at rest regardless of region. Contabo GmbH's EU-headquartered status is a more protective posture than a US-controlling-entity equivalent (cf. Vultr below), because the contracting counterparty for purposes of supervisory-authority cooperation and Data Subject rights sits in the EU.
Vultr	Vultr Holdings, LLC (The Constant Company, LLC)	USA (Delaware) — 13 probe locations across USA, Netherlands (Amsterdam), Germany (Frankfurt), United Kingdom (London), Australia (Sydney), Japan (Tokyo)	Default — probe network	No DPF certification — SCC + supplementary measures; the ephemeral-processing property described in Annex B.6 (verified at least annually per B.6 (f), including an explicit check against crash-dump, core-dump, memory-snapshot, and swap-write persistence) is the principal supplementary measure relied on, since the probe layer holds no Customer Personal Data at rest. EU-located Vultr regions do not by themselves resolve the cross-border issue because Vultr's controlling entity is in the USA.

C.3 Authentication

Sub-processor	Legal entity	Location	Function	Transfer mechanism
Auth0	Auth0 EMEA Limited (Okta Group)	Ireland (+ US sub-processing)	Required — identity management, login flow, social-connection orchestration	DPF + SCC fallback

Auth0 social-connection sub-sub-processors. Where the Controller's end-user chooses to sign in via a social connection on the Auth0-hosted login page, Auth0 hands the OAuth flow off to the chosen identity provider. There is no direct OAuth integration between Uptimia and these providers — they are reached only through Auth0, and Auth0 holds the underlying DPA. Listed here for transparency under Art. 28 (2) GDPR.

Sub-sub-processor	Legal entity	Location	Function	Transfer mechanism
Google (Auth0 social connection)	Google Ireland Limited	Ireland (+ US sub-processing via Google LLC)	"Sign in with Google" — fires only when the end-user chooses Google on the Auth0 login page	DPF + SCC fallback (held by Auth0)
GitHub (Auth0 social connection)	GitHub, Inc. (Microsoft Group)	USA (EU subsidiary: Microsoft Ireland Operations Limited)	"Sign in with GitHub" — fires only when the end-user chooses GitHub on the Auth0 login page	DPF + SCC fallback (held by Auth0)

C.4 Security and threat intelligence

Sub-processor	Legal entity	Location	Function	Transfer mechanism
Google Web Risk API	Google Ireland Limited	Ireland (+ US sub-processing)	Default — malware/phishing screening of monitored URLs	DPF + SCC fallback
Google PageSpeed Insights	Google Ireland Limited	Ireland (+ US sub-processing)	Required — page-speed monitoring	DPF + SCC fallback

C.5 Alert delivery channels (Controller-configured)

C.5 is organised in two tiers. Default-available channels (C.5.1) are surfaced on the standard alert-channel menu in the Service and require no additional acknowledgement beyond the general Art. 28 (3)(a) GDPR instruction recorded by the act of configuration (§ 1.3 (b)). Restricted Channels (C.5.2) are not on the default menu and require a per-channel in-product acknowledgement of the disclosed transfer posture before activation (§ 1.3 (b), § 10.5); JJ Online retains the acknowledgement as part of the instruction record under § 14.1 (e).

C.5.1 Default-available channels

Sub-processor	Legal entity	Location	Function	Transfer mechanism
Twilio	Twilio Ireland Limited	Ireland (+ US sub-processing)	Controller-configured — SMS alerts	DPF + SCC fallback
Meta WhatsApp Cloud	Meta Platforms Ireland Limited	Ireland (+ US sub-processing)	Controller-configured — WhatsApp alerts via WhatsApp Business Cloud API	DPF + SCC fallback
Slack	Slack Technologies Limited (Salesforce Group)	Ireland (+ US sub-processing)	Controller-configured — Slack workspace alerts	DPF + SCC fallback
Microsoft Teams	Microsoft Ireland Operations Limited	Ireland (+ US sub-processing)	Controller-configured — Teams workspace alerts	DPF + SCC fallback
Discord	Discord Netherlands BV	Netherlands (+ US sub-processing)	Controller-configured — Discord server alerts	DPF + SCC fallback
Mattermost	Mattermost, Inc.	USA	Controller-configured — Mattermost workspace alerts	DPF + SCC fallback
PagerDuty	PagerDuty, Inc.	USA	Controller-configured — incident creation	DPF + SCC fallback
Atlassian Statuspage	Atlassian B.V.	Netherlands (+ US sub-processing by Atlassian, Inc.)	Controller-configured — incident creation on Customer's Statuspage	DPF + SCC fallback. EU contracting entity verified at the version date of this DPA from JJ Online's then-current Atlassian Cloud Subscription Agreement / Order Form covering the Statuspage subscription. Atlassian's contracting entity for EU cloud subscriptions has historically varied between Atlassian Pty Ltd (Australia) and Atlassian B.V. (Netherlands) depending on product, region, and order date; the entity recorded here is the one shown on JJ Online's then-current Atlassian-side contract for Statuspage. If Atlassian migrates JJ Online's Statuspage subscription to a different contracting entity (or if a contract renewal results in a different entity appearing on the Order Form), this row is updated under § 20.4 (i) (Sub-processor location / contracting-entity change) as a presumptive material change. Atlassian, Inc. as the US sub-processor is DPF-certified at the version date of this DPA.
Generic webhooks	(variable — Controller-chosen destination)	(variable)	Controller-configured — custom alert delivery	Controller's responsibility

C.5.2 Restricted Channels (activation requires in-product acknowledgement)

Restricted Channels are not part of the default alert-channel menu. To activate a Restricted Channel the Controller must, through an authorised user of the Controller's account, confirm an in-product acknowledgement of the per-channel transfer posture set out below. JJ Online retains a timestamped record of each acknowledgement (account ID, user identifier, channel, this Annex's disclosure version, acknowledgement timestamp) and produces it on supervisory-authority or Controller request. A fresh acknowledgement is required if the channel is deactivated and later re-activated, or if this Annex's disclosure version for the channel changes.

Sub-processor	Legal entity	Location	Function	Transfer mechanism
Telegram	Telegram FZ-LLC	UAE	Controller-configured — Telegram bot alerts	Acknowledgement tier: Tier 2 — Elevated-risk Restricted Channel (§ 1.3 (b) Two-tier acknowledgement standard). No adequacy decision for UAE. Telegram FZ-LLC does not offer Commission SCCs (Module 3) to bot operators, so no Art. 46 GDPR mechanism is available for this channel. JJ Online does not itself assert an Art. 49 GDPR derogation for the transfer: routine outage alerting is not occasional or non-repetitive within the meaning of EDPB Guidelines 2/2018, and Art. 49 (1)(c) — "contract in the interest of the Data Subject" — is not a comfortable fit for an alert routed to the Controller's operations team. The Controller, by completing the Tier 2 elevated-risk acknowledgement at § 1.3 (b) and configuring Telegram as their chosen alert channel under § 10.5, positively acknowledges the EDPB Guidelines 2/2018 narrow-derogation analysis, confirms an independent Art. 44–49 GDPR evaluation for their own circumstances, and accepts the supervisory-authority risk that a competent SA may find the transfer unlawful. Customers who cannot or do not want to bear that risk should choose a channel from C.5.1 instead.
X (formerly Twitter)	X Corp.	USA	Controller-configured — status update posting	Acknowledgement tier: Tier 1 — Standard Restricted Channel (§ 1.3 (b) Two-tier acknowledgement standard). X Corp's DPF certification status has been historically volatile; this Annex's "current DPF status" determination is made at the version date of this DPA and may shift between Annex updates. JJ Online's transfer posture is therefore SCC + supplementary measures as the operative mechanism, with DPF treated as opportunistic additional cover where the current certification holds. By completing the Tier 1 standard acknowledgement the Controller confirms awareness of (i) the SCC + supplementary-measures basis, (ii) the DPF volatility, and (iii) the Controller's own Art. 44–49 GDPR analysis for the resulting transfer. If at any future Annex revision JJ Online determines that the SCC + supplementary-measures basis itself becomes structurally unavailable for X Corp (e.g. material adverse supervisory-authority action against SCC reliance for the platform), this row moves to Tier 2 and prior Tier 1 acknowledgements are treated as expired (§ 1.3 (b)).

C.6 Marketing-page integrations (visitor-data only, not Customer Personal Data)

Sub-processor	Legal entity	Location	Function	Transfer mechanism
FirstPromoter	Igil Webs SRL (30 Talmacelului St., Talmaciu, Sibiu county, Romania; sole identification number 30864432)	Romania	Affiliate attribution on uptimia.com marketing pages — fires only when the URL carries `?via=<code>`	n/a (EU)

Note: FirstPromoter processes data of visitors to uptimia.com marketing pages, not Customer Personal Data of the Controller's users. It is included here for transparency but is not strictly part of the Art. 28 sub-processor chain for the Service itself.

C.7 Not Sub-processors (first-party / internal)

The following are operated by JJ Online itself and are NOT Sub-processors under this DPA:

Self-hosted time-series database (operated by JJ Online on its own EU infrastructure) — time-series storage for monitoring metrics. NOT a Sub-processor.
Altcha (proof-of-work captcha library, executed locally on Uptimia infrastructure — no third-party data flow). NOT a Sub-processor.
Datriva CMP (JJ Online sister product) — cookie consent banner on uptimia.com marketing pages. Same controller (JJ Online GmbH); not an Art. 28 Sub-processor.
HelpCanvas (JJ Online sister product) — live-chat widget on uptimia.com marketing pages. Same controller; not an Art. 28 Sub-processor.
Uptimia RUM (own product — first-party self-dogfooded) — first-party RUM on uptimia.com marketing pages.
ErrorHawk (JJ Online sister product) — out of production scope. The ErrorHawk DSN is configured only on our internal development environment, which does not carry real user data. Production uptimia.com does not forward exceptions to ErrorHawk. No Customer Personal Data of Uptimia customers is routed through ErrorHawk. If ErrorHawk is ever wired into production, it must be promoted from this section to Annex C and a Sub-processor change notification issued under § 9.3.

For all items in this section, no Customer Personal Data of Uptimia customers is routed to a third party. Datriva, HelpCanvas, and Uptimia RUM process visitor data on uptimia.com marketing pages under JJ Online GmbH's own controller responsibility (i.e., as the controller for the marketing site, not as a processor under this DPA).

Annex D — International data transfers (Module 2 / Module 3 SCCs)

D.1 Module incorporation

For the purposes of Art. 46 (2) (c) GDPR. JJ Online's main establishment is in Berlin (EEA); JJ Online is therefore the data exporter whenever Customer Personal Data is transferred to a non-EEA Sub-processor. Module 3 is the operative module for those onward transfers; Module 2 (Controller-to-Processor) is the operative module only in the narrower case in which the Controller is itself established outside the EEA and the transfer to JJ Online in Berlin is itself the SCC-governed transfer.

(a) Module 3 — JJ Online → non-EEA Sub-processor (the principal case). Where JJ Online's onward transfer to a Sub-processor is to a destination outside the EEA, the Parties incorporate by reference Module 3 (Processor-to-Processor) of the Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), with JJ Online acting as data exporter and the Sub-processor as data importer.

(b) Module 2 — non-EEA Controller → JJ Online (residual case). Where the Controller is itself established outside the EEA and uses the Service such that the Controller's own transfer of Customer Personal Data to JJ Online in Berlin is the SCC-governed transfer, the Parties incorporate by reference Module 2 (Controller-to-Processor), with the Controller acting as data exporter and JJ Online acting as data importer. The Parties recognise that the application of the SCCs to a transfer whose importer is established in the EEA is itself debated; this paragraph (b) is included as a belt-and-braces incorporation for Controllers whose home regime treats the transfer-to-EEA-importer leg as an SCC-eligible transfer.

(c) Each module is read with the Annexes set out below, which incorporate by reference the corresponding content of this DPA's Annexes A, B and C.

D.2 Annex I to the SCCs

List of Parties. As set out in the Preamble to this DPA.

Description of Transfer. As set out in Annex A.

Competent Supervisory Authority. The competent supervisory authority for the purposes of Annex I to the Standard Contractual Clauses is the Berliner Beauftragte für Datenschutz und Informationsfreiheit (BlnBDI), Alt-Moabit 59-61, 10555 Berlin, Germany — as the lead supervisory authority for JJ Online's main establishment in Berlin under Art. 56 (1) GDPR. This designation is specific to Annex I of the SCCs and is without prejudice to the Controller's own lead supervisory authority under Art. 56 (1) GDPR, to any concerned supervisory authority under Art. 4 (22) GDPR, and to JJ Online's general cooperation duty under § 14.4 of this DPA in respect of the Art. 60 GDPR one-stop-shop mechanism.

D.3 Annex II to the SCCs — Technical and Organisational Measures

As set out in Annex B of this DPA.

D.4 Annex III to the SCCs — List of Sub-processors

As set out in Annex C of this DPA.

D.5 UK transfer mechanism — Addendum (default) or IDTA (alternative)

For transfers subject to the UK GDPR, the Parties incorporate one of two ICO-issued instruments, at the Controller's election under § 10.3 (c):

(a) Default — UK Addendum. The Parties incorporate by reference the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses issued by the UK Information Commissioner's Office and laid before Parliament on 2 February 2022. The information required by Table 1 of the Addendum is set out in the Preamble of this DPA; Table 2 selects the appropriate module of the SCCs as per §D.1; Tables 3 and 4 are not relevant. The UK Addendum is the default election because it preserves the Commission SCCs as the underlying instrument and reduces drafting fragmentation across parallel EEA-and-UK transfer chains.

(b) Alternative — standalone IDTA. Where the Controller notifies JJ Online in writing under § 10.3 (c) that the Controller prefers the standalone International Data Transfer Agreement (IDTA) issued by the ICO and laid before Parliament on 2 February 2022, the Parties incorporate the IDTA in place of the UK Addendum for transfers subject to the UK GDPR. The IDTA is a standalone instrument and does not depend on the Commission SCCs; the Parties complete Part 1 (Parties), Part 2 (Transfer Details), and Part 3 (Mandatory Clauses) of the IDTA using the information set out in the Preamble of this DPA and at Annex A.

Both instruments are recognised by the ICO as valid Art. 46 UK GDPR transfer mechanisms. The election is the Controller's; absent a written election, the default at (a) applies.

D.6 Swiss FADP

For transfers subject to the Swiss FADP, the SCCs are read with the Swiss-specific amendments published by the Federal Data Protection and Information Commissioner: references to "Member State" include "Switzerland", references to the GDPR include corresponding FADP provisions, the competent supervisory authority is the Swiss FDPIC, and the term "personal data" includes data of legal persons until that protection is removed from the FADP.

D.7 Supplementary Measures

In line with EDPB Recommendations 01/2020 on supplementary measures, JJ Online assesses for each non-EEA transfer:

(a) whether the destination country provides essentially equivalent protection;

(b) where it does not, whether the technical measures (in particular encryption in transit and at rest) and contractual measures (in particular the requirement that Sub-processors notify JJ Online of any government access request) are sufficient;

(c) whether transparency about government access requests is operationally provided (JJ Online publishes a transparency report annually where it has received such requests; as of the Stand date, no such requests have been received).

Annex E — Contact information

For DPA-related notices, sub-processor change notifications, Data Subject request forwarding, and breach notifications:

JJ Online GmbH Attn: Data Protection Schönhauser Allee 163, 10435 Berlin, Germany Email: admin@uptimia.com

Data Protection Officer: Not appointed. JJ Online is below the threshold for mandatory DPO appointment under § 38 Abs. 1 BDSG (fewer than 20 persons constantly engaged in automated processing, no Art. 35 DPIA-triggering core activity, no processing of Special Categories of Personal Data as core activity). The Controller may direct data-protection enquiries to the contact above; Andrius Gecius (Managing Director) is the responsible point of contact.

Lead Supervisory Authority: Berliner Beauftragte für Datenschutz und Informationsfreiheit (BlnBDI), Alt-Moabit 59-61, 10555 Berlin, Germany — competent for JJ Online's main establishment.

#Preamble

#Parties

#Recitals

#Definitions

#1. Subject matter and scope

#2. Duration

#3. Nature and purpose of processing

#4. Type of Personal Data and categories of Data Subjects

#5. Roles and responsibilities

#6. Processing on documented instructions

#7. Confidentiality

#8. Security of processing (Art. 32 GDPR)

#9. Sub-processor engagement (Art. 28 (2) GDPR)

#10. International data transfers (Art. 44–49 GDPR)

#11. Assistance with Data Subject requests (Art. 12–22 GDPR)

#12. Personal Data breaches (Art. 33–34 GDPR)

#13. DPIA and prior consultation (Art. 35–36 GDPR)

#14. Audit rights (Art. 28 (3) (h) GDPR)

#15. End-of-contract treatment of data (Art. 28 (3) (g) GDPR)

#16. Records of processing (Art. 30 (2) GDPR)

#17. Liability

#18. Term and termination

#19. Order of precedence

#20. Miscellaneous

#Annex A — Subject matter, nature, purpose, data categories, Data Subjects

#A.1 Subject matter of processing

#A.2 Duration of processing

#A.3 Nature and purpose of processing

#A.4 Types of Customer Personal Data

#A.5 Categories of Data Subjects

#A.6 Special Categories of Personal Data (Art. 9 GDPR)

#A.7 Data of children (Art. 8 GDPR / national thresholds)

#A.8 Per-account Processing Instructions Summary

#A.9 Retention schedule (Customer Personal Data — DPA scope)

#Annex B — Technical and organisational measures (TOMs) per Art. 32 GDPR

#B.1 Confidentiality

#B.1.1 Rationale for the /24 IPv4 and /48 IPv6 truncation thresholds

#B.2 Integrity

#B.3 Availability

#B.4 Resilience and recovery

#B.5 Regular testing, assessing and evaluating

#B.6 Specific measure — ephemeral probe processing

#B.7 Personnel

#B.8 Sub-processor due diligence

#Annex C — Approved Sub-processors

#C.1 Payments and billing

#C.2 Hosting and infrastructure

#C.3 Authentication

#C.4 Security and threat intelligence

#C.5 Alert delivery channels (Controller-configured)

#C.5.1 Default-available channels

#C.5.2 Restricted Channels (activation requires in-product acknowledgement)

#C.6 Marketing-page integrations (visitor-data only, not Customer Personal Data)

#C.7 Not Sub-processors (first-party / internal)

#Annex D — International data transfers (Module 2 / Module 3 SCCs)

#D.1 Module incorporation

#D.2 Annex I to the SCCs

#D.3 Annex II to the SCCs — Technical and Organisational Measures

#D.4 Annex III to the SCCs — List of Sub-processors

#D.5 UK transfer mechanism — Addendum (default) or IDTA (alternative)

#D.6 Swiss FADP

#D.7 Supplementary Measures

#Annex E — Contact information