Privacy Policy

Version: v0.2 · Effective date: 2026-09-02

This policy is pre-release (0.x). JobPuul has not launched and has no registered users, so this document is not yet claiming the stability a 1.0 would. While it is 0.x we revise it as the product takes shape and publish each revision as it is made; § 12's 14-day notice and in-app notice bind from v1.0 onward, which is the version that will be in force when the first account is created. Every revision is still dated, and every prior version is in this repository's git history at docs/legal/privacy.md.

The renumbering, so the trail below is followable. The revision published 2026-08-18 as v1.0 is this document's v0.1; the revision published 2026-08-31 as v1.1 is superseded by v0.2 and never took effect. Both are in this repository's git history under their original headings — § 12 explains how to request a specific past version.

What changed in v0.2: most of it removes claims about data we never held — we do not accept CV uploads, and the only thing in our object storage is the nightly database backup. Two changes are genuine retention changes, so under 1.0 they would have carried § 12's notice period: messages are now kept with the application they belong to rather than for a separate 36 months, and moderation records are declared as kept indefinitely rather than for 24 months. It also declares one new data class: the addresses we have stopped emailing — and, with it, the one case where an account is kept longer than 24 months: if the notice we owe you cannot be delivered, we hold the account rather than deleting it unwarned, until 30 months from your last activity and six months from the bounce have both passed.

Why 0.x rather than v1.1. The superseded revision numbered this v1.1 and recorded that § 12's 14-day notice "had no recipients". That was true and still the wrong shape: a 1.x number asserts a stability this document does not have, and an exception written into a policy is the kind of thing that outlives the reason for it. Numbering it honestly retires the exception instead — pre-1.0 carries no notice obligation because it has not started promising one. v1.0 is the commitment, and by then both mechanisms § 12 names exist in the product rather than as a promise (#557).

The short version

The full policy is below and it is what governs. In plain terms:

• What we hold: your account and profile, anything you post, applications and CVs you send, messages, billing records, and security logs. Section 3 lists every field.
• Why: to run the platform you asked to use, to bill you if you buy something, to keep the place safe, and to meet Czech accounting law. Section 4 maps each purpose to its legal basis.
• We do not sell your data and we do not share it with advertisers (Section 7). We also do not buy it from brokers, scrape profiles, or make automated decisions about you that carry legal weight (Section 3.12).
• Who else sees it: the employers and clients you choose to apply or talk to, plus the processors that run our infrastructure — hosting, storage, email, payments, error tracking. All named in Section 5.
• Where it lives: the EU. The database and its nightly backups stay in EU-jurisdiction storage (Section 8).
• You can export or delete everything yourself at Settings → Privacy, or email [email protected]. Your full rights are in Section 9.
• Under-16s may not use JobPuul (Section 11).

1. Who we are

JobPuul is a global professional network and jobs platform operated at jobpuul.com. We help people find jobs and contracting work, and we help employers and clients find them back. The service is global; the operating entity is registered in Czechia.

The data controller for personal data processed via jobpuul.com is Tomáš Zálešák, a sole trader (fyzická osoba podnikající) registered in the Czech Trade Register (živnostenský rejstřík), IČO 11765411, place of business Sochorova 3228/46, Žabovřesky, 616 00 Brno, Czech Republic.

How to reach us

• General contact (privacy queries): [email protected]
• Security contact (vulnerability reports): [email protected]

We have not appointed a Data Protection Officer. We are not legally required to appoint one at our current scale; we will reassess as the user base grows.

2. Scope

This policy covers personal data processed when you:

• Create or use a JobPuul account.
• Build a public or private profile on JobPuul.
• Apply to jobs or contracts via JobPuul.
• Post jobs, review applications, or contact candidates as an employer or client.
• Send or receive messages, notifications, or posts on JobPuul.
• Pay for, or are paid via, JobPuul features (paid plans, promotions).
• Visit jobpuul.com without an account (logs, cookies, security telemetry).

It does not cover:

• Third-party sites we link to. Their privacy notices apply when you click through.
• Personal data you choose to publish on JobPuul that you also publish elsewhere — we have no control over the other copies.

3. What data we collect

3.1 Account

• Email address (required).
• Hashed password (when you sign up with email/password) — we never store the plaintext.
• OAuth identity (Google at launch; LinkedIn next) — provider user ID, email, display name, avatar URL when you grant them.
• Email verification timestamp.
• Session records (device, IP at session start, user agent, expiry).
• Two-factor authentication metadata when you enable it.

3.2 Profile

Anything you put on your professional profile, which can be public, semi-public, or private depending on your visibility settings.

• Display name, slug (/u/<slug>), headline, bio, avatar.
• Country, city, preferred language for the interface.
• Employee / contractor status.
• Verification signals (which method verified you and when — e.g., email-domain match, OAuth, manual review).
• One or more addresses (home, billing) — structured per country.
• One or more tax identifiers per country — for example CZ IČO / DIČ, DE Steuernummer / USt-IdNr., US EIN. We collect tax IDs only when needed for billing or for contractor surfaces; profiles that never use those surfaces have no tax IDs stored.
• Country-shaped preferences and discriminators (e.g., CZ preferred employment form: DPP / DPČ / IČO-OSVČ). We do not store national identifiers (SSN, passport numbers, Sozialversicherungsnummer) in the country-extension JSON; structured-access national IDs are held separately, under strict access control.

3.3 Companies you join

If you act on behalf of a company:

• Company name, slug, description, logo, website, size bucket, home country.
• Your role on that company (owner / admin / recruiter).
• Company billing and registered addresses, tax IDs.

A company record is corporate data, not personal data — but the fact that you are linked to it, and in what role, is personal data about you.

3.4 Job postings

If you post jobs, we store the postings themselves, including title, description, compensation range, location, employment type, and country-specific shape (e.g., CZ DPP/DPČ, US H-1B sponsorship flag).

A job is recorded against the company that posted it. The person who posted it is identifiable through their membership of that company.

3.5 Applications

When you apply to a job:

• The fact that you applied (job ID, your user ID, submission timestamp).
• Your cover letter. We do not accept CV or résumé uploads yet — an application carries a cover letter and nothing else. When that changes, this section and Section 6 will say what we keep, and the change is notified under Section 12.
• Application status over time (submitted → viewed → shortlisted / rejected / withdrawn).
• Who changed the status of your application, when, and an optional note about why. We keep this history on purpose: if you are rejected and want to challenge that months later — under your GDPR rights around automated decisions, or under anti-discrimination law — we need to be able to tell you what actually happened.

3.6 Messages, posts, notifications

Where these features are available to you, we hold:

• Message bodies, sender, recipient, timestamps, read state.
• Post body, author, reactions, comments.
• Your notifications. A notification stores only a reference to the thing it is about, never a copy of it — so once that thing is deleted, the notification cannot show it either.

3.7 Billing (Paddle)

We use Paddle as Merchant of Record. Paddle collects payment instruments (card, bank details, PayPal account, billing address) on their hosted checkout. We do not see or store payment instruments. We receive from Paddle:

• The Paddle customer ID linked to your JobPuul user.
• Subscription / one-off purchase events (start, renewal, cancellation, refund).
• Invoice metadata (invoice number, country of taxation, amount, currency).
• VAT-relevant billing country (Paddle computes; we store).

Paddle is the controller for the payment-instrument data; JobPuul is the controller for the link between your JobPuul user and Paddle's customer record, and for the events we receive.

3.8 Logs and security telemetry (Cloudflare, GlitchTip, app logs)

• Cloudflare access logs: IP address, user agent, request path, response code, country (derived from IP) for every HTTP request that hits jobpuul.com. Cloudflare retains these per their published retention schedule; we read aggregates and security signals from them.
• GlitchTip error events: Sentry-compatible error reports including stack traces, the offending request URL and method, the user ID when one is available, browser / runtime info, and a coarse IP. GlitchTip is self-hosted on our hardware at home (see §5).
• Application logs: stdout from our Next.js server and pg-boss workers, captured by Dokploy on the Hetzner VPS. These include request IDs, user IDs, action names — never message or cover-letter bodies, never passwords, never tax-ID values.

3.9 Feedback and support messages

When you use the contact / "report a problem" form — with or without an account:

• The name, email address, and message text you type, plus what kind of message it is (question, bug report, translation error, idea or suggestion, other).
• A keyed (non-reversible) hash of your IP address, used only to rate-limit the form against spam. We do not store the raw IP.
• Context we attach automatically so the report is actionable: the interface language you were using, the page path you were on (never the query string — it is stripped before storage, so links containing one-time tokens are not retained), your browser's user-agent string, your window size, and the build identifier of the running app. For a translation report you may also paste the exact wording that is wrong.
• Your user ID when you were signed in, so we can follow up. That link is severed automatically if you later delete your account.

We use this to answer you and to fix the reported problem (see §4). Deleting your account blanks the name, email, message text, captured context, and rate-limiting hash of the messages you sent while signed in.

3.10 Email we could not deliver to you

This applies with or without an account — we email people who only used the contact form, too.

• If an email we sent bounces, or you report one as spam, we record that address, which of the two happened, the provider's event id when the event carried one, and when we last heard about it. Nothing from the message itself.
• It is how we stop writing to a mailbox that rejects our mail, and how we honour a "stop emailing me". Section 6 says how long we keep it.

3.11 Cookies and similar technologies

We set only first-party cookies, and only these:

jp_consent deserves the explicit mention: it is the cookie that stores your answer to the cookie banner. Storing a refusal requires a cookie, and leaving it out of a cookie list — as this policy previously did — is a small dishonesty we would rather not commit.

Strictly-necessary cookies need no consent under ePrivacy, which is why the banner governs the categories below rather than the table above.

We use no third-party analytics, advertising trackers, or social-network beacons. The consent banner exposes one optional category, analytics, and nothing currently writes to it — it exists so that adding analytics is a decision you get asked about rather than one that ships silently. If we add any, this section and the banner are updated before the tag fires.

You can review or change your choices any time at /cookies.

Still to confirm before launch: whether Cloudflare's bot-management or Turnstile (CAPTCHA) features set any cookie of their own once they are enabled in front of the site, and how those classify. Neither is live yet (#25).

3.12 What we do not collect

• We do not buy personal data from data brokers.
• We do not scrape third-party sites to seed profiles.
• We do not use special-category data (race, religion, health, political opinion, sexual orientation, trade-union membership) for ranking, matching, or advertising. You may choose to disclose some of these in your bio; that does not authorise us to process them as special-category data.
• We do not perform fully automated decisions with legal or similarly significant effects on you (GDPR Art. 22). Ranking and matching produce signals; humans make hiring decisions.

4. Legal basis per processing activity

We rely on the bases in GDPR Art. 6. For Czech-resident users, the same bases apply under Act No. 110/2019 Coll. on Personal Data Processing.

5. Third-party processors

We disclose every processor that handles personal data on our behalf. Each of these has, or will have, a signed Data Processing Agreement (DPA) under GDPR Art. 28 unless explicitly noted.

Notes:

• Hetzner is the primary location of personal data. PostgreSQL (Better Auth tables, profiles, applications, messages, etc.) runs on a Hetzner VPS in Germany. It is dumped nightly to EU-jurisdiction Cloudflare R2, and each night's run deletes dumps older than the configured window, 30 days by default.
• Cloudflare R2 buckets are pinned to EU jurisdiction (eu location hint) so nothing we store there leaves the EEA at rest. Today that is nightly database backups and nothing else. Cloudflare's edge may temporarily transit data through non-EU PoPs in flight; the DPA + SCCs cover this.
• Resend is in the United States. Transfers of transactional-email payloads to Resend rely on SCCs and the EU–US Data Privacy Framework (Resend's parent is DPF-certified at the time of writing — to be re-verified before publish).
• Paddle is in the United Kingdom and Ireland. Transfers to Paddle UK rely on the UK adequacy decision (Commission Implementing Decision (EU) 2021/1772). Paddle's Irish entity handles EU customers directly.
• GlitchTip carries no third-party processor relationship. Self-hosting on our own hardware does not create a controller-processor link. It does mean we own the security posture for that box;. for the threat model.

We will publish a notification on this page before adding a new processor that processes personal data.

6. How long we keep your data (retention)

The defaults below apply unless a longer period is required by law — for example the invoice-keeping obligations under Czech accounting law — or you ask us to keep something longer. There is no reactivation window: account deletion is immediate and irreversible.

Automation status. Notifications, applications and inactive accounts are erased by a nightly job, without you asking. Everything else is erased when you act — deleting your account erases it in one transaction — or is controlled by a third party, as the table says. Two rows are neither: billing events and consent records are insert-only, so their long periods are a commitment rather than something a job enforces, and we will delete on request where the law allows. You can always email [email protected]; Article 17 applies regardless of what any job does.

7. Sharing your data

We share personal data only with:

• The processors listed in §5, for the purposes listed.
• Other JobPuul users as the product requires — for example, a job poster sees the application you submitted to their job; a profile marked "public" is visible to anyone (logged in or not, depending on your settings).
• Law-enforcement, regulators, courts when we receive a binding, properly served request. We log every such request internally and tell you about it unless legally prohibited.
• A successor entity in the unlikely event of a merger, acquisition, or asset sale. You will be notified in advance and given a chance to delete your account before the transfer completes.

We do not sell personal data. We do not share personal data with advertisers.

8. International transfers

Most data stays in the EU/EEA (Hetzner DE, Cloudflare R2 EU jurisdiction). Some flows leave the EEA:

• Resend (United States) for transactional email delivery. Safeguard: EU Standard Contractual Clauses + EU–US Data Privacy Framework certification (to be re-verified at publish).
• Paddle (United Kingdom) for payments. Safeguard: UK adequacy decision.
• Cloudflare edge (global) for CDN delivery. Safeguard: Cloudflare DPA + SCCs; R2 storage pinned to EU jurisdiction.

You can request the relevant transfer-safeguard documentation by emailing [email protected].

9. Your rights (GDPR Chapter 3)

If you are in the EU/EEA, the UK, or any jurisdiction that mirrors GDPR (Switzerland, parts of California, Brazil's LGPD, etc.), you have the rights below. We extend the same rights to all users globally as a matter of policy — Art. 3(2) extraterritoriality applies anyway when we offer the service to EU residents.

• Access (Art. 15) — a copy of the personal data we hold about you. Self-service from Settings → Privacy (/settings/privacy): request an export and we email you a secure, time-limited download link to a structured JSON archive of your data across every table.
• Rectification (Art. 16) — correct anything wrong. Most fields are user-editable from the account settings; for the rest, email [email protected].
• Erasure / "right to be forgotten" (Art. 17) — delete your account, self-service from Settings → Privacy. We email a confirmation link (two-step, to prevent accidental loss); confirming performs a hard delete with cascades. Rows we must keep for legal reasons (invoices, audit logs) are retained but pseudonymised — the actor link is SET NULL and free-text scrubbed in the same transaction.
• Restriction of processing (Art. 18) — pause processing while a dispute is open.
• Portability (Art. 20) — receive your data in a machine-readable format. Same export as Access; the file is JSON (with attached files as the original binary).
• Object (Art. 21) — to processing based on legitimate interest (§4). We will stop unless we can show a compelling overriding ground.
• Not be subject to automated decisions with legal effects (Art. 22) — we do not perform such decisions on JobPuul.
• Withdraw consent (Art. 7(3)) — for any processing based on consent, at any time, without affecting the lawfulness of prior processing.
• Complain to a supervisory authority — for users in Czechia, this is Úřad pro ochranu osobních údajů (uoou.gov.cz). Users in other EU/EEA countries can complain to their local DPA; UK users to the ICO.

9.1 How to make a request (DSAR procedure)

1. Email [email protected] from the email address associated with your JobPuul account, stating which right(s) you are exercising. If you cannot use that email address (e.g., it is no longer accessible), include enough information for us to identify your account — but expect us to ask for proof of identity to prevent account takeover.
2. We acknowledge receipt within 3 business days.
3. We respond substantively within 30 calendar days of receipt. If the request is complex or we receive a high volume of requests, we may extend by up to 60 days under Art. 12(3), and we tell you why within the original 30.
4. Access and portability requests are self-service from Settings → Privacy — you get an emailed download link to your JSON archive. (Or email us and we run the same export for you.)
5. Erasure is self-service from Settings → Privacy (two-step email confirmation); requests are otherwise confirmed in writing once the deletion has executed (typically the same day; up to 30 days when the deletion fans out across processors).
6. Requests are free of charge unless they are manifestly unfounded or excessive (Art. 12(5)), in which case we may charge a reasonable fee or decline — and we explain why.

10. Security

We treat security as a precondition for the rest of the privacy promises, not as a separate concern. In broad terms:

• TLS everywhere (Cloudflare-terminated; HSTS + HTTPS-only cookies).
• Passwords hashed with Better Auth's default (argon2-class); never logged.
• R2 buckets are private. The only thing we write there today is the nightly database dump, uploaded and read by the server with credentials that are never sent to a browser.
• Database access restricted to the application and a short list of admins.
• Application errors captured in GlitchTip (self-hosted) with PII scrubbing at the SDK boundary.
• Vulnerability reports to [email protected]. We acknowledge within 3 business days.
• Breach notification: if a breach is likely to result in a risk to your rights and freedoms, we notify the relevant supervisory authority within 72 hours of becoming aware (Art. 33) and inform affected users without undue delay (Art. 34) when the risk is high.

11. Children

JobPuul is not directed at children. You must be at least 16 years old (the GDPR default for digital-services consent) to use the service. We do not knowingly collect personal data from anyone under 16. If we learn we have, we delete the account.

12. Changes to this policy

We update this policy when we add a processor, change a retention period, add a new processing activity, or otherwise materially affect what we do with personal data.

• Every published version has an effective date at the top.
• We keep prior versions in this repository's git history; the file path is docs/legal/privacy.md. You can request a specific past version by emailing [email protected].
• While this policy is pre-release (0.x) — JobPuul has not launched and has no registered users — we revise it as the product takes shape and publish each revision as it is made, with its own date. There is nobody to notify and nobody relying on a prior version, so the notice period below does not yet apply.
• From v1.0 onward, for changes that affect you materially (new processor, new processing activity, expanded data collection, changed retention), we notify registered users by email to the address on the account at least 14 days before the new version becomes effective, and we show an in-app notice on first login after the change. We keep a record, against your account, of which version you were notified of and which you have seen.
• For typo fixes, clarifications, or link updates, we update silently and bump the "Last updated" date.

13. Glossary and references

• Better Auth — the authentication layer that holds your login details, sessions and any linked Google or LinkedIn identity.
• pg-boss — our queue. Owns the pgboss schema. Job payloads are versioned per CLAUDE.md §5. Personal data appears in job payloads only as IDs; bodies are joined in at processing time.
• R2 — Cloudflare's object store. Used for nightly database backups. EU-jurisdiction bucket.
• DPA — Data Processing Agreement under GDPR Art. 28.
• DSAR — Data Subject Access Request.
• DPF — EU–US Data Privacy Framework.
• SCC — Standard Contractual Clauses for international transfers.
• GDPR — Regulation (EU) 2016/679.
• Act No. 110/2019 Coll. — the Czech law implementing GDPR alongside the EU regulation.