Privacy Policy

Last updated: 27 May 2026

Controlling language. This Privacy Policy is published in English and translated into one or more additional languages for convenience. In case of conflict or ambiguity between language versions, the English version prevails.

#1. Introduction

This notice describes how Uptimia ("we", "us", or "our"), operated by JJ Online GmbH, processes your personal data in connection with https://uptimia.com (the "Website") and the Uptimia monitoring service (the "Service"), in line with Articles 13 and 14 of the GDPR and equivalent data-protection law. It is provided for your information; where processing depends on your consent, that consent is collected separately. For the terms that govern your contractual relationship with us, see our Terms of Service.

Direct and indirect collection (Art. 13 and Art. 14 GDPR). Most of the personal data described in § 3 is provided to us directly by you when you create an account, configure monitors, or otherwise use the Service. Where any item is instead collected from a third party — specifically:

• payment-method metadata returned by Stripe or PayPal in connection with your subscription;
• PayPal Instant Payment Notification (IPN) payloads received from PayPal in connection with each transaction, which may include transaction-context fields (settlement currency, payer status, address-confirmation status) that were not originally provided by you;
• identity attributes returned by Google or GitHub through the Auth0-hosted login page where you elect to sign in via a social connection (and the associated tokens issued by Auth0);
• address normalisation, VAT-ID validation outputs, and other invoice-generation metadata returned by easybill in connection with the issuance of your invoice (where easybill returns a field — such as a normalised postal address or a VAT-ID validity flag from the EU VIES system queried through easybill — that was not literally typed by you, that field is collected indirectly);

— the third party that is the source of that data is identified in the relevant entry of § 5 (Third-Party Services) below, in satisfaction of our Art. 14 (2)(f) GDPR obligation to name the source. Outside those specific flows, no personal data we hold about you as an account holder is obtained from a third party.

#2. Data controller

For the purposes of the GDPR (Art. 4 (7)) and equivalent data-protection laws, the controller responsible for the processing of your personal data as an Uptimia account holder is:

JJ Online GmbH (operating Uptimia)

Schönhauser Allee 163, 10435 Berlin

Germany

Registered at: Amtsgericht Berlin-Charlottenburg, HRB 235074 B

USt-IdNr.: DE351060880

Represented by: Andrius Gecius, Geschäftsführer (Managing Director)

Phone: +49 151 12032902

Email — general / Imprint: admin@uptimia.com

Email — privacy and data-subject requests: privacy@uptimia.com

Full provider identification as required by § 5 DDG is set out in our Imprint (English) / Impressum (German).

Note on roles. Where you use Uptimia to monitor resources you operate, you act as the data controller in respect of personal data your monitoring touches — visitor IP addresses captured by RUM scripts you deploy, end-user data captured in transaction-monitoring screenshots, authenticated-check response payloads that include user information. In that scenario Uptimia acts as a data processor for you, governed by our DPA — see § 7 below.

This Policy describes our processing as a controller of your own data as a user of the Service. The processor relationship is described in § 7 and in the DPA.

#3. Information we collect

We collect the following categories of personal data about users of the Service.

#Account data

• Identity: email address, password (stored as a bcrypt hash; legacy hashes are upgraded on first successful sign-in), full name, an opaque account-resumption token
• Postal address: street, postal code, city, state, country, time zone
• Business identification: company name, VAT identification number, currency, billing region (two-character ISO code)
• Contact: phone number, reporting email, custom sender label for outbound mail
• Network metadata: the IP address from which you registered and the IP address from which you most recently signed in
• Lifecycle dates: registration date, last activity date, subscription start, membership-renewal date, SMS-credit-renewal date
• Security: two-factor-authentication state, sign-in email-notification preference, last failed sign-in timestamp, failed sign-in counter, an internal heuristic risk score (advisory; see § 8 and the retention note under § 11)
• Operational preferences: your email-alerting and SMS-alerting opt-in states, unsubscribe state, onboarding flags, "do not alert" days, your alert-hours window
• Marketing / lifecycle: the UTM or referral-source code from the URL through which you first reached us

#Billing data

• Invoice metadata, amounts, references, and stored PDF references
• Payment-method metadata (Stripe / PayPal / credit-card tokens — we never see the full card number)
• Where you pay via PayPal, the PayPal Instant Payment Notification payload received from PayPal in connection with the transaction

#Authentication and session data

• Session cookies as listed in our Cookie Policy § 4
• Two-factor sign-in audit records — user, timestamp, IP address, user-agent — written every time you complete a 2FA challenge
• Password-reset request records — generated on demand when you request a password reset
• Personal API keys you create for programmatic access to the Service — stored as one-way hashes only; see § 12
• Failed sign-in counter and last-failed timestamp on your user record

Two-factor authentication channels. Where you enable two-factor authentication, the one-time code is delivered either by email (via our transactional-mail processor — AWS SES, see § 5.2) or generated locally by a TOTP authenticator application on your device (Google Authenticator, 1Password, Authy, or equivalent). We do not send 2FA codes by SMS and do not transmit your phone number to any SMS provider in the 2FA flow. Where the SMS-alerting feature is separately enabled by you for monitoring alerts, that flow is documented in § 5 and § 7 (Twilio).

#Monitor configurations you create

When you create a monitor, the configuration is stored in our application database and forwarded to the probe network at execution time. Configurations may contain personal data:

• Authenticated HTTP checks: the URL, the HTTP authentication credentials (Basic credentials and/or custom request headers, which may carry bearer tokens or API keys), any POST body you supply, and the expected-content patterns you configure
• Transaction monitors: the CSS selectors and XPath expressions used to drive the journey, together with any literal values (including test credentials) that the journey submits at each step

Credentials and secrets you supply in monitor configurations are held under column-level envelope encryption with separately-managed keys, as described in § 12.

#Check results

Generated by our probe network on every check:

• Uptime / HTTP: per-phase timings, status, error type, and the response body returned by the monitored URL (response bodies are retained for 7 days and then automatically expired, per § 11)
• SSL: certificate issuer, validity dates, and any certificate-related errors observed
• Domain / WHOIS: registrar, nameservers, lifecycle dates, and the full WHOIS response
• Speed: load times, per-resource breakdown, PageSpeed scores
• Transaction: per-step status, duration, and a stored screenshot of the page at each step (the screenshot may include personal data visible on the screen at the time of capture)
• Real User Monitoring (RUM): aggregated metrics only — page-load time, pageviews, JavaScript-error counts, geographic origin, browser and device class. No Core Web Vitals (LCP / INP / CLS / TTFB) are collected (per product scope)
• Virus / malware: the status returned by the malware-screening provider; no scanned payload is retained
• Server agent: CPU, memory, disk, and network metrics streamed by the agent you deploy on your own servers. These metrics describe the health of a server, not a natural person. They are, however, linkable to you as the account holder because the agent is registered against your Uptimia account, and on that linkage we treat them as personal data of you as account holder for the duration of the contractual relationship — processed on Art. 6 (1)(b) GDPR (contract). The agent transmits no end-user identifiers from the monitored server (no process lists, no user-account names, no environment variables); the categories listed above are exhaustive.

Retention windows for each of the categories above are governed by § 11.

#Notification channel configurations

When you configure an alert channel (Slack, Discord, Twilio SMS, Meta WhatsApp Cloud, PagerDuty, Atlassian Statuspage, Microsoft Teams, Mattermost, Telegram, X, generic webhooks), we store the channel credentials and the contact records you supply. Each is forwarded to the chosen channel on every alert.

Dual role of alert channels. Alert channels carry two different categories of data under two different role characterisations, and the same third party (Slack, Twilio, etc.) wears both hats:

• Ops-team contact records and credentials — the phone numbers, Slack workspace and channel identifiers, PagerDuty integration keys, Telegram bot tokens, webhook URLs, etc. that you supply, plus the alert payload itself when it is addressed to your own ops team. These records identify your personnel (your on-call engineers, your incident-response staff), not visitors of your monitored websites. For this leg Uptimia is a controller in respect of the alert-channel data flow, and the alert-channel third parties are Uptimia's own service providers; the lawful basis is Art. 6 (1)(b) GDPR (performance of your subscription contract — alert delivery is the contracted output) and Art. 6 (1)(f) GDPR (legitimate interest of you, the account holder, in being notified). These flows are inventoried in § 5 as part of Uptimia's controller-relationship stack.
• End-user / visitor data that may incidentally appear in an alert payload — e.g., where you have authored a transaction-monitoring step whose failure message contains an end-user identifier, or where an authenticated-check response body extract surfaces personal data of one of your visitors and is included in the alert summary. For that incidental component Uptimia acts as a processor for you (the data Controller), the alert-channel third party becomes a Sub-processor for that leg, and the flow falls under the DPA Annex C.5 sub-processor inventory. This component is the one § 7 below addresses.

The two characterisations co-exist because the alert event is a single message carrying both kinds of content. The § 5 controller-relationship analysis governs the contact-records-and-credentials leg and the alert-addressed-to-your-ops-team leg; the § 7 processor-role analysis governs the embedded-visitor-data leg only.

#Support data

When you contact us, we receive and store the content of the interaction together with the contact identifiers you supply:

• HelpCanvas chat-widget conversations — the chat widget is loaded on the marketing site (https://uptimia.com) and, where you are signed in, in the application surface. Each conversation is stored as the message thread itself, your display name and email address (where you provide them), and the technical metadata HelpCanvas records about the session (timestamps, browser User-Agent, IP address, page URL on which the conversation was started). HelpCanvas is a JJ Online product running on JJ Online's own EU infrastructure (see § 5.7 below); the conversation does not leave the EU and is not shared with any third party that is not already a sub-processor for HelpCanvas.
• Email correspondence to our role addresses — admin@uptimia.com (general), privacy@uptimia.com (privacy and data-subject requests), and any other role address you write to. We receive and store the email headers (your sender address, our recipient address, timestamps, message-id), the message body, and any attachments you choose to send. Inbound and outbound mail is processed through AWS SES eu-central-1 (see § 5.2) and stored on JJ Online's own EU mail infrastructure.

Categories. Identifiers (name, email address), free-text content (your message and any attachments), and technical metadata (timestamps, IP, User-Agent, page context for the chat widget; SMTP headers for email).

Lawful basis. Art. 6 (1)(b) GDPR where the correspondence relates to performance of the Service contract you have with us (e.g. a feature question on a paid account); Art. 6 (1)(c) GDPR where the correspondence is itself the discharge of a legal obligation (e.g. responding to an Art. 12–22 GDPR data-subject request); Art. 6 (1)(f) GDPR for inbound enquiries from prospects and other correspondents we have no contract with, with the legitimate interest being to respond to inbound communications addressed to our published role addresses.

Recipients. Internal: members of JJ Online GmbH who handle the relevant support, billing, or privacy queue. External sub-processors: AWS SES eu-central-1 for email transport (§ 5.2); the HelpCanvas application stack runs on JJ Online's own EU infrastructure and does not introduce a third-party recipient (§ 5.7 and § 11 "HelpCanvas-hosted support conversations"). No support content is shared with third parties beyond what is necessary to deliver the email or to action your specific request (for example, where you ask us to forward a billing query to Stripe, we will do so on your instruction).

Retention. Duration of the support matter plus 3 calendar years anchored at end of year, per the Support correspondence row in § 11, on the basis of Art. 6 (1)(f) GDPR read with the regelmäßige Verjährungsfrist in §§ 195 + 199 BGB. The HelpCanvas-platform conversation and the email correspondence are subject to the same retention; see § 11 "HelpCanvas-hosted support conversations" for the platform-of-record analysis.

#Server-side request metadata read on every request

• Your IP address (used for rate limiting and abuse defence)
• Your browser's User-Agent string (used for session-integrity validation; hashed into the per-session integrity check)

The IP address is persisted on your account record only as the registration and most-recent-sign-in values described under "Account data" above; it is otherwise read transiently and not retained. The User-Agent string is not retained beyond the hashed session-integrity check.

#Whether providing this information is required (Art. 13 (2)(e) GDPR)

We are required under Art. 13 (2)(e) GDPR to tell you whether the provision of your personal data is a statutory or contractual requirement and what happens if you choose not to provide it:

• Required by law. Your name, billing address, VAT-ID where applicable, and transaction details must be retained to comply with German tax and accounting obligations (§ 147 AO, § 257 HGB; § 14 UStG for VAT-invoice content). Without these, we cannot lawfully invoice you.
• Required by contract. Your email, password, billing payment-method identifier, and the monitor configurations you submit are necessary to operate the Service contract under Art. 6 (1)(b) GDPR. Without them we cannot provide the Service.
• Required for account access and security. Your IP address, user-agent, sign-in timestamps and 2FA state are processed under Art. 6 (1)(f) GDPR to keep your account secure.
• Voluntary. Marketing-opt-in preferences, optional profile fields, and feedback are at your discretion; non-provision does not affect your access to the Service.

#Special categories of personal data (Art. 9 GDPR)

We do not knowingly process special categories of personal data within the meaning of Art. 9 (1) GDPR — i.e., data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic data, biometric data processed to uniquely identify a natural person, data concerning health, or data concerning a natural person's sex life or sexual orientation. Uptimia is a business-to-business observability product; none of the categories listed in § 3 above (account, billing, authentication, monitor configurations, check results, notification-channel configurations, support data, server-side request metadata) is designed or intended to capture Art. 9 data.

Please do not submit special-category data to us — for example, do not paste it into monitor URLs, monitor headers, request bodies, alert-channel test messages, or support tickets, and do not script transaction-monitoring journeys that route special-category data through Uptimia. If you nonetheless submit such data to us inadvertently — for example in a free-text support description — we treat it as inadvertent receipt: we do not assert any Art. 9 (2) GDPR basis to process it as special-category data, we do not use it for any purpose beyond what is strictly unavoidable to action the support ticket that brought it to us, and we will delete the offending field on request without prejudice to the remainder of the support thread. To the limited extent that handling the field is unavoidable in the moments between receipt and deletion (e.g., the agent reads the message in order to understand the request before redacting it), we rely on Art. 9 (2)(f) GDPR (processing necessary for the establishment, exercise or defence of legal claims — here, the support-ticket handling that itself rests on Art. 6 (1)(f) and § 195 + § 199 BGB as set out at § 11 "Support correspondence") only insofar as that limb is actually engaged. We do not rely on Art. 9 (2)(e) GDPR (data manifestly made public by the data subject): submitting personal information into a private support ticket is not a deliberate, addressed-to-the-public disclosure within the narrow Art. 9 (2)(e) reading required by Lindqvist (CJEU C-101/01) and EDPB guidance, and we do not treat it as such.

Where you, as a Controller, deploy our RUM script or transaction-monitoring on a surface that processes special-category data of your visitors / end-users, that is your own controller decision and your own responsibility under Art. 9 GDPR; nothing in our Service or DPA authorises you to route special-category data through Uptimia, and the DPA Annex A category-of-data declaration assumes ordinary visitor / end-user data only.

#4. How we use your information

We use the data we collect for the purposes set out below. Per Art. 13 (1)(c) GDPR, the legal basis is shown alongside each purpose.

Purpose	Legal basis (Art. 6 GDPR)
Operating, maintaining, and improving the Service and the Website	Art. 6 (1)(f) — legitimate interest
Authenticating you, maintaining your session, enforcing 2FA where you enabled it	Art. 6 (1)(b) — contract
Running the monitor configurations you create and delivering check results to your dashboard	Art. 6 (1)(b) — contract
Delivering alerts to the channels you configured (SMS, WhatsApp, Slack, Discord, Teams, Mattermost, Telegram, PagerDuty, Atlassian Statuspage, X, webhooks)	Art. 6 (1)(b) — contract
Processing subscription payments and issuing invoices	Art. 6 (1)(b) — contract
Maintaining tax and accounting records	Art. 6 (1)(c) — legal obligation (§ 147 AO, § 257 HGB)
Detecting, preventing, and addressing fraud, brute-force credential attacks, and abuse of the Service	Art. 6 (1)(f) — legitimate interest in account integrity
Executing your monitors against the resources you configure, from the multi-region probe network	Art. 6 (1)(b) — contract
Cross-customer measurement-quality and probe-network operations — aggregating probe outcomes across customers to detect probe-side anomalies, calibrate timing, and identify regional incidents that affect multiple customers; output is aggregate and produces no individual-level signal	Art. 6 (1)(f) — legitimate interest in service-quality, probe-anomaly detection, and platform-wide reliability. We do not assert that the aggregated output is "anonymous" within the strict three-test framework of the (former) Article 29 Working Party Opinion 05/2014 on Anonymisation Techniques (singling-out, linkability, inference, all defeated); we treat the cross-customer aggregation as pseudonymous for the lawful-basis analysis and ground it in Art. 6 (1)(f) accordingly. Output reports are released only at a per-region aggregation threshold sufficient to prevent re-identification of any individual Controller's monitor configuration
Running affiliate-attribution tracking on the marketing site (FirstPromoter — fires only when the URL carries ?via=)	Art. 6 (1)(a) + § 25 Abs. 1 TDDDG (in force from 14 May 2024 as the successor to the TTDSG) — consent via the Datriva banner
Issuing transactional communications (account, billing, security)	Art. 6 (1)(b) — contract
Issuing legally mandated notices (privacy / terms updates under Art. 12–14, Art. 34 personal-data-breach notifications)	Art. 6 (1)(c) — legal obligation
Sending product-update communications to existing account holders (Uptimia feature releases, service-relevant updates, and announcements about similar JJ Online services)	Art. 6 (1)(f) GDPR in conjunction with § 7 Abs. 3 UWG (Bestandskundenwerbung). The four cumulative § 7 Abs. 3 UWG conditions are all satisfied: (i) your address was obtained in the context of the sale of our goods or services (subscription or trial sign-up); (ii) we use the address only for direct marketing of our own similar products and services; (iii) you have not objected to this use — once you object, all further such mail stops immediately; and (iv) you were clearly and conspicuously informed, both at the point we collected your address and in every subsequent message, that you may object at any time without incurring any costs beyond the basic transmission rates (Basistarif) — i.e., nothing more than what the recipient would pay to send a standard message back over the medium of transmission. Objection under Art. 21 GDPR is unconditional and processed on receipt without detriment to your underlying contract
Sending marketing communications you opted into	Art. 6 (1)(a) — consent
Complying with legal obligations, responding to lawful requests	Art. 6 (1)(c) — legal obligation

For each purpose grounded in legitimate interests, the balancing-test summary and your right to object under Art. 21 GDPR are described in § 15. A Legitimate Interests Assessment (LIA) for any of these activities is available on request at privacy@uptimia.com.

#5. Third-party services we use as a data controller

The services listed in this section process personal data of you as an Uptimia account holder under our instructions as data controller of the Website and the Service. Where Uptimia additionally acts as a data processor on your behalf for personal data of your own visitors / end-users, the sub-processors engaged for that distinct role are listed in § 7 and in the DPA Annex C.

The full Sub-processor list with addresses, DPA dates, and transfer mechanisms is set out in the DPA Annex C. The summary below is for transparency under Art. 13 (1)(e) GDPR.

#5.1 Payments and billing

Provider	Legal entity	Location	Function	Transfer mechanism
Stripe	Stripe Payments Europe Ltd.	Ireland (+ US sub-processing by Stripe, Inc.)	Subscription payment processing, card tokenisation, fraud detection	EU–US DPF + SCC fallback
PayPal	PayPal (Europe) S.à r.l. et Cie, S.C.A.	Luxembourg (+ US sub-processing)	Alternative checkout payment	EU–US DPF + SCC fallback
easybill	easybill GmbH	Germany	Invoice generation, GoBD-compliant invoice archiving	n/a (EU only)

#5.2 Hosting and core infrastructure

Provider	Legal entity	Location	Function	Transfer mechanism
OVH	OVH SAS	France	Main application hosting (dashboard, API, primary application database), probe network (EU region), self-hosted time-series database	n/a (EU)
AWS — EU	Amazon Web Services EMEA SARL	Luxembourg (eu-central-1 Frankfurt + S3)	Transactional email via SES to EU recipients; invoice-PDF and export storage in S3; probe network (EU regions)	n/a (Frankfurt EU region)
AWS — US	Amazon Web Services, Inc.	USA (us-east-1 Virginia)	Transactional email via SES to non-EU recipients; probe network (non-EU regions)	EU–US DPF + SCC fallback

#5.3 Probe network

The Uptimia probe network is geographically distributed across nine providers. Important design property: probes process the check result transiently in memory + transit and immediately delete any local copy after forwarding the result to the main EU-located infrastructure. No Customer Personal Data is persisted at rest on the probe layer.

Provider	Legal entity	Location	Transfer mechanism
OVH	OVH SAS	France	n/a (EU)
GCore	G-Core Labs S.A.	Luxembourg + global regions	n/a EU regions; SCC for non-EU
DigitalOcean	DigitalOcean, LLC	USA + regions	EU–US DPF + SCC fallback
Linode / Akamai	Akamai Technologies, Inc.	USA + regions	EU–US DPF + SCC fallback
EDIS	EDIS Telekommunikation GmbH (operating as EDIS.at)	Klagenfurt, Austria	n/a (EU)
Scaleway	Scaleway SAS (Iliad Group)	France — probe regions in France (Paris), the Netherlands (Amsterdam), and Poland (Warsaw); all EU	n/a (EU)
AWS	as above (5.2)	EU + USA	n/a EU; DPF + SCC US
Contabo	Contabo GmbH	Germany (Munich HQ) — probe regions in EU (Germany, Austria, Spain, Portugal) and non-EU (USA, UK, Singapore, Japan, Australia, India)	n/a EU regions (Contabo GmbH is the EU contracting entity); SCC for non-EU regions, with the ephemeral-processing property described under § 7 (Annex B.6 of the DPA) as the supplementary measure that prevents persistent storage of Customer Personal Data on probe hosts regardless of region
Vultr	Vultr Holdings, LLC (The Constant Company, LLC)	USA (Delaware) — 13 probe locations across USA, Netherlands, Germany, UK, Australia, Japan	No DPF certification — SCC + the ephemeral-processing property described above as the principal supplementary measure. Vultr supplies raw IaaS and does not contractually guarantee a no-persistent-storage property for any specific customer's use of its servers; the ephemeral-processing property is therefore a JJ Online deployment-level technical and organisational measure (no application-layer persistence to Vultr disks; check inputs and outputs held only in memory and in transit; the probe binary writes no Customer Personal Data to local disk) implemented by us as the controller, and is documented as such in DPA Annex B.6. We periodically verify the property — at least quarterly and on every change to the probe binary or its deployment configuration — by sampling probe hosts, listing local-disk writes against a deny-list of paths the probe binary is permitted to touch, and confirming that no Customer Personal Data has been written to disk; the verification log forms part of the Art. 32 (1)(d) regular-testing record we maintain and is producible on supervisory-authority request. The Vultr DPA itself remains the standard provider-side DPA and is not relied on to evidence this measure.

#5.4 Authentication

Provider	Legal entity	Location	Function	Transfer mechanism
Auth0	Auth0 EMEA Limited (Okta Group)	Ireland (+ US sub-processing)	Identity management, login flow, social-connection orchestration	EU–US DPF + SCC fallback

Auth0 social-connection sub-sub-processors. Where you choose to sign in with Google or GitHub on the Auth0-hosted login page, Auth0 hands the OAuth flow off to those providers. There is no direct OAuth integration between Uptimia and Google or GitHub; Auth0 holds the underlying DPA. The providers are: Google Ireland Limited (with US sub-processing by Google LLC) and GitHub, Inc. (Microsoft Group).

Cookies during the sign-in flow. The Auth0-hosted login page sets its own strictly-necessary cookies on the Auth0 domain (not on uptimia.com) during authentication. These cookies are necessary to complete the sign-in you requested and are exempt from consent under § 25 Abs. 2 Nr. 2 TDDDG. The "Sign in with Google" and "Sign in with GitHub" buttons on our sign-in and sign-up pages use a click-to-load pattern: no Auth0, Google, or GitHub scripts are loaded, and no requests to those providers are made, until you click one of those buttons; full detail and the Auth0 / Okta privacy URL are in our Cookie Policy § 4.8.

#5.5 Security and threat intelligence

Provider	Legal entity	Location	Function	Transfer mechanism
Google Web Risk API	Google Ireland Limited	Ireland (+ US sub-processing)	Malware / phishing screening of monitored URLs — only the URL is sent	EU–US DPF + SCC fallback
Google PageSpeed Insights	Google Ireland Limited	Ireland (+ US sub-processing)	Performance analysis for the Speed monitor — only the URL is sent	EU–US DPF + SCC fallback

#5.6 Marketing-page integrations

Provider	Legal entity	Location	Function	Transfer mechanism
FirstPromoter	Igil Webs SRL	Romania	Affiliate attribution on uptimia.com marketing pages — fires only when the URL carries ?via=; gated by your consent via the Datriva cookie banner	n/a (EU)

#5.7 Internal JJ Online cross-product services (same controller — not Art. 28 sub-processors)

The following are operated by JJ Online GmbH itself and are not Article 28 sub-processors. All five run on the same EU footprint as the main Uptimia application — OVH France (application database and self-hosted services) and, where blob storage is required, AWS Frankfurt eu-central-1 — under the same Art. 32 technical and organisational measures described in § 12. No JJ Online sister-product processing leaves the EU.

• Datriva CMP banner — cookie consent management on the marketing site (https://datriva.com/cdn/banner/uptimia.js). Hosted on OVH France.
• HelpCanvas widget — in-app chat support on the marketing site. The HelpCanvas application and its message store are hosted on OVH France under the JJ Online stack; HelpCanvas chat transcripts do not leave the EU.
• Self-hosted time-series database — time-series storage for monitoring metrics, operated by JJ Online on OVH France infrastructure.
• Altcha — proof-of-work captcha library executed locally on Uptimia infrastructure; no third-party data flow.
• ErrorHawk (sister product) — out of production scope: the DSN is configured only on our internal development environment, not on the production uptimia.com infrastructure. No Customer Personal Data is forwarded to ErrorHawk in production. ErrorHawk's own production stack, where relevant to other JJ Online products, also runs on OVH France.

Disclosure to third parties — no resale, no AI training, no audience-building. We do not disclose your personal data to third parties for their own commercial purposes. The third-party services in § 5.1–5.6 process your personal data only as our processors, on our documented instructions, under written data-processing agreements that contractually prohibit each processor from using your personal data for any purpose beyond the specific service they perform for us. The prohibited secondary uses include, without limitation:

• Training of artificial-intelligence, machine-learning, or large-language models — including foundation-model pre-training, fine-tuning, embedding extraction, retrieval-augmented-generation indexing, evaluation-set construction, or any other incorporation of your personal data into derived datasets or model weights, whether by the processor or by any third party to which the processor onward-licenses
• Advertising, profiling, look-alike audience-building, ad targeting, or audience-segment enrichment
• Resale, sub-licensing, or syndication of your personal data — whether on a named, pseudonymised, hashed, or aggregated basis — to data-broker, analytics-network, or advertising-network counterparties
• Any other secondary use that is not necessary to deliver the contracted service to us

The Art. 28 (3) restrictions in each processor's data-processing agreement are the enforcement mechanism for the prohibitions above. Where a processor's standard terms or DPA do not adequately cover these prohibitions, we either negotiate amended terms before instructing them or do not engage the processor.

#6. Other recipients — tax, audit, legal, M&A, and lawful requests

Beyond the day-to-day processors in § 5, in line with Art. 13 (1)(e) GDPR and the EDPB Guidelines on Transparency (WP260 rev. 01), we may also disclose personal data to the following categories of recipients:

Recipient category	When	Legal basis	Scope
Tax authorities (Finanzamt; equivalents in other jurisdictions)	Periodic tax returns, compliance audits, lawful information requests	Art. 6 (1)(c) — § 147 AO, § 257 HGB	Limited to transaction, invoicing, accounting data required by statute
External auditors (statutory, voluntary, buyer-side due-diligence)	Annual audit, voluntary financial or security audit, pre-acquisition due diligence	Art. 6 (1)(c) where mandated; otherwise Art. 6 (1)(f)	Under written professional-confidentiality obligations; minimised to scope of engagement
Legal counsel (external solicitors, attorneys, notaries)	Claims defence, contract disputes, regulatory response, transactional advice	Art. 6 (1)(f); § 203 StGB professional confidentiality	Minimised to scope of instruction
Potential acquirers and their advisors (M&A, investment, asset-sale, restructuring)	Corporate transactions — due-diligence data rooms, share-purchase agreements, asset sales	Art. 6 (1)(f), interpreted consistently with the DSK Beschluss "Datenschutz im Asset Deal" of 11 September 2024 (which replaced and expanded the original DSK paper of 24 May 2019). Specifically, we apply the Beschluss's phase-by-phase structure: in the due-diligence phase, customer personal data is in principle only made available in pseudonymised or aggregated form, with disclosure of identifying data limited to the narrow late-stage Art. 6 (1)(f) exception the Beschluss recognises (signed LOI / advanced negotiations, NDA in place, minimisation to what is strictly necessary for the buyer's remaining diligence questions, no broad data-room dump); in the closing / transfer phase, we follow the lawful-basis path the Beschluss prescribes for the relevant transaction structure, and in particular we treat the sale of a customer database as a standalone asset as the more sensitive case that, on the Beschluss's analysis, generally requires either consent or a meaningful pre-transfer information and objection process, distinct from the case in which customer relationships transfer incidentally as part of a larger going-concern asset deal. Across both phases the Beschluss's move away from a pure post-closing Widerspruchslösung toward pre-transfer information of affected data subjects is reflected in the safeguards column	Written NDA, data-room minimisation, pseudonymisation or aggregation during due diligence (with identifying data released only under the narrow late-stage Art. 6 (1)(f) exception, on a need-to-know basis and only after the LOI / advanced-negotiation threshold is crossed), and pre-transfer information of affected data subjects in accordance with the 11 September 2024 Beschluss rather than a bare post-transfer opt-out — with the standalone-customer-database scenario handled on the more protective lawful-basis path the Beschluss specifies for that case
Law enforcement, courts, regulators	Lawful request — court order, subpoena, regulatory investigation	Art. 6 (1)(c) where binding; Art. 6 (1)(f) for verified voluntary cooperation	Limited to scope of specific request; we challenge overbroad requests where law permits
Insurance carriers and claims administrators	Professional-indemnity, cyber-insurance, commercial-liability claims	Art. 6 (1)(f)	Minimised to personal data necessary to evaluate and handle the specific claim

None of these recipients receive personal data routinely or at scale; each disclosure is triggered by a specific event.

#7. Uptimia as a data processor for your visitors' / end-users' data

When you use Uptimia to monitor resources you operate, certain processing flows arise where you are the data controller of your visitors' or end-users' personal data and Uptimia is the data processor acting on your behalf:

Flow	What personal data flows through Uptimia
Authenticated HTTP checks	Response bodies from URLs you configure may contain user names, email addresses, or other personal data of your end-users — captured in our check-response snapshots (7-day TTL on the response-body field)
Transaction monitoring	Screenshots captured at each step of a transaction script may include personal data visible on authenticated pages (e.g. a logged-in user's name in the navigation bar) — stored under the retention period set out in § 11
Real User Monitoring (RUM)	When you deploy our RUM script on URLs you select, it sends back page-load timings, browser and device metadata, geographic origin, and JavaScript error events; visitor IP addresses are truncated to /24 IPv4 and /48 IPv6 before storage; events are persisted only in aggregate form — there is no per-beacon record of an individual visitor
Status-page incident subscriptions	Email addresses your visitors enter to subscribe to incident notifications on a status page you operate via Uptimia

Controller / processor split — the essential / non-essential means analysis. Art. 28 GDPR requires the controller to determine the purposes and means of processing and the processor to act on the controller's documented instructions. The EDPB Guidelines 07/2020 on the concepts of controller and processor (¶ 38) draw a sharp line between essential means — which categories of data are processed, which categories of data subjects, retention duration, recipients of the data — which the controller must determine and non-essential means — technical implementation choices such as algorithm, format, software, hardware — which the processor is free to determine. We are the processor of your visitors' / end-users' personal data on the following analysis:

• Purposes are yours. You decide whether to deploy our RUM script and on which URLs, whether to monitor an authenticated endpoint, whether to script a transaction journey, and whether to operate a public status page that takes visitor subscriptions. None of those processing operations begin until you initiate them.
• Essential means are yours. Your deployment choice determines the category of data (deploying RUM = page-load events from your visitors; configuring transaction monitoring = screenshots of the journey you scripted); the categories of data subjects are determined by who visits your sites and who you script the journey for; the retention period is determined by your Service plan tier (see § 11 and the plan-tier matrix on uptimia.com); the recipients of the data are limited by your account isolation and by the sub-processors documented in the DPA Annex C, to which you consent by deploying.
• Non-essential means are ours. The /24 IPv4 and /48 IPv6 truncation of visitor IP addresses before storage, the aggregation logic that keeps RUM events out of per-beacon tables, the choice of EU-located storage infrastructure (OVH France for the application database, AWS Frankfurt eu-central-1 for screenshot blobs in S3), and the ephemeral-processing property of the probe layer are technical implementation choices we make as the processor. They constitute Art. 32 GDPR technical and organisational measures — they enhance your control over the essential means rather than displacing it.

On this analysis, the four flows above are clean Art. 28 controller-to-processor relationships. Our DPA incorporates the controller-to-processor terms required by Art. 28 (3) GDPR; the deployment of the Service (script deployment, monitor configuration, plan-tier selection), the documented instructions in the DPA, and the per-account Processing Instructions Summary described at DPA § 6.1(e) and Annex A.8 together constitute your documented instructions for the purposes of Art. 28 (3)(a) GDPR. The DPA applies automatically by reference under Uptimia ToS § 17.2 when you start using monitoring features that process personal data of your visitors / end-users; no separate signature is required to bring the DPA into force.

Art. 28 (9) GDPR — written / electronic form. Art. 28 (9) GDPR requires the controller-processor contract to be "in writing, including in electronic form." The Uptimia Terms of Service into which the DPA is incorporated are themselves in electronic form, and the full DPA text is published at a stable, persistent URL on uptimia.com (currently https://uptimia.com/legal/dpa — the same canonical surface from which this Privacy Policy is published) and is accessible to you at the moment of incorporation, both before and during your acceptance of the ToS. Your electronic acceptance of the ToS — by signing up for, paying for, or otherwise using the Service in a way that engages monitoring features that process personal data of your visitors / end-users — constitutes your signature of the DPA for the purposes of Art. 28 (9) GDPR. The "counter-signed counterpart on request" path in the next paragraph is therefore an accommodation to procurement-form preferences, not a precondition to the DPA being in force; the DPA is fully binding under Art. 28 (9) on electronic-acceptance alone.

Per-account documented instructions. You may request the per-account Processing Instructions Summary at any time by writing to privacy@uptimia.com. The Summary is generated from your account state at the time of the request and lists, for your specific account: the active monitor types, the URLs and resources you have chosen to monitor, your Service plan tier and the retention periods that follow from it, the alert channels you have activated (and therefore the Sub-processors active on your account), the EU storage region applicable to your data, and any subsequent written instructions we have accepted from you. We return the Summary within five (5) business days. The Summary is documentary — it does not vary the DPA — and it is intended to support your Art. 30 (1) record-of-processing-activities obligation and Art. 5 (2) accountability where you process personal data of your visitors / end-users through the Service. Self-service generation of the Summary in your dashboard is on the product roadmap; until then the manual process applies.

Signed counterpart of the DPA. Where your procurement, audit, or regulatory process requires a counter-signed counterpart of our DPA with the Processing Instructions Summary attached as Annex A.8, we will execute one on request at no fee. Contact privacy@uptimia.com.

Visitor-side sub-processors. The sub-processors engaged for the processor role are listed in the DPA Annex C. They are a superset of the sub-processors in § 5 above. The additional Annex C.5 entries are the alert channels you configure (Slack, Discord, Twilio, PagerDuty, etc.), which become Sub-processors only to the extent the alert payload includes visitor / end-user personal data of yours (as set out in § 3 "Notification channel configurations — dual role of alert channels" above), and only when you actually enable the channel. The same third parties also act as Uptimia's own service providers in respect of the ops-team contact records and credentials and the alert-addressed-to-your-ops-team component of the same flow — that controller-relationship leg is the one inventoried in § 5, not here. The Annex C.5 listing is therefore narrower than the channel-by-channel list in § 5: it is the processor-role projection of the same set of third parties.

Technical safeguards for the processor-role flows.

• RUM visitor IP addresses are truncated to /24 (IPv4) or /48 (IPv6) before the event is written to storage; the full IP address is never persisted
• RUM events are persisted in aggregate form only — there is no per-beacon table, and no individual visitor can be reconstructed from the stored data
• Transaction screenshots and check-response snapshots are stored on AWS S3 (Frankfurt) under our account; access is gated by the account-of-record's authentication
• Probe nodes process check inputs and outputs only ephemerally; no Customer Personal Data is persisted at rest on the probe layer
• Credentials and secrets you supply so the Service can authenticate to your resources (HTTP Basic credentials, custom request headers, integration credentials, transaction-step literal values) are held under column-level envelope encryption with separately-managed keys, as described in § 12

Visitor consent. It is your responsibility as data controller to obtain any required consent from your visitors before deploying our RUM script on your website. Where § 25 TDDDG or equivalent EU national law requires consent for storage of or access to information on the visitor's terminal, your visitors must be given a § 25-compliant consent opportunity before our RUM script loads. We provide documentation on integrating consent gating; the implementation is yours.

#8. Profiling and automated decision-making

This section discloses the automated activities the Service operates that meet the definition of profiling under Art. 4 (4) GDPR, as required by Art. 13 (2)(f) and Art. 15 (1)(h) GDPR — including the one activity that meets the definition of an automated decision under Art. 22 (1) GDPR.

Payment-fraud decisioning at checkout (Art. 22 (1) GDPR). When you submit a payment, our payment processor evaluates the transaction against signals including payment method, device fingerprint, billing address, IP address, prior usage history, and machine-learning patterns drawn from the processor's wider fraud corpus, in order to produce a fraud-risk score. A sufficiently elevated score causes the transaction to be declined, flagged for manual review by the processor, or routed to additional verification such as 3-D Secure. This is a solely automated decision that, by preventing the purchase from completing in real time, has effects on you significant enough to fall within Art. 22 (1) GDPR.

The analysis here is split between (i) the lawful basis for the underlying processing of your payment data (Art. 6 GDPR) and (ii) the Art. 22 (2) GDPR gateway that authorises the automated decision itself. Following the EDPB's narrow reading of "necessary for the contract" in its Guidelines on Article 22 (and the line reinforced in the post-SCHUFA Holding (CJEU C-634/21, 7 Dec 2023) commentary), we lead on the statutory bases and treat contract-necessity only as a fallback.

Lawful basis for the underlying processing — Art. 6 (1)(c) GDPR (principal). The processing is necessary for the payment processor's compliance with PSD2 Strong Customer Authentication requirements (Directive (EU) 2015/2366 and Commission Delegated Regulation (EU) 2018/389), with anti-money-laundering / counter-terrorism-financing regimes (Directive (EU) 2015/849 as amended; the EU AML Regulation; national transposition acts), and with the obligation in EBA Guidelines EBA/GL/2017/17 on the security measures for operational and security risks of payment services to apply transaction-monitoring mechanisms that detect fraudulent payment transactions. Those statutory obligations bind the payment processor directly and flow through to us as the merchant on whose behalf the screening is operated; they make the processing necessary for compliance with a legal obligation to which Uptimia (through the processor) is subject within the meaning of Art. 6 (1)(c) GDPR.

Art. 6 (1)(f) GDPR — alternative basis for the residual merchant-side fraud-prevention interest. To the extent that any element of the screening goes beyond what is strictly required by the statutory framework above and reflects our own merchant-side interest in preventing card-not-present fraud, chargebacks, and account-takeover at sign-up, we rely on Art. 6 (1)(f) GDPR. The legitimate-interest balancing for this residual element is documented at § 15 ("Legitimate Interests Assessment summary") and treats the interest as substantial (direct fraud loss + dispute-handling burden), the data-subject interests as protected by the Art. 22 (3) safeguards below, and the processing as proportionate (per-transaction signals, not retained as a profile).

Art. 6 (1)(b) GDPR — contract-performance basis, fallback only. Where neither the statutory nor the residual-interest framing reaches a specific element of the processing, the screening is also necessary to enable us to enter into the payment leg of the contract you are seeking to conclude with us, supporting Art. 6 (1)(b). We list this as a fallback because we share the EDPB's view that Art. 6 (1)(b) "necessity" should be read narrowly: the fact that fraud screening is operationally indispensable does not by itself satisfy the "no less intrusive alternative" test, and the Art. 6 (1)(c) and (f) bases above are the cleaner story.

Art. 22 (2) gateway for the automated decision itself. Art. 6 alone does not authorise the Art. 22 (1) automated-decision; that decision needs an Art. 22 (2) gateway — (a) contract necessity, (b) authorising Union or Member State law that lays down suitable safeguards, or (c) explicit consent. We rely principally on Art. 22 (2)(b) GDPR: the PSD2 SCA framework (Directive (EU) 2015/2366 read with Commission Delegated Regulation (EU) 2018/389) and the AML / CTF framework cited above constitute authorising Union law that requires the very transaction-monitoring decisions made at checkout and that itself lays down the suitable safeguards for the data subject (PSD2 Title IV consumer-protection chapter; AMLD complaint and review mechanisms in national transposition; the data-subject Art. 22 (3) GDPR safeguards below applied in parallel). The EBA Guidelines cited above operationalise that statutory regime through binding supervisory expectations on payment-monitoring decisions. We treat Art. 22 (2)(a) GDPR (contract necessity) as a fallback Art. 22 gateway only — engaged if and to the extent a supervisory authority were to read the Art. 22 (2)(b) authorising-law gateway narrowly — and we do not rely on Art. 22 (2)(c) (explicit consent), which would not be freely given in a payment-checkout context.

Your safeguards under Art. 22 (3) GDPR. You have the right:

• to obtain human intervention in the decision — write to privacy@uptimia.com identifying the declined transaction; we will route the case to the payment processor's manual-review team and our own billing operations, both of whom can override the automated outcome on the facts;
• to express your point of view — you may submit any context you believe is relevant (e.g. travel context for a foreign-IP decline, corrected billing details, evidence of card ownership);
• to contest the decision — the manual-review outcome is itself reviewable by us; if you remain dissatisfied you may use the alternative checkout path (Stripe ↔ PayPal) or request a written explanation suitable for forwarding to your card issuer.
• to receive the specific decline-reason code and, where applicable, the Stripe Radar rule name — on Art. 22 (3) request we will, in addition to the human-review steps above, communicate to you the decline-reason code returned by the payment processor for your transaction and, where the decline was driven by a specific Radar rule that the processor has surfaced to us in the merchant dashboard (as opposed to an issuing-bank decline), the name of that rule. This is the per-decision principal-reasons disclosure described under "Meaningful information about the logic involved" below; we make the commitment explicit here so it is reachable from the Art. 22 (3) safeguards list without having to read the SCHUFA-implementation paragraph first.

We will respond to any Art. 22 (3) request within the Art. 12 (3) GDPR timeframe (one month, extendable by two further months in complex cases with notice to you).

Meaningful information about the logic involved (Art. 15 (1)(h) GDPR; CJEU Case C-634/21 SCHUFA Holding, 7 Dec 2023). The fraud-risk score is produced by a third-party machine-learning model maintained by the payment processor (Stripe Radar; the equivalent PayPal model) and tuned against that processor's global fraud corpus. The internal weights of those models are not published by the processor and are not made available to us under standard merchant terms — exposing the weights would let fraudsters reverse-engineer the model, which is why no card-payment processor of consequence discloses them. We do not consider that absence to defeat your Art. 15 (1)(h) right. SCHUFA Holding requires "meaningful information about the logic involved" sufficient to allow the data subject to understand the procedure that led to the score and, where appropriate, to challenge the specific decision in their case — not the algorithm itself. On that standard we disclose, and on request will confirm to you in writing:

• The principal factor groups the model evaluates — transaction amount and currency; payment-method metadata (card BIN, country of issue, brand, funding type); the AVS billing-address verification outcome; device and browser fingerprint; IP address, IP geolocation, and IP-vs-billing-country mismatch; prior outcomes for the same card or account at the processor's global corpus and at Uptimia (your own history with us); network-level reputation and blocklist signals; 3-D Secure outcome where available.
• The principal reason for your specific outcome. If your transaction was declined, the processor returns a specific decline-reason code (for example do_not_honor, card_declined, fraudulent, lost_card, stolen_card, pickup_card, incorrect_cvc, expired_card) and, where the decline was driven by a Radar rule rather than the issuing bank, the name of the rule that triggered (visible to us in the merchant dashboard). We will pass that specific code and, where available, the specific rule name through to you on request — that is the principal-reasons disclosure required by SCHUFA Holding § 54–§ 59.
• The override path we as merchant control. A processor-side fraud decline does not lock you out of the Service. We can choose to honor a transaction that the model declined; write to privacy@uptimia.com identifying the transaction, supply any context you believe is relevant (travel, corrected billing details, evidence of card ownership), and we will (a) escalate to the processor's manual-review team, who can override the model on the facts, and (b) re-attempt the charge from our merchant side after the override, or use the alternative checkout path (Stripe ↔ PayPal).
• Significance for you. A sufficiently elevated score either declines the transaction at checkout, triggers a 3-D Secure step-up, or routes the transaction to manual review at the processor. The score is not retained as a profile on your user record; it is a per-transaction signal.

Anti-abuse rate limits and signup-bot scoring (no Art. 22 decision). Separate from payment fraud, we apply automated rate-limit decisions against the API and sign-up endpoints based on request patterns, IP reputation, and account age. Sign-up is additionally gated by Altcha, a self-hosted proof-of-work challenge executed locally on Uptimia infrastructure (no third-party data flow). An internal heuristic score is also recorded on your user record. These signals are advisory only — there is no auto-suspension or auto-rejection logic. Accounts are disabled manually by an administrator after human review. Sign-up is rate-limited at 3 attempts per 15 minutes per IP. The decision is reversible by writing to privacy@uptimia.com.

Profiling transparency for the advisory heuristic (Art. 4 (4), Art. 13 (2)(f), Art. 14 (2)(g), Art. 15 (1)(h) GDPR). The advisory heuristic score on your user record is profiling within Art. 4 (4) GDPR even though no solely-automated decision producing legal or similarly significant effects is taken on the basis of it (Art. 22 (1) GDPR is not engaged). The transparency obligations under Art. 13 (2)(f) and Art. 14 (2)(g) — and the corresponding right of access to "meaningful information about the logic involved" under Art. 15 (1)(h) — are, on the better reading, not strictly limited to Art. 22 (1) profiling; we therefore disclose, both here in advance and on access request, the principal categories of inputs the heuristic evaluates: rate of sign-up or sign-in attempts from the same IP and the same email-domain over a defined window; presence of the IP on internal and well-known external reputation lists (e.g. open-proxy / Tor-exit / known-VPN list aggregators); account-age and account-state signals (newly-created vs long-standing, prior support-ticket history); pattern-similarity to known abuse fingerprints (proof-of-work failure rate via Altcha, monitor-creation pattern in the minutes after sign-up). On Art. 15 (1)(h) access request, we will additionally disclose the score recorded on your account, the principal contributors to that score, and the absence of any auto-decision rule attached to it.

Your right to object under Art. 21 GDPR. You retain the right to object to any profiling that relies on our legitimate interests (Art. 6 (1)(f) GDPR). This right does not, however, extend to the payment-fraud decision described above to the extent that decision rests on the Art. 22 (2)(b) authorising-law gateway and on the Art. 6 (1)(c) statutory-compliance basis — neither of which engages Art. 21. For the residual Art. 6 (1)(f) element of the screening, Art. 21 applies but the legitimate-interest balancing recorded at § 15 would in practice override an objection in respect of an active payment attempt; for the decision itself, your safeguards are the Art. 22 (3) rights set out above.

#9. Cookie consent — giving and withdrawing

The cookie banner on uptimia.com is operated by Datriva (also a JJ Online GmbH product — we dogfood our own consent-management platform). Where we use cookies or comparable technologies that require your consent under Art. 6 (1)(a) GDPR and § 25 Abs. 1 TDDDG, the consent mechanism and withdrawal mechanism are governed by the following rules.

How we obtain consent. On your first visit to the marketing site, the Datriva banner appears before any non-essential cookie is set. The banner presents the three consent-required categories (Functional, Analytics, Marketing) as opt-in only — each category is unticked by default. You can accept all, reject all, or accept a granular subset with the same number of clicks, consistent with Art. 7 (2) GDPR and EDPB Guidelines 05/2020 on consent. Strictly-necessary cookies are set without consent on the basis of § 25 Abs. 2 Nr. 2 TDDDG.

Withdrawal — as easy as giving consent. Art. 7 (3) GDPR requires withdrawal of consent to be as easy as giving it. Per EDPB Guidelines 05/2020 on consent (§ 117), parity here means the same medium and the same number of steps as the original opt-in. We therefore operate a single Art. 7 (3) parity route:

• Cookie Preferences link in the marketing-site footer (Art. 7 (3) parity route). A persistent "Cookie Preferences" link is present in the footer of every marketing page. Clicking it reopens the same Datriva banner with your current settings, where you can switch any category off — or reject all non-essential cookies — in the same number of clicks it took to accept them. Because the banner that handles withdrawal is the same UI element, in the same medium, with the same toggle controls as the banner that handled the original consent, the withdrawal mechanism is identical to (not merely "as easy as") the giving mechanism. This is the strongest form of Art. 7 (3) parity contemplated by EDPB Guidelines 05/2020 on consent § 117 and is what we rely on as our parity route.

Two further routes are available for your convenience but are not equivalent to the original opt-in and are not relied on to satisfy Art. 7 (3) parity:

• Email to privacy@uptimia.com. We will record and action the withdrawal manually within the Art. 12 (3) GDPR timeframe.
• Clearing cookies in your browser. This also clears our locally-stored consent record so the banner reappears on your next visit; the steps involved are not equivalent to the original opt-in mechanism.

Effect of withdrawal. Non-essential cookies stop being set immediately on withdrawal. Withdrawal does not affect the lawfulness of processing carried out before withdrawal (Art. 7 (3) GDPR, second sentence).

For the per-cookie inventory, see the Cookie Policy.

#10. Cookies

We use cookies and similar tracking technologies. Our Cookie Policy sets out: (i) the four categories (Strictly Necessary, Functional, Analytics, Marketing — we currently use no Functional, no Analytics, and one Marketing-category third party only when you arrive via ?via=), (ii) each specific cookie and localStorage / sessionStorage entry with its provider and duration, (iii) third-party scripts, (iv) the legal bases for each category under § 25 TDDDG and Art. 6 GDPR, and (v) the consent and withdrawal mechanisms.

#11. Data retention

We retain personal data only for as long as necessary for the purposes set out in this policy or as required by law. Per Art. 5 (1)(e) GDPR we apply a category-based storage-limitation analysis rather than a single uniform clock. The categories below cover all personal data we process.

Category	Retention period	Legal basis
Account & contract-evidencing data — legal name, contact email, billing identity, order and subscription history, contract amendments, termination notice, dispute correspondence	Duration of your account + 3 calendar years after termination (anchored at end of year)	Art. 6 (1)(f); § 195 + § 199 Abs. 1 BGB (establishing, exercising, defending legal claims)
Invoices, payment records, books of account	6 to 10 years, depending on document type, anchored at end of calendar year — 10 years for books, inventories, and annual accounts (§ 147 Abs. 1 Nr. 1 AO; § 257 Abs. 1 Nr. 1, Nr. 3 HGB read with Abs. 4); 8 years for accounting vouchers and § 14b UStG invoice records (§ 147 Abs. 1 Nr. 4 and Nr. 4a AO post-Bürokratieentlastungsgesetz IV, in force 1 January 2025; § 257 Abs. 4 HGB post-BEG IV); 6 years for commercial correspondence (§ 147 Abs. 1 Nr. 2 and Nr. 3 AO; § 257 Abs. 1 Nr. 2 HGB)	Art. 6 (1)(c); § 147 AO, § 257 HGB, § 14 UStG
Operational preferences — notification and communication preferences, UI settings, saved filters, dashboard layouts, integration tokens, API keys, uploaded files	Duration of the contractual relationship	Art. 6 (1)(b)
Authentication and security-audit events — sign-in records, two-factor events, IP audit, failed-sign-in counters	180 days	Art. 6 (1)(f); BSI IT-Grundschutz baseline
Internal advisory heuristic risk score (described in § 3 "Security" and § 8 "Anti-abuse rate limits and signup-bot scoring") — a single advisory integer per user record	Duration of your account, recomputed on each new abuse signal and overwritten in place (no historical-score table is retained); deleted with the account at end-of-account anonymisation under the "Account & contract-evidencing data" row above	Art. 6 (1)(f) (abuse defence; no Art. 22 (1) decision is taken on the basis of this score)
Application and access logs — routine traffic, error logs	30 days	Art. 6 (1)(f) (operational integrity)
Monitor configurations you create	Duration of the monitor	Art. 6 (1)(b)
Monitor result data — uptime, SSL, domain/WHOIS, speed, transaction, RUM aggregates, virus/malware, server-agent metrics	Up to 13 months, plan-tiered (see the plan-tier matrix on uptimia.com)	Art. 6 (1)(b); customer-utility ceiling
Uptime HTTP response bodies	7 days (auto-expired)	Art. 6 (1)(b) (operational only)
Transaction screenshots	30 days	Art. 6 (1)(f); data-minimisation under Art. 5 (1)(c) (personal data may be visible on authenticated screens)
Support correspondence	Duration of the support matter + 3 calendar years (anchored at end of year)	Art. 6 (1)(f); § 195 + § 199 BGB
Cookie-consent records	180 days for the consent record + 12 months audit-log retention	Art. 7 (1) GDPR (consent evidence)
Backups	Rolling 14-day window	Art. 6 (1)(f) (disaster recovery)

After the period above expires, personal data is deleted or — where deletion would impair audit integrity — anonymised so that re-identification is no longer reasonably possible. Statutory retention (the second row above) prevails over earlier deletion under Art. 17 (3)(b) GDPR.

Account-erasure behaviour (Art. 17 GDPR). When you delete your account via Settings or by request to privacy@uptimia.com, payment integrations, status pages, operators, and active sessions are removed immediately; monitor configurations and alert settings enter the claims-defence tail described in the first row above; your contact and contract-evidencing identity is anonymised or deleted at the end of that tail, subject to the statutory retention required for invoices and books of account. Backups age out per the rolling 14-day window: during that window 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. We maintain an internal backup register documenting the in-scope systems (application database, time-series database, AWS S3 Frankfurt for transaction screenshots), the rotation policy, the storage location, the access controls, and the re-erasure runbook. If we restore from a backup that pre-dates an erasure request, 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 traffic — so that the erased 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 traffic was admitted to the restored system between (i) and (ii).

Visitor data processed under § 7 (processor role). Retained per the DPA, generally as instructed by you as controller. Defaults match the equivalent category above.

HelpCanvas-hosted support conversations. HelpCanvas is a JJ Online product running on JJ Online's own EU infrastructure (§ 5.7) — not a third-party platform — so JJ Online is the single controller for the conversation regardless of which surface it is read or written on. Retention follows the Support correspondence row above (duration of the support matter + 3 calendar years anchored at end of year; Art. 6 (1)(f); § 195 + § 199 BGB). There is no separate "platform-of-record" retention to defer to.

#12. Data security

We implement appropriate technical and organisational measures under Art. 32 GDPR to protect your personal data against unauthorised access, disclosure, alteration, or destruction. In practice:

• TLS 1.2+ for all customer-facing interfaces and all sub-processor communications
• Role-based access controls limiting access to personal data to staff who need it; multi-factor authentication for all operational staff
• Written staff confidentiality obligations
• Disk-level encryption at rest for the application database and the time-series database on EU infrastructure; encrypted backups under a separately-managed key
• Column-level (envelope) encryption for credentials and secrets you supply so the Service can act on your behalf — see the dedicated paragraph below; personal API keys are stored as one-way hashes only
• IP-address truncation for RUM events (/24 IPv4, /48 IPv6) before storage
• Per-user logical isolation in the application layer
• 72-hour personal-data-breach notification process per Art. 33 GDPR
• Periodic vulnerability scanning, dependency monitoring, code review before merge

Credentials and secrets you entrust to us. Where you supply credentials so the Service can authenticate to your resources on your behalf — for example, HTTP Basic credentials, custom request headers (including bearer tokens and API keys), integration credentials for alert channels, and literal values configured in transaction-monitoring steps — those credentials are held under column-level encryption in addition to the disk-level encryption that applies to the database as a whole. The encryption keys are managed separately from the database itself, so operational staff with database access cannot read the cleartext credentials. Decryption occurs only at the point where the probe network executes the check against the resource you configured, and the cleartext is held in memory only for the duration of that single check execution. Personal API keys that you create for programmatic access to the Service are stored as one-way hashes; we do not retain a cleartext copy after issuance — if you lose a personal API key, you must rotate it through the dashboard.

No method of internet transmission or electronic storage is completely secure. If you believe your interaction with us is no longer secure, contact privacy@uptimia.com.

#13. Your rights

As a controller established in the European Union, we are subject to the GDPR under Art. 3 (1) for all our processing, regardless of where the data subject is located. The rights below therefore apply to every individual whose personal data we process, not only to EU/EEA/UK/Swiss residents.

You have the following rights:

• Right of access (Art. 15 GDPR) — request a copy of the personal data we hold about you
• Right to rectification (Art. 16 GDPR) — request correction of inaccurate or incomplete data
• Right to erasure (Art. 17 GDPR) — request deletion, subject to the exceptions in Art. 17 (3) (in particular: legal obligation under § 147 AO / § 257 HGB for invoices)
• Right to restriction of processing (Art. 18 GDPR)
• Right to data portability (Art. 20 GDPR) — receive your data in a structured, commonly-used, machine-readable format
• Right to object (Art. 21 GDPR) — object to processing based on our legitimate interests, including profiling; objection to direct marketing is unconditional
• Right not to be subject to automated decision-making (Art. 22 GDPR) — one Art. 22 (1) decision exists at checkout (payment-fraud screening); the underlying processing rests principally on Art. 6 (1)(c) GDPR (PSD2 SCA + AML/CTF statutory compliance) with Art. 6 (1)(f) covering the residual merchant-side fraud-prevention interest, and the Art. 22 (1) decision itself is authorised under the Art. 22 (2)(b) GDPR authorising-Union-law gateway (with Art. 22 (2)(a) treated as a fallback only). We provide the Art. 22 (3) safeguards (human intervention, expression of view, contest, plus the Stripe Radar decline-reason-and-rule-name disclosure described in § 8). All other automated activities in § 8 are profiling without a solely-automated significant-effect decision attached. Details in § 8.
• Right to withdraw consent (Art. 7 (3) GDPR) — where we rely on your consent, withdraw at any time without affecting the lawfulness of prior processing
• Right to lodge a complaint (Art. 77 GDPR) — Art. 77 (1) gives you three alternative fora: the supervisory authority of (i) your habitual residence, (ii) your place of work, or (iii) the place of the alleged infringement. See § 15 below for the competent authorities and the directory of EEA supervisory authorities.

To exercise any of these rights, contact privacy@uptimia.com. Under Art. 12 (3) GDPR we will respond within one month of receipt of a complete request, extendable by up to two further months for complex or numerous requests; where we extend, we inform you of the extension and the reason within the first month, as Art. 12 (3) requires.

Operational fulfilment pathways.

• Right of access (Art. 15 GDPR) and right to data portability (Art. 20 GDPR) — account-data export. Until self-service is available, the export is generated and returned manually on email request to privacy@uptimia.com. Internally we maintain a written SAR (Subject Access Request) standard operating procedure that targets a working delivery time of five (5) to ten (10) business days for a normal account, well inside the Art. 12 (3) one-month statutory ceiling. The export is delivered as a single ZIP archive containing structured JSON files per data category — account profile, billing history, monitor configurations (credentials shown as one-way fingerprints, never as plaintext; see § 12), check-result summaries, support-correspondence index, cookie-consent record — via a time-limited download link. A self-service /api/v1/me/export endpoint is on the product roadmap; until it ships, the manual SOP is the operational guarantee.
• Right to erasure (Art. 17 GDPR). Account deletion is self-service from the Settings page (password-confirmed) and triggers the purge cron described in § 11; tax-and-bookkeeping records survive per § 11 / § 147 AO / § 257 HGB. Where you prefer human handling, write to privacy@uptimia.com.
• Right to rectification (Art. 16 GDPR). Most account fields are user-editable in the Settings page; for fields that are not user-editable (e.g. invoice billing name on already-issued tax documents), email privacy@uptimia.com.
• Right to restriction (Art. 18 GDPR) and right to object (Art. 21 GDPR). Email privacy@uptimia.com identifying the processing you wish to restrict or object to. Objection to direct marketing is processed on receipt without further reasoning (Art. 21 (2) and (3) GDPR).
• Right to withdraw consent (Art. 7 (3) GDPR). For cookies, see § 9 (Cookie Preferences link, sole parity route per EDPB Guidelines 05/2020 § 117). For any other consent-based processing, email privacy@uptimia.com.

All requests are handled free of charge. Where a request is manifestly unfounded or excessive, we may charge a reasonable administrative fee or refuse to act under Art. 12 (5) GDPR.

Identity verification. Our identity-verification approach is proportionate to the request, as required by Art. 12 (6) GDPR and the EDPB Guidelines 01/2022 on data subject rights — Right of access (§ 64 ff.). In the normal case, we verify identity by matching the sender address of your request against the email address on file for your Uptimia account, and, for actions taken from within the application, by relying on your authenticated session (password + 2FA where you have enabled it). Where this match is sufficient to remove reasonable doubt, we do not request further information — asking for ID documents on every routine request would itself breach the data-minimisation principle in Art. 5 (1)(c) GDPR. Where we have specific reasonable doubt under Art. 12 (6) GDPR — for example, where the request arrives from an address other than the one on file, where the account has recently changed hands or had its contact email updated, where the request concerns sensitive categories such as authentication logs or payment-fraud signals, or where the requested action is irreversible (full data export, account erasure) — we may apply one or more proportionate additional checks: confirmation from the registered email address, completion of an action from the authenticated dashboard, or a one-time code delivered via your configured 2FA channel. We do not ask for government-issued ID, copies of identity documents, or "selfie" verification — those measures would be disproportionate for a B2B observability product whose account binding is to an email address, not to a real-world identity, and they are inconsistent with the EDPB Guidelines 01/2022 § 73 caution against routine ID-document collection. If after proportionate checks reasonable doubt about your identity remains, we will, in accordance with Art. 12 (6) GDPR, request the minimum additional information strictly necessary to resolve that doubt, and we will tell you exactly what we are asking for and why.

#14. Children's privacy

The Service is not directed to children under the age of 16, and we do not knowingly collect personal data from children under 16. If we learn we have collected personal data from a child under 16 without verifiable parental consent, we will delete it as soon as possible.

We apply 16 as our global floor for consent-based processing, regardless of any lower national threshold under Art. 8 (1) GDPR — and we are aware that several Member States have exercised the Art. 8 (1) Wahlrecht downward, including Spain at 14, France at 15, and Italy at 14. The "16 globally" floor is therefore a deliberate, self-imposed standard that is more protective than the lowest applicable national thresholds in those markets, and we accept that as a matter of policy we are auditable against it: if we ever begin to target one of those lower-threshold markets directly, we will continue to apply the 16-floor rather than dropping to the national minimum, and any change to that posture would itself be a material change to this Policy disclosed under § 17. Our verification approach is proportionate to a service that is not directed at children, in the sense contemplated by Art. 8 (2) GDPR. We do not collect date of birth at sign-up — Uptimia is a business-to-business observability product, the sign-up surface is technical-administrator-facing (server names, monitor URLs, alert channels), and asking every account holder for a date of birth would itself create a data-minimisation problem disproportionate to the risk. Instead we rely on the combination of: (i) the Service is not directed at children, marketed to children, or designed for children; (ii) account holders self-identify as professional users by the act of configuring monitors, accepting paid subscriptions, or signing the Terms of Service; (iii) where, on the face of an account or a support interaction, we have reasonable doubt that an account holder is under 16 — for example, support correspondence that affirmatively indicates the account is operated by a minor — we ask the account holder to confirm in writing that they are 16 or older, and delete the account where confirmation is not forthcoming. This is the "service not directed at children, with reasonable-doubt deletion" model that Art. 8 (2) GDPR's proportionality language contemplates for B2B services.

Where you deploy our RUM script on a website that is directed at children, that is your own decision under Art. 8 GDPR and your own controller responsibility.

Parents or guardians who believe a child has submitted personal data may contact privacy@uptimia.com for immediate deletion.

#15. Applicable regimes, lead supervisory authority, and cross-border transfers

#Applicable regimes

• EU GDPR. As a controller established in Germany, Regulation (EU) 2016/679 applies under Art. 3 (1) to all our processing regardless of where the data subject is located.
• UK GDPR. We do not direct our Service to data subjects in the United Kingdom. The EDPB Guidelines 3/2018 § 2.1 / § 2.2 territorial-scope analysis turns on a cumulative reading of the named markers — currency, top-level domain, language as a country signal, mention of local customers, country-specific marketing campaigns, dedicated local phone or address, delivery terms — and the conclusion is reached by examining the markers together, not by ruling out any single one. On a cumulative reading of those factors, none points to the United Kingdom: our pricing is listed in EUR (and, where applicable, USD), not GBP; our domain is uptimia.com with no .co.uk surface; we publish no UK landing pages, no UK case studies, no UK-resident customer testimonials, no UK-specific marketing campaigns, and no UK-geo-targeted advertising; we run no UK-language SEO or UK-targeted content production; and the Website is published in English because English is the controlling language of our documentation and product (English is, on the Guidelines 3/2018 analysis, not a country signal where it is not paired with any of the other markers above). On those facts we consider Art. 3 (2)(a) UK GDPR not to be engaged: UK data subjects who sign up for the Service do so by reaching uptimia.com through organic English-language search and not because we have offered the Service to them in the United Kingdom within the meaning of Art. 3 (2)(a). We do not "monitor the behaviour" of UK data subjects within the meaning of Art. 3 (2)(b) either — the RUM script the Controller deploys runs on the Controller's own visitors on the Controller's own websites and is processed on the Controller's instructions, not directed by us at any UK population. Should Art. 3 (2) UK GDPR nonetheless be considered to apply to incidental UK signups, our processing also satisfies the Art. 27 (2)(a) UK GDPR exemption as occasional (no structured UK operations, no UK acquisition activity, no UK customer-success motion) and low-risk (no special-category data, no large-scale profiling, no monitoring at scale of UK data subjects). We will reassess this position and appoint a UK representative if we begin to target the United Kingdom — for example by adding GBP pricing, a .co.uk domain or subdirectory, UK case studies or testimonials, UK-specific landing pages or comparison pages, UK-geo-targeted paid acquisition, or UK-language content production. UK data subjects who interact with the Service retain their statutory right to lodge a complaint with the Information Commissioner's Office (ICO) at https://ico.org.uk under Art. 77 UK GDPR; we will cooperate with any ICO inquiry on its merits regardless of our territorial-scope position.
• Other jurisdictions (CCPA / CPRA, LGPD, PIPL, and similar extraterritorial regimes). We do not currently process personal data of California consumers, Brazilian data subjects, Chinese data subjects, or other non-EEA / non-UK / non-Swiss data subjects on a scale or in a configuration that triggers the thresholds for extraterritorial application of the California Consumer Privacy Act (as amended by the California Privacy Rights Act), the Brazilian Lei Geral de Proteção de Dados (LGPD), the Chinese Personal Information Protection Law (PIPL), or comparable non-EU privacy regimes. In particular, we are below the US-revenue and California-consumer thresholds for CCPA / CPRA applicability under Cal. Civ. Code § 1798.140(d). We monitor our exposure under each of these regimes as our customer base evolves and will update this Policy and appoint local representatives or designated agents (e.g., a US verified-request agent under § 999.312 CCPA Regulations; an encarregado (DPO) under Art. 41 LGPD — noting that the LGPD itself contains no GDPR-Art.-27 equivalent and any local-representation obligation in Brazil would arise separately under Brazilian corporate law (in particular Art. 1.134 of the Brazilian Civil Code and Art. 146 § 2 of Law 6.404/1976), not under the LGPD as such; a PIPL local representative under Art. 53 PIPL) if and when thresholds are crossed.
• Swiss FADP. Applies under Art. 3 (1) FADP where our activities have an effect in Switzerland. The targeting analysis here mirrors the cumulative-reading discipline applied above for the UK: the question is whether the named country-marker factors, taken together, point to Switzerland — not whether each individual factor can be ruled out on its own. On a cumulative reading, none of them does: we operate no .ch domain, no CHF pricing, no Swiss landing pages, and no Swiss-targeted campaigns; and the Website is published in English, not as a Swiss country signal but as our controlling documentation language. Art. 14 (1) FADP requires a private controller domiciled abroad to designate a representative in Switzerland where it processes personal data of persons in Switzerland and the processing cumulatively satisfies four conditions: (a) the processing is in connection with the offering of goods or services or with the monitoring of the behaviour of those persons; (b) it is extensive (large-scale); (c) it is regular; and (d) it poses a high risk to the personality of the data subjects (hohes Risiko für die Persönlichkeit der betroffenen Personen). The threshold is not met on our facts: Swiss data subjects who sign up for the Service reach uptimia.com through organic English-language search incidental to our EU operations, not through a Swiss offering by us — so condition (a) is not engaged — and the volume is neither extensive within condition (b) nor regular within condition (c) as those terms are understood in FDPIC guidance; we also do not consider condition (d) to be met, since the Service does not, on the facts of our typical Swiss-incidental processing, pose a high risk to the personality of the data subjects. Failure of any one of the four cumulative conditions is sufficient on its own; on our facts conditions (a)–(d) each independently fail. (Note that high risk is both the Art. 14 (1)(d) representative-appointment condition above and, separately, the trigger for a Data Protection Impact Assessment under Art. 22 FADP — they are independent obligations attached to the same factual element, and we treat the Art. 22 FADP DPIA analysis separately.) We will reassess and appoint a Swiss representative if we begin to target Switzerland (a .ch surface, CHF pricing, Swiss case studies, Swiss-targeted advertising) or if our Swiss processing becomes large-scale and regular.

#Lead supervisory authority

Our lead supervisory authority under the GDPR one-stop-shop mechanism is the Berliner Beauftragte für Datenschutz und Informationsfreiheit (BlnBDI):

Alt-Moabit 59-61 10555 Berlin, Germany Website: https://www.datenschutz-berlin.de

EEA residents may complain, at their option under Art. 77 (1) GDPR, to the supervisory authority of (i) their habitual residence, (ii) their place of work, or (iii) the place of the alleged infringement — or to BlnBDI directly as the lead authority. The directory of EEA supervisory authorities is at https://edpb.europa.eu. UK residents may complain to the Information Commissioner's Office (ICO) at ico.org.uk under Art. 77 UK GDPR. Swiss residents may notify the Federal Data Protection and Information Commissioner (FDPIC / EDÖB) at edoeb.admin.ch under Art. 49 FADP.

#Legitimate interests assessment summary

For each purpose grounded in Art. 6 (1)(f):

• Account-security signals (your registration IP, your most-recent sign-in IP, your failed-sign-in counter, your two-factor-authentication audit log, and an internal heuristic risk score) — our interest in protecting your account against credential stuffing, brute-force attacks, and sign-up abuse, weighed against the limited and account-tied nature of the signals; the data subject's interests are protected by access controls and the fact that the data is tied to a contractual relationship.
• Service improvement and probe-network operations — pseudonymised or aggregated processing only; no individual profiling.
• Aggregate server-side measurement-quality monitoring — no individual identification.
• Product-update communications to existing account holders (§ 7 Abs. 3 UWG Bestandskundenwerbung) — our retention interest in keeping paying customers informed of product changes that affect what they bought, weighed against the marketing-burden imposition on the recipient. Compliance with the four cumulative § 7 Abs. 3 UWG conditions is treated as the principal safeguard: (i) address collected in the context of the sale of our goods or services; (ii) content limited to direct marketing of our own similar products and services; (iii) the recipient has not objected; and (iv) the recipient was clearly and conspicuously informed (klar und deutlich) of the right to object both at the point of collection and in each subsequent message, with no costs beyond the basic transmission rates (Basistarif). Objection under Art. 21 GDPR is unconditional and processed on receipt without further reasoning.
• Non-customer enquiry responses — answering inbound enquiries from visitors who contact us (sales questions, partnership requests, support questions outside an active account) is grounded on the reasonable expectation that we will reply to the address they used to write to us.

A full LIA for any of these activities is available on request at privacy@uptimia.com.

#Automated decision-making (Art. 22 GDPR)

One automated decision in scope of Art. 22 (1) GDPR operates at the point of payment-fraud screening at checkout, described in § 8. The Art. 22 (2) gateway we rely on is principally Art. 22 (2)(b) GDPR — the PSD2 SCA framework (Directive (EU) 2015/2366 read with Commission Delegated Regulation (EU) 2018/389) and the AML/CTF framework cited in § 8 constitute authorising Union law that requires the very transaction-monitoring decisions made at checkout and that itself lays down suitable safeguards for the data subject; Art. 22 (2)(a) GDPR (contract necessity) is engaged as a fallback only, consistent with the EDPB's narrow reading of "necessary for the contract." We provide the Art. 22 (3) GDPR safeguards in full: a meaningful right to human intervention by the payment processor's manual-review team and by our billing operations, a right to express your view, a right to contest the outcome, and — added 2026-05-27 — disclosure on Art. 22 (3) request of the specific decline-reason code and, where applicable, the Stripe Radar rule name (see § 8 fourth Art. 22 (3) bullet). The contact for any such request is privacy@uptimia.com; we respond within the Art. 12 (3) GDPR timeframe. The internal heuristic score on your user record described in § 8 is an advisory input to human review, not an automated decision.

#Personal-data breach notification (Art. 33–34 GDPR)

In the event of a personal-data breach likely to result in a risk to your rights and freedoms, we will notify the BlnBDI without undue delay and, where feasible, within 72 hours of becoming aware of the breach (Art. 33 GDPR). Where the breach is likely to result in a high risk, we will also notify affected users without undue delay under Art. 34 GDPR.

Notification mechanism. Direct email to the address registered on your account, with a subject line identifying the message as an Art. 34 GDPR personal-data-breach notification. We additionally display an in-product notice in the authenticated dashboard on your next session. Where direct notification would involve disproportionate effort under Art. 34 (3)(c), we issue a public communication on the Website.

#International data transfers

We transfer personal data to recipients outside the EEA only as part of the normal operation of the third-party services listed in § 5 and § 7. The following non-EEA destinations are involved:

Destination	Recipient(s)	Mechanism
USA	Stripe, Inc. (Stripe sub-processing); PayPal, Inc. (PayPal sub-processing); Amazon Web Services, Inc. (SES non-EU recipients, probe network non-EU regions); DigitalOcean, LLC (probe network); Akamai Technologies, Inc. (probe network); Vultr Holdings, LLC (probe network); Contabo GmbH (probe network — US-located probe regions; contracting entity is Contabo GmbH in Munich, processing physically occurs at Contabo's US infrastructure); Okta, Inc. (Auth0 sub-processing); GitHub, Inc. (Auth0 social connection); Google LLC (Web Risk, PageSpeed sub-processing; Auth0 social connection); Mattermost, Inc. (alerts, if configured); PagerDuty, Inc. (alerts, if configured); Microsoft Corporation (Teams alerts sub-processing, if configured); Slack Technologies, LLC (Salesforce Group) (Slack alerts sub-processing, if configured); Discord, Inc. (Discord alerts sub-processing, if configured); X Corp. (X alerts, if configured); Twilio, Inc. (SMS sub-processing); Meta Platforms, Inc. (WhatsApp Cloud sub-processing)	EU–US Data Privacy Framework (Implementing Decision (EU) 2023/1795) where the recipient is DPF-certified, with SCCs (Implementing Decision (EU) 2021/914) maintained as automatic fallback. Vultr is not DPF-certified — SCCs + the ephemeral-processing property on the probe layer (see § 5.3) are the supplementary measures relied on. Contabo is contracted through its EU entity (Contabo GmbH, Munich) so the SCC analysis applies to the physical-processing leg at non-EU Contabo regions; the same ephemeral-processing property on the probe layer (Annex B.6 of the DPA) is the supplementary measure relied on for non-EU Contabo regions. X Corp. is not currently DPF-certified — SCCs + supplementary measures; only activated if you configure X as an alert channel.
UAE	Telegram FZ-LLC (alerts, only if you configure Telegram)	No adequacy decision for the UAE, and Telegram FZ-LLC does not offer a standard Art. 46 GDPR transfer mechanism (no published SCC offer, no DPA template, no transfer-impact materials). We therefore rely, as the controller initiating the transfer when an alert dispatches, on the Art. 49 (1)(b) GDPR derogation — the transfer is necessary for the performance of the contract between you (the account holder, as the data subject) and Uptimia: by configuring Telegram as your chosen alert delivery channel in the alert-channel settings, you have made delivery of the alert to your Telegram chat an objectively necessary element of the monitoring service you have contracted for. The Art. 49 (1)(b) basis covers the account holder's own personal data (your Telegram user-ID, the bot-channel ID you provided, the alert payload addressed to you). Where you would route alerts to a Telegram group or channel that includes recipients who are not parties to your Uptimia contract, those recipients are outside the scope of the Art. 49 (1)(b) basis — please use a controller-to-controller arrangement of your own (e.g. obtain Art. 49 (1)(a) explicit consent from those recipients before adding them, or route the alert through an intermediary they have an established relationship with), and do not rely on Uptimia's Art. 49 (1)(b) coverage for that leg. The supplementary measures we apply on our side are encryption-in-transit (HTTPS to the Telegram Bot API), payload minimisation (the alert event contains incident metadata only — monitor name, state change, timestamp; we do not transmit end-user personal data of your visitors), and the channel is opt-in (configurable on, configurable off). Consistent with the EDPB Guidelines 2/2018 on derogations under Article 49 § III, we treat the Art. 49 (1)(b) reliance as occasional and necessary: it is engaged only on accounts that have affirmatively configured Telegram, the transferred data is minimised to what is strictly required for alert delivery, and we will reconsider the basis if Telegram alerts become a structurally repetitive flow for a given account beyond what is required to fulfil your contract. Recommended for ops-team paging only; do not script end-user personal data into Telegram alert payloads.
Australia (with onward processing in the USA)	Atlassian Pty Ltd (Statuspage alerts and public status pages, only if you configure Statuspage as an alert channel or status-page surface)	No adequacy decision for Australia. Statuspage is operated by Atlassian on US infrastructure (AWS), so a transfer to the USA arises in parallel with the contracting-party transfer to Australia. We rely on Atlassian's published Data Processing Addendum and the EU SCCs (Implementing Decision (EU) 2021/914) covering the Australian-controller and US-sub-processor flows, together with the Atlassian Sub-Processor list (which we monitor at every policy revision) for the onward chain. Supplementary measures: TLS 1.2+ on every outbound alert / status-page event, minimisation of the alert/status payload to incident metadata (an alert or status post is incident-state, timing, and summary; no end-user personal data is required in a Statuspage event), and the channel / status-page surface is activated only on your configuration. You bear the controller-side risk assessment for choosing Statuspage as an alert channel or public status surface.

For the parallel UK GDPR regime, we apply the UK International Data Transfer Agreement and the UK Addendum to the EU SCCs (ICO March 2022) for incidental UK customers. For the Swiss FADP regime, we apply the FDPIC-approved EU SCCs with the Swiss-specific addendum.

A per-recipient Transfer Impact Assessment is maintained on file for each US recipient and for the Atlassian (Australia + US-onward) row. Copies available at privacy@uptimia.com. The Telegram (UAE) row does not rest on Art. 46 GDPR — instead it rests on the Art. 49 (1)(b) GDPR derogation, with the operational scope set out in the table above. The Art. 49 reliance is recorded in an Art. 30 (1)(e) GDPR entry on our record of processing activities (account-by-account, since the basis is engaged only on accounts that have affirmatively configured the channel) rather than in a transfer-mechanism TIA, which is the EDPB Guidelines 2/2018 format for Art. 49 reliance.

DPF-status version-dating. The DPF-certification status of each US recipient identified above is verified as at the Last updated: date at the top of this Policy. DPF certifications can be granted, suspended, or withdrawn between policy revisions — X Corp., for example, has appeared and disappeared from the active list more than once since the framework took effect under Implementing Decision (EU) 2023/1795. We re-verify the DPF list at every policy revision; in the interim, SCCs (Implementing Decision (EU) 2021/914) are maintained as automatic fallback for every US recipient, regardless of current DPF status, so that no transfer ever depends solely on a status we have not just re-checked. The SCC module selected per recipient, the supplementary measures, and the per-recipient Transfer Impact Assessment copies are version-controlled internally and reissued whenever the underlying facts change.

DPF dispute-resolution mechanisms — your rights against the recipient. Recipients certified under the EU–US Data Privacy Framework are bound, as a condition of certification, to comply with the DPF Principles, to provide an independent recourse mechanism at no cost to the data subject (each certified organisation designates one — typically TRUSTe, BBB EU Privacy Shield, JAMS, the AAA-ICDR, the panel of EU Data Protection Authorities for HR data, or another approved provider) and, as a binding last-resort option, to participate in binding arbitration before the DPF Panel under Annex I to the DPF Principles. They are subject to investigatory and enforcement powers of the US Federal Trade Commission (or, for certain sectors, the US Department of Transportation), and to oversight by the US Department of Commerce. You may invoke these routes directly against the certified recipient if you believe that recipient has breached its DPF commitments in respect of your personal data — typically by first filing a complaint with the recipient, then escalating to the independent recourse mechanism designated in the recipient's DPF certification record at https://www.dataprivacyframework.gov, and ultimately by referring the matter to the FTC or invoking DPF Panel arbitration. The recipient is required to identify the applicable independent recourse mechanism in its own privacy notice and at its DPF certification entry on dataprivacyframework.gov; we recommend you consult the recipient's certification entry for the current designation. Nothing in this paragraph displaces your right to lodge a complaint with your competent EU/EEA supervisory authority under Art. 77 GDPR or to pursue judicial remedies under Arts. 78–79 GDPR — those remedies remain available in parallel with the DPF routes.

#Data protection officer

We have assessed the criteria in Art. 37 (1) GDPR and § 38 Abs. 1 BDSG. § 38 Abs. 1 BDSG requires DPO designation on three independent bases: (a) the headcount basis — 20 or more persons permanently occupied with the automated processing of personal data (threshold raised from 10 to 20 by the 2. DSAnpUG-EU of 20 November 2019, in force from 26 November 2019); (b) the DPIA basis — processing subject to a data protection impact assessment under Art. 35 GDPR regardless of headcount; and (c) the commercial-transfer-or-research basis — commercial processing of personal data for the purpose of transfer, anonymised transfer, or market or opinion research, again regardless of headcount. We do not meet any of the three bases. On (a), we do not meet the 20-person threshold. On (b), our processing is not subject to a DPIA: it does not appear on the BlnBDI Art. 35 (4) list of processing operations requiring a DPIA, and our own Art. 35 (1) self-assessment — small B2B observability service, no special-category data as a core activity, no large-scale systematic monitoring of natural persons in their private life, no automated decision with legal or similarly significant effect outside the narrow payment-fraud flow described in § 8 (which itself is authorised under the Art. 22 (2)(b) authorising-Union-law gateway, with Art. 22 (2)(a) as a fallback only) — concludes that no individual processing operation reaches the Art. 35 (1) "likely to result in a high risk" trigger. On (c), we do not commercially process personal data for the purpose of transfer to third parties, for anonymised transfer, or for market or opinion research; the Service is a paid observability tool, not a data-broker, list-rental, or research-panel business. We are therefore not required to designate a DPO. Matters relating to our processing of personal data can be directed to privacy@uptimia.com; Andrius Gecius (Geschäftsführer) is the responsible point of contact.

#16. Links to other websites

The Service may contain links to third-party websites. We have no control over and accept no responsibility for the privacy practices or content of those websites. We encourage you to read the privacy policy of any website you visit.

#17. Changes to this policy

We may update this Privacy Policy from time to time. When we do, we will update the Last updated: date at the top of this document and bump the version. For material changes — in particular any change affecting the legal basis for processing, the categories of recipients of your personal data, or international transfers — we will give you prominent notice (such as an email notification) at least 30 days before the change takes effect.

You do not lose any rights, and you do not grant any new ones, by continuing to use the Service.

#18. Contact us

For questions, concerns, or to exercise your rights under this policy, contact the controller identified in § 2:

JJ Online GmbH (operating Uptimia)

Schönhauser Allee 163, 10435 Berlin

Germany

Phone: +49 151 12032902

Email — general: admin@uptimia.com

Email — privacy and data-subject requests: privacy@uptimia.com

For data-processor-role matters (your visitor / end-user data flowing through Uptimia), see the DPA.