VeloLog — Privacy Policy

Version 1.0 · Drafted [Date] · Takes effect [Date + 30 days]

⚠ Important notice — please read

This document explains how we collect, use, share, and protect your personal data when you use VeloLog. It is the paired companion to our Terms of Service and forms part of the agreement between you and us.

We have tried to write this in plain language. Sections that affect what we do with your data or what rights you have are marked in bold.

Your rights under the General Data Protection Regulation (EU 2016/679, "GDPR") and equivalent UK and national data protection law always apply, even where they go beyond what is described here.

Plain-language summary (not legally binding — see the full text below)

• We collect only what we need. Your name, email, the bikes you register, the events you log, and a few technical details (IP, device, browser) for security.
• We don't sell your data, and we don't train AI on it. Period.
• The bike-history log is permanent by design — this is what makes the registry trustworthy. When you delete your account, your name is anonymised but the events persist for the next owner.
• EU data residency. Everything stays inside the EU/EEA. Payment data is processed by Stripe (subject to Standard Contractual Clauses).
• You can leave at any time. Account deletion, data export, and the full set of GDPR rights are one click or one email away.
• For stolen-bike investigations, we may share data with law enforcement on a legitimate-interest basis (Section 8).

Table of contents

1. Who we are
2. Scope — what this policy covers
3. What personal data we process
4. Where the data comes from
5. Lawful bases under GDPR Article 6
6. Purposes — what we do with the data
7. Retention — how long we keep it
8. Recipients — who else sees the data
9. International transfers
10. Your rights
11. Automated decision-making and profiling
12. Cookies and similar technologies
13. Minors
14. Security
15. Changes to this Policy
16. How to contact us

1. Who we are

1.1. Controller. The controller of your personal data is [Legal Entity Name] (the "Company", "VeloLog", "we", "us",

"our"), company registration number [Number], registered office at [Address].

1.2. Data Protection Officer. Our DPO can be contacted at

dpo@velolog.io, or by post to the address above marked "FAO Data Protection Officer".

1.3. Supervisory authority. The lead supervisory authority for our processing is [Authority name, e.g. the Lithuanian State Data Protection Inspectorate / the Irish Data Protection Commission]. You have the right to lodge a complaint with this authority or with the supervisory authority of your country of residence (Section 10).

1.4. Scope of this policy. This policy applies to personal data we process about you in our capacity as data controller. For limited flows where we act as processor (described in Section 8.4), the relevant controller's privacy policy governs.

2. Scope — what this policy covers

2.1. This Privacy Policy applies when you:

• create or use an Account on the Platform (velolog.io and our official apps);
• pay for a subscription;
• contact us by email, support form, or other channel;
• visit our marketing site, blog, or social media accounts;
• have a Bike Record associated with you (whether or not you created the Account that holds it).

2.2. What this policy does not cover.

• Third-party services we integrate with (Strava, Stripe, Google sign-in, Apple sign-in, EUID providers). Each has its own privacy policy and acts as a separate controller for the data it processes.
• Other websites we link to from the Platform.
• Personal data Business Users process about their own customers using the Platform (the Business User is the controller for that processing — see §13.6 of our Terms).

2.3. Special privacy notice for non-Users. If you do not have a VeloLog Account but personal data about you appears in someone else's Bike Record (for example, you sold a bike to a User, and they recorded the transfer), see Section 4.3 for what we do with that data and how to exercise your rights.

3. What personal data we process

We process the categories of personal data set out in this section. Not all categories apply to every User; the categories that apply depend on how you use the Platform.

3.1. Account and identity data

3.2. Account activity data

3.3. Bike Records and Events

3.4. Photos and document uploads

3.4.1. EXIF metadata is stripped from photos. Phone photos embed GPS coordinates and other location data in EXIF tags by default. We automatically strip all EXIF metadata (including GPS, camera model, timestamp, orientation note, and software signature) from photos before publication. This protects your home or storage location from inadvertent disclosure.

3.4.2. EUID-evidence files are not EXIF-stripped because they're registration documents (PDFs or scans), not camera photos. They are stored in a private bucket — never made public — and access is via short-lived signed URLs requested only when a platform reviewer opens the specific review.

3.5. Billing and payment data

We do not store full payment-card numbers, expiry dates, or CVV codes on our servers. Card data is collected directly by Stripe in its hosted checkout, encrypted in transit, and processed by Stripe under its own controller role. From Stripe we receive and store only:

• a Stripe Customer ID (an opaque token);
• a Stripe Subscription ID (per active subscription);
• card brand and last 4 digits, for your reference on the billing page;
• billing address (country, postcode, line 1 — needed for VAT);
• VAT number (Business Users only);
• invoice records (line items, dates, totals);
• tax identification number where collected for DAC7 reporting (Section 6.6).

3.6. Communication and support data

3.7. Strava integration data

3.7.1. What we receive from Strava. If you authorise the Strava integration, we receive:

• your Strava athlete ID and profile name;
• ride summaries (date, distance, duration, average speed, equipment field if set);
• access token and refresh token (encrypted at rest, used to fetch new rides on your behalf).

3.7.2. What we do not receive. We do not receive your full GPS tracks, heart-rate data, or any other detailed activity data beyond the summary fields above. We do not receive data about other Strava athletes you follow.

3.7.3. Strava's restrictions on us. Under the Strava API Agreement (updated November 2024), we have agreed:

• not to display your Strava data to any other VeloLog User (it's only shown to you);
• not to use Strava-derived data to train artificial-intelligence models;
• to respect your Strava privacy choices (we only see data that your Strava privacy settings allow).

3.7.4. Disconnecting Strava. You can disconnect the integration at any time from Account settings. On disconnect, we revoke the tokens immediately. Historical Strava-derived data already attached to your Bike Records (e.g. mileage-driven wear) stays, but no new data is fetched.

3.8. EUID and business verification data (Business Users only)

For Business Users, we additionally process:

• legal entity name and registration number;
• EUID (or equivalent national business identifier);
• registered business address;
• nominated representative's name and contact details;
• VAT number;
• verification check results (verified / not verified / pending).

We re-verify EUID status quarterly. Verification results are stored to demonstrate compliance and avoid re-running needlessly costly checks.

3.9. Sensitive data

3.9.1. We do not ask for, expect, or want sensitive personal data (GDPR Article 9) — health data, biometrics, religious or political opinions, sexual orientation, ethnic origin, etc. If you choose to upload sensitive data (for example, in a free-text dispute statement), you do so on your own initiative and at your own risk.

3.9.2. Minor flag. The Minor/Adult flag is a special category in the sense that it triggers extra protections (Section 13) but it is not a GDPR Article 9 category. We process it on the legal basis of compliance with GDPR Article 8 (child consent).

3.9.3. Police references and stolen-bike data. Police case numbers and stolen-bike circumstantial descriptions may relate to criminal matters. We process these only when you voluntarily provide them for the purpose of recovery (Section 6.3) and on the legitimate-interest basis of helping prevent and detect bicycle theft (Section 5.1.d).

3.10. Service booking workflow data

These are visible to the two parties on the booking (rider and shop staff) and to support staff on a read-only basis (Section 14.5). They are not part of the immutable Bike Record event log — they're operational chatter about scheduling, not service history.

3.11. Operational and security logs

We process several categories of operational logs for security, fraud prevention, and platform integrity:

The admin_audit_log records the time, the admin's user ID, the action (e.g. "support_lookup", "euid_override_approved"), the target user/business, and the IP-hash of the admin's session. It does not record the underlying PII — only the fact of access, not the data accessed.

4. Where the data comes from

4.1. Directly from you — when you create an Account, fill in profile fields, upload photos, log events, raise a stolen flag, send a support message, or otherwise interact with the Platform.

4.2. Automatically when you use the Platform — IP, user agent, device identifiers, session events, the page or feature you used, the time of the action. Subject to the cookie consent you give (Section 12).

4.3. From other Users about you.

• A buyer or seller you transact with on the Platform may record the transfer, your display UID at the time of transfer, and the sale price.
• A Business User you booked a service with may record the work performed on your bike.
• A counterparty may submit a Valuation about you in their dispute.
• A previous owner of a bike you now own may have left service-history records that mention you.

In each case, we are the controller of the resulting record, but the record was created by another User. If you believe data another User recorded about you is inaccurate, contact privacy@velolog.io and we will investigate.

4.4. From third-party providers.

• Stripe sends us subscription events, invoice metadata, and a Customer ID.
• Strava sends us ride summaries and athlete profile data (only with your authorisation).
• EUID providers / national business registries confirm Business User verification status.
• Google / Apple send us your name and email if you sign in via OAuth.
• Sentry receives error reports from our application (these may contain User UUIDs but never PII content like email or name — see §14.4).

4.5. Information about non-Users. Sometimes a User records data about someone who doesn't have a VeloLog Account — for example, when they log a private off-platform sale of a bike. In these cases:

• We only receive the data the User chose to enter (usually a name and an email or phone, plus the transaction details).
• We notify the non-User at the contact details provided, where this doesn't conflict with the User's instructions.
• The non-User has the same GDPR rights as a User (Section 10) and can contact privacy@velolog.io to exercise them, even without creating an Account.

5. Lawful bases under GDPR Article 6

We process personal data only where we have a valid legal basis under GDPR Article 6. The table below maps our most common processing activities to their bases.

5.1. Mapping of activities to legal bases

5.2. Legitimate-interest balancing

Where we rely on legitimate interest (Article 6(1)(f)), we have balanced our interest against your privacy interest:

5.2.1. Permanent event log. Our legitimate interest: maintaining a trustworthy bicycle history register. Your interest: not having your name attached to events you logged after you've left the platform. Balance: your name is anonymised at account deletion, but the Event itself persists — the buyer of your old bike still sees that a service event happened on date X with work-type Y, just without your name attached. Without this balance, the registry's whole purpose breaks.

5.2.2. Stolen-bike data sharing with law enforcement. Our legitimate interest: helping recover stolen bikes and disrupt the stolen-bike trade. Your interest: not having unproven theft allegations broadcast about you. Balance: Stolen flags raised against a User are visible internally, but the User has 24h to retract without penalty and a dispute mechanism to challenge. Police-reference data is shared only with the requesting authority, not the public.

5.2.3. IP-hash retention. Our legitimate interest: investigating abuse, attempted fraud, account takeovers. Your interest: not being re-identifiable from IP records. Balance: we don't store raw IPs; we store SHA-256 hashes which can be used to detect repeat patterns without retaining the underlying IP. Hashes are retained 12 months.

You have the right to object to processing based on legitimate interest (Section 10.6). Where you object, we will stop the processing unless we can demonstrate compelling legitimate grounds that override your interests, rights, and freedoms.

6. Purposes — what we do with the data

This section describes the specific purposes for which we process personal data, grouped by module.

6.1. Account and authentication

• Create your Account, authenticate you on each login, manage password resets, manage OAuth sign-ins.
• Maintain session tokens, detect suspicious sign-in patterns, lock or unlock accounts.
• Send required service emails (verification, password reset, account changes).

6.2. Registry and Bike Records

• Store your Bike Records and the append-only Event log.
• Calculate Veracity Scores from event-signing data and validation history.
• Present Bike Records to you, to the current owner of a bike (when ownership changes), and to authorised Business Users (during a service booking).
• Make a Bike Record's anonymised history portable to future owners.

6.3. Stolen-bike flags and recovery

• Record stolen-bike flags raised by current custodians (owner or shop with active check-in).
• Display flags on the bike's record so other Users searching the frame number can see them.
• Where you provide a police reference and other supporting evidence, store this with the flag.
• Cooperate with law-enforcement requests for information about flagged bikes (subject to the safeguards in §8.7).

6.4. Service bookings

• Facilitate the booking workflow between Riders and Business Users (requested → proposed → confirmed → checked_in → completed).
• Transfer custody of a bike to a Business User on check-in (which gates who can raise stolen flags).
• Log the work performed as a permanent service Event.

6.5. Marketplace and transfers

• Show listings to Users browsing the marketplace.
• Facilitate buyer-seller contact (Premium feature; Basic Riders can browse but not contact).
• Issue and redeem single-use Transfer Tokens that complete ownership changes atomically.
• Block transfers on bikes with active stolen flags or open Disputes.

6.6. Tax and billing compliance

• Issue VAT invoices (Premium Riders and Business Users).
• Apply the correct VAT rate by determining country of residence.
• Report seller data to your country's tax authorities under Council Directive (EU) 2021/514 ("DAC7") where you exceed the thresholds: - more than 30 transactions in a calendar year, OR - total annual revenue exceeding EUR 2,000. If you reach a threshold, we send you an in-app notification and an email requesting your tax identification number ("TIN"). If you don't submit a TIN, we re-send the reminder at most once every 14 days until you do. We submit the year-end report to the tax authority of your country of residence by the legally-mandated deadline (31 January of the following year). DAC7 reporting does not change your tax obligations; it only makes platform income visible to tax authorities who could already request it.
• Specific DAC7 data points we collect and report (dac7_records table): your tax identification number (encrypted at rest), country of tax residence, year-to-date transaction count and revenue, your acknowledgement record of the DAC7 obligation, and the timestamp of filing. We record this data once you cross a threshold; we do not store TINs for users below the thresholds.
• Retain billing and tax records for 7 years (or longer where local tax law requires it) to comply with bookkeeping obligations.

6.6a. Manual EUID verification (Business Users only)

If the automated EUID check (Section 6.6 of our Terms) wrongly reports your business as unverified — for example, because a national registry API was momentarily unavailable, or your registered name uses a punctuation variant — you can submit a registration certificate for manual review. We process the following data for this purpose:

• The uploaded registration certificate (PDF, JPG, or PNG, up to 8 MB), stored in a private storage bucket scoped to your business.
• The submission timestamp, your optional explanatory note, the outcome of the review (approved / rejected / withdrawn), the resolution timestamp, and the reviewer's ID.

The reviewer performs a strictly mechanical four-point match: business name, registration number, registered address, EUID. They do not assess whether your business "should" be on the platform — only whether the document you provided matches the data you submitted. The four match points are recorded individually in the audit log so the basis for the approval (or rejection) is traceable. Rejections include a specific reason that you see verbatim, and you can re-submit.

Retention: the uploaded file is deleted 90 days after the review is resolved; the outcome and audit-log entries are retained for 7 years (matching other admin-action audit records).

Legal basis: Article 6(1)(b) Contract (you can't access Business User features without a verified EUID, so verification is a step in performing the contract) and Article 22 GDPR human-intervention right for the automated EUID check.

6.7. Communications and dispute resolution

• Carry messages between Users (marketplace, bookings, dispute evidence submissions).
• Resolve Disputes via the automated weighted-evidence ruling engine described in §18 of our Terms. Users may request human review of any automated ruling under GDPR Article 22; further escalation is via the EU ODR or national consumer authorities.

6.8. Valuations and reputation

• Calculate Reputation Scores (0–100) and Trustworthiness ratings (0–5 stars) from your activity, valuation submissions, and dispute outcomes.
• Display these scores on your public profile (with the special exemption for Minors — Section 13).
• Apply automatic reputation deltas for documented events (false flag retracted late, dispute lost, etc. — see §7.3 of our Terms for the full list).

6.9. Service improvement and analytics

• Aggregate, pseudonymised analytics to understand how the Platform is used (e.g. how long onboarding takes, which features are used most, where users drop off).
• A/B testing of UI improvements, where this is based on consent (Section 12 cookies) or legitimate interest.

6.10. Marketing — opt-in only

• Newsletter and product-announcement emails (only if you opt in).
• Targeted in-product messaging based on your interests (only if you opt in to non-essential cookies).
• You can withdraw consent at any time from the Account preferences page or by clicking the "unsubscribe" link in any marketing email.

6.11. Security, fraud, abuse

• Detect, prevent, and investigate suspicious activity, account compromises, abuse, fraud, and Terms violations.
• Apply rate limits and lockouts on a per-User, per-IP-hash, or per-Account basis.
• Record audit-log events for sensitive admin actions (Ghost Admin access to PII is itself audit-logged — §14.5).

6.12. Legal claims and compliance

• Establish, exercise, or defend legal claims; respond to lawful requests from regulators, tax authorities, courts.

6.13. We do not

• Sell your personal data to anyone, for any purpose.
• Use your data to train generative AI models. Limited internal use of anonymised data to train anti-abuse classifiers on our own Platform is permitted (see §6.14).
• Process your data for purposes incompatible with those listed above without your consent.

6.14. Internal anti-abuse classifiers (clarification)

We train internal machine-learning models to detect:

• spam and bot patterns;
• duplicate-account creation;
• coordinated reputation gaming;
• prohibited-item listings.

These models are trained on data that has been pseudonymised (User UUIDs hashed, names and emails removed) and only on data already collected for the abuse-detection purpose. We do not share these models or the underlying data with third parties. We do not use them to train generative AI of any kind.

7. Retention — how long we keep it

We retain personal data only as long as needed for the purpose for which we collected it. The retention periods below are defaults; they can be shortened (we'll delete sooner if you ask) or extended where a specific legal obligation requires.

7.1. Retention by data category

7.2. The permanent event log (explained)

The Event log within a Bike Record is preserved indefinitely. This is the single most-significant design choice in the Platform and we want to explain it clearly.

Why permanent. The value of a bike registry depends on continuity. If we deleted the service history every time a user left the platform, every bike's record would degrade with each ownership change. The buyer of a 5-year-old bike would inherit a history with gaps where every previous owner closed their account.

What's permanent vs. what's anonymised. When you delete your account:

• The Events you created remain in their Bike Records — the next owner can still see "service performed on date X, type Y, by shop Z".
• Your name is replaced with a snapshot of your display name at the time of each Event. Your email, address, and contact details are purged from active databases.
• Your billing records are retained 7 years for tax compliance.
• Your support history is retained 3 years for dispute defence.

Your right of erasure (Article 17). Article 17(1) gives you the right to ask us to erase personal data. Article 17(3)(b) and (e) provide exceptions where processing is necessary "for the establishment, exercise or defence of legal claims" and "for compliance with a legal obligation". The Event log relies on Article 17(3)(e) compatible-use of personal data for ongoing registry purposes, with personal identification anonymised. If you nonetheless want full erasure of your contribution to the Event log, we will consider the request on a case-by-case basis under the balancing test in Article 17. Contact dpo@velolog.io.

7.3. After retention expires

When a retention period expires, data is deleted from active databases within 30 days and from backups within 90 days (because our backup strategy uses 90-day rolling encrypted snapshots — see §14.3).

8. Recipients — who else sees the data

We disclose personal data to the categories of recipients listed below, only as needed for the purposes in Section 6 and only in compliance with GDPR.

8.1. Other Users on the Platform

• Your display UID and any data you choose to make public (display name, optional bio, public bike photos if you opt in).
• Your Reputation Score, Trustworthiness rating, and recent Valuations on your public profile.
• Counterparties in your transactions (the seller sees the buyer's display UID and chosen contact channel, etc.).
• Authorised Business Users during a service booking (limited to the Bike Record, the booking context, and the contact details needed to complete the service).

8.2. Service providers (processors acting on our behalf)

These providers process personal data on our instructions under a data-processing agreement (DPA). They cannot use the data for their own purposes.

We review providers for GDPR compliance, sign DPAs, and routinely re-assess. A current list (with version and DPA date) is available on request to dpo@velolog.io.

8.3. Independent third-party controllers

When you use these features, the third party becomes a separate controller of the data flowing through them. Their privacy policy governs that data.

8.4. We are a processor for some flows

Where a Business User uses the Platform to manage their own customers' data (e.g. a shop logs that their private customer dropped off a bike for service), we act as a processor on behalf of the Business User for that customer's data. The Business User is the controller for that data and its privacy policy governs.

8.5. Law enforcement and regulators

We may disclose personal data to law enforcement, regulators, or other public authorities where:

• a lawful request (subpoena, court order, properly-served regulatory notice) requires it;
• it is necessary to investigate suspected theft, fraud, or other serious crime affecting Users (especially in stolen-bike cases);
• it is necessary to protect the rights, property, or safety of VeloLog, our Users, or the public.

We resist over-broad or non-specific requests, narrow the scope of disclosures to what is strictly necessary, and where lawful and feasible we notify the affected User so they have an opportunity to challenge.

8.6. Successor entities

If we sell, merge, restructure, or otherwise transfer all or part of our business to another entity, personal data may be transferred as part of the transaction. We will notify you in advance (Section 15) and you will have the right to terminate your subscription before the change takes effect.

8.7. Stolen-bike data flow (special section)

Because the stolen-bike module shares data more broadly than most features, we describe the flow explicitly:

We do not share with police authorities the data of Users who are not connected to a specific flagged bike. We do not broadcast the identity of someone alleged to have taken a bike unless and until that allegation has been formally confirmed.

9. International transfers

9.1. Our default is to keep personal data inside the EU/EEA. All our primary infrastructure providers (Supabase, Resend, Sentry, Railway, PostHog) host the data in EU regions (Frankfurt, primarily).

9.2. Exceptions. Some flows necessarily involve transfer outside the EU/EEA:

• Stripe is incorporated in Ireland (EU) but its parent has US operations. Stripe's transfer arrangements rely on Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914) and the EU-US Data Privacy Framework where applicable.
• Apple sign-in routes through Apple's global infrastructure; transfers covered by Apple's standard EU agreements.
• Google sign-in similarly.
• Cloudflare edge nodes process request data globally for routing; transfers covered by Cloudflare's EU SCCs and EU-US Data Privacy Framework participation.
• Strava is a US company; transfers covered by Strava's SCCs and the EU-US Data Privacy Framework. Your authorisation when connecting Strava is your consent to these transfers (Article 49(1)(a)).

9.3. Safeguards we apply. For each non-EU recipient we:

• check their inclusion in the EU-US Data Privacy Framework where applicable;
• sign Standard Contractual Clauses where the Framework doesn't apply;
• check for any additional measures the provider takes (encryption in transit and at rest, FIPS-compliant key management, data-residency options).

9.4. You can ask for the specifics of any transfer that concerns your data by emailing dpo@velolog.io.

10. Your rights

You have the following rights regarding personal data we hold about you. They apply to natural-person Users in the EU, UK, and (in most cases) worldwide. We do not charge for the exercise of these rights; we will respond to your request within one month, with one possible 30-day extension in complex cases (we'll tell you if we need it).

10.1. Right of access (Article 15)

Ask us what personal data we hold about you, why we process it, who we share it with, how long we keep it. You can also request a copy of the data.

10.2. Right to rectification (Article 16)

Ask us to correct inaccurate data. (Note: Bike Record Events themselves are immutable by design — we correct errors by adding a new Event that notes the correction. We can correct your account profile, contact details, and other non-Event data freely.)

10.3. Right to erasure (Article 17, "right to be forgotten")

Ask us to delete your data. We will, with the carve-outs explained in Section 7.2 (immutable Event log) and Section 7.1 (billing records retained for tax law compliance). Account deletion is also available self-serve from your Account settings — see §15.2 of our Terms.

10.4. Right to restrict processing (Article 18)

Ask us to stop processing your data (but keep storing it) in specific cases — e.g. while you challenge accuracy, or while we investigate a legitimate-interest objection.

10.5. Right to data portability (Article 20)

Receive your data in a structured, machine-readable format, and have it transmitted to another controller where technically feasible. You can self-serve this from your Account settings: Settings → Privacy → Export my data.

10.6. Right to object (Article 21)

Object to processing based on legitimate interest (Article 6(1)(f)) or direct marketing. We will stop unless we have compelling legitimate grounds. For marketing, the right is absolute — we will stop on request, no balancing.

10.7. Right not to be subject to solely-automated decisions (Article 22)

You have the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects.

The Platform's automated decisions include reputation deltas, dispute auto-rulings, and EUID verification. You can request human review of any of these decisions by contacting support@velolog.io. A qualified person on our team will re-examine the decision and either confirm it or revise it. See Section 11.

10.8. Right to withdraw consent (Article 7(3))

Where we process data based on your consent (marketing, non-essential cookies, Strava integration), you can withdraw consent at any time. This doesn't affect the lawfulness of processing before withdrawal.

10.9. Right to lodge a complaint (Article 77)

You can complain to your national data protection authority. A current list of authorities is at https://edpb.europa.eu/about-edpb/about-edpb/members_en.

10.10. How to exercise your rights

• Self-serve in Account settings for export, account deletion, and consent preferences.
• Email privacy@velolog.io for everything else.
• Email dpo@velolog.io for complex matters or if you'd prefer to speak with the Data Protection Officer directly.

We may need to verify your identity before fulfilling a request, especially for sensitive requests like erasure or rectification. We will ask for the minimum information necessary to do so.

11. Automated decision-making and profiling

The Platform makes a number of decisions algorithmically. We describe the most significant ones below, the data they use, the consequences, and your right to human review.

11.1. Reputation Score deltas

What: A 0–100 score adjusted by specific events: dispute outcomes, stolen-flag resolutions, false-flag retractions, etc.

Data used: Documented Events on your record (dispute rulings, flag-raise / flag-retract / flag-confirmation timestamps).

Consequences: Lower scores affect counterparty trust and can lock you out of some Premium features at very low values.

Human review: Available on request. We will examine the underlying Events and confirm or revise the delta.

11.2. Dispute auto-rulings

What: When a User-vs-User dispute is unresolved by Day 10, the ruling engine assesses evidence by weighted category (police reference = 30, purchase receipt = 25, platform log = 20, etc.) and produces a ruling.

Data used: Evidence both parties submitted; platform logs; documented previous-Event history.

Consequences: Reputation delta (won +5 / lost −8); for marketplace disputes, possible transfer block; for service disputes, possible listing on the Business User's profile.

Human review (GDPR Article 22): Available — submit through the Dispute interface within 14 days of the ruling. We verify that the evidence was correctly classified and weighted per the documented rules, and re-run the ruling if we find a classification error. We do not substantively re-adjudicate the merits of the dispute — for that, appeal to the EU ODR or a national consumer authority. See Terms §18.4 for the full scope and §18.5 for the appeal path.

11.3. EUID verification

What: Business User registration is verified by checking the EUID (or equivalent national business registry) against the data the User provided.

Data used: Business name, registration number, address, legal representative.

Consequences: Pass → Business User features unlock + trial period starts. Fail → Account stays locked at Business level, can be re-tried.

Human review: Available — contact support@velolog.io. A qualified member of staff can manually verify against documentary evidence (registration certificate, etc.) if the automated check produces a false negative.

11.4. Stolen-flag fallback

What: If a Business User has custody (active check-in) and is unresponsive for 24 hours after the bike was due to be returned, custody falls back to the owner automatically.

Data used: Booking state, last activity timestamp.

Consequences: Owner regains the ability to raise a stolen flag. Business User's Reputation gets a −5 for unresponsiveness.

Human review: Available — contact support@velolog.io.

11.5. We do not

• Apply price discrimination (everyone in the same tier pays the same price; the only price variation comes from the published seniority schedule, which is applied identically across all Users at the same seniority).
• Apply credit-scoring algorithms.
• Apply automated employment-related decisions.
• Use any other algorithm with consequences not described above.

12. Cookies and similar technologies

12.1. Cookie categories

12.2. Cookie consent

On your first visit (and on changes to the cookie set), you'll see a banner asking which categories you accept. Strictly-necessary cookies load without consent because the Platform can't function without them and they qualify under the Recital 25 / Article 5(3) ePrivacy exemption. All other categories load only if you opt in.

12.3. Withdrawing consent

You can change your cookie preferences at any time from the Cookie Preferences link in the footer.

12.4. Do Not Track

We respect the browser Do Not Track signal where it is set: we treat it as a withdrawal of consent for analytics and marketing cookies.

12.5. Server-side analytics (no cookie required)

We collect a small amount of aggregated, server-side analytics that doesn't require cookies (counts of requests by route, response times, error rates). This is processed under legitimate interest for operational purposes and never used to profile individual Users.

13. Minors

This section applies in addition to §4 of our Terms.

13.1. Age threshold. We treat a User as a Minor if they are under

18 (or, in jurisdictions where local law sets a higher minimum age for digital contracts, under that age — see §4 of the Terms).

13.2. Parental consent. We do not knowingly process personal data of a Minor without prior verifiable parental consent. The consent is captured at registration via a method appropriate to the Minor's declared age, in line with GDPR Article 8 and equivalent national guidance.

13.3. What we don't store about Minors.

• We never store date of birth itself — we check it at the consent gate and discard.
• We don't send marketing emails to Minor accounts.
• We don't show their Reputation Score or Trustworthiness rating on a public profile.
• We don't include Minor data in any aggregated analytics that could re-identify the User.

13.4. What we do store.

• A Minor/Adult flag (boolean).
• A consent record linking back to the parent's verification.
• The same Account, Bike Record, and Event data as for adult Users, with the extra protections above.

13.5. Parental access and revocation. A parent or guardian who provided consent can withdraw it at any time, by emailing

privacy@velolog.io. Withdrawal triggers deletion of the Minor's Account within 30 days (with the Bike Record anonymisation described in §7.2).

13.6. If we discover unconsented Minor data. If we become aware that a Minor has signed up without verifiable parental consent, we delete the Account and all associated data within 30 days. Parents who discover such an Account can report it to privacy@velolog.io.

14. Security

14.1. Technical measures

• Encryption in transit: All connections to the Platform use TLS 1.3 with strong cipher suites.
• Encryption at rest: Sensitive personal data (names, emails, contact details) is encrypted at the database column level. Email is also indexed via a peppered HMAC for lookup without decryption.
• Separate cryptographic keys for different sensitive-data domains (encryption key, JWT secret, email-hash pepper, supabase JWT secret), so a single key compromise doesn't open everything.
• Authenticated and rate-limited access to all sensitive endpoints. We apply different rate limits to different endpoint categories: tighter on pre-auth (login, registration, password reset, password change), moderate on post-auth write actions (stolen-flag raising, marketplace contact, dispute messaging, booking extension requests), and looser on read operations. Limits are tracked by IP-hash on pre-auth and by user ID on post-auth. Repeated violations trigger temporary lockouts.
• EXIF stripping on all uploaded photos to prevent location leaks.

14.2. Organisational measures

• Least-privilege access for staff; access to PII requires explicit reason and is audit-logged.
• Background checks appropriate to the role for staff with PII access.
• Mandatory security training at onboarding and refreshers annually.
• Incident response procedures with defined roles, escalation paths, and notification timelines.

14.3. Backups

• Encrypted daily snapshots of the production database, retained for 90 days on rolling basis.
• Backups stored in the same EU region as the primary database.
• Backup restore procedure tested at least quarterly.

14.4. Sentry error reports

Application errors are reported to Sentry. We have configured Sentry not to forward PII content (no email, no name, no plaintext addresses) — only User UUIDs (which are random and not directly identifying) and the error stack trace. Sensitive fields are scrubbed client-side and server-side before transmission.

14.5. Platform-admin (Ghost) access

When platform support staff (the "Ghost Admin" role, used for subscription management, promotional codes, and the support inbox) accesses User PII (for example, during a support investigation), the access is audit-logged with timestamp, target User, action, and the support case ID. Support staff cannot access PII silently.

The Ghost Admin does not have authority to adjudicate disputes between Users or to override automated decisions — those are governed by Sections 11.2 and 18 respectively. Support access is read-only for investigation purposes.

14.6. Breach notification

If a breach occurs that is likely to result in a risk to the rights and freedoms of natural persons, we will:

• Notify the supervisory authority within 72 hours (GDPR Article 33).
• Notify affected Users without undue delay where the risk is high (Article 34).

In notifications we explain what happened, what data was affected, what we're doing about it, and what you can do to protect yourself.

14.7. Your security responsibilities

• Use a unique, strong password.
• Enable two-factor authentication when offered.
• Protect devices that have access to your Account.
• Notify us immediately at security@velolog.io if you suspect compromise.

14.8. Security disclosure

If you believe you have found a security vulnerability, please report it confidentially to security@velolog.io. We commit to acknowledging reports within 5 working days. We do not pursue legal action against researchers acting in good faith under our security disclosure policy (velolog.io/security).

15. Changes to this Policy

15.1. We may update this Privacy Policy from time to time.

15.2. Material changes — for example, a new category of data, a new recipient, a new lawful basis — will be communicated to you at least

30 calendar days before they take effect, by email to the address linked to your Account and prominently on the Platform.

15.3. Non-material changes — typo fixes, clarifications, contact address updates — may be published without advance notice.

15.4. The version history of this Policy (current and past versions) is available at velolog.io/legal/privacy-history for full transparency.

15.5. If you don't agree with material changes, you have the right to delete your Account before they take effect (Section 7 of this Policy and §15.2 of our Terms describe what happens then).

16. How to contact us

Postal address: [Legal Entity Name] [Address line 1] [Address line 2] [City, Postcode] [Country]

Company registration number: [Number] VAT number: [Number] ICO / [national DPA] registration: [Number, if applicable]

Version 1.0 — drafted from research across reference platforms (carVertical, Bike Index, Vinted, Strava API, Booksy) with specific attention to GDPR Articles 6, 8, 11, 13, 14, 17, 22, 33, 34; ePrivacy Directive; Council Directive (EU) 2021/514 (DAC7); Strava API Agreement (November 2024); and the EU-US Data Privacy Framework. Last updated: [Date].

Internal notes for legal review (delete before publication)

This is a working draft. Send this to a qualified EU privacy lawyer before publishing — I am not a lawyer. Below are the specific areas where lawyer input is most important.

Cross-references that must remain in sync

This Privacy Policy is the paired companion to the Terms of Service. A change in one almost always requires a change in the other. Please keep these in sync:

Sections needing lawyer's specific review

1. §1.3 (Supervisory authority) — Depends on Member State of establishment. Replace placeholder with actual lead supervisory authority. If the Company is established in multiple Member States, the "main establishment" rule under Article 56 GDPR applies.

1. §5.2.1 (Permanent event log balancing) — This is the most novel and risky clause in the whole document. The balance between our legitimate interest in registry continuity and the right of erasure has not, to my knowledge, been litigated at this scale before. A lawyer needs to confirm the wording stands up to a CJEU-style balancing test, and the practical implementation (name → snapshot, not raw deletion) is consistent with what the Policy says.

1. §6.6 (DAC7) — The thresholds (30 transactions OR €2,000 revenue per year) are the EU minimums. Member States may set lower thresholds; please verify per country of operation. Also confirm that VeloLog meets the DAC7 definition of "Platform Operator" — we are not a payment-processing marketplace, which may put us outside the strict scope of DAC7 (only those that facilitate payment are caught). If we're outside scope, the §6.6 paragraph should be revised accordingly.

1. §7.1 (Retention periods) — These default to 7 years for billing (the longest common EU tax requirement). National tax law may require longer (10 years in Belgium and Germany for some categories). Adjust per Member State.

1. §8.7 (Stolen-bike data flow) — The "we provide ownership history, etc. on lawful written request" language needs a lawyer's review against the actual disclosure procedures we implement. The Policy commits us to specific behaviour that the engineering team must actually deliver.

1. §9 (International transfers) — The Stripe / Apple / Google / Cloudflare / Strava transfer arrangements rely on the EU-US Data Privacy Framework. As of 2026, the DPF remains in force but it is subject to ongoing legal challenges (Schrems III risk). A lawyer should confirm whether the current state of EU-US transfer law still supports the wording in §9.2.

1. §10.7 + §11 (Automated decisions) — Article 22 GDPR is the thorniest area. The current draft offers human review on request for each automated decision. A lawyer should confirm whether "available on request" is sufficient, or whether the regulators in our markets expect human review by default for some categories.

1. §13.1 (Age threshold) — Article 8 GDPR allows Member States to set the digital-consent age between 13 and 16. The current draft uses 18 as a more conservative figure, but lawyer should confirm this maps correctly to "Minor" status in each operating market.

1. §14.4 (Sentry PII scrubbing) — The Policy commits us to technical measures that engineering must actually enforce. Co-ordinate the legal text with the actual Sentry configuration so they match.

1. All functional email addresses — They must exist as monitored inboxes before launch. Especially dpo@velolog.io (statutory contact under Article 37 GDPR) and privacy@velolog.io (where most rights requests will arrive). A 4-week SLA for response is bare minimum; faster is better.

1. §1.4 + §8.4 (Controller vs processor) — The split between our role as controller (most flows) and processor (for some Business-User-customer data) needs a lawyer's confirmation. A joint-controller relationship (Article 26 GDPR) might arise for some Business User flows where we co-determine purposes — for example, the booking workflow. If so, a joint-controller agreement is required.

1. §3.1 (Email hashing with pepper) — The Policy commits us to "peppered HMAC" hashing. Engineering must implement this. The pepper must be stored separately from the database and rotated on a documented schedule. Document the implementation in the security policy referenced at velolog.io/security.

Comparison with reference platforms

The §7.2 treatment of the permanent event log is the single most novel clause, because no consumer-facing reference platform has the same "records survive ownership change" property combined with EU consumer rights. It deserves the most lawyer attention.