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 ProductLog ("we", "us", or "our"), operated by JJ Online GmbH, processes your Personal Data in connection with https://productlog.dev (the "Website") and the ProductLog service (the "Service"), in line with Arts. 13 and 14 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 a Workspace, configure projects and boards, or otherwise use the Service. Where any item is instead collected from a third party — specifically:

• payment-method metadata returned by Stripe in connection with your Subscription;
• 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 a Workspace Operator is obtained from a third party.

#2. Data Controller and the three-audience model

#2.1 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 a ProductLog Workspace Operator is:

JJ Online GmbH (operating ProductLog)

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: [email protected]

Email — privacy and data-subject requests: [email protected]

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

#2.2 Three audiences, two controllership shapes

ProductLog touches three populations:

Audience	Who you are	Our role	Governing document
Workspace Operator	A paying ProductLog account holder running the tool for your team	Controller in respect of your operator Account data	This Privacy Policy describes our processing
End-Subscriber	A person who subscribed to a customer's public changelog board to receive email notifications	The Workspace Operator is Controller; we are Processor under Art. 28 GDPR on their behalf	The Workspace Operator's own privacy notice + our DPA
End-Feedback-User	A person who posts, votes, comments, or reacts on a customer's public roadmap or feedback board	The Workspace Operator is Controller; we are Processor on their behalf	The Workspace Operator's own privacy notice + our DPA

This Policy describes our processing as Controller for Workspace Operators. § 7 below describes our Processor-role processing for End-Subscribers and End-Feedback-Users — operating under our DPA on the Workspace Operator's documented instructions.

#3. Information we collect

#3.1 Workspace-Operator Account data

When you create or operate a ProductLog Account, we process the following:

• Identity: email (unique), password (stored as a bcrypt hash; the cleartext is never persisted), name, avatar URL
• Role and access: Owner / Admin / Editor / Viewer; status (Active / Inactive); organisation assignment
• Two-factor authentication: TOTP secret (base32), enabled flag, recovery codes (bcrypt-hashed)
• Lifecycle: last sign-in timestamp; team-invitation token (64-hex, 7-day TTL); created / updated timestamps; soft-delete timestamp
• Organisation: legal name, slug, plan (Free / Starter / Pro / Business), status, white-label branding (color, logos, sanitised CSS), Stripe customer + Subscription IDs, trial-end timestamp, operator-locale preference
• Project configuration: name, slug, custom domain + DNS-TXT verification token + verified flag, public / private flag, comment / reaction enablement, per-project categories and statuses

Two-factor authentication channels. Where you enable 2FA, the second factor is 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.

#3.2 Billing data

• Stored locally on the organisation record: Stripe customer ID, Stripe Subscription ID, plan, status, trial-end timestamp. No card data is stored locally — Stripe holds card details under the PCI-DSS scope it operates.
• Subscription invoices and credit notes: issued and archived by easybill GmbH (Germany) on our behalf — easybill integration is imminent and will be live before the first paid ProductLog Subscription is billed.

#3.3 Customer-authored content (Workspace Content)

When a Workspace Operator publishes content on the customer's public boards, we host it as part of operating the Service:

• Changelog entries — title, slug, rich-text body, plaintext preview, status (Draft / Scheduled / Published), publish timestamp, SEO fields, cover image, label set, view / reaction / comment counters
• Roadmap and feedback posts — title, rich-text description, status (Pending → Open → Under Review → Planned → In Progress → Shipped → Closed), prioritisation framework fields (RICE: reach / impact / confidence / effort; MoSCoW category), pinned / tag / metadata fields
• Surveys — survey question definitions, response payloads
• Knowledge-base articles — published under productlog.dev/kb/… or under a custom domain
• Image uploads for rich-text content — stored on our own local filesystem at OVH France; no S3 / R2 / Spaces Sub-processor

#3.4 Authentication and session data

• JWT access token — 30-day TTL, RSA-signed. Stored client-side in localStorage under the key token — today this token is not stored in an HttpOnly cookie, which means any JavaScript executing on productlog.dev (including the embedded HelpCanvas widget) can read it. Migration to an HttpOnly + Secure cookie is on the product roadmap; until then the disclosure is honest and the residual XSS exposure is an accepted known risk under Art. 5 (1)(a) GDPR transparency
• Refresh token — SHA-256 hash stored server-side; raw token never persisted; 30-day TTL, revocation timestamp
• Password-reset tokens — SHA-256 hash, 60-minute TTL, used-at timestamp
• Team-invitation tokens — 64-hex, 7-day TTL
• Sign-in throttling — 5 failed attempts per 5 minutes per IP, enforced via a distributed lock; no persistent failed-sign-in table

#3.5 End-Subscriber data (Processor-role)

When an End-Subscriber signs up to receive changelog notifications from a Workspace Operator's public board, we process — on the Workspace Operator's behalf as their Art. 28 GDPR Processor — the following:

• email (indexed against the project), optional name, status (Pending → Active → Unsubscribed → Bounced)
• source (organic / api / import), per-subscriber attributes (locale, segments, custom fields)
• unsubscribe token (one-click), double-opt-in confirmation token

The double-opt-in confirmation email is dispatched via AWS SES (Frankfurt) and links the subscriber back to a verification URL. Until verification, the subscriber row sits in Pending status and receives no broadcasts.

#3.6 End-Feedback-User data (Processor-role)

When a visitor posts a comment, leaves a vote, or reacts on a customer's public board, we process — on the Workspace Operator's behalf — the following:

• Changelog comments: body, author name, optional author email (not validated)
• Changelog reactions: emoji choice
• Feedback posts: author-supplied title and body; author name; optional author email
• Feedback votes: voter key — the visitor's authenticated end-user UUID where they signed in, otherwise the server-side fingerprint hash (see § 3.7)
• Feedback comments: body, author name, optional author email; staff-only "internal" comments are tagged separately and hidden from public

#3.7 Public-board visitor metadata (Processor-role)

For each request to a public-board surface, we process (on the Workspace Operator's behalf):

• IP address — read in plaintext at the application layer for rate-limiting and the fingerprint computation below
• User-Agent — read in plaintext for the same purposes
• Fingerprint hash — server-side SHA-256(IP | User-Agent) hash, stored against each vote / reaction / comment / survey response. This is the anti-double-vote / anti-double-reaction enforcement — see Cookie Policy § 8. The hash is not used for tracking, profiling, or analytics; it is functionally equivalent to a server-side one-vote-per-visitor lock
• Public-board analytics events — event type (page view, entry view, vote, comment, etc.), session ID (client-generated UUID, posted with each event — no first-party tracking cookie is set), subject reference, occurrence timestamp, IP address, User-Agent. Today the IP and User-Agent in those analytics records are stored in plaintext; hashing at the storage layer is a pending product item disclosed here under Art. 5 (1)(a) GDPR transparency

#3.8 Broadcast-email tracking

When a Workspace Operator publishes a changelog entry and sends a broadcast to its End-Subscribers, we process:

• open events (a 1×1 pixel load triggers an analytics event)
• click events (outbound links are rewrapped through our redirector; the redirect triggers an analytics event)
• per-broadcast counters: recipient count, open count, click count, failed count

#3.9 Customer-enabled outbound integration configurations

When a Workspace Operator connects a third-party tool (Slack / Jira / Linear / generic webhooks), we store the integration configuration (provider type, enabled flag, the customer-supplied credentials) and relay event payloads as configured. Today the customer-supplied outbound-integration credentials (Slack webhook URL, Jira API token, Linear API key) are stored as plaintext in the application database; column-level (envelope) encryption is a pending product item. The destinations are not Sub-processors of JJ Online; the Workspace Operator is the Controller of the onward transfer and is responsible for its own DPA with the chosen provider.

Outbound webhook delivery payloads currently accumulate indefinitely with the full event payload (which may include End-Feedback-User Personal Data) attached. A TTL + purge job (target 30 days) is a pending product item disclosed here under Art. 5 (1)(a) GDPR transparency.

#3.10 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://productlog.dev), the authenticated dashboard, and (today) every public board surface we render. 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.3 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 — [email protected] (general), [email protected] (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), 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 your Service contract; 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, with the legitimate interest being to respond to inbound communications addressed to our published role addresses.

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.

#3.11 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 and for the public-board fingerprint described at § 3.7)

These values are read transiently for the request and are not persisted on your operator Account beyond the sign-in audit trail in § 3.4.

#3.12 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. For paid Workspaces, your name, billing address, VAT-ID where applicable, and transaction details must be retained to comply with German tax and accounting obligations (§ 147 Abs. 3 AO, § 257 Abs. 4 HGB for accounting vouchers; § 14 UStG for VAT-invoice content). Without these, we cannot lawfully invoice you.
• Required by contract. Your email, password, the Workspace and project configurations you submit, and any Workspace Content you publish 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, sign-in timestamps, refresh-token state, and (where you enabled it) 2FA state are processed under Art. 6 (1)(f) GDPR to keep your Account secure.
• Required for the End-Subscriber flow. An End-Subscriber's email + double-opt-in confirmation are the basis for sending the notifications they signed up for under Art. 6 (1)(a) GDPR consent; without them we cannot deliver the service the subscriber requested.
• Voluntary. Optional avatar URL, optional author email on end-feedback comments, optional segment attributes are at your or your end-user's discretion; non-provision does not affect access to the Service.

#3.13 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. ProductLog is a business-to-business changelog / roadmap / feedback tool; none of the categories listed in § 3 is designed or intended to capture Art. 9 data.

Please do not submit special-category data — for example, do not paste it into changelog entries, feedback posts, public-board comments, survey questions, support tickets, or outbound integration payloads. 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.

Where a Workspace Operator, as Controller, publishes a public board (or sends a broadcast) on a surface where End-Feedback-Users may submit special-category data, that is the Workspace Operator's own controller decision and the Workspace Operator's own responsibility under Art. 9 GDPR; nothing in our Service or DPA authorises the Workspace Operator to route special-category data through ProductLog, 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, issuing / rotating JWT and refresh tokens, enforcing 2FA where you enabled it	Art. 6 (1)(b) — contract
Storing and rendering the Workspace Content you publish	Art. 6 (1)(b) — contract
Operating the public boards you publish — accepting and displaying End-Feedback-User comments, votes, reactions, and survey responses	Art. 6 (1)(b) — contract (as your Processor, on your behalf)
Sending changelog-notification broadcast emails to End-Subscribers who completed double opt-in	Art. 6 (1)(a) — consent (the End-Subscriber's, collected via double opt-in, on the Workspace Operator's behalf)
Relaying event payloads to customer-enabled outbound integrations (Slack / Jira / Linear / generic webhooks)	Art. 6 (1)(b) — contract (extension of the Workspace Operator's contract)
Anti-double-vote / anti-double-reaction enforcement on public boards via server-side IP + User-Agent hash	§ 25 Abs. 2 Nr. 2 TDDDG · Art. 6 (1)(b) and (f) — see Cookie Policy § 8
Operator-facing public-board analytics (page views, entry / post engagement, broadcast open and click rates)	Art. 6 (1)(f) — legitimate interest of the Workspace Operator in measuring engagement on their own board; 90-day retention target (purge job pending — see § 11)
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; § 14 UStG)
Bot defence via the self-hosted Altcha proof-of-work challenge on signup and public-form submissions	Art. 6 (1)(f) — legitimate interest in abuse prevention
Rate-limiting on sign-in, sign-up, forgot-password, contact-form, and public-board action endpoints	Art. 6 (1)(f) — legitimate interest in Account integrity
Issuing transactional communications (Account, billing, security)	Art. 6 (1)(b) — contract
Issuing legally mandated notices (Art. 12–14, Art. 34 personal-data-breach notifications)	Art. 6 (1)(c) — legal obligation
Sending product-update communications to existing Workspace Operators (ProductLog 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). Objection under Art. 21 GDPR is unconditional and processed on receipt without detriment to your underlying contract
Sending marketing communications you separately 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 [email protected].

#5. Third-party services we use as a Controller

The services listed in this section process Personal Data of you as a ProductLog Workspace Operator under our instructions as Controller of the Website and the Service. Sub-processors engaged for our Processor role (End-Subscribers + End-Feedback-Users) are listed in § 7 and in our 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
easybill	easybill GmbH	Germany	Invoice generation, GoBD-compliant invoice archiving	n/a (EU only)

Stripe is our sole payment processor. We do not accept PayPal or any other payment method.

#5.2 Hosting and core infrastructure

Provider	Legal entity	Location	Function	Transfer mechanism
OVH	OVH SAS	France (Roubaix / Gravelines / Strasbourg)	Hosting of application servers, primary database, local file storage for image uploads, backups	n/a (EU)
Cloudflare	Cloudflare, Inc.	USA HQ (with EU edge nodes)	CDN, DDoS protection, DNS, TLS termination, geolocation (CF-IPCountry) for public boards	SCC (Implementing Decision (EU) 2021/914) + Cloudflare EU Data Protection Addendum
AWS SES	Amazon Web Services EMEA SARL	Luxembourg (eu-central-1 Frankfurt)	Transactional email (signup, password reset, team invitation, security alerts) and broadcast email (changelog notifications, feedback status changes)	n/a (Frankfurt EU region); corporate-group access by Amazon.com, Inc. (USA) covered by SCC

#5.3 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 Art. 28 Sub-processors. All run on the same EU footprint as the main ProductLog application — OVH France — under the same Art. 32 technical and organisational measures described in § 12.

• HelpCanvas widget — in-app chat support, loaded on every productlog.dev route. The HelpCanvas application and its message store are hosted on OVH France under the JJ Online stack; HelpCanvas conversations do not leave the EU. The pre-consent loading of the widget is documented in § 9
• ErrorHawk SDK — internal operational error tracking. The SDK is wired on the production backend and ships uncaught exceptions (with request context) to JJ Online's own ErrorHawk instance on EU infrastructure. Same-controller flow, not a third-party Sub-processor. Inbound payloads may incidentally include request body fields and are subject to the same Art. 32 measures as the main application
• Altcha — self-hosted proof-of-work captcha on signup and public-form submissions; runs locally on our infrastructure, no third-party data flow

#5.4 What we deliberately do not use

For the avoidance of doubt — and verified against the production codebase on 2026-05-26 — ProductLog does not use any of the following on productlog.dev: Google Analytics / GA4 / Google Tag Manager, Meta Pixel, LinkedIn Insight, X / Reddit pixels, Plausible, Matomo, Fathom, Umami, PostHog, Mixpanel, Segment, Hotjar, FullStory, LogRocket, Microsoft Clarity, Sentry browser SDK, Intercom / Crisp / Drift (HelpCanvas is our chat), A/B-testing SDKs, PayPal, Stripe.js on first-party pages, AI-translation provider (see § 5.5 below).

#5.5 Planned features — not yet built

The product vision includes AI translation of public-board content into the end-user's language. This is not yet built: no implementation exists in the production stack today. When it ships, the chosen LLM provider must be added to this Privacy Policy and to the DPA Annex C as a Sub-processor, with a 30-day Sub-processor change notification under DPA § 9.3.

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.3 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.

#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). 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, 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. ProductLog as a Processor for End-Subscribers and End-Feedback-Users

When a Workspace Operator operates a public board through ProductLog, the Workspace Operator is the Controller of the End-Subscribers, End-Feedback-Users, and public-board visitors, and ProductLog is the Processor on their behalf.

Flow	What Personal Data flows through ProductLog
Public-board changelog subscription	End-Subscriber email + optional name + locale + double-opt-in tokens
Public-board feedback posting / voting / commenting / reactions	Author name, optional author email, comment body, fingerprint hash (IP + User-Agent)
Broadcast email delivery (changelog notifications, feedback-status changes)	End-Subscriber email, message content, delivery / open / click metadata
Operator-facing public-board analytics	Analytics-event records: IP, User-Agent, session ID, subject reference, timestamp

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 End-Subscribers' / End-Feedback-Users' Personal Data on the following analysis:

• Purposes are yours. You decide whether to publish a public board, whether to open it to subscriptions, whether to allow comments / votes / reactions, whether to send broadcasts, and which outbound integrations to relay events to. None of those processing operations begin until you initiate them
• Essential means are yours. Your configuration determines the category of data (publishing a public roadmap = author names + optional emails + post bodies; enabling subscriptions = subscriber-email list; enabling broadcasts = engagement metrics on your subscriber list); the categories of Data Subjects are determined by who visits your boards and who you invite; the retention period defaults are set out in § 11 and may be tightened by you on instruction; the recipients of the data are limited by your Workspace isolation and by the Sub-processors documented in the DPA Annex C, to which you consent by deploying
• Non-essential means are ours. The choice of EU-located storage infrastructure (OVH France for the application database, AWS SES Frankfurt for email delivery), the rich-text rendering pipeline, the server-side fingerprint computation for one-vote-per-visitor enforcement, the proof-of-work challenge on public-form submissions, and the broadcast-pipeline architecture are technical implementation choices we make as 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 (Workspace creation, project configuration, board publication, broadcast composition), the documented instructions in the DPA, and the per-Account Processing Instructions Summary described at DPA § 6.1(e) together constitute your documented instructions for the purposes of Art. 28 (3)(a) GDPR. The DPA applies automatically by reference under ToS § 18.2 when you begin operating a public board or sending a broadcast that involves Personal Data of your End-Subscribers / End-Feedback-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 ProductLog 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 productlog.dev (https://productlog.dev/legal/dpa). Your electronic acceptance of the ToS — by signing up for, paying for, or otherwise using the Service in a way that engages processing of End-Subscribers' / End-Feedback-Users' Personal Data — constitutes your signature of the DPA for the purposes of Art. 28 (9) GDPR. A signed counterpart is available on request to [email protected] at no fee.

Visitor-side Sub-processors. The Sub-processors engaged for the Processor role are listed in the DPA Annex C — OVH (hosting), Cloudflare (CDN / DDoS / TLS / DNS / geolocation), and AWS SES (broadcast email). Customer-enabled outbound integrations (Slack, Jira, Linear, generic webhooks) are not Sub-processors of JJ Online; the Workspace Operator is the Controller of those onward transfers and is responsible for its own DPA with each chosen provider — see § 5 and ToS § 12.

Visitor consent. It is your responsibility as Controller to obtain any required consent from your End-Feedback-Users / visitors before publishing your public board. Where § 25 Abs. 1 TDDDG or equivalent EU national law requires consent for storage of or access to information on the visitor's terminal — including any storage written by the embedded HelpCanvas chat widget loaded on your public board surface — your visitors must be given a § 25-compliant consent opportunity before that storage takes place. We document the relevant facts in the DPA Annex C so you can compose your own Art. 13 GDPR notice; the implementation of the consent gate on your public board is your responsibility.

#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 Subscription 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 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.

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) and with anti-money-laundering / counter-terrorism-financing regimes (Directive (EU) 2015/849 as amended; the EU AML Regulation; national transposition acts). Those statutory obligations bind the payment processor directly and flow through to us as the merchant on whose behalf the screening is operated. Art. 6 (1)(f) GDPR (residual merchant-side fraud-prevention interest in preventing card-not-present fraud, chargebacks, and account-takeover at sign-up) and Art. 6 (1)(b) GDPR (contract necessity) apply as alternative / fallback bases consistent with the EDPB's narrow reading of Art. 6 (1)(b) post-SCHUFA Holding (CJEU C-634/21, 7 Dec 2023).

Art. 22 (2) gateway for the automated decision itself. We rely principally on Art. 22 (2)(b) GDPR: the PSD2 SCA and AML / CTF frameworks 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. Art. 22 (2)(a) GDPR (contract necessity) is engaged as a fallback only; we do not rely on Art. 22 (2)(c) explicit consent, which would not be freely given in a checkout context.

Your safeguards under Art. 22 (3) GDPR.

• to obtain human intervention in the decision — write to [email protected] 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;
• 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 required by SCHUFA Holding § 54–§ 59.

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). The fraud-risk score is produced by a third-party machine-learning model maintained by the payment processor (Stripe Radar) 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. 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 — not the algorithm itself. On request we will confirm to you in writing: (i) the principal factor groups the model evaluates (transaction amount and currency, payment-method metadata, AVS billing-address verification outcome, device / browser fingerprint, IP and IP-vs-billing-country mismatch, prior outcomes for the same card or Account, 3-D Secure outcome where available); (ii) the specific decline-reason code returned by the processor for your transaction and, where the decline was driven by a Radar rule, the name of the rule; (iii) the override path we as merchant control; and (iv) the significance for you (per-transaction signal only; no profile retained on your user record).

Anti-abuse rate-limits and bot defence (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. Sign-up is additionally gated by Altcha, a self-hosted proof-of-work challenge executed locally on ProductLog infrastructure (no third-party data flow). 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 [email protected].

Feedback moderation and prioritisation are human-operated. Feedback moderation (Pending / Approved / Spam) and prioritisation (RICE, MoSCoW) are operated by the Workspace Operator using deterministic formulas applied to operator-entered inputs — they are not decisions about you.

#9. Cookie consent — current posture

A cookie banner is not currently deployed on productlog.dev. We disclose this honestly here under Art. 5 (1)(a) GDPR transparency. The current factual position is:

• The cookies and localStorage / sessionStorage entries that ProductLog sets itself are classified as Strictly Necessary under § 25 Abs. 2 Nr. 2 TDDDG (storage strictly necessary to provide a telemedia service explicitly requested by the user) and require no consent — see Cookie Policy § 4
• The only non-first-party script loaded today is the HelpCanvas chat widget, which is operated by JJ Online GmbH (the same Controller as ProductLog) on JJ Online's own EU infrastructure. Because HelpCanvas is operated by the same Controller, it is not a third-party data flow in the controller-to-controller sense — but § 25 TDDDG still applies to any storage the widget writes in the visitor's terminal, regardless of who the recipient is. Whether the HelpCanvas widget sets any non-essential storage in production, and therefore whether a § 25 Abs. 1 TDDDG consent gate is required, is a pending product decision

When a cookie banner is deployed on productlog.dev, it will be the Datriva CMP (also a JJ Online product) and will operate per Art. 7 (2) and (3) GDPR: opt-in by default on each non-essential category, withdrawal as easy as giving consent (same UI, same number of clicks), and a 12-month consent-record renewal floor.

For the per-cookie inventory and the legal-basis analysis per category, 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 only Strictly Necessary first-party storage), (ii) each specific cookie and localStorage / sessionStorage entry with its provider and duration, (iii) third-party scripts (today, only the HelpCanvas widget), (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. Where the observed retention behaviour in the codebase differs from the documented target, we report the code state honestly under Art. 5 (1)(a) GDPR transparency.

Category	Retention period	Legal basis
Account & contract-evidencing data — operator legal name, contact email, billing identity, organisation 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 und 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 und Nr. 3 AO; § 257 Abs. 1 Nr. 2 HGB)	Art. 6 (1)(c); § 147 AO, § 257 HGB, § 14 UStG
Operational and preference data — UI preferences, integration configurations, project configuration, custom-domain configuration	Duration of the contractual relationship	Art. 6 (1)(b)
Authentication and security-audit events — sign-in records, refresh-token state, 2FA state	Target 180 days; today retained indefinitely until Account deletion — no purge job is in place; disclosed here under Art. 5 (1)(a) GDPR transparency	Art. 6 (1)(f); BSI IT-Grundschutz baseline
Workspace Content — changelog entries, roadmap and feedback posts, surveys, knowledge-base articles	Lifetime of the entry; cascade on project delete; soft-deleted entries remain in the database pending a hard-delete job	Art. 6 (1)(b)
End-Subscriber data — subscriber rows	Retained indefinitely on status flag (Active / Unsubscribed / Bounced) today; target 24 months after last engagement, pending a purge implementation	Art. 6 (1)(a) — consent; § 7 Abs. 3 UWG hygiene
End-Feedback-User data — author name, optional email, comment body, vote / reaction records	Retained indefinitely (soft-delete only) today; author name and author email persist after soft-delete; anonymisation pending	Art. 6 (1)(b) (Processor for the Workspace Operator); Art. 6 (1)(f) for the fingerprint
Public-board visitor analytics — analytics-event records	Target 90 days via a scheduled purge — the purge schedule is not yet provisioned on the production host; until provisioned, the 90-day retention is aspirational and the rows accumulate	Art. 6 (1)(f) (Workspace Operator's legitimate interest in measuring engagement on their own board)
Broadcast tracking — open / click events	Open / click events are analytics-event records and expire under the row above once the purge job runs; per-broadcast counters persist for the lifetime of the broadcast	Art. 6 (1)(a) and (f)
Customer-enabled outbound integration data — integration configuration and webhook subscriptions	Lifetime of the project	Art. 6 (1)(b)
Outbound webhook delivery payloads — full event payloads (may include End-Feedback-User Personal Data)	Currently retained indefinitely — TTL + purge job (target 30 days) is a pending product item disclosed here under Art. 5 (1)(a) GDPR transparency	Art. 6 (1)(b)
Authentication tokens — refresh tokens (30-day TTL); password-reset tokens (60-minute TTL); team-invitation tokens (7-day TTL); subscriber confirmation tokens	TTL as listed; expired and used tokens currently accumulate pending purge	Art. 6 (1)(b), (f)
Application and access logs — routine traffic, error logs	30 days	Art. 6 (1)(f) (operational integrity)
Support correspondence — HelpCanvas conversations + role-address email	Duration of the support matter + 3 calendar years (anchored at end of year)	Art. 6 (1)(f); § 195 + § 199 BGB
Cookie-consent records (when a CMP is deployed)	180 days for the consent record + 12 months audit-log retention	Art. 7 (1) GDPR (consent evidence)
Backups	Target rolling 14-day window matching other JJ Online products; a documented backup-rotation policy is pending	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 prevails over earlier deletion under Art. 17 (3)(b) GDPR.

Account-erasure behaviour (Art. 17 GDPR). Account deletion today is soft-delete only — across the affected records (operator accounts, organisations, projects, changelog entries, feedback posts), deletion sets a soft-delete flag with cascade-or-null on referenced rows. A hard-delete job is a pending product item; until built, Art. 17 erasure is technically incomplete and we disclose this gap here under Art. 5 (1)(a) GDPR transparency. Once the hard-delete job is built, the same backup-replay discipline described below will apply.

Backup-restore re-erasure. When a documented backup-rotation policy is in place, the policy will commit to the following: backups age out per a rolling 14-day window; during that window the data is not actively processed and exists only as a frozen disaster-recovery snapshot. 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 erasure log lives outside the backup chain so it survives the restore.

#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; HSTS enforced
• Role-based access controls in the dashboard (Owner / Admin / Editor / Viewer); multi-factor authentication for our operational staff
• Written staff confidentiality obligations
• Full-disk encryption at rest on the application database and backup volumes at the hosting provider
• bcrypt password hashing; refresh tokens stored as SHA-256 hashes (only the hash, never the raw token); password-reset tokens stored as SHA-256 hashes
• Altcha self-hosted proof-of-work captcha on signup and public-form submissions (10-minute TTL, HMAC-signed; no data leaves to a third party)
• Server-side rate-limits: 5 failed sign-in attempts per 5 minutes per IP; 3 signups per 15 minutes per IP
• 72-hour personal-data-breach notification process per Art. 33 GDPR
• Per-tenant logical isolation in the application layer (organisation + project IDs on every row)

Known security gaps disclosed under Art. 5 (1)(a) GDPR (transparency). Several items are currently below the protection level we want to claim; they are listed here so the Policy does not overstate the live posture:

• JWT in localStorage — the access token is readable by any JavaScript running on productlog.dev, including the embedded HelpCanvas widget. Migration to an HttpOnly + Secure cookie is a pending product item
• Plaintext customer-supplied outbound-integration credentials at rest — the Slack webhook URL, Jira API token, and Linear API key supplied by the Workspace Operator are stored as plaintext in the application database. Column-level (envelope) encryption is a pending product item; today, operational staff with database access could in principle read these credentials
• Outbound webhook delivery payload retention is indefinite — full event payloads (with End-Feedback-User Personal Data) accumulate on every webhook fire; TTL + purge job is pending
• Analytics-event IP and User-Agent stored in plaintext — hashing at the storage layer is under consideration
• No audit log of operator actions (role changes, integration-credential updates, deletions, exports) — accountability under Art. 5 (2) GDPR is therefore limited until per-tenant audit logging ships

No method of internet transmission or electronic storage is completely secure. If you believe your interaction with us is no longer secure, contact [email protected].

#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.

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); see § 8 for the full analysis and the Art. 22 (3) safeguards
• 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 [email protected]. 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. Workspace Operators have per-project content exports today (CSV / JSON of changelog entries; CSV of subscribers; survey responses) available from the dashboard. A per-Account aggregated GDPR-style export is handled manually on email request to [email protected] — targeted working delivery 5 to 10 business days, 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, organisation, project, billing history, authored content, support-correspondence index, cookie-consent record — via a time-limited download link. A self-service aggregated-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; soft-delete only today (see § 11 — hard-delete job pending). Where you prefer human handling, write to [email protected]
• Right to rectification (Art. 16 GDPR). Most operator-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 [email protected]
• Right to restriction (Art. 18 GDPR) and right to object (Art. 21 GDPR). Email [email protected] 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. For any other consent-based processing, email [email protected]
• End-Subscriber unsubscribe — one-click unsubscribe link included in every broadcast email
• End-Subscriber / End-Feedback-User rights (Processor role) — direct rights requests are forwarded to the Workspace Operator (their Controller); we assist the Workspace Operator under our DPA § 6

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 ProductLog Account and, for actions taken from within the application, by relying on your authenticated session. Where this match is sufficient to remove reasonable doubt, we do not request further information. 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 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 product whose Account binding is to an email address.

#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.

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 — ProductLog is a business-to-business product, the sign-up surface is product-team-facing (changelog publishing, roadmap management, broadcast composition), and asking every Workspace Operator 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) Workspace Operators self-identify as professional users by the act of configuring projects, 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, we ask the holder to confirm in writing that they are 16 or older, and delete the Account where confirmation is not forthcoming.

Where a Workspace Operator, as Controller, publishes a public board (or sends a broadcast) on a surface directed at an audience under 16, that is the Workspace Operator's own decision under Art. 8 GDPR and the Workspace Operator's own controller responsibility — including any age-verification gate the Workspace Operator may need to add.

Parents or guardians who believe a child has submitted Personal Data may contact [email protected] 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 the 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. On a cumulative reading, none points to the United Kingdom: our pricing is listed in EUR (with USD as the secondary checkout currency per ToS § 13.4), not GBP; our domain is productlog.dev 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 and we do not "monitor the behaviour" of UK Data Subjects within the meaning of Art. 3 (2)(b). 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) and low-risk (no special-category data, no large-scale profiling). 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.
• Swiss FADP. The cumulative analysis applied above for the UK mirrors here: we operate no .ch domain, no CHF pricing, no Swiss landing pages, and no Swiss-targeted campaigns; the Website is published in English, not as a Swiss country signal. 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 behaviour; (b) it is extensive (large-scale); (c) it is regular; and (d) it poses a high risk to the personality of the Data Subjects. The threshold is not met on our facts — conditions (a)–(d) each independently fail. We will reassess and appoint a Swiss representative if we begin to target Switzerland.
• 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 those regimes. In particular, we are below the US-revenue and California-consumer thresholds for CCPA / CPRA applicability under Cal. Civ. Code § 1798.140(d).

#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 sign-in audit, refresh-token state, 2FA state, rate-limit decisions) — our interest in protecting your Account against credential stuffing, brute-force, 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 operations — pseudonymised or aggregated processing only; no individual profiling
• Anti-double-vote / anti-double-reaction fingerprint — the IP+User-Agent hash is functionally a one-vote-per-visitor lock; the visitor's interest is protected by the hash being non-reversible by design and by the absence of any tracking, profiling, or cross-site use
• Operator-facing public-board analytics — the Workspace Operator's interest in measuring engagement on their own board, weighed against the visitor's interest in not being tracked across sites; protected by the absence of cross-site tracking, the absence of third-party analytics, and the 90-day retention target (subject to the purge-job-provisioning gap disclosed in § 11)
• Product-update communications to existing Workspace Operators (§ 7 Abs. 3 UWG Bestandskundenwerbung) — our 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 (address obtained in the context of the sale; own similar products only; no objection; clear and conspicuous information at collection and in every message, with no costs beyond the Basistarif) is the principal safeguard. 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 [email protected].

#Automated decision-making (Art. 22 GDPR)

One automated decision in scope of Art. 22 (1) GDPR operates at payment-fraud screening at checkout, described in § 8. The Art. 22 (2) gateway we rely on is principally Art. 22 (2)(b) GDPR (PSD2 SCA + AML / CTF authorising-Union-law gateway); Art. 22 (2)(a) GDPR (contract necessity) is engaged as a fallback only. We provide the Art. 22 (3) GDPR safeguards in full, including disclosure on Art. 22 (3) request of the specific decline-reason code and, where applicable, the Stripe Radar rule name.

#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. The following non-EEA destinations are involved in our Controller-role processing:

Destination	Recipient(s)	Mechanism
USA	Stripe, Inc. (Stripe sub-processing); Amazon Web Services, Inc. (corporate-group access by AWS EMEA SARL); Cloudflare, Inc. (US HQ with EU edge nodes)	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. Cloudflare additionally relies on its EU Data Protection Addendum.

A per-recipient Transfer Impact Assessment is maintained on file for each US recipient. Copies available at [email protected].

Customer-enabled outbound integrations — transfers on Workspace Operator instruction. Where a Workspace Operator connects Slack (USA), Jira (Australia + USA sub-processing), Linear (USA), or a generic outbound webhook to its workspace, event payloads are forwarded to the destination the Workspace Operator chose. The Workspace Operator is the Controller of those onward transfers and is responsible for its own Chapter V GDPR assessment for the chosen destination — these transfers are not Controller-role transfers of JJ Online GmbH.

DPF-status version-dating. The DPF-certification status of each US recipient 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. 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.

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, 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 the investigatory and enforcement powers of the US Federal Trade Commission 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 — 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. 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.

#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; (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, 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 changelog / roadmap product, 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 (authorised under the Art. 22 (2)(b) authorising-Union-law gateway) — 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 transfer to third parties, for anonymised transfer, or for market or opinion research. We are therefore not required to designate a DPO. Matters relating to our processing of Personal Data can be directed to [email protected]; 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 ProductLog)

Schönhauser Allee 163, 10435 Berlin, Germany

Phone: +49 151 12032902

Email — general: [email protected]

Email — privacy and data-subject requests: [email protected]

For Processor-role matters (your End-Subscriber / End-Feedback-User data flowing through ProductLog), see the DPA.